Patent Application
20200097907
A company may receive multiple requests, such as a batch ordering of goods or services, periodically (e.g., every day). Each request may have a different characteristics, such as an origin, a destination, a pick-up time, a price, and some request specific requirements (e.g., a type of vehicle). The company needs to fulfill the requests and meet the requirements. The company would also like to optimize the fulfillment of the requests and minimize cost. However, due to the different combinations of requests and requirements, the optimization may be very complex.
In one example, if the requests are in the delivery space, the company may need to take into account many variables, such as the number of vehicles to use, the transportation route, and the timetable for each vehicle. Also, the pick-up time and duration of each request may be different and the company may want to optimize the timetable and route for each vehicle. However, the company would like to minimize the number of vehicles to minimize the cost. The company also has to consider the specific requirements, such as vehicle types, and different vehicle types may have different costs. Further, other restrictions may be imposed, such as a maximum waiting time for vehicles when servicing multiple requests.
The analysis of the above variables to optimize the routes takes a large amount of computing resources and time. As the number of requests increases, the time to optimize the routes also increases. Due to the real-time nature of fulfilling the requests, the time and computing resources taken to optimize the routes needs to be efficient. However, due to the complexity of the analysis, a company's route optimization may not meet the time requirements and the company may generate inefficient routes.
Described herein are techniques for a batch request processing system. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of some embodiments. Some embodiments as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
Some embodiments optimize a number of batch requests. For example, the requests may be serviced by a provider, such as the request may be orders for goods or services, but other requests can be optimized. As used herein, the term request and order may be used interchangeably. The requests may include characteristics, such as an origin, a destination, a time-dependency, an order, and a cost of the request. Additionally, some requests may have special requirements, such as delivery special requests. A system considers the origin and destination for each request in addition to a time dependency (e.g., the duration needed to fulfill the request). Also, the system determines a profit for the request based on the cost of the request and revenue received. Then, the system generates a plurality of lines from the request where each line includes a duration from the time dependency, the origin, the destination, and a profit for the request. Each line may refer to one of the requests.
The system then generates a plurality of paths that include a set of lines. Each path may include an identification of the lines in the path, a set of requests, and a weight based on the profit of the set of requests. For example, a path may include multiple lines that fulfill multiple requests of goods or services. The paths identify different combinations of lines that meet a restriction, such as a maximum wait time between requests. Then, some embodiments select a minimum number of paths from the plurality of paths using an optimization that considers the weight of each path.
The use of the paths to optimize the batch of requests reduces the amount of computing resources that are used in addition to increasing the speed of optimization. The paths group lines together and the system considered a fewer number of possible combinations because there are a fewer number of paths to consider compared to the number of lines. By decomposing the complex problem into three phases: a line generator, a path generator, and a delivery optimizer, some embodiments simply the optimization of the delivery optimizer, such as the optimization can be limited to a controlled space and also weights can be applied to the paths. The use of the paths allows a company to process the batch requests faster and more efficiently. Additionally, the optimization allows the company to generate schedules in real-time as requests are received.
System Overview
Fulfillment processors 104 may be entities that fulfill the requests. For example, if the requests are orders for goods transportation, then fulfillment processors 104 may be vehicles that can fulfill the requests. A vehicle may pick up a request at a first location and transport the request to a second location. However, although vehicles may be discussed, fulfillment processors 104 may be other entities, such as messengers.
Server system 102 may receive the requests from requesters 106, optimize the requests via a batch request optimization, and then output the schedule to fulfillment processors 104. The schedule may direct fulfillment processors 104 to fulfill the requests based on the optimization.
A request optimizer 108 optimizes a batch of requests. A database 110 may store information that is used by request processor 108 to optimize the requests. For example, a request may include a request identifier (ID), a pick-up time, time duration, and a price. Request optimizer 108 outputs a schedule that includes a timetable and routes that are used to process the requests. In request optimizer, a line generator 112 receives the requests and can generate a number of lines that are possible from the requests. A line may be associated with a single request and may include duration, an origin and a destination, and a profit-per-unit. Line generator 112 calculates the profit-per-unit based on the price of the request compared to the cost to the company to process the request.
Then, a path generator 114 generates all possible paths using a restriction. In some embodiments, a restriction may be a maximum wait time, such as an amount of time in between the end of the processing of a request and the beginning of the processing of another request. For example, a single vehicle may have a restriction of not waiting more than an hour between multiple requests.
Each of the paths includes a set of lines, which may include a single line or multiple lines. For example, a first path may only include one line that processes one request. The path may include a weight that is derived from the profit. For example, a higher profit may include a higher weight. Another path may include multiple lines that processes multiple requests. The weight may be a combination of the profit for the multiple lines. When multiple requests are combined into a path, the multiple requests in the path meet the restriction that is specified, such as a maximum wait time.
A delivery optimizer 116 receives the paths and can optimize the paths into a schedule that can be used to process the batch of requests. The optimization may select a schedule that maximizes profit while being efficient because the weights are used. Also, optimizing the paths instead of the individual lines improves the processing of the requests. For example, delivery optimizer 116 selects a batch of scheduled routes for the vehicles that optimizes the total profit from the orders and fulfills as many of the orders as batches as possible. The optimization is used to find the optimal subset of paths the covers the orders. Delivery optimizer 116 may optimize the paths in a resource efficient manner. For example, delivery optimizer 116 can use fewer calculations to determine the minimum number of paths that are required to fulfill the orders. Using the smaller amount of paths, delivery optimizer 116 can search for a solution to the optimization in a much smaller subset of paths instead of in the whole space of every line. By decomposing the complex problem into three phases: line generator, path generator and delivery optimizer, some embodiments created a smaller space to perform the optimization. Further, using the weights may allow delivery optimizer to reduce the space even further, such as only the top k paths in terms of the weights between an origin and a destination may be used in the optimization. Additionally, delivery optimizer 116 may use less memory when processing the paths. For example, the number of paths being processed may be fewer than the number of lines and less storage may be needed to store the number of paths in memory. Also, instead of storing the whole feasible space of paths, some embodiments may only cache top k paths for each pair of origin/destination.
Request Optimization Example
Each row of tables 300 and 304 may list a request ID (Name), a pick-up time, a requirement (if specified), and a price for a different request. For example, in a first row of table 300, the request for “GOODS_1” has a pick-up time of 11:00 a.m., no requirement, and a price of 30€. Some requests may also specify various requirements. For example, a third request in the third row is for “GOODS_3” and has a pick-up time of 11:00 a.m., with a requirement of a car type #1, and a price of 60€. A car type #1 may specify a type of car, such as a brand of car. Table 304 includes other requests, such as a first row is for “GOODS_5” and has a pick-up time of 8:00 a.m., no requirement, and a price of 40€. The other rows also include other requests.
At 204, line generator 112 of request optimizer 108 generates lines for the requests where each line may be associated with a single request.
Each line may correspond to a request. Line L1 corresponds to GOODS_1, line L2 corresponds to GOODS_2, line L3 corresponds to GOODS_4, line L4 corresponds to GOODS_5, line L5 corresponds to GOODS_9, line L6 corresponds to GOODS_7, and line L7 corresponds to GOODS_8. Lines LS1 and LS2 correspond to GOODS_3 and GOODS_6, respectively.
Referring back to
The paths may include one or more lines. For example, one path may be line L1 and another path may be line L1 and LX where X is a number. Including more one than one line in the paths creates combinations of lines. As discussed above, the paths are analyzed instead of the lines individually.
The paths include different combinations of lines. It is possible that multiple paths include the same line. For example, path P4, P5, P7, and P8 include the line L7. During optimization, delivery optimizer selects the best path that includes line L7.
Referring back to
At 210, request optimizer 108 then outputs the paths to request fulfillment processors 104. For example, the paths that are selected may form a schedule that can be output to fulfillment processors 104. In some examples, if path P3 is selected, then one fulfillment processor 104 can fulfill lines L4, L1, and L6 together, such as a vehicle may be notified to fulfill these lines.
Process Description
In line #2, a request is pruned from the set if an edge condition has been violated. For example, request optimizer 108 may create a line graph that maps the time duration between locations. The lines for requests may be connected or a connection may be removed. For example, a connection between requests is pruned when a line for a request that connects with another line for a request does not meet a restriction, such as the connection between the lines exceeds the maximum waiting time. For example, request optimizer 108 removes a line that violates the maximum waiting time.
In line #3, request optimizer 108 finds the k shortest paths between u and v in subG (u,v). In one example, the k shortest paths may be based on an algorithm, such as Yen's algorithm. Finding the k shortest paths determines a number of paths from the lines without looping through lines already processed. In line #4, the generated paths are returned.
Once the paths are generated,
In line #2, request optimizer 108 initializes a variable C as 0 and defines a function f(C) as the |∪secs|, which is the cardinality for a set union (e.g., a size of the set union). The function f(C) is the number of requests that has been covered previously.
In line #3, request optimizer 108 repeats the following process until f(C)=f(S). That is, the process is repeated until all of the requests have been covered and added to the variable C. Request optimizer 108 iteratively selects the most cost-effective set per the objective using the weight and removes the covered requests, until all requests are covered. In line #3a, request optimizer 108 selects a path S and minimizes the 1/weight per element using
where f(C∪{s})−f (C) is the number of goods previously covered in addition to the number of good covered added by the current path minus the number of goods previously covered. In line #3b, the requests for the paths are included in a set C.
In line #4, request optimizer 108 outputs set C, which is the output path set.
In one example, result optimizer 108 initializes a result path variable RESULT_PATH={ } and a covered request variable COVERED_REQUEST={ } to an empty set. The result path variable contains the identification of the paths that are selected. The covered request variable includes the requests that are covered by the paths. The function f(C)=0 identifies a number of requests that have been fulfilled by the covered requests.
Result optimizer 108 selects path P6 since this path has the minimum value (15/(1−0)) of 15 for all the paths according to
In this case, delivery optimizer 116 minimizes the cost Result optimizer 108 then adds the path P6 to the result path variable: RESULT_PATH={P6}, and adds the goods GOODS_8 that are covered by the path to the covered request variable: COVERED_REQUEST={GOODS_8}. Since one request of goods is added, the function f(C)=1.
Result optimizer 108 then selects path P8 because this path has the minimum value (65/(4−1))=22.5 for all remaining paths. Result optimizer 108 then adds the path P8 to the result path variable: RESULT_PATH={P6, P8}, and adds the goods GOODS_1, GOODS_4, GOODS_7 that are covered by the path to the covered request variable: COVERED_REQUEST={GOODS_1, GOODS_4, GOODS_7, GOODS_8}. Path P8 covered three lines {L5, L3, and L7} and the corresponding goods for those lines are added to the covered requests. The variable f(C)=4 because the number of goods added is four.
Result optimizer 108 then selects path P3 because this path has the minimum value (60/(6−4))=30 for all remaining paths. In this case, the one with larger cardinality is selected (e.g., the greatest number of lines). Result optimizer 108 then adds the path P3 to the result path variable: RESULT_PATH={P6, P8, P3}, and adds the goods GOODS_5, GOODS_1, GOODS_9 to the covered request variable: COVERED_REQUEST={GOODS_1, GOODS_4, GOODS_5, GOODS_7, GOODS_8, GOODS_9}. Path P3 covered three lines {L4, L1, L6} and the corresponding goods for those lines are added to the covered requests. The variable f(C)=6 because the number of goods added is six.
Result optimizer 108 then selects path P4 because this path has the minimum value (42/(7−6))=42 for all remaining paths. Result optimizer 108 then adds the path P6 to the result path variable: RESULT_PATH={P6, P8, P3, P4}, and adds the goods GOODS_2, GOODS_7 to the covered request variable: COVERED_REQUEST={GOODS_1, GOODS_2, GOODS_4, GOODS_5, GOODS_7, GOODS_8, GOODS_9}. Path P4 covered three lines {L2, L7} and the corresponding goods for those lines are added to the covered requests. The variable f(C)=8 because the number of goods added is eight. GOODS_3 and GOODS_6 include special requirements and are not considered for this optimization. In the above optimization, delivery optimizer 116 selects four paths out of the eight possible paths to cover the requests. The calculation is more efficiently performed because the optimization only involves selecting among eight paths using the associated weights. Optimizing the paths is more efficient than attempting to optimize the individual lines.
Example System
Line generator 112 then receives the information for requests 502 and can generate information for lines that is stored in database 110 as lines 504.
Path generator 114 receives the information for lines 504 and then can generate information for paths that is stored in database 110 as paths 506.
Delivery optimizer 116 then optimizes the paths and generates information for a path and line mapping 508, a path and request mapping 510, and a schedule 512, which are all stored in database 110.
Delivery optimizer 116 then generates a schedule, which is stored in database 110 as schedule 512.
Accordingly, some embodiments can generate a schedule that optimizes the requests received. The optimization may select the schedule using less computing resources and more efficiently because lines and paths are generated first, and then the schedule is optimized using the paths that are generated based on the lines.
System
Computer system 710 may be coupled via bus 705 to a display 712, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device 711 such as a keyboard and/or mouse is coupled to bus 705 for communicating information and command selections from the user to processor 701. The combination of these components allows the user to communicate with the system. In some systems, bus 705 may be divided into multiple specialized buses.
Computer system 710 also includes a network interface 704 coupled with bus 705. Network interface 704 may provide two-way data communication between computer system 710 and the local network 720. The network interface 704 may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links are another example. In any such implementation, network interface 704 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
Computer system 710 can send and receive information through the network interface 704 across a local network 720, an Intranet, or the Internet 730. In the Internet example, software components or services may reside on multiple different computer systems 710 or servers 731-735 across the network. The processes described above may be implemented on one or more servers, for example. A server 731 may transmit actions or messages from one component, through Internet 730, local network 720, and network interface 704 to a component on computer system 710. The software components and processes described above may be implemented on any computer system and send and/or receive information across a network, for example.
Some embodiments may be implemented in a non-transitory computer-readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or machine. The computer-readable storage medium contains instructions for controlling a computer system to perform a method described by some embodiments. The computer system may include one or more computing devices. The instructions, when executed by one or more computer processors, may be configured to perform that which is described in some embodiments.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
The above description illustrates various embodiments along with examples of how aspects of some embodiments may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of some embodiments as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope hereof as defined by the claims.
