Effective and Efficient: Large-Scale Dynamic City Express

Effective and Efficient: Large-Scale Dynamic City Express
Siyuan Zhang, Lu Qin, Yu Zheng, Senior Member, IEEE, and Hong Cheng Presentation by: Ziqi Lin | Tyler Pietri | Dennis Silva

Overview Starting Questions Background, Motivation, Problem
Presentation Cliffnotes Proposed Methodology Evaluation & Results Applications & Future Work Cost is a measure of time

Starting Questions Have you purchased physical products from the internet? Where do you purchase them from? How often do you purchase? How do you receive or pick up the product?

Background Problem & Motivation
Cost is a measure of time

Background - Evolution of Retail Logistics
Direct Replenishment (1970s) Domestic sourcing Supplied customers directly Rationalization (1980s) Retail chains create distribution centers Became sorting facilities between suppliers and several regional stores Global Sourcing (1990s) Outsourcing and offshoring expanded Import centers unpack containers and arrange shipments for distribution E-Commerce (2000s) Web based sales become the norm Logistics from local depots to final destinations are commonly called “last mile logistics.” [1]

Background - Evolution of Retail Logistics
Direct Replenishment (1970s) Domestic sourcing Supplied customers directly Rationalization (1980s) Retail chains create distribution centers Became sorting facilities between suppliers and several regional stores Global Sourcing (1990s) Outsourcing and offshoring expanded Import centers unpack containers and arrange shipments for distribution E-Commerce (2000s) Web based sales become the norm Logistics from local depots to final destinations are commonly called “last mile logistics.” Make sure to note that within the last mile logistics, the visual does not include the pickup of packages to then send out. So there should be arrows in both directions in this case. [1]

Background - City Express Services - Logistics
A city is divided into several regions (R_1 & R_2) A city is divided into several regions (e.g., R1 and R2), each of which covers some streets and neighborhoods.

A transit station is built in a region to temporarily store parcels received in the region (t_S1 & t_S2) A transit station is built in a region to temporarily store the parcels received in the region (e.g., ts1 in R1). The received parcels in a transit station are further organized into groups according to their destinations.

Each group of parcels is sent to a corresponding transit station by trucks regularly Each group of parcels will be sent to a corresponding transit station by trucks regularly (e.g., from ts1 to ts2).

Couriers deliver and receive parcels from specific locations in the region using precomputed delivery routes. In each region, there are a team of couriers delivering parcels to and receiving parcels from specific locations in the region. When a truck carrying parcels arrives at a transit station, each courier will send a portion of these parcels to their final destinations by a small delivery van, or a bike, or a motorcycle, which has a limited capacity. Before departing from the transit station, they will pre-compute the delivery routes (e.g., the blue lines in Fig. 1) usually based on their own knowledge.

During a delivery, a courier can receive pickup requests. Accepting or declining the request is up to the courier’s judgement. (r_5) During the delivery, each courier could receive pickup requests (e.g., r5, r6 and r7) from a central dispatch system or directly from end users. Each pickup request is associated with a location and a deadline of pickup time. A courier may change the originally planned route to fetch the new parcels, or decline the pickup request due to the constraints in their schedule or their vehicle capacity. All the couriers are required to return to their own transit station by some specific time (so as to fit the schedule of trucks that travel between transit stations regularly), or when fully loaded.

During a delivery, a courier can receive pickup requests. Accepting or declining the request is up to the courier’s judgement. (r_7) During the delivery, each courier could receive pickup requests (e.g., r5, r6 and r7) from a central dispatch system or directly from end users. Each pickup request is associated with a location and a deadline of pickup time. A courier may change the originally planned route to fetch the new parcels, or decline the pickup request due to the constraints in their schedule or their vehicle capacity. All the couriers are required to return to their own transit station by some specific time (so as to fit the schedule of trucks that travel between transit stations regularly), or when fully loaded.

Background - City Express Services - Problems
Current Process = Unsatisfactory Pickup requests processed individually Courier status unknown Requests near regions boundaries ignored The service quality and operational efficiency of current express services have never been found satisfactory due to the following three reasons. First, current central dispatch systems process each pickup request individually without a global optimization. For example, a new pickup request (e.g., r5) is usually assigned to the nearest courier (e.g., c1) to the pickup location. In the meantime, each courier makes a decision on whether to pick up a new parcel solely based on his own situation without knowing the status of other couriers in the same region (e.g., c3 can pick up a parcel at r5 instead of c1). Second, the dispatch systems do not know the current status of a courier either, e.g., the remaining capacity, the number of parcels that have not been delivered, and the following pickup-delivery route, before assigning a new pickup request. Note that these statuses would change dynamically due to the new pickup requests. Third, requests near the boundary of a region (e.g., r7) are ignored by couriers (e.g., c1) in other regions because couriers only pick up parcels in their own regions.

Motivation for a Solution
Increase operational efficiency Increase customer satisfaction Increase profit

Problem Construct an effective scheduling algorithm for couriers to deliver and pick up parcels in real time. Central Dispatch System Message Courier Data Schedule study the dynamic city express problem and aim to design a central dispatch system with an effective scheduling algorithm for couriers to deliver and pick up parcels in real time. Each courier in the system carries a handheld device recording his location, uploading his status when he finishes a delivery or pickup task, and receiving new pickup requests. The central dispatch system receives information of couriers from their handheld devices and manages their schedules consisting of pickup and delivery time and routes. After collecting pickup requests from customers in a short period, the system processes the requests in a batch according to the minimum incurred distance. Finally, the system sends the updated schedules to all the couriers and the confirmation or decline messages to the customers. Processed by scheduling algorithm

Presentation cliffnotes

ALL Terminology KEY Terminology
C = courier R = task S = schedule of tasks (R) L = location of task D = deadline to complete tasks

Function example : Courier Schedule (s)
Cost(S) = Sum of all [time to travel to between tasks + (time to service * tasks)] Cost is a measure of time

Cost(S) = Sum of all [time to travel to between tasks + (time to service * tasks)] Ordered Segment Cost is a measure of time. Rij = subsequent trip j+1 = proceeding trip When we insert we insert it between the these thing

New Task (r) Cost(S) = Sum of all [time to travel to between tasks + (time to service * tasks)] Ordered Segment Cost is a measure of time. Rij = subsequent trip j+1 = proceeding trip When we insert we insert it between the these thing

Proposed Method Cost is a measure of time

Proposed Solution Overview
Batch pick up requests Identify candidates Shortest path calculation Two level request priority queue Bb

Methodology Components
Network Indexing

Indexing: Network Voronoi Diagram (NVD)
NVD partitions G into a set of Voronoi regions - each is represented by a generator Handling Boundary Regions If edge exists in 2 different Voronoi regions → Split it into 2 Compute cost between node and the generator; cost between 2 generators ts1 ts2 In order to compute the candidate couriers to serve a pickup request and avoid unnecessary shortest path computations

Indexing: Network Voronoi Diagram (NVD)
Compute cost between node and the generator; cost between 2 generators Given any l in G, suppose l lies on the edge, the distance from l to ts(l): ts1 ts2 In order to compute the candidate couriers to serve a pickup request and avoid unnecessary shortest path computations

