WO2001069488A1 - Systeme de planification pour vehicule - Google Patents

Systeme de planification pour vehicule Download PDF

Info

Publication number
WO2001069488A1
WO2001069488A1 PCT/US2001/007507 US0107507W WO0169488A1 WO 2001069488 A1 WO2001069488 A1 WO 2001069488A1 US 0107507 W US0107507 W US 0107507W WO 0169488 A1 WO0169488 A1 WO 0169488A1
Authority
WO
WIPO (PCT)
Prior art keywords
schedule
vehicle
delivery
time
location
Prior art date
Application number
PCT/US2001/007507
Other languages
English (en)
Inventor
Charles P. Jones
Kenneth B. Fiering
Duane Desieno
Original Assignee
Jones Charles P
Fiering Kenneth B
Duane Desieno
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jones Charles P, Fiering Kenneth B, Duane Desieno filed Critical Jones Charles P
Priority to AU2001245544A priority Critical patent/AU2001245544A1/en
Publication of WO2001069488A1 publication Critical patent/WO2001069488A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem

Definitions

  • the present invention relates to a system for automated scheduling of the destination(s) and arrival time(s) for vehicles, such as delivery trucks.
  • the present invention is directed, in general, to a system for scheduling a plurality of destinations and arrival times for vehicles such as delivery trucks.
  • One technique to optimize two conflicting goals is utilization of a fuzzy determination function. Fuzzy refers to the fact that the function used is smoothly varying as opposed to a step function.
  • the preferred embodiment of the present invention uses this technique to maximize efficiency while still delivering excellent customer service. It allows a delivery time to be assigned when the customer orders, i.e. in real time, and all the delivery parameters such as delivery window, maximum delivery distance and promptness of arrival are directly controllable through the form of the fuzzy determination function.
  • Efficient scheduling is obtained by checking, at the time the customer orders, all available delivery times that are feasible for a vehicle to reach the customer.
  • the software selects several of the most cost-effective times, spread out over the day or part of the day as chosen by the customer, e.g. morning, and offers those choices to the customer. In one embodiment, for example, the customer first selects morning, afternoon, evening, or night, each a 3 or 4 hour segment, and the software will then suggest times about an hour apart if they are available. This technique makes use of the fact that what most customers care about is having a fixed time and not a long window over which they must wait. Efficiency is achieved because the suggested times are the best ones for the delivering company.
  • a rule- based system can also be employed to define the cost, however, the fuzy determination system usually is more effective.
  • the "cost” or “efficiency” of a given set of assignments of deliveries to vehicles is calculated using the fuzzy determination function and then a neural network or genetic algorithm performs the optimization over the possible sets of assignments.
  • the "cost” can include actual expenses such as fuel and labor as well as early and late arrival penalties as assigned by the delivering company.
  • the definition of these costs controls the allowable window of delivery, maximum distance allowable, etc.
  • the neural network or genetic algorithm optimization is extremely fast and enables full optimization in real time. This is very important because, in general, the number of calculations required increases as n factorial, where n is the number of delivery stops.
  • the Internet provides an excellent platform for automated scheduling in real time. While we are emphasizing this real time aspect because of the importance of Internet applications, the present invention can also provide highly efficient automated scheduling solutions in older "after-the-fact" delivery schemes. In fact, if one eliminates early and late penalties, for instance, or defines the cost determination function to be broad, e.g. several hours, the system will give very efficient traditional minimum distance solutions after all customers have been determined and can do so automatically. These solutions in general, however, lie at the poor customer service end of a continuum of customer service versus efficiency. There are many applications, nonetheless, for which this is appropriate and the present invention offers an automatic, fast, and efficient means for scheduling.
  • the preferred embodiments also allow for multiple types of reservations in the schedule.
  • the first type of reservation is the "usual" or "normal” reservation that is added to the schedule at the time the customer decides to order. Once inserted it is has a fixed target arrival time and will not be removed unless the customer or authorized user specifically directs the program to do so.
  • the second type are 'hardwired" reservations. This category allows for assigning a set delivery time to a customer and having it reappear at regular intervals. For example, a customer might wish a product delivered on Mondays at 12:00 pm every week. Hard- wired reservations, like normal reservations are not removed from the schedule once inserted unless the program is specifically directed to do so.
  • the third type of reservation is referred to as a "Ghost Reservation".
  • the Ghost Reservation is a vehicle for accomplishing two things. First, it can be used to give the program statistical information known ahead of time to increase delivery efficiency. If, for instance, a company keeps accurate records of delivery requests on a stop-by-stop basis, statistical predictions of times and locations can be preloaded into the schedule by assigning ghost stops.
  • the time slot generation routine checks all available times, it is allowed to replace any of the ghost reservations with a normal (real as opposed to ghost) reservation. The easiest way to understand this effect is to think of an isolated neighborhood that always gets numerous deliveries within some time period of the day. After the first person from that neighborhood makes a reservation, the time slot routine may send the truck to a location further away from that neighborhood than is desirable before other customers from the area make their reservations.
  • the time slot routine and optimizer routine treat the ghosts as "normal" reservations while determining the cost.
  • the program thus knows via the cost function that it is should not venture far from the isolated neighborhood because it must return later. This leads to the second purpose of ghosts, enabling delivery to a remote location. Again thinking of our remote neighborhood, it is possible that the program may not deliver to the neighborhood at all because the cost of driving there exceeds the maximum cost set by the user on an individual delivery basis, even though the deliveries may be cost effective when considered in aggregate. Defining ghosts overcomes this problem. In practice, the neighborhood in question must truly be remote to the normal delivery area for the scheduler to have any difficulty in efficiently handling it without ghosts.
  • Fig. 1 shows a sample dialog box that helps a user configure parameters in an embodiment of the present invention.
  • Fig. 2 shows a sample graph of a cost function generated according to an embodiment of the present invention.
  • Fig. 3 shows a sample graph of a cost function generated according to another embodiment of the present invention.
  • Fig. 4 shows a sample graph of a cost function generated according to still another embodiment of the present invention.
  • Fig. 5 shows a sample graphic of a delivery route generated accordmg to an embodiment of the present invention.
  • Fig. 6 shows a table of information displayed to a user according to an embodiment of the present invention.
  • Fig. 7 shows another table of information displayed to a user according to an embodiment of the present invention.
  • Fig. 8 shows a sample dialog box useful in assisting the user to enter information according to an embodiment of the present invention.
  • Fig. 9 shows a sample dialog box useful in assisting the user to enter additional information according to an embodiment of the present invention.
  • Fig. 10 shows a table of information generated according to an embodiment of the present invention. DETAD ED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • location-time proposed or actual location and associated time preference for a visit by a vehicle; the location-time may also include cargo data specifying cargo (human, animal or other) to be transferred to and/or from the vehicle during the visit; the time preference may take the form of a specific time, a set of discrete times, a range of times aor a combination of these types; efficacy value: a number or other code reflecting the overall desirability of a proposed schedule; the efficacy value preferably reflects all qualities that impact overall desirability of a schedule; efficacy considerations may include, but are not limited to, cost considerations, efficiency considerations, time considerations, timeliness considerations, customer satisfaction, vehicle operator satisfaction, compliance with labor laws, and energy cost considerations.
  • vehicle includes, but is not limited to, land vehicles, sea vehicles
  • the above definitions shall be considered supplemental in nature.
  • the above definitions shall control. If the definitions provided above are broader than the ordinary, plain and accustomed meanings in some aspect, then the above definitions will control at least in relation to their broader aspects.
  • One objective is to build and optimize a delivery schedule that a delivery vehicle uses in order to meet all of its delivery requirements.
  • the present invention finds particular applicability for use with delivery services, it will become apparent upon reviewing this description that it does not require that goods actually be left behind by the truck or other traveling vehicle. Accordingly, the terms “delivery” and “delivery vehicle” are intended to refer broadly to any vehicle, which can take one of several paths to one or more destinations, regardless whether they are traveling there to deliver goods and services, or for any other reason. Similarly, the present invention will find applicability to vehicles other than land vehicles, such as boats and aircraft, and/or to a system that employs a mixture of such vehicles.
  • the present invention is comprised of software routines and an architecture that applies certain artificial intelligence (AI) techniques in a unique way to generate a delivery schedule that one or more vehicles should follow in order to arrive at prescribed destinations in a most efficient manner.
  • AI artificial intelligence
  • AI techniques are applied to accompanying simulations, they also provide a useful tool for understanding the impact of constraints on the ability to successfully deliver orders to customers. For example, the question of how many trucks are needed to satisfy a given number of customers in a day can be answered using hypothetical situations in the automatic schedule building embodiments of the present invention. For real customers, it is possible to determine the average delivery cost for a customer and discover the effects of distance from a warehouse on the likelihood of obtaining a delivery time slot. The system can simulate the real world with high fidelity because of the automated nature of the software. One merely needs to assign random or probabilistic selections of the suggested delivery times by the fictitious customers, and the system performs the scheduling as it would in the real world application.
  • the scheduling program in both real world and simulation applications, preferably includes a neural network or genetic algorithm to optimize the assignment of deliveries to vehicles.
  • the simulation can be operated with the neural net optimization performed after scheduling a number of customers, to minimize computer time, or simultaneously with the addition of customers. Additional features include the ability to save optimized schedules and to load saved schedules rather than re-calculate them.
  • the second routine is a schedule optimization routine, which takes the existing schedule and looks for ways to rearrange the appointments on the vehicles.
  • the optimization routine differs from the time slot generation routine by its ability to change the scheduled delivery route(s) of the delivery vehicle(s), such as by inserting a new leg into the route, or by re-designating one destination to a different delivery vehicle so that, in aggregate, the total cost is minimized, or by otherwise manipulating the schedule.
  • the present invention may be used internally by authorized employees of a retailer and/or its delivery service. It may also be designed to be accessible over the Internet by customers of an on-line retailer or the like.
  • the user of the software is likely an authorized employee.
  • the user may be the actual customer, inputting information from a remote data sharing device such as a personal computer, personal telecommunications device (e.g., cell phone), palm top computer, etc.
  • the scheduling software In order to begin developing and optimizing a delivery schedule, the scheduling software must have certain initialization parameters. Such parameters can be pre-coded as defaults into the neural network, or they can be customized by the user. For example, the maximum number of delivery vehicles, the maximum number of deliveries per vehicle, the maximum cost allowed for a delivery, and the form of the fuzzy cost determination function are preferably made available to the neural network before adding deliveries to a blank schedule. There are two possible sources of this information. The first is for the information to be generated internally by the software itself. The second option is to import this information from an external data file or interaction with the user.
  • the neural network should also be given general information about the customers to whom deliveries will be made. Some examples in the preferred embodiments are the distance and travel time from a given customer to every other customer and an estimate of the time needed at each location. Regarding the latter, either default or input data can be used. This allows the user to utilize historical or other means to determine the length of time needed on a stop-by- stop basis or to use a predefined default or algorithm if better information is not available.
  • the information on time and distance is pre-calculated using geocode-type or other software in order to save time during the schedule optimization process. Provision is made for the software to utilize different time and distance matrices for different days and times within days. This makes adjustment for rush hour, holidays, construction, etc. easy and allows for much better predictions.
  • PARAMETERS Figure 1 shows some of the parameters preferably used in the present invention, and in particular it shows a sample dialog box 5 that is displayed to the authorized user of the system. This example also contains parameters relevant to a simulation developed for that embodiment. The format and appearance of the dialog box need not be exactly as shown in Figure 1.
  • the Max Values area 10 includes the maximum number of trucks or other delivery vehicles 10a that can be used in the schedule, the number of customers included in the simulation to be sampled from 10b, and the maximum number of legs 10c, i.e., the maximum number of deliveries/stops per vehicle per shift.
  • the number of vehicles 10a may represent the number of physical vehicle/shift combinations that could exist. For example, if four trucks are used in two non-overlapping shifts, then parameter 10a may be set to eight.
  • the vehicle capacity may be naturally limited by the time required to make deliveries or by the capacity of the vehicle to carry payload.
  • the number of customers 10b determines the dimension of a Customer ID Array that the simulation will produce, along with a Vehicle Distance Array and a Travel Time Array. In the real world application, these arrays are given to the program via an Application Program Interface (API).
  • Figure 1 also shows scheduling constants 20 that define the shape of the fuzzy cost determination function that is used in calculating the best delivery routes.
  • the late arrival offset 20a (in units of time) sets the number of minutes late from "on time” that a predetermined proportion of the cost, e.g. 50%, should be applied in the cost evaluation of a late arrival.
  • An example of the fuzzy arrival time cost function, i.e. the fuzzy determination function is given in Figure 2, which shows a combined effect of both late and early costs and helps illustrate some of the parameters of Figure 1.
  • the default early arrival cost is often set to zero (not shown in Figure 2).
  • the late arrival multiplier 20b (in units of time) is the number of minutes, centered on the late arrival offset 20a, between where a predetermined low proportion, e.g. 10%, and high proportion, e.g. 90%, of the late arrival cost 20c is applied in the cost function.
  • a predetermined low proportion e.g. 10%
  • high proportion e.g. 90%
  • the value 20b is set to 15 minutes, so in
  • the late arrival cost 20c (in monetary units) is a maximum amount of money, chosen as a fictional amount or estimated in terms of time and/or fuel, value of lost customers, and/or any other factor, that can be applied to the fuzzy cost function if a delivery is late. In the example of Figures 1 and 2, the value is set to $120.
  • the late arrival line 20d (in monetary units per time) represents the dollars per hour to be added to the fuzzy cost function for each hour late.
  • Figure 2 uses a late arrival line of zero, and thus it has a flat region 210.
  • Figure 3 shows how the cost function increases at region 310 with a slope equal to Figure l 's late arrival line 20d of $50 per hour.
  • the late arrival quad 20e (in monetary units per time) represents the dollars to be added to the fuzzy cost function for each hour squared late, essentially a quadratic term in the cost function.
  • the value is set to 50.
  • Figure 4 shows how the increase in cost accderates for late arrivals at region 410.
  • the arrival time parameters in essence, set the window over which arrival is to be expected.
  • the quadratic term is included to allow the user to remove the possibility that a small number of stops will be scheduled very late. In some applications, sacrificing prompt arrival at a single or small number of stops can yield a schedule whose overall cost is lower. If this is undesirable, it can be eliminated.
  • Schedule constants 20 also include an early arrival offset 20f (in units of time) which is the number of minutes early from on-time that a predetermined proportion of the cost, e.g. 50%, should be applied in the cost evaluation of an early arrival. It is similar to the late arrival offset, and in the example of Figure 1 is set to 30 minutes, conesponding to point 202 in Figure 2.
  • the early arrival multiplier 20g (in units of time) is the number of minutes, centered on the early arrival offset 20f, between where a predetermined low proportion, e.g. 10%, and high proportion, e.g. 90%, of the early arrival cost 20h is applied in the fuzzy early arrival cost function. In the example of Figures 1-4, the value is set to 30 minutes.
  • the early arrival cost 20h (in monetary units) is the maximum value, created as a fictional number or estimated based on time and/or fuel and/or any other factor, that can be applied in the fuzzy cost function when a delivery is early. In the example of Figures 1-4, the value is set to $20.
  • the overload cost 20i (in monetary units) represents the cost added to an evaluated schedule if the number of packages scheduled to be delivered by a vehicle exceeds the maximum value 30d set for that vehicle. This allows the vehicle's maximum capacity to be based on time or payload, whichever occurs first.
  • the cost threshold 20j (in monetary units) is used by the time slot generation routine to limit the cost of any delivery to a maximum value. If the incremental cost of adding a customer to the schedule at a given slot exceeds this value, the slot will not be returned to the customer as being available. The value typically should be less than the late arrival cost 20c. In building schedules, this cost threshold value will affect the total schedule cost by restricting the cost of the slots presented to the customer. A higher value makes it possible for the customer to pick costlier slots, which, in turn, is likely to raise the expected cost for the final schedule. A low value will reduce the expected cost of the final schedule, but raises the possibility that a customer will not be offered a feasible slot due to cost considerations.
  • the default service time 20k sets the amount of time that a vehicle is expected to spend at each delivery stop.
  • the service time can be set independently 802f ( Figure 8) for each customer, and in real world applications it can be passed through the API or the default can be used.
  • the dialog box 5 also shows parameters related to the vehicles (or trucks) themselves.
  • vehicle parameters 30 include a set of parameters 30b through 30q that are preferably individualized for the vehicle designated by an identifier 30a.
  • all of the parameters 30b through 30q can apply to all of the vehicles, such as when the system uses a single type of vehicle.
  • the vehicle identifier 30a is numerical, but it can be the vehicle's license plate or any other means of identifying the vehicle.
  • the distance cost 30b (in monetary units per distance) is the cost in dollars per mile that should be associated with the specified vehicle. It can be based on fuel consumption, anticipated wear and tear, etc. The distance cost (and time cost discussed next) are often used in conjunction with the fuzzy arrival time function.
  • the time cost 30c (in monetary cost per time unit) is the cost in dollars per hour that should be associated with the specified vehicle and might be based on personnel wages, monthly depreciation, etc.
  • Bin capacity 30d is the total number of bins (or packages or whatever is being delivered, if any) that the vehicle can hold. If this capacity is exceeded in the schedule being evaluated, then the overload cost 20i is added to the cost of that schedule. This is included as an alternative to maximum legs for defining when a vehicle has reached delivery capacity. In some cases, the capacity of the truck will depend on the particular orders placed.
  • the start time 30e is the time of day that the vehicle departs on its route. Stop time 30f is the time of day that the vehicle should arrive back at the warehouse (or other location) at the end of its route. If the evaluated schedule has the truck returning to the warehouse late, then the cost for that schedule will include the late anival cost 20c just as it is for a late arrival to a customer.
  • Alternative embodiments can use a separate late-to-warehouse parameter, or exclude any late-to-warehouse cost.
  • the system preferably accommodates lunch-time and other breaks if the delivery schedule is long.
  • Lunch time 30g is the duration (e.g., in minutes) of a lunch break;
  • lunch start 30h is the earliest time of day that the vehicle's personnel can begin taking lunch;
  • lunch stop 30i is the latest time of day that they can begin lunch.
  • Break time #1 30j is the duration (e.g., in minutes) of a first break that the delivery personnel are permitted;
  • break #1 start 30k is the earliest time of day that the vehicle's personnel can begin the first break begins;
  • break #1 stop 301 is the latest time of day when they can start their first break.
  • Break #2 time 30m, start 30n, and stop 30o are analogous to parameters 30j through 301, but for a second break.
  • the invention can accommodate additional breaks, or fewer, depending on the desires of the end user.
  • the options "use lunch in schedule” 30p and “use breaks in schedule” 30q determine whether the initialized schedule will contain lunches and breaks for the vehicles. These parameters are preferably examined only when the schedule is initialized, so if either one is changed, the schedule must be re-initialized for the change to take effect.
  • the dialog box 5 also shows Simulation Data 40, including the square size 40a in linear units such as miles, although it could accept square units. The square size
  • 40a is the size of the geographic region that is serviced by the delivery system. This parameter is not used if customer information is imported from an external data file.
  • the simulation included in the example embodiment can also artificially generate customer data, and customer locations are randomly generated in this region.
  • the authorized user can thus study delivery efficiency by defining a delivery region and a density of customers. Delivery cost is strong function of customer density in most applications.
  • the average vehicle speed 40b (in linear units per time) is an estimated average travel speed for the vehicle, to be used in generating customer data. Tre average speed is used with the distance information to determine the values for the travel time matrix. This parameter is not used if customer data is imported from and external data file.
  • the Euclidean distance option 40c allows the system to determine the method of calculating the distance between any two customers. When selected, straight line distances are used in the distance calculation. When not selected, city block distances, actual road lengths, or other types of distances are used. Alternatvely, an externally generated customer matrix and associated data can be passed to the simulation, in which case, the time and distance data are also passed and are not generated by the simulation. In real world applications, geocode software is generally used to calculate time and distance.
  • a random seed 40d is used to initiate a random number generator for building customer data. Using different values will place customers into different locations along the delivery route. The random number generator is only used in the simulation for random selection of customer locations, choosing times, etc.
  • Simulation size 40e determines the number of customers that will be added to the schedule each time the build schedule command is executed in the simulation. If this value is set to 10 for instance, every time the operator tells the simulation to build the schedule, the simulation will attempt to add 10 more fictitious customers to the then cunent schedule. This process can be performed manually or automatically in conjunction with the AutoBuild function. If, for a given customer, no available delivery time slots are generated, then that customer will not be added to the delivery schedule.
  • the simulation size parameter 40e can be set to a small value when used in conjunction with a nonzero value for the AutoBuild seconds parameter 40h to slowly add customers while concurrently running schedule optimization routine.
  • the user may select or deselect a random segment option 40f which, when set during the automated construction of a schedule, instructs the schedule builder to randomly select a segment during the day and randomly select a slot returned by the slot generation function.
  • a random segment option 40f which, when set during the automated construction of a schedule, instructs the schedule builder to randomly select a segment during the day and randomly select a slot returned by the slot generation function.
  • slots are generated for all segments of the day and the lowest cost slot is selected by the build function. This allows the operator to study a theoretical lowest cost schedule as opposed to a more "real world" schedule.
  • the user may also select a random customer option 40g which, when selected during the automated construction of a schedule, instructs the schedule builder to randomly select one of the available customers for inclusion in the schedule.
  • a random customer option 40g which, when selected during the automated construction of a schedule, instructs the schedule builder to randomly select one of the available customers for inclusion in the schedule.
  • Autobuild parameter 40h determines the time in seconds between automatic calls to the build schedule function. Calls will be made continually at this time interval until this parameter is reset to zero or the AutoBuild iteration limit has been reached. This gives the user a way to test optimization of the schedule (which can be run concurrently) as customers are being added to the schedule. When using this parameter it is preferable to set its value to 15 seconds or more in order to allow the schedule optimization routine time to improve the schedule. Too small a value will decrease the effects of optimization on the final schedule.
  • An AutoBuild iteration parameter 40i designates the maximum number of times that automatic calls to the build function will occur, thus allowing for a totally automatic optimized simulation.
  • the originally generated schedule 510 is displayed at the left side of the graphic, with a current optimized schedule 512 displayed at the right. If the delivery system uses more than one vehicle, then it is preferable to use different colors or shadings to designate the routes of different vehicles. By placing the original and updated schedules adjacent one another, the user can make a visual comparison in order to see how it has changed due to the optimization.
  • the original schedule 510 is updated when a build schedule command is entered. This allows the user to view tie effects of adding customers on the latest schedule produce by the simulation.
  • the display becomes a text representation of the current optimized schedule.
  • An example is shown in Figure 6.
  • the times shown represent the scheduled arrival times for the customer.
  • the statistics shown in the graphics display of Figure 5 are shown in Figure 6 as "customer identifier/scheduled delivery time slot," with each column conesponding to a respective vehicle.
  • the customer identifier is, for example, a three digit number and the target arrival time is expressed in 24-hour time, hh:mm. Starting times for lunch and breaks are denoted by LN and BR, respectively.
  • LN and BR Starting times for lunch and breaks are denoted by LN and BR, respectively.
  • Also shown are the average distance between the warehouse and all of the customers, the average distance per leg in the schedule and the actual number of legs in the schedule, all in region 602.
  • the display preferably uses different shades or colors to designate the type of delivery order. Normal customer orders are shown in black, for example, while available slots are color coded, e.g. in blue. Available slots will either be converted to real orders or removed at some point in time before final schedule optimization is performed. Ghost orders (orders that are used to force the software to start vehicles from specified regions, e.g. outlying areas) may also be used as the available slots, and should be removed from the schedule before final schedule optimization is performed. A command exists to automatically perform this removal.
  • the Actual Times option 50c is selected, a text representation of the cunent optimized schedule is displayed. An example is shown in Figure 7. The times shown represent the actual arrival times for the customer.
  • Actual arrival times are the times the program believes the truck will actually arrive at the destination based on the time matrix. These times may be different from the target anival times.
  • the program allows the optimizer to reanange the schedule so that expected anival times may be different from targets if the cost is still below the maximum allowable cost and the overall cost for the schedule is reduced.
  • Beta is a parameter which controls the probability that higher cost schedules are accepted. The higher the value, the less likely a solution will be accepted into the genetic algorithm popthat has a higher cost than the best schedule.
  • Gamode is a parameter that controls whether the parent or the worst solution is replaced during the optimization.
  • the parameter will therefore have one of two possible values, and simply acts as an identifier of which of the two to replace. Any two values can thus be used; other unrecognized values may cause the genetic algorithm to malfunction.
  • NConsenses is the number of schedules in the population being used by the genetic algorithm. A default value can exist, such as 8. A larger value will increase the time it takes to find an "optimal" solution. Too small a value will give poorer solutions. This parameter should only be changed if the schedule optimization is stopped and any change should be followed by a schedule initialization command.
  • the slot time generation routine analyzes the cost related to placing that customer in the delivery schedule using the fuzzy cost determination function at time slots that are spaced by predetermined time spacings, such as every 5 minutes
  • this cost analysis is preferably done only for the time segment of the day that the user specified. For systems that control more than one delivery vehicle, this cost analysis routine is also preferably done for more than one vehicle, and preferably for every vehicle in the schedule. However, tie artisan will appreciate that only some of the vehicles may be suited for delivering a particular item to that customer, such as when the item is very large and requires a larger vehicle, or if it is a frozen item and requires a refrigerated vehicle, etc. Regardless, the software routine analyzes the cost based on one or more of parameters 802b-802f, and the resulting cost increase(s) are placed in a sorted list. The top few, e.g., four, are returned to the calling process.
  • the slot generation routine sorts the available slots according to cost and, in the embodiment reflected in Figure 8, returns the four best slots to the user's display, at region 804. Behind the scenes, the slot generation routine stores a data record identifying the four slots, the customer's identifier (a valid identifier from the customer ID anay), and the other pertinent data for that delivery.
  • the customer or user decides which one of the four time slots is most convenient, and selects it using a mouse, keyboard, etc.
  • This time slot is loaded into the customer ID anay under that customer's identifier and, from there, is retrieved by the optimization routine in order to include that customer into the schedule.
  • the optimization routine may also load the customer ID anay with the identity of the vehicle and leg on which that customer will be serviced.
  • the software can choose a winner based on any criteria.
  • an added cost related to the closeness in time to cunently selected times is used to break the tie. For example, in the time period from 8:00 to 12:00, the added cost for a given delivery might be $5. If all 5-minute slots have the same cost, then the first slot selected is 8:00. The closeness cost is then added to the remaining slots on the list. This cost is calculated, in one example, as a price such as $50, divided by (one plus the square of the scaled difference in time, e.g. in minutes, between the selected slot and the slot under consideration). By using this method the next slot generated would be 12:00 since it is farthest from the first selection.
  • the software can settle a tie simply by choosing the first few slots immediately preceding or following a slot that is already on the schedule. This method allows the slot generation routine to space possible times suggested to the customer across a segment of the day.
  • the time slot generation function preferably does not report a slot as being available if the incremental cost for that slot exceeds the cost threshold 20k.
  • this cost threshold setting 22k will affect the total schedule cost by restricting the cost of the slots presented to the customer.
  • a higher threshold value 22k will make it possible for the customer to pick costlier slots. The effect will be to raise the expected cost for the schedule, though additional stops may be added.
  • a low value will lower the expected cost of the schedule while raising the possibility that a customer will not be given a feasible slot based on cost considerations. Experimenting with different threshold values 22k will aid in determining an optimal value for the environment in which the invention is to be used.
  • the present invention preferably employs geocodes, or latitudinal and longitudinal coordinates, expressed in degrees, hours, minutes, seconds, and tenths-of- seconds of arc.
  • Software databases cunently exist which are able to translate street addresses into such coordinates, such as Navtech and GDT, so they need not be explained in further detail herein. These databases are able to generate physical distances and time-of-travel between street addresses which the slot generation routine uses in order to evaluate the cost of adding a new customer to a particular slot within a schedule.
  • the artisan will appreciate that certain embodiments of the present invention can omit physical distance and/or time-of-travel as elements of cost. Nevertheless, these pieces of data can be extremely useful in an evaluation of cost.
  • Schedule Optimization In a prefened embodiment of the present invention, the schedule optimization routine is a server that operates continually, improving the cost efficiency of the delivery schedules. In alternative embodiments, and in particular low-volume applications, it can be called only when a new customer is added.
  • the server tries to improve the cost effectiveness of the overall delivery schedule for all vehicles while retaining, as best it can, the customers' requested delivery time slots.
  • a customer who requested a particular time slot will have his or her time slot adjusted.
  • the present invention places constraints on how much the scheduled time slot can differ from the requested time slot.
  • the optimization routine re-allocates the deliveries by switching some customers to different vehicles, by moving the legs of certain vehicles' routes, or by changing the actual delivery times for certain customers so that, in aggregate, the cost for the entire delivery schedule for all vehicles is minimized.
  • the schedule optimization is best performed using a genetic algorithm.
  • a genetic algorithm modifies a schedule using two basic methods.
  • the first is a mutation operation.
  • the mutation operation is simply to move a leg from its original position in the schedule to a new position in the schedule. This could mean changing either the vehicle and/or the delivery sequence for this leg.
  • the second operation is called a crossover operation.
  • This term comes from the genetic analogy of reproduction where two different genes are cut at a random point and the tails are switched to form two new genes.
  • crossover operations include switching two vehicles' schedules at a certain point in the day, by reversing the order of delivery for a certain sequence of legs, or by switching the positions of two legs in the schedule. Any of these changes will cause the Distance Anay, Time Anay, and/or Customer ID Anay to be changed.
  • Each modified schedule is evaluated based on the cost function. If the cost improves, then the improved schedule is added back into the population of solutions. Although the number of possible solutions (population) can simply be increased, that would also increase future processing time. So it is preferable to have a limit on the number of solutions to be evaluated, such as eight although any number can be used, and to have the new solution replace either the parent (previous version of that solution) or the worst (most costly) schedule in the population. If the cost does not improve, the newly created schedule may still end up in the population.
  • the difference in cost between the then-generated solution and the best (least costly) solution is used to generate a probability of acceptance (e.g., a percentage). The greater the difference the lower the probability of acceptance.
  • a random number (e.g., between zero and one) is then generated. If the random number is lower than the probability of acceptance then the schedule is added back into the population. Otherwise it is discarded.
  • the process of generating and evaluating solutions is preferably repeated continually during the optimization.
  • the best schedule found during this process is saved for use by the slot time generation algorithm and for actual deliveries. That is, time slots that are free in the best schedule are made available to the slot time generation routine for selection and (optional) presentation to the user. See Figure 8. This is done by setting a flag for all available time slots in the schedule anay for that particular vehicle.
  • the optimization routine excludes that vehicle's schedule from those that are manipulated.
  • the fixed schedule is printed and the vehicle's driver is given the list of customers and their addresses, preferably also with the geocode software's street directions on how to travel from one destination to the next.
  • Schedule Cost Function One of the keys to the optimization routine is the schedule cost evaluation function.
  • the neural network uses this function to evaluate schedules.
  • the specification of the cost function is best when it closely represents realistic costs encountered in a schedule. It is clear that distance related costs should be part of this cost function.
  • This cost can be implemented in various manners, one of which is to specify a cost per mile traveled (or other linear measurement) and/or a cost per minute of travel time (or other unit of time) for each of the vehicles in the schedule. These costs are specified in the vehicle structure as Distance Cost and Time Cost.
  • the vehicle structure is essentially a data record specific to a vehicle, storing data relevant to that vehicle's operation in the system. Some or all of the information displayed in sections 20 and 30 of dialog box 5 can be part of the vehicle structure.
  • vehicle structure is preferably accessible by both the slot time generation routine and the optimization server. If distance related costs were the only costs in the schedule, the neural network or genetic algorithm optimization would not care if a customer received their order late or early. However, the cost of being late by a certain time can be detrimertal as well. If late means greater than 15 minutes, it is undesirable to have the cost of being 14 minutes late be zero, and 15 minutes late to be $50 (or whatever cost is designated).
  • constraints are difficult if not impossible to program into the genetic algorithm, they are best implemented as part of the cost function. For example, each truck should have a lunch or dinner break. If the genetic algorithm assigns two lunch breaks to the same truck (e.g. through a mutation that moves lunch from vehicle #j to vehicle #k), then the cost evaluation should tell the algorithm that this is infeasible by returning a high cost for that schedule. For example, the system could set an enormous constraint cost, such as $999999.00, to insure that no such constraints would be violated. Controlling the Optimization
  • the implementation of the present invention preferably follows some basic characteristics or rules related to optimization. First, the larger the schedule (number of legs), the harder it is to find an optimal solution. The difficulty grows by (n!) or "n factorial,” where "n" is the number of legs in the schedule.
  • the optimization is handled in a separate thread from the slot time generation.
  • the system is designed so that both operations can occur concunently.
  • the best schedule can be changed as slot times are generated.
  • a different embodiment contemplates running the optimization routine only after the slot time generation. This reduces processing requirements.
  • the structures outlined above makes it possible to run several schedule programs independently and then recombine them into a single optimization later. This allows, for example, that vehicles can be removed from the overall schedule and then reinserted. It also allows for independently scheduling a remote region and then putting that schedule into the master schedule for optimization. If, for instance, the user wishes to operate deliveries in a remote region, is uncertain of the number of deliveries which will be requested and wishes to fill all requested. He can operate an independent schedule until a cutoff time, for example, and then insert the truck into the master schedule. The optimizer may be able to schedule other deliveries on the way to or from the remote region. As is the case with using ghosts, the region must be truly remote to require this approach, as the normal program operation is highly efficient in scheduling most regions, even those that are not uniform in the density of delivery locations.
  • the slot time generation routine in rare instances can have trouble finding slots for customers in outlying areas due to the remoteness
  • Ghosts are added to a schedule by selecting and adding fictional customers from the area in a normal fashion.
  • a minimum distance solution can be calculated for the selected customers by setting late arrival cost to zero and running the optimization routine on those fictional customers, or ghosts. This produces a minimum distance solution but contains bad arrival times for the ghosts.
  • a routine exists to change the target arrival times for the ghosts and distribute them evenly in time across the shift. This prevents a situation in which all ghosts are bunched together at the beginning of the vehicle's route.
  • the optimization routine can remove a ghost (as recognized by its Type) whenever a new customer is added to that schedule near the ghost revervation. Such replacement can occur each time a new customer is added, or every other time, or on some other periodic basis.
  • the optimization routine should scour the customer Types and remove any remaining ghosts. Additional Variations What results at the end of processing is a set of routes for the delivery vehicles to take. The routes will bring the vehicles to their appointed destinations in a most efficient manner, with only minimal likelihood that deliveries will be later than the window originally defined by the cost anival function.
  • the parameters described herein are expressed in terms of monetary or other "real" units. Such need not be the case; the parameters can be designated in fictional units. However, using real units permits the cost estimations to be used in delivery charges to the customer. A customer can be shown the approximate cost for a selected time slot, and only upon agreeing to pay that cost will the time slot be forwarded to the optimization routine. The cost function can also be used on the actual delivery schedule that took place. The vehicle's log can be input and evaluated against the optimized schedule in order to see whether and how much money should be credited to the customers' accounts due to the fact that a delivery was late.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

Un système de planification pour véhicule de livraison crée un itinéraire pour un ou plusieurs véhicules, de manière que les livraisons puissent être effectuées de la manière la plus efficace possible. Les paramètres relatifs aux destinataires des livraisons (10) ainsi qu'aux véhicules et aux coûts d'une arrivée tardive et/ou en avance (20), sont utilisés pour l'analyse des créneaux horaires disponibles et pour la sélection de ceux ayant le moins d'impact en matière de coût sur la planification de livraison ponctuelle. Un sous-programme d'optimisation prend ensuite lesdits créneaux horaires nouvellement générés et les insère dans le planning de livraison existant (40). L'optimisation est assurée, de préférence, par un réseau neuronal ou un algorithme génétique qui manipule les embranchements de chaque itinéraire du véhicule, de manière que le coût total du planning de livraison intégral pour tous les véhicules soit minimisé. Les créneaux horaires pour les clients ultérieurs sont générés en fonction de ce planning récemment optimisé, et lesdits nouveaux créneaux horaires sont à nouveau optimisés.
PCT/US2001/007507 2000-03-10 2001-03-09 Systeme de planification pour vehicule WO2001069488A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001245544A AU2001245544A1 (en) 2000-03-10 2001-03-09 Vehicle scheduling system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US18855100P 2000-03-10 2000-03-10
US60/188,551 2000-03-10

Publications (1)

Publication Number Publication Date
WO2001069488A1 true WO2001069488A1 (fr) 2001-09-20

Family

ID=22693628

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/007507 WO2001069488A1 (fr) 2000-03-10 2001-03-09 Systeme de planification pour vehicule

Country Status (2)

Country Link
AU (1) AU2001245544A1 (fr)
WO (1) WO2001069488A1 (fr)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004092995A1 (fr) * 2003-04-15 2004-10-28 United Parcel Service Of America, Inc. Modelisation de l'heure de pointe pour la circulation et la programmation
WO2005088493A1 (fr) * 2004-03-10 2005-09-22 Ingo Morgenstern Procede et systeme d'optimisation de travaux de transport
US7233907B2 (en) 2002-08-07 2007-06-19 United Parcel Service Of America, Inc. Parcel or service delivery with partially scheduled time windows
US7793294B2 (en) 2005-02-22 2010-09-07 Northrop Grumman Corporation System for scheduling tasks within an available schedule time period based on an earliest possible end time of the task
CN103279857A (zh) * 2013-06-13 2013-09-04 南京航空航天大学 数控车间自动配送车辆调度方法
US20130278213A1 (en) * 2012-04-23 2013-10-24 State Grid Corporation Of China Integrated battery dispatching system with centralized charging and centralized allocation
AU2008202871B2 (en) * 2008-06-30 2014-04-03 Autonomous Solutions, Inc. Vehicle dispatching method and system
US20140214715A1 (en) * 2013-01-30 2014-07-31 Command Alkon Incorporated Scheduling system and method for distribution of perishable loads of pre-mixed concrete to multiple sites
US9135575B2 (en) 2005-05-09 2015-09-15 Roadnet Technologies, Inc. Systems and methods for routing and scheduling visits to delivery locations
US20170206621A1 (en) * 2016-01-14 2017-07-20 Alibaba Group Holding Limited Systems and Methods for Determining the Effectiveness of Warehousing
CN107578197A (zh) * 2017-07-10 2018-01-12 同济大学 需求不确定的混流生产线物流车辆调度区域优化方法
US9911087B1 (en) 2014-09-18 2018-03-06 Servicenow, Inc. System and method for efficient travel time and route computation
CN107977739A (zh) * 2017-11-22 2018-05-01 深圳北斗应用技术研究院有限公司 物流配送路径的优化方法、装置及设备
CN109961221A (zh) * 2019-03-20 2019-07-02 合肥工业大学 一种直接配送时间依赖于机器地理位置的平行机调度方法
US20190228376A1 (en) * 2018-01-19 2019-07-25 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US20200143319A1 (en) * 2018-11-01 2020-05-07 Walmart Apollo, Llc Systems and methods for determining delivery time and route assignments
CN111666681A (zh) * 2020-06-03 2020-09-15 重庆大学 基于改进遗传算法的pbs缓冲区车辆排序调度方法
CN113095636A (zh) * 2021-03-25 2021-07-09 深圳前海联动云软件科技有限公司 一种燃油共享汽车的智能调度系统及其方法
US20210344624A1 (en) * 2012-04-27 2021-11-04 Calendar Research Llc Appointment negotiation systems and methods
US11354610B2 (en) 2018-12-27 2022-06-07 Clicksoftware, Inc. Methods and systems for scheduling location-based tasks and location-agnostic tasks
GB2602473A (en) * 2020-12-30 2022-07-06 British Telecomm Optimised route planning
CN115469622A (zh) * 2022-09-16 2022-12-13 重庆大学 Wbs缓冲区车辆调度方法
US20230169415A1 (en) * 2018-01-19 2023-06-01 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US12026647B2 (en) 2019-12-23 2024-07-02 Clicksoftware, Inc. Systems and methods for using predicted demand to optimize task scheduling

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5265006A (en) * 1990-12-14 1993-11-23 Andersen Consulting Demand scheduled partial carrier load planning system for the transportation industry
JPH05313583A (ja) * 1992-05-14 1993-11-26 Matsushita Electric Ind Co Ltd ナビゲーション装置
US5623413A (en) * 1994-09-01 1997-04-22 Harris Corporation Scheduling system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5265006A (en) * 1990-12-14 1993-11-23 Andersen Consulting Demand scheduled partial carrier load planning system for the transportation industry
JPH05313583A (ja) * 1992-05-14 1993-11-26 Matsushita Electric Ind Co Ltd ナビゲーション装置
US5623413A (en) * 1994-09-01 1997-04-22 Harris Corporation Scheduling system and method

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7233907B2 (en) 2002-08-07 2007-06-19 United Parcel Service Of America, Inc. Parcel or service delivery with partially scheduled time windows
WO2004092995A1 (fr) * 2003-04-15 2004-10-28 United Parcel Service Of America, Inc. Modelisation de l'heure de pointe pour la circulation et la programmation
US8433511B2 (en) 2003-04-15 2013-04-30 United Parcel Service Of America Rush hour modeling for routing and scheduling
WO2005088493A1 (fr) * 2004-03-10 2005-09-22 Ingo Morgenstern Procede et systeme d'optimisation de travaux de transport
US7793294B2 (en) 2005-02-22 2010-09-07 Northrop Grumman Corporation System for scheduling tasks within an available schedule time period based on an earliest possible end time of the task
US9135575B2 (en) 2005-05-09 2015-09-15 Roadnet Technologies, Inc. Systems and methods for routing and scheduling visits to delivery locations
AU2008202871B2 (en) * 2008-06-30 2014-04-03 Autonomous Solutions, Inc. Vehicle dispatching method and system
US20130278213A1 (en) * 2012-04-23 2013-10-24 State Grid Corporation Of China Integrated battery dispatching system with centralized charging and centralized allocation
US20210344624A1 (en) * 2012-04-27 2021-11-04 Calendar Research Llc Appointment negotiation systems and methods
US20140214715A1 (en) * 2013-01-30 2014-07-31 Command Alkon Incorporated Scheduling system and method for distribution of perishable loads of pre-mixed concrete to multiple sites
CN103279857A (zh) * 2013-06-13 2013-09-04 南京航空航天大学 数控车间自动配送车辆调度方法
US10133991B2 (en) 2014-09-18 2018-11-20 Servicenow, Inc. System and method for efficient travel time and route computation
US9911087B1 (en) 2014-09-18 2018-03-06 Servicenow, Inc. System and method for efficient travel time and route computation
US10817810B2 (en) 2014-09-18 2020-10-27 Servicenow, Inc. System and method for efficient travel time and route computation
CN106971282A (zh) * 2016-01-14 2017-07-21 阿里巴巴集团控股有限公司 一种仓储方案有效性的确定方法和系统
US20170206621A1 (en) * 2016-01-14 2017-07-20 Alibaba Group Holding Limited Systems and Methods for Determining the Effectiveness of Warehousing
CN107578197A (zh) * 2017-07-10 2018-01-12 同济大学 需求不确定的混流生产线物流车辆调度区域优化方法
CN107578197B (zh) * 2017-07-10 2021-02-02 同济大学 需求不确定的混流生产线物流车辆调度区域优化方法
CN107977739A (zh) * 2017-11-22 2018-05-01 深圳北斗应用技术研究院有限公司 物流配送路径的优化方法、装置及设备
CN107977739B (zh) * 2017-11-22 2021-07-06 深圳北斗应用技术研究院有限公司 物流配送路径的优化方法、装置及设备
US11475395B2 (en) * 2018-01-19 2022-10-18 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US11922343B2 (en) 2018-01-19 2024-03-05 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US20190228376A1 (en) * 2018-01-19 2019-07-25 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US20230169415A1 (en) * 2018-01-19 2023-06-01 Walmart Apollo, Llc Systems and methods for combinatorial resource optimization
US11615368B2 (en) 2018-11-01 2023-03-28 Walmart Apollo, Llc Systems and methods for determining delivery time and route assignments
US20200143319A1 (en) * 2018-11-01 2020-05-07 Walmart Apollo, Llc Systems and methods for determining delivery time and route assignments
US11354610B2 (en) 2018-12-27 2022-06-07 Clicksoftware, Inc. Methods and systems for scheduling location-based tasks and location-agnostic tasks
US11551167B2 (en) 2018-12-27 2023-01-10 Clicksoftware, Inc. Systems and methods for fixing schedule using a remote optimization engine
US11593728B2 (en) 2018-12-27 2023-02-28 Clicksoftware, Inc. Systems and methods for scheduling tasks
US11615353B2 (en) * 2018-12-27 2023-03-28 Clicksoftware, Inc. Methods and systems for offerring service times based on system consideration
US11823104B2 (en) 2018-12-27 2023-11-21 Clicksoftware, Inc. Systems and methods for scheduling connected device
CN109961221A (zh) * 2019-03-20 2019-07-02 合肥工业大学 一种直接配送时间依赖于机器地理位置的平行机调度方法
US12026647B2 (en) 2019-12-23 2024-07-02 Clicksoftware, Inc. Systems and methods for using predicted demand to optimize task scheduling
CN111666681A (zh) * 2020-06-03 2020-09-15 重庆大学 基于改进遗传算法的pbs缓冲区车辆排序调度方法
CN111666681B (zh) * 2020-06-03 2024-03-22 重庆大学 基于改进遗传算法的pbs缓冲区车辆排序调度方法
GB2602473A (en) * 2020-12-30 2022-07-06 British Telecomm Optimised route planning
CN113095636B (zh) * 2021-03-25 2024-01-23 深圳前海联动云软件科技有限公司 一种燃油共享汽车的智能调度系统及其方法
CN113095636A (zh) * 2021-03-25 2021-07-09 深圳前海联动云软件科技有限公司 一种燃油共享汽车的智能调度系统及其方法
CN115469622A (zh) * 2022-09-16 2022-12-13 重庆大学 Wbs缓冲区车辆调度方法

Also Published As

Publication number Publication date
AU2001245544A1 (en) 2001-09-24

Similar Documents

Publication Publication Date Title
WO2001069488A1 (fr) Systeme de planification pour vehicule
Larsen The dynamic vehicle routing problem
Cordeau et al. Transportation on demand
Branchini et al. Adaptive granular local search heuristic for a dynamic vehicle routing problem
Larsen et al. The a priori dynamic traveling salesman problem with time windows
Psaraftis Dynamic vehicle routing problems
CN112005258A (zh) 混合式车辆选择和路线优化
Eglese et al. Disruption management in vehicle routing and scheduling for road freight transport: a review
CN110110903B (zh) 一种基于神经进化的配送车辆路径规划方法
CN114169613A (zh) 基于机器学习和干扰管理的低碳物流配送系统及其方法
Pouls et al. Adaptive forecast-driven repositioning for dynamic ride-sharing
Su Dynamic vehicle control and scheduling of a multi‐depot physical distribution system
KR100470919B1 (ko) 허브앤스포크 물류망의 간선 운송 계획 시스템과 그 계획생성 방법
Belenguer et al. RutaRep: a computer package to design dispatching routes in the meat industry
Zhou et al. Two-echelon time-dependent vehicle routing problem with simultaneous pickup and delivery and satellite synchronization
Chouaki Agent-based simulations of intermodal mobility-on-demand systems operated by reinforcement learning
Lacombe et al. Integrated charging scheduling and operational control for an electric bus network
Rapp Man-machine interactive transit system planning
Barceló et al. Making real-time fleet management decisions under time-dependent conditions in urban freight distribution
Vallée et al. Reinsertion algorithm based on destroy and repair operators for dynamic dial a ride problems
Erdmann On-Demand Mobility Service Evaluation for the Ride Hailing and Ride Pooling Use Case with a Novel Diffusion Customer Model
Ghilas et al. Spot Market versus Full Charter Fleet: Decisions Support for Full Truck Load Tenders
Reitsma Customer preferred time window scheduling
Luo Heuristics and performance metamodels for the dynamic dial-a-ride problem
D’Haen et al. Integrating order picking and vehicle routing decisions in a dynamic e-commerce setting

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP