This disclosure relates generally to systems and/or methods for generating last-mile delivery routes from a depot.
E-Commerce has become an undivided part of our daily life. People nowadays can buy almost everything online and often demand the orders delivered as soon as possible or at a specific time window. In view of the volume of packages to be delivered, which can easily reach hundreds or thousands daily for each store or depot, systems and methods for automatically generating last-mile delivery routes can be desired. In addition, with the increased demand of same-day, 2-hour, or even 1-hour deliveries, it can be desirable that the systems and methods generate the last-mile delivery routes in a time efficient manner.
To facilitate further description of the embodiments, the following drawings are provided in which:
For simplicity and clarity of illustration, the drawing figures illustrate the general manner of construction, and descriptions and details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the present disclosure. Additionally, elements in the drawing figures are not necessarily drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of embodiments of the present disclosure. The same reference numerals in different figures denote the same elements.
The terms “first,” “second,” “third,” “fourth,” and the like in the description and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms “include,” and “have,” and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, device, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, system, article, device, or apparatus.
The terms “left,” “right,” “front,” “back,” “top,” “bottom,” “over,” “under,” and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the apparatus, methods, and/or articles of manufacture described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.
The terms “couple,” “coupled,” “couples,” “coupling,” and the like should be broadly understood and refer to connecting two or more elements mechanically and/or otherwise. Two or more electrical elements may be electrically coupled together, but not be mechanically or otherwise coupled together. Coupling may be for any length of time, e.g., permanent or semi-permanent or only for an instant. “Electrical coupling” and the like should be broadly understood and include electrical coupling of all types. The absence of the word “removably,” “removable,” and the like near the word “coupled,” and the like does not mean that the coupling, etc. in question is or is not removable.
As defined herein, two or more elements are “integral” if they are comprised of the same piece of material. As defined herein, two or more elements are “non-integral” if each is comprised of a different piece of material.
As defined herein, “approximately” can, in some embodiments, mean within plus or minus ten percent of the stated value. In other embodiments, “approximately” can mean within plus or minus five percent of the stated value. In further embodiments, “approximately” can mean within plus or minus three percent of the stated value. In yet other embodiments, “approximately” can mean within plus or minus one percent of the stated value.
As defined herein, “real-time” can, in some embodiments, be defined with respect to operations carried out as soon as practically possible upon occurrence of a triggering event. A triggering event can include receipt of data necessary to execute a task or to otherwise process information. Because of delays inherent in transmission and/or in computing speeds, the term “real-time” encompasses operations that occur in “near” real-time or somewhat delayed from a triggering event. In a number of embodiments, “real-time” can mean real-time less a time delay for processing (e.g., determining) and/or transmitting data. The particular time delay can vary depending on the type and/or amount of the data, the processing speeds of the hardware, the transmission capability of the communication hardware, the transmission distance, etc. However, in many embodiments, the time delay can be less than approximately one second, five seconds, ten seconds, thirty seconds, one minute, five minutes, ten minutes, or fifteen minutes.
Turning to the drawings,
Continuing with
As used herein, “processor” and/or “processing module” means any type of computational circuit, such as but not limited to a microprocessor, a microcontroller, a controller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a graphics processor, a digital signal processor, or any other type of processor or processing circuit capable of performing the desired functions. In some examples, the one or more processors of the various embodiments disclosed herein can comprise CPU 210.
In the depicted embodiment of
In some embodiments, network adapter 220 can comprise and/or be implemented as a WNIC (wireless network interface controller) card (not shown) plugged or coupled to an expansion port (not shown) in computer system 100 (
Although many other components of computer system 100 (
When computer system 100 in
Although computer system 100 is illustrated as a desktop computer in
Turning ahead in the drawings,
In a number of embodiments, operators and/or administrators (e.g., a user 361) of system 300 can manage system 300, the processor(s) of system 300, and/or the memory storage unit(s) of system 300 using the input device(s) and/or display device(s) of system 300, or portions thereof in each case.
In many embodiments, system 300 can include a system 310, an order system 320, a store system 330, a delivery dispatching system 340, and/or a user computer 360. System 310, order system 320, store system 330, delivery dispatching system 340, and/or user computer 360 can each be a computer system, such as computer system 100 (
Referring to
Meanwhile, in many embodiments, system 310, order system 320, store system 330, delivery dispatching system 340, and/or user computer 360 also can be configured to communicate with and/or include one or more databases (e.g., a database 311). The one or more databases can include a product database that contains information about products, items, or SKUs (stock keeping units), for example, among other data as described herein. The one or more databases also can include a store database that contains information about the locations of the stores, in-house delivery fleets for the stores, store hours, delivery driver shifts, or past deliveries by the in-house delivery fleets, etc. The one or more databases can be stored on one or more memory storage units (e.g., non-transitory computer readable media), which can be similar or identical to the one or more memory storage units (e.g., non-transitory computer readable media) described above with respect to computer system 100 (
The one or more databases can each include a structured (e.g., indexed) collection of data and can be managed by any suitable database management systems configured to define, create, query, organize, update, and manage database(s). Exemplary database management systems can include MySQL (Structured Query Language) Database, PostgreSQL Database, Microsoft SQL Server Database, Oracle Database, SAP (Systems, Applications, & Products) Database, and IBM DB2 Database.
Still referring to
In some embodiments, order system 320 can include store system 330. In several embodiments, each store system (e.g., 330) can be located in a different physical store. In some embodiments, a physical store can include a depot, warehouse, or fulfillment center that is not open to the public. In many embodiments, the physical stores each can be a brick-and-mortar store that is associated (e.g., operated by a common business entity or entities under common control) with order system 320. In a number of embodiments, a physical store can be a grocery store or a larger store (e.g., a super store) that include a grocery store or grocery department. In other embodiments, a physical store can be a department store or other retail store that does not sell groceries. In some embodiments, each store system (e.g., 330) can be in data communications with system 310 and/or delivery dispatching system 340 for scheduling and dispatching an in-house delivery driver or a third-party carrier driver to deliver packages from a depot or a physical store. In a few embodiments, store system 330 can include system 310 and/or delivery dispatching system 340.
In many embodiments, upon receiving an order with a delivery request from a customer, order system 320 can transmit a package delivery request for a package of the order (or multiple package delivery requests for multiple packages of the order) to system 310 for system 310 to assign a delivery route for the package. The package delivery request can comprise or be associated with a depot (e.g., a physical store) from which the package will be picked up by a delivery driver, a destination where the customer plans to receive the package, an arrival time window during which the package should be dropped off at the destination, the weight of the package, and/or the volume of the package, for example, among other things. In some embodiments, system 310, instead of order system 320, can determine the depot for the package delivery request based on the destination for the package.
In a number of embodiments, system 310 can be employed to automatically design delivery routes from a depot (e.g., a physical store) for multiple package delivery requests. The delivery routes can be generated for the multiple package delivery requests with arrival time windows in a certain period of time, such as an hour, a shift (e.g., morning, afternoon, or evening), or a day. In some embodiments, system 310 can sort the multiple package delivery requests in a descending order based on a respective degree of limitation for a first respective constraint (e.g., the length of the arrival time window) for each of the multiple package delivery requests. In several embodiments, system 310 further can generate one or more delivery routes originated from the depot based, at least in part, on the multiple package delivery requests, as sorted, and a respective destination distance for each pair of the multiple package delivery requests. In certain embodiments, once the delivery routes are determined, system 310 can generate one or more driving directions based on the one or more delivery routes. In a few embodiments, system 310 also can transmit the delivery routes and/or driving directions via the computer network to store system 330 and/or delivery dispatching system 340 to match delivery drivers with the delivery routes.
Turning ahead in the drawings,
In many embodiments, system 300 (
In some embodiments, method 400 and blocks in method 400 can include using a distributed network including distributed memory architecture to perform the associated activity. This distributed architecture can reduce the impact on the network and system resources to reduce congestion in bottlenecks while still allowing data to be accessible from a central location.
Referring to
In a number of embodiments, method 400 further can include a block 420 of generating one or more delivery routes originated from a depot based, at least in part, on the multiple package delivery requests, as sorted, and a respective destination distance for each pair of the multiple package delivery requests. In many embodiments, block 420 can generate the delivery routes further based on other constraints. For example, in some embodiments, block 420 can take into consideration one or more respective second constraints (or route constraints) for each of the delivery routes, such as a respective between-stops idle time constraint, a respective volume constraint, a respective weight constraint, and/or a respective driver shift constraint, among other things.
In a number of embodiments, in the process of generating the delivery routes, block 420 also can consider the first respective constraint for each of one or more already-scheduled package delivery requests for the each of the delivery routes so that adding a package delivery request to a delivery route that includes at least one already-scheduled package delivery request would not result in any conflicts. Conflicts can exist when the delivery route with the package delivery request added can no longer satisfy all of the constraints, including: (a) the respective constraints for each of the package delivery request and the already-scheduled package delivery request, and (b) the respective second constraints (i.e., the route constraints) for the delivery route, etc. In many embodiments, the respective second constraints for a delivery route further can include the first respective constraint and/or other respective constraint(s) for each of the already-scheduled package delivery request(s) of the delivery route.
Moreover, in some embodiments where not all delivery vehicles are the same, block 420 further can generate the delivery routes by assigning a respective delivery vehicle to each of the one or more delivery routes based, at least in part, on a respective cost for the respective delivery vehicle. For example, block 420 can assign the most cost-efficient delivery vehicle in terms of gas mileage to the first delivery route, the potentially longest delivery route, or a delivery route to the farthest destination.
Still referring to
In a number of embodiments, block 420 further can include a block 422 of sorting one or more remaining unscheduled package delivery requests of the one or more unscheduled package delivery requests in an ascending order based on a respective destination distance between the first candidate and each of the one or more remaining unscheduled package delivery requests. In some embodiments, block 422 further can include one or more exception detecting steps, such as before sorting the one or more remaining unscheduled package delivery requests, checking if the available delivery route is still available.
In a number of embodiments, block 420 additionally can include a block 423 of assigning one or more second candidates of the one or more remaining unscheduled package delivery requests of the one or more unscheduled package delivery requests, as sorted based on the respective destination distance, to the available delivery route. In some embodiments, block 423 further can include before assigning each of the one or more second candidates to the available delivery route, determining that no conflicts exist between the each of the one or more second candidates and one or more route constraints for the available delivery route. In certain embodiments, block 423 also can include determining an optimal stop sequence for the already-scheduled package delivery request(s) in the available delivery route, including the first candidate, and the one or more second candidates inserted into the available delivery route. The criteria for the optimal stop sequence can include for example, the total mileage, the total delivery time, the between-stops idle time, the dead mileage, and/or the costs for the available delivery route, which can the wage for the delivery driver, the cost for fuel, and/or the costs associated with the delivery vehicle, etc., among other things. In certain embodiments, block 423 can determine the optimal stop sequence by applying any suitable stop-sequence-optimizing algorithm(s), such as greedy algorithm, based at least in part on the respective costs for the available delivery route.
In many embodiments, after the one or more second candidates are successfully inserted into the available delivery route, the one or more second candidates can be removed from the one or more unscheduled package delivery requests. In some embodiments, after assigning the one or more second candidates to the available delivery route in block 423, when (a) the available delivery route is full or none of the one or more remaining unscheduled package delivery requests can be inserted into the available delivery route, and (b) the one or more remaining unscheduled package delivery requests are not empty, block 420 can continue at block 421 for a next available delivery route.
Still referring to
Turning ahead in the drawings,
In many embodiments, system 300 (
In some embodiments, method 500 and activities/steps in method 500 can include using a distributed network including distributed memory architecture to perform the associated activity. This distributed architecture can reduce the impact on the network and system resources to reduce congestion in bottlenecks while still allowing data to be accessible from a central location.
Referring to
In a number of embodiments, method 500 further can include a step 520 for generating one or more delivery routes originated from a depot based, at least in part, on the package delivery requests, as sorted in step 510, a respective destination distance for each pair of the package delivery requests, and/or a respective cost for each of the one or more delivery routes. In many embodiments, step 520 can be similar or identical to block 420 (
In some embodiments, step 520 also can include a step 521 for assigning a first candidate (e.g., A) of one or more unscheduled package delivery requests (e.g., the package delivery request(s) not in booked) of the multiple package delivery requests, as sorted, to an available delivery route of the one or more delivery routes. In many embodiments, step 521 can be similar or identical to block 421 (
In a number of embodiments, step 520 further can include a step 522 for sorting one or more remaining unscheduled package delivery requests (e.g., B) of the one or more unscheduled package delivery requests in an ascending order based on a respective destination distance between the first candidate (e.g., A) and each of the one or more remaining unscheduled package delivery requests (e.g., B). In many embodiments, step 522 can be similar or identical to block 422 (
In a number of embodiments, step 520 additionally can include a step 523 for assigning one or more second candidates of the one or more remaining unscheduled package delivery requests, as sorted, to the available delivery route by determining that no conflicts exist at least between the one or more second candidates and one or more route constraints for the available delivery route. In many embodiments, step 523 can be similar or identical to block 423 (
Further, in some embodiments, step 523 can determine an optimal stop sequence for the packages assigned to the available delivery route, including A and B, by finding the best position for inserting the second candidate B into the already-scheduled package(s) in the available delivery route. In many embodiments, the best position for the to-be-assigned second candidate B is the position that would result in the lowest delivery cost for the available delivery route. In similar or different embodiments, the best position can be determined based at least in part on one or more of: the overall costs, the overall delivery time, or the total idle time, etc.
In a number of embodiments, method 500 also can include a step 530 for returning the delivery routes generated in steps 510 and 520 to the depot (e.g., store system 330 (
Turning ahead in the drawings,
Referring to
In many embodiments, method 600 can include a step (not shown in the drawings) that is similar or identical to block 410 (
P={D1, D2, D3, D4, D5, D6, D7, D8, D9}.
After sorting in the step, in some embodiments, the multiple package delivery requests (P) can become {D2, D4, D1, D3, D5, D6, D7, D8, D9}.
In some embodiments, method 600 further can include a step in
In the embodiment in
P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
Pu=P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
C1=D2; and
Ra=R1={ }.
After C1 is assigned to the then empty available delivery route Ra, in the step in
P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
Pu={D4, D1, D3, D5, D6, D7, D8, D9};
C1=D2; and
Ra=R1={D2}.
Additionally, in many embodiments, with the first candidate assigned to the available delivery route in the step in
In a number of embodiments, method 600 further can include a step (not shown in the drawings) that is similar or identical to block 422 (
P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
Pu={D4, D1, D3, D5, D6, D7, D8, D9};
Pr={D4, D3, D6, D5, D1, D7, D8, D9};
C1=D2; and
Ra=R1={D2}.
In a number of embodiments, method 600 further can include a step in
In the exemplary embodiment, the step in
Next, when C2-2 (i.e., D3) is temporarily assigned to the available delivery route Ra, the step in
P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
Pu={D4, D1, D5, D6, D7, D8, D9};
Pr={D4, D6, D5, D1, D7, D8, D9};
C1=D2; and
Ra=R1={D2, D3}.
In many embodiments, the step in
Back to the step in
P={D2, D4, D1, D3, D5, D6, D7, D8, D9};
Pu={D1, D5, D6, D7, D8, D9};
Pr=Pu={D1, D5, D6, D7, D8, D9};
R1={D3, D2};
C1=D4; and
Ra=R2={D4}.
From here, in many embodiments, the step in
Finally, in a number of embodiments, method 600 also can include another step (not shown in the drawings) that is similar or identical to block 430 (
In many embodiments, the techniques described herein can provide a practical application and several technological improvements. In some embodiments, the techniques described herein can provide for automatically generating and optimizing delivery routes while taking into consideration the various constraints of the packages and/or delivery vehicles (including the constraints for the delivery drivers and/or store policies). These techniques described herein can provide a significant improvement over conventional approaches of assuming that all packages are equal.
In many embodiments, the techniques described herein can provide several technological improvements. In some embodiments, the techniques described herein can provide a system and/or a method for generating and optimizing delivery routes for package delivery requests from a depot in an easier and more efficient way, compared to other known systems/methods, such as shortest path algorithms, stimulated annealing, large neighborhood search, etc. In a number of embodiments, the system/method can significantly reduce the complexity of the system/method by starting with assigning the delivery routes for the packages with the most limiting constraint(s) (e.g., the packages with the shortest respective arrival time periods). For example, in some embodiments, the system/method can result in at least 9% or up to 30% reduction in computing time, without sacrificing (sometime even with improvement in) the average cost and/or miles per order.
In many embodiments, the techniques described herein can be used continuously at a scale that cannot be handled using manual techniques. For example, the number of packages to be delivered from a depot can be over thousands per day, and the delivery routes, as well as loads/capacities, for delivery vehicles that comply with all the constraints in time and/or load capacity can be generated in real-time or near-real-time, such as less than 10-30 minutes, or any time period between a delivery cutoff time and a time for the preparation of the next pickup time.
In a number of embodiments, the techniques described herein can solve a technical problem that arises only within the realm of computer networks, as online ordering do not exist outside the realm of computer networks. Moreover, the techniques described herein can solve a technical problem that cannot be solved outside the context of computer networks. Specifically, the techniques described herein cannot be used outside the context of computer networks, in view of a lack of data.
Various embodiments can include a system including one or more processors and one or more non-transitory computer-readable media storing computing instructions configured to run on the one more processors and perform certain acts. The acts can include sorting multiple package delivery requests in a descending order based on a respective degree of limitation for a first respective constraint for each of the multiple package delivery requests. In many embodiments, each of the multiple package delivery requests can comprise the first respective constraint and a respective destination. The acts further can include generating one or more delivery routes originated from a depot based, at least in part, on the multiple package delivery requests, as sorted, and a respective destination distance for each pair of the multiple package delivery requests. The acts also can include generating one or more driving directions based on the one or more delivery routes.
In many embodiments, the first respective constraint for each of the package delivery requests can comprise a length of a respective arrival time window for the each of the multiple package delivery requests. In a number of embodiments, each of the one or more delivery routes can be associated with one or more respective second constraints. In several embodiments, the one or more respective second constraints for each of the delivery routes further can comprise at least one or more of: (a) a respective between-stops idle time constraint; (b) a respective volume constraint; (c) a respective weight constraint; (d) a respective driver shift constraint; and/or (e) the first respective constraint for each of one or more already-scheduled package delivery requests for the each of the delivery routes. In some embodiments, the multiple package delivery requests can comprise the one or more already-scheduled package delivery requests for the each of the delivery routes. In a number of embodiments, generating the one or more delivery routes further can comprise assigning a respective delivery vehicle to each of the one or more delivery routes based, at least in part, on a respective cost for the respective delivery vehicle.
In many embodiments, generating the one or more delivery routes further can comprises: (a) assigning a first candidate of one or more unscheduled package delivery requests of the multiple package delivery requests, as sorted, to an available delivery route of the one or more delivery routes; (b) sorting one or more remaining unscheduled package delivery requests of the one or more unscheduled package delivery requests in an ascending order based on a respective destination distance between the first candidate and each of the one or more remaining unscheduled package delivery requests; and/or (c) assigning one or more second candidates of the one or more remaining unscheduled package delivery requests, as sorted, to the available delivery route by determining that no conflicts exist between the one or more second candidates and one or more route constraints for the available delivery route. In certain embodiments, assigning the first candidate to the available delivery route further can comprise determining that no conflicts exist at least between the first candidate and the one or more route constraints for the available delivery route.
In a number of embodiments, after assigning the first candidate to the available delivery route, the one or more route constraints for the available delivery route further can comprise the first respective constraint for the first candidate. In some embodiments, determining the one or more second candidates for the available delivery route further can comprise determining an optimal stop sequence for the one or more second candidates and the already-scheduled package delivery requests (including at least the first candidate) in the available delivery route. In certain embodiments, determining the optimal stop sequence further can comprise applying a greedy algorithm.
A number of embodiments can include a method being implemented via execution of computing instructions configured to run at one or more processors and stored at one or more non-transitory computer-readable media. The method can include sorting multiple package delivery requests in a descending order based on a respective degree of limitation for a first respective constraint for each of the multiple package delivery requests, which can comprise the first respective constraint and a respective destination. The method also can include generating one or more delivery routes originated from a depot based, at least in part, on the multiple package delivery requests, as sorted, and a respective destination distance for each pair of the multiple package delivery requests. The method additionally can include generating one or more driving directions based on the one or more delivery routes. In some embodiments, the method additionally can include one or more procedures, processes, and/or activities of method 400 (
The foregoing is provided for purposes of illustrating, explaining, and describing embodiments of these disclosures. Modifications and adaptations to these embodiments will be apparent to those skilled in the art and may be made without departing from the scope or spirit of these disclosures.
Although generating one or more delivery routes for multiple package delivery requests has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes may be made without departing from the spirit or scope of the disclosure. Accordingly, the disclosure of embodiments is intended to be illustrative of the scope of the disclosure and is not intended to be limiting. It is intended that the scope of the disclosure shall be limited only to the extent required by the appended claims. For example, to one of ordinary skill in the art, it will be readily apparent that any element of
Replacement of one or more claimed elements constitutes reconstruction and not repair. Additionally, benefits, other advantages, and solutions to problems have been described with regard to specific embodiments. The benefits, advantages, solutions to problems, and any element or elements that may cause any benefit, advantage, or solution to occur or become more pronounced, however, are not to be construed as critical, required, or essential features or elements of any or all of the claims, unless such benefits, advantages, solutions, or elements are stated in such claim.
Moreover, embodiments and limitations disclosed herein are not dedicated to the public under the doctrine of dedication if the embodiments and/or limitations: (1) are not expressly claimed in the claims; and (2) are or are potentially equivalents of express elements and/or limitations in the claims under the doctrine of equivalents.