Indexing: NVD example The lower bound cost between two points:
Max(0, (travel time b/t task stations) - (travel time b/t station and task1) - (travel time b/t station and task2) NVD index for a road network G with three transit stations ts0; ts1 and ts2 as generators. Accordingly, G is partitioned into three regions by the bold lines. Roads in different Voronoi regions are depicted in different line styles. The distance matrix for generators is shown in Fig. 2b

Network Indexing Candidate Courier Generation & Pruning

Candidate Courier Generation
A new request: r => A set of couriers that can possibly arrive at l(r) before deadline d(r) Using the NVD index, we can identify the candidate couriers Prune candidates using Incurred distance calculation

Candidate Pruning: Incurred Distance Calculation
Ex: S = (Rij, R, Ri,j+1) Two criteria for inserting R: New tasks ( R) can be serviced before it’s deadline ( D) (Arrival time of R service time + (travel from task Rij to Rij+1) < Deadline of R Shove red thing in the middle is OK???

Ex: S = (Rij, R, Ri,j+1) Two criteria for inserting R: 2. All pre-existing tasks ( Rij and Rij+1) are unaffected d= latest possible arrival time

Ex: S = (Rij, R, Ri,j+1) dist = latest possible time a courier can arrive at Rij and still meet deadlines Δdist = ( (travel b/t Rij & R) (travel b/t R & Rij+1) (travel between Rij to Rij+1) ) Add the new task to the courier with Min( Δdist)

Network Indexing Candidate Courier Generation & Pruning Lazy Path Computation

Lazy Path Computation - Lower Bound of Incurred Distance
Ex: S = (Rij, R, Ri,j+1) Δdist calculation is computationally expensive Reduce processing time by computing lower bound Δdist_j If Δdist_j is too large we don’t consider it, this prunes the search space If delta d = large. Servicing the request R is too much = small. Good!!

Network Indexing Candidate Courier Generation & Pruning Lazy Path Computation BestR Algorithm - Priority Queue

BestR Algorithm & Priority Queue
Initialize an empty queue

Initialize an empty queue Compute all lower bound costs

Initialize an empty queue Compute all lower bound costs Check if each lower bound is valid, if so add to queue

Initialize an empty queue Compute all lower bound costs Check if each lower bound is valid, if so add to queue Pop queue and check if actual distance was calculated, if so return that courier and segment

Initialize an empty queue Compute all lower bound costs Check if each lower bound is valid, if so add to queue Pop queue and check if actual distance was calculated, if so return that courier and segment If lower bound was used, compute costs

Initialize an empty queue Compute all lower bound costs Check if each lower bound is valid, if so add to queue Pop queue and check if actual distance was calculated, if so return that courier and segment If lower bound was used, compute costs Check if, with actual distance, entry is valid. If so, push back onto queue

Initialize an empty queue Compute all lower bound costs Check if each lower bound is valid, if so add to queue Pop queue and check if actual distance was calculated, if so return that courier and segment If lower bound was used, compute costs Check if, with actual distance, entry is valid. If so, push back onto queue If no courier is found, return that request cannot be satisfied

Network Indexing Candidate Courier Generation & Pruning Lazy Path Computation BestR Algorithm - Priority Queue Batch Assignment Basic Algorithm

Batch Assignment - Basic Algorithm
Compute the time and the latest time to arrive in schedule for each courier. And update courier locations as new request comes in.

Compute the time and the latest time to arrive in schedule for each courier. And update courier locations as new request comes in. Compute candidate couriers for a request, and use BestR to find best courier. If none exists, the request is declined.

Compute the time and the latest time to arrive in schedule for each courier. And update courier locations as new request comes in. Compute candidate couriers for a request, and use BestR to find best courier. If none exists, the request is declined. Updating the schedule set via inserting new request

Effectiveness: Batch Assignment
Time: 46min Example of Basic Algorithm (first-come, first-served): Consider r3, but it does not satisfy (if travel to r3 -> miss the latest time to r2) Consider r4, it works. However, r5 and r6 are not available (large distance of r4 to r5 and r6) Improvement?

Effectiveness: Batch Assignment
Time: 46min Time: 44min Example of Basic Algorithm (first-come, first-served): Consider r3, but it does not satisfy (if travel to r3 -> miss the latest time to r2) Consider r4, it works. However, r5 and r6 are not available (large distance of r4 to r5 and r6) Improvement? Using incurred distance as the first priority.

Network Indexing Candidate Courier Generation & Pruning Lazy Path Computation BestR Algorithm - Priority Queue Batch Assignment Basic Algorithm SIDF (shortest incurred distance first)

SIDF Accepts task requests
Identify candidate couriers for each request Creates a set of potential request for each candidate Prioritized by min(Δdist) i.e. Δdist_j Formally assigns to a schedule Update priority of potential request set Terminates Why would you want to update remaining potenial requestst

SIDF - Shortest Incurred Distance First
For each courier, compute the time & latest time to arrive at new location The Basic solution (Algorithm 2) adopts a first-come, firstserved strategy in which early requests have high priority to be assigned. However, using request arrival time as the first priority may result in inferior scheduling result. SDIF

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests The Basic solution (Algorithm 2) adopts a first-come, firstserved strategy in which early requests have high priority to be assigned. However, using request arrival time as the first priority may result in inferior scheduling result. SDIF

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests Compute candidate couriers for each new request and then the candidate requests (where each courier can reach before their deadlines) Candidate Computation. The procedure ComputeCand to compute the candidates is shown in lines 8-13 of Algorithm 3. We first compute the candidates candðrÞ for each request r 2 R (lines 10-11) using the same method in Algorithm 2. Then we compute the candidate set candðciÞ, which is a set of requests that courier ci can reach before their deadlines, for each ci 2 C. candðciÞ can be considered as an inverse set of candðrÞ, thus, for each ci 2 candðrÞ, we simply add r into candðciÞ (lines 12-13).

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests Compute candidate couriers for each new request and then the candidate requests (where each courier can reach before their deadlines) Initialize global priority queue (maintains priorities of all requests) Candidate Computation. The procedure ComputeCand to compute the candidates is shown in lines 8-13 of Algorithm 3. We first compute the candidates candðrÞ for each request r 2 R (lines 10-11) using the same method in Algorithm 2. Then we compute the candidate set candðciÞ, which is a set of requests that courier ci can reach before their deadlines, for each ci 2 C. candðciÞ can be considered as an inverse set of candðrÞ, thus, for each ci 2 candðrÞ, we simply add r into candðciÞ (lines 12-13).

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests Compute candidate couriers for each new request and then the candidate requests (where each courier can reach before their deadlines) Initialize global priority queue (maintains priorities of all requests) The best courier for each request (by BestR) is pushed into the priority queue with minimum distance priority Candidate Computation. The procedure ComputeCand to compute the candidates is shown in lines 8-13 of Algorithm 3. We first compute the candidates candðrÞ for each request r 2 R (lines 10-11) using the same method in Algorithm 2. Then we compute the candidate set candðciÞ, which is a set of requests that courier ci can reach before their deadlines, for each ci 2 C. candðciÞ can be considered as an inverse set of candðrÞ, thus, for each ci 2 candðrÞ, we simply add r into candðciÞ (lines 12-13).

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests Compute candidate couriers for each new request and then the candidate requests (where each courier can reach before their deadlines) Initialize global priority queue (maintains priorities of all requests) The best courier for each request (by BestR) is pushed into the priority queue with minimum distance priority In order of minimum distance, assign a request to best courier and remove request from new requests Candidate Computation. The procedure ComputeCand to compute the candidates is shown in lines 8-13 of Algorithm 3. We first compute the candidates candðrÞ for each request r 2 R (lines 10-11) using the same method in Algorithm 2. Then we compute the candidate set candðciÞ, which is a set of requests that courier ci can reach before their deadlines, for each ci 2 C. candðciÞ can be considered as an inverse set of candðrÞ, thus, for each ci 2 candðrÞ, we simply add r into candðciÞ (lines 12-13).

For each courier, compute the time & latest time to arrive at new location Each time interval, update courier locations and save new requests Compute candidate couriers for each new request and then the candidate requests (where each courier can reach before their deadlines) Initialize global priority queue (maintains priorities of all requests) The best courier for each request (by BestR) is pushed into the priority queue with minimum distance priority In order of minimum distance, assign a request to best courier and remove request from new requests Each remaining candidate request that that courier can serve needs to be updated. If this updated priority is still valid, insert the request back into the global queue

Network Indexing Candidate Courier Generation & Pruning Lazy Path Computation BestR Algorithm - Priority Queue Batch Assignment Basic Algorithm SIDF (shortest incurred distance first) Two-level Priority Queue Structure SIDF (shortest incurred distance first) vs SIDF*

SIDF vs SIDF* SIDF computationally expensive SIDF*
Update priority of all potential request sets Calculates all incurred distances SIDF* Same as SIDF Key differences Limits which couriers are affected by updates Two level priority queue Why would you want to update remaining potenial requestst

Two-level priority structure

Global list (H) sources from local lists (Hi . . . Hn)

Formally assign task to courier 1

Delete task for courier 1’s set of potential requests

Update Courier 1’s Actual Schedule

Lazily delete the task from any other couriers that had it

Evaluation & Results Cost is a measure of time

Evaluation Dataset Dataset Assumptions Bejing road network (15x5 Km)
8.8K nodes & 11.3K edges Tested methodology on a generated data set Assumptions Requests from everywhere 5400 requests/hour

Evaluation Results: Effectiveness
Satisfaction Rate Avg. Incurred Distance (cost to service) Tested with against different models with different parameters for couriers, confirmation time, speed Nearest = assign to whatever is closest

Evaluation Results: Effectiveness vs. Varying Couriers
SIDF* = less staff for same amount of work

Evaluation Results: Effectiveness vs. Varying Confirmation Time
Nearest/Basic are independent of SR

Evaluation Results: Effectiveness vs
Evaluation Results: Effectiveness vs. Varying Courier Speed (cost to travel b/t tasks)

Evaluation Results: Effectiveness vs. Scalibility

Evaluation Results: Efficiency vs. Varying Couriers

Evaluation Results: Efficiency vs. Varying Confirmation Time

Evaluation Results: Efficiency vs. Varying Confirmation Time
Evaluates two-level priority structure (SIDF*) vs. not having it (SIDF)

Evaluation Results: Efficiency vs. Varying Request Amounts
Exhaustive Search doesn’t scale! EXACT = exhaistove seat

Exact algorithm don’t scale!

Evaluation Results: Effectiveness & Efficiency
How can we expand on the testing methodologies? How would taking courier capacity in account change the results?

Applications & Future Work

Potential Applications & Future Work
Mail services TaskRabbit PostMates Future Work Take courier capacity into account

References & Images References Images
[1] "Evolution of Retail Logistics." THE GEOGRAPHY OF TRANSPORT SYSTEMS. N.p., n.d. Web. 13 Feb < Images Home depot Walmart Sephora Apple Macys Ebay Jcrew Amazon NYC Region

Effective and Efficient: Large-Scale Dynamic City Express

Similar presentations

Presentation on theme: "Effective and Efficient: Large-Scale Dynamic City Express"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Effective and Efficient: Large-Scale Dynamic City Express

Similar presentations

Presentation on theme: "Effective and Efficient: Large-Scale Dynamic City Express"— Presentation transcript:

Similar presentations

About project

Feedback