CN111768043A

CN111768043A - Distribution plan generation method, device and system for distribution vehicle

Info

Publication number: CN111768043A
Application number: CN202010627772.3A
Authority: CN
Inventors: 池田博和
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2017-07-28
Filing date: 2017-07-28
Publication date: 2020-10-13
Also published as: JP7130806B2; CN111768042A; JP2020091887A; CN109308540A; JP2021106036A; JP6660973B2; CN109308540B; JP2019028992A; CN111325383A; JP6862589B2

Abstract

The invention provides a method, a device and a system for generating a delivery plan of a delivery vehicle. The invention introduces the task cost of the empty container return task into the total cost of the candidate delivery plan, can ensure that the algorithm automatically outputs the expected delivery sequence returned by the empty container, meets the requirement of empty container return in the actual logistics scene, avoids adopting a manual mode to make the delivery plan, reduces the making cost of the delivery plan and improves the generation efficiency of the delivery plan.

Description

Distribution plan generation method, device and system for distribution vehicle

The present application is a divisional application entitled "a delivery plan generating method, device, and system for delivering vehicles" with application number 201710630010.7, application date of 2017, month 07, and 28.

Technical Field

The invention relates to the technical field of Vehicle Routing Problem (VRP), in particular to a method, a device and a system for generating a delivery plan of a delivery Vehicle.

Background

The Vehicle Route Problem (VRP) refers to a certain number of customers, each having a different number of goods, and the distribution center provides the customers with goods, and a fleet of vehicles is responsible for distributing the goods and organizing appropriate driving routes, so as to meet the needs of the customers and achieve the purposes of shortest route, minimum cost, minimum time consumption and the like under certain constraints.

The existing solving method of the related vehicle route problem comprises an exact algorithm (exact algorithm) and a heuristic solution (heuritics), wherein the exact algorithm comprises a branch boundary method, a branch cutting method, a set covering method and the like; the heuristic solution includes a saving method, a simulated annealing method, a deterministic annealing method, a tabu search method, a Genetic Algorithm, a neural network, an ant colonizer Algorithm, a Genetic Algorithm (GA), and the like. In the automatic generation of a vehicle distribution plan, a Large Neighborhood Search (LNS), which is generally one of Neighborhood Search methods, is effective, and the LNS is used to Search an optimal distribution task distribution pattern for vehicles. In general, the search is repeated in a direction of reducing the cost by digitizing the difference (sum of costs) from the optimal solution so as to approach the optimal solution.

In some application scenarios of the VRP, the distribution container is required to be loaded with the distribution goods for distribution, and such a scenario usually requires returning the empty container after the goods distribution is completed. For example, in a manufacturing logistics schedule including automobile parts distribution, since the number of distribution containers is limited and the distribution containers differs for each supplier, it is often necessary to return empty containers to the supplier immediately after distribution. Because of such special requirements, it is technically difficult to achieve the order between the delivery tasks by using only the neighborhood search algorithm for the application scenario, and therefore the existing algorithm is not practical for making a delivery plan including returning empty containers, and most of the logistics industry is currently implementing a delivery plan manually making the application scenario.

Disclosure of Invention

The technical problem to be solved by the embodiments of the present invention is to provide a method, an apparatus, and a system for generating a delivery plan of a delivery vehicle, which are used to automatically generate a delivery plan including delivery requirements for returning an empty container to a supplier after delivery, thereby improving the generation efficiency of the delivery plan and reducing the labor cost.

To solve the above-described problems, an embodiment of the present invention provides a delivery plan generating method for outputting a delivery order of picking up and delivering goods among a plurality of stations by a plurality of delivery vehicles,

evaluating the candidate delivery plan according to whether an empty container return task and an associated cargo delivery task in the candidate delivery plan are allocated to the same delivery vehicle and whether the empty container return task and the associated cargo delivery task are executed within a predetermined time, and obtaining an evaluation result;

outputting one or more candidate delivery plans as a final delivery plan according to the evaluation result of the candidate delivery plans;

the execution includes that the empty container returning task and the associated goods distribution task are executed simultaneously within the preset time, or the empty container returning task is after the associated goods distribution task, and no other distribution task exists between the empty container returning task and the associated goods distribution task.

An embodiment of the present invention further provides a delivery plan generating apparatus for outputting a delivery order of picking up and delivering goods among a plurality of stations by using a plurality of delivery vehicles, including:

a delivery plan evaluation unit for evaluating the candidate delivery plan to obtain an evaluation result, based on whether an empty container return task and a related cargo delivery task in the candidate delivery plan are assigned to the same delivery vehicle and whether the empty container return task and the related cargo delivery task are executed within a predetermined time when assigned to the same delivery vehicle;

a delivery plan output unit configured to output one or more candidate delivery plans as a final delivery plan based on an evaluation result of the candidate delivery plans;

An embodiment of the present invention further provides a delivery plan generating system, including: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps of the delivery plan generating method as described above.

An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the delivery plan generating method described above are implemented.

Compared with the prior art, the delivery plan generating method, the device and the system provided by the embodiment of the invention introduce the task cost of the empty container return task into the total cost of the candidate delivery plan, and the optimal task cost is configured in the first delivery mode in advance, so that the expected delivery sequence returned by the empty container can be automatically output by the algorithm, the requirement of empty container return in the actual logistics scene is met, the manual mode for making the delivery plan is avoided, the making cost of the delivery plan is reduced, and the generating efficiency of the delivery plan is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

Fig. 1 is a flowchart of a delivery plan generating method according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of a delivery plan generating apparatus according to an embodiment of the present invention;

fig. 3 is a block diagram illustrating an overall structure of a delivery plan generating system according to an embodiment of the present invention;

FIG. 4 is a flowchart illustrating an exemplary delivery plan generating method according to an embodiment of the present invention;

FIG. 5 is a diagram of an example of site management data in an embodiment of the invention;

FIG. 6 is a diagram showing an example of vehicle management data in the embodiment of the present invention;

FIG. 7 is a diagram illustrating an example of distributing task data in an embodiment of the invention;

FIG. 8 is an exemplary diagram of input data generated in an embodiment of the present invention;

FIG. 9 is a flowchart illustrating an exemplary process of appending empty container return tasks in accordance with an embodiment of the present invention;

FIG. 10 is a flowchart illustrating an example of appending an empty container pick task in accordance with an embodiment of the present invention;

FIG. 11 is an exemplary diagram of inter-site distance matrix data in an embodiment of the invention;

fig. 12 is a flowchart of an example of the mixable determination processing of an empty container in the embodiment of the present invention;

FIG. 13 is an exemplary flow chart of the total cost calculation process in an embodiment of the present invention;

FIG. 14 is a flowchart of an example of a process of violating the same vehicle enforcement constraints in an embodiment of the present invention;

FIG. 15 is a diagram of an example of output data in an embodiment of the present invention;

FIGS. 16A-16B are diagrams of an example of an output screen generated in an embodiment of the present invention;

FIG. 17 is a block diagram of another embodiment of a delivery plan generating system;

fig. 18 is a schematic diagram of processing and data connection in another system block diagram shown in fig. 17.

Detailed Description

In order to make the technical problems, technical solutions and advantages of the present invention more apparent, the following detailed description is given with reference to the accompanying drawings and specific embodiments. In the following description, specific details such as specific configurations and components are provided only to help the full understanding of the embodiments of the present invention. Thus, it will be apparent to those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the invention. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In various embodiments of the present invention, it should be understood that the sequence numbers of the following processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

Referring to fig. 1, an embodiment of the present invention provides a delivery plan generating method for outputting an optimal sequence of delivery tasks for picking up and delivering goods by using a plurality of delivery vehicles to travel to a plurality of stations, as shown in fig. 1, the method including:

step 11 evaluates the candidate delivery plan based on whether the empty container return task and the associated cargo delivery task in the candidate delivery plan are assigned to the same delivery vehicle and whether the empty container return task and the associated cargo delivery task are executed within a predetermined time, and obtains an evaluation result.

The delivery tasks according to the embodiment of the present invention include a cargo delivery task of delivering cargo from one station (e.g., a delivery origin station) to another station (a delivery destination station), and for the cargo delivery task, may further include an empty container return task of returning an empty container from the delivery destination station to the delivery origin station. Therefore, each empty container returning task has one cargo delivery task associated therewith, but the cargo delivery task may or may not have a task associated therewith. Here, the performing within the predetermined time includes the empty container returning task being performed simultaneously with the associated goods delivery task, or the empty container returning task being subsequent to the associated goods delivery task without other delivery tasks therebetween.

In the embodiment of the present invention, when evaluating and evaluating the candidate delivery plan, different task costs may be set for the empty container return task according to whether the empty container return task and the associated cargo delivery task are assigned to the same delivery vehicle, and whether the empty container return task and the associated cargo delivery task are executed within a predetermined time; then, the task costs in the candidate delivery plan are summed up to obtain the total cost of the candidate delivery plan as the evaluation result of the candidate delivery plan.

And a step 12 of outputting one or more candidate delivery plans as a final delivery plan based on the evaluation results of the candidate delivery plans.

Here, in order from the lowest total cost candidate delivery plan to the highest total cost candidate delivery plan, 1 or more candidate delivery plans may be selected and output as the final delivery plan.

Through the steps, the task cost of the empty container return task in different delivery modes is considered in the total cost of the candidate delivery plan, the expected delivery sequence returned by the empty container can be automatically output by the algorithm, the requirement of the empty container return in the actual logistics scene is met, the delivery plan is prevented from being made manually, the making cost of the delivery plan is reduced, and the generation efficiency of the delivery plan is improved.

In the embodiment of the present invention, the candidate delivery plan includes the execution order of the delivery tasks and the delivery vehicles to be distributed. Specifically, for the distribution tasks to be distributed (including the cargo distribution task and the empty container return task), a Search Algorithm such as a Genetic Algorithm (GA) or a Large Neighborhood Search (LNS) may be used to approach the optimal solution through multiple searches, and a plurality of distribution plans obtained in the Search process may be obtained, and these distribution plans may be used as candidate distribution plans.

The search process may be terminated after the execution reaches a predetermined upper limit of the number of searches, or the extraction may be terminated before the execution reaches the predetermined upper limit of the number of searches, for example, when the obtained candidate delivery plan has satisfied a predetermined condition, specifically: if the delivery vehicles required for the candidate delivery plan are equal to or less than a predetermined first threshold value, the search may be interrupted and the obtained candidate delivery plan may be output. For another example, when the sum of the number y1 and the number y2 is equal to or less than a predetermined second threshold value, the search process may be terminated early, where y1 denotes the number of empty container return tasks that are present in the candidate delivery plan and to which delivery vehicles different from the associated cargo delivery tasks are assigned, and y2 denotes the number of empty container return tasks that are not executed within the predetermined time from the associated cargo delivery tasks although the same vehicles are assigned to the associated cargo delivery tasks.

In the search process of the search algorithm, when the number of empty container return jobs, which are present in the current candidate delivery plan and to which delivery vehicles different from the associated cargo delivery jobs are assigned, is above a predetermined second threshold value, the delivery jobs in the current candidate delivery plan may be adjusted or the current candidate delivery plan may be discarded. The adjusting may include: the delivery order of the empty container return tasks to which the delivery vehicles are assigned differently from the associated cargo delivery tasks is adjusted, for example, by inserting the empty container return tasks at another position in the current candidate delivery plan or exchanging the delivery order with another delivery task.

The total cost includes the task cost of the empty container return task. In order to achieve the purpose of returning the empty container immediately after the goods are delivered, the embodiment of the present invention may set different task costs for the empty container returning task, and when the empty container returning task and the associated goods delivery task are assigned to the same delivery vehicle and the empty container returning task and the associated goods delivery task are executed within the predetermined time, the empty container returning task has the lowest task cost. By introducing the task cost described above into the candidate delivery plan, the embodiment of the present invention can obtain a desired delivery plan by taking into account the influence of the order between the delivery tasks in the delivery plan.

In the embodiment of the invention, different task costs can be set for the empty container returning task according to whether the empty container returning task and the associated cargo delivery task are distributed to the same delivery vehicle or not and whether the empty container returning task and the associated cargo delivery task are executed within the preset time, so as to guide the algorithm to output the expected delivery mode. As a specific implementation, it may be preset that the empty container return task has a first task cost in the first distribution mode, a second task cost in the second distribution mode, a third task cost in the third distribution mode, and a fourth task cost in the fourth distribution mode. The first distribution mode is that an empty container returning task and an associated cargo distribution task are distributed to the same distribution vehicle, and whether the empty container returning task and the associated cargo distribution task are executed within the preset time is judged; the second distribution mode is as follows: the empty container returning task and the associated cargo delivery task are assigned to the same delivery vehicle, and the empty container returning task is located after the associated cargo delivery task, with other delivery tasks in between. The third distribution mode is as follows: the empty container return task is assigned the same delivery vehicle as the associated cargo delivery task, but the empty container return task precedes the associated cargo delivery task. The fourth distribution mode is as follows: the empty container return task and the associated cargo delivery task are assigned different delivery vehicles.

Here, the first task cost, the second task cost, the third task cost, and the fourth task cost sequentially increase. The different task costs of the different delivery modes above indicate that the first delivery mode is the most desirable delivery mode for the empty container return task in the embodiment of the present invention.

In addition to accounting for the mission cost of the empty container return mission, embodiments of the present invention may also account for the delivery distance cost in the total cost of the candidate delivery plan. Different candidate delivery plans may have different delivery vehicle routes and therefore different delivery distances, corresponding to different delivery distance costs. In step 12, the delivery distance cost of each delivery task in the candidate delivery plan and the task cost of the empty container return task in the candidate delivery plan may be counted; and obtaining the evaluation result of the candidate delivery plan according to the delivery distance cost and the task cost. For example, different weights may be set for the delivery distance cost and the task cost, and the delivery distance cost and the task cost may be weighted and summed to obtain the evaluation result of the candidate delivery plan.

It should be noted that the embodiment of the present invention may also consider more factors in the evaluation result, such as the time consumed for distribution, the distribution road cost (for example, different roads may have different costs, and expressways may need additional passing fees, etc.), etc., which may be considered in the search by the search algorithm, and will not be further described herein.

As one implementation, when one candidate delivery plan (hereinafter, referred to as a current candidate delivery plan) generated by a search algorithm is obtained, the embodiment of the present invention may determine the number of empty container return tasks that are present in the candidate delivery plan and to which delivery vehicles other than the associated cargo delivery tasks are allocated. If the number exceeds a preset threshold, the delivery tasks in the candidate plans are adjusted, or the candidate delivery plans are abandoned.

The embodiment of the invention can preset a mixed loading capacity for judging whether mixed loading can be carried out, wherein the mixed loading capacity has an upper limit value M_max(ii) a Setting the mixed load capacity of the distribution tasks which cannot be mixed loaded as the upper limit value M_maxSetting the mixed load capacity of the distribution tasks which can be mixed loaded to be far less than M_maxA positive number K, the value of which can be set with reference to the number S of delivery tasks, for example, less than M_maxA value of/S. Further, the delivery vehicles may be provided with a delivery capacity for determining whether or not the mixed loading is possible, and the cargo loaded by the delivery vehicles at the same time cannot exceed the delivery capacity. As an example, an upper limit value M of the loading capacity is set_maxThe number 1 is set to 0.01, which is the mixed load capacity of the distribution tasks that can be mixed loaded. On-line confirmationWhen a delivery vehicle violating the preset limit condition in the current candidate delivery plan is determined, the mixed capacity of all delivery tasks delivered by the delivery vehicle is accumulated for each delivery vehicle in the candidate delivery plan, and if the mixed capacity is larger than or equal to the mixed capacity, the setting condition that the delivery vehicle violates the unmixed capacity of the delivery tasks is determined.

Whether or not a certain delivery task can be mixed may be determined by the task attribute of the delivery task. When the distribution tasks to be distributed are obtained, task attributes can be specified, and the task attributes can include indication information of whether mixed loading is available. And for the empty container returning task, if the associated goods distribution task is not mixedly loaded, the empty container returning task is defaulted to be not mixedly loaded. Of course, when the cargo distribution task associated with the empty container returning task is not mixable, it may also be specifically indicated that the empty container returning task is mixable.

As one implementation, when one candidate delivery plan (hereinafter, referred to as a current candidate delivery plan) is obtained, the embodiment of the present invention may determine whether there is a delivery vehicle exceeding the mixed capacity in the candidate delivery plan; when there is a delivery vehicle exceeding the mixed capacity in the candidate delivery plan, the delivery task in the candidate plan is adjusted or the candidate delivery plan is discarded.

When it is determined whether or not there is a delivery vehicle exceeding the mixed capacity in the candidate delivery plan, the delivery vehicles in the candidate delivery plan may be identified as the delivery vehicles in the candidate delivery plan, the links between the adjacent stations through which the delivery vehicle passes may be identified, the mixed capacity of all the delivery tasks of the delivery vehicle on the link may be accumulated, and if the mixed capacity is greater than or equal to the upper limit value of the mixed capacity, the delivery vehicles exceeding the mixed capacity may be identified as being present. Alternatively, one or more delivery vehicles passing through the link between the adjacent stations of the candidate delivery plan may be identified, the mixed capacity of all delivery tasks for each delivery vehicle on the link may be accumulated, and if the mixed capacity is greater than or equal to the upper limit value of the mixed capacity, it may be determined that there is a delivery vehicle exceeding the mixed capacity.

Further, in addition to the mixed capacity, the embodiment of the present invention may further set more restriction conditions to determine that the delivery vehicle satisfies the conditions. At this time, it may be determined whether there is a delivery vehicle violating the preset vehicle limit condition in the current candidate delivery plan. When a delivery vehicle violating a preset vehicle limit condition exists in the current candidate delivery plan, the delivery tasks in the candidate delivery plan are adjusted, or the current candidate delivery plan is abandoned, and the total cost is not calculated for the current candidate delivery plan. If no delivery vehicle violating the preset vehicle limit condition exists, the cost of each delivery task in the current candidate delivery plan is counted to obtain the total cost of the candidate delivery plan.

Here, the preset vehicle limitation conditions include: the total cargo volume of the vehicle does not exceed the upper volume limit of the vehicle, or the total cargo weight of the vehicle does not exceed the upper load limit of the vehicle, or the vehicle does not violate the set condition of the immiscible loads of the delivery tasks.

Further, in the embodiment of the present invention, after obtaining one candidate delivery plan (which is the current candidate delivery plan), if it is determined that there is no delivery vehicle violating the preset vehicle limit condition in the current candidate delivery plan, then it is further possible to continue determining the first number of empty container return jobs, which are different from the associated delivery job assignments for the delivery vehicles, in the current candidate delivery plan: when the first number exceeds a preset first threshold, adjusting delivery tasks in a candidate plan, or abandoning the current candidate delivery plan; and when the first quantity does not exceed the preset first threshold, counting the task cost of each delivery task in the current candidate delivery plan to obtain the total cost of the candidate delivery plan. The preset first threshold may be set according to the total number of tasks to be delivered, the requirement for cost, and other factors.

It should be noted that the distribution task to be allocated in the embodiment of the present invention may be a distribution task that is generated based on a cargo distribution task provided by a user and includes a cargo distribution task and an empty container return task. Specifically, for example, when the delivery task provided by the user only includes a cargo delivery task, the embodiment of the present invention may determine the cargo delivery task that needs to return an empty container after cargo delivery; and adding a related empty container returning task for the goods distribution task needing to return the empty container, and marking the execution sequence of the related empty container returning task to be after the goods distribution task needing to return the empty container after goods distribution.

Here, the task attribute of the cargo delivery task may be analyzed to determine whether the cargo delivery task needs to return an empty container. When a user provides a certain cargo delivery task, the task attribute of the task needs to be specified, and the task attribute generally includes information such as a starting station, an ending station, delivery time requirements, cargo volume and weight information, whether mixed loading is available, whether empty containers need to be returned, and the like of the cargo delivery task.

Considering that the empty container is not at the starting station of the cargo distribution task sometimes, the empty container needs to be picked up from other stations, then the empty container is loaded at the starting station, and then the empty container is distributed to the destination station. Therefore, after at least one goods delivery task provided by a user is obtained, the embodiment of the invention can determine that the goods delivery task of taking goods from an empty container is required to be carried out from other sites except for a delivery starting site before goods delivery; and adding an associated empty container picking task for the goods distribution tasks needing to take the empty containers from other stations except the distribution starting station, and identifying that the execution sequence of the associated empty container picking task is before the goods distribution tasks needing to take the empty containers from other stations except the distribution starting station.

Through the above manner, the embodiment of the invention can generate the delivery tasks to be distributed based on the goods delivery tasks provided by the user, specifically can include the goods delivery tasks, and can also include one or both of the empty container picking task and the empty container returning task.

In order to identify a certain delivery task in the search algorithm, the embodiment of the present invention allocates a task identification ID uniquely identifying the delivery task to all the delivery tasks, and establishes an association relationship for the delivery tasks having an association relationship, for example, establishes an association relationship for an associated empty container pickup task and a cargo delivery task, and establishes an association relationship for an associated cargo delivery task and an empty container return task.

In the embodiment of the present invention, when the candidate delivery plan of the delivery task to be distributed is generated by the search algorithm, an upper limit of the number of search times may be set. And when the searching times reach the upper limit value, the searching process is quitted, and the candidate delivery plan is output. In the search process, in order to accelerate the convergence process, the following process can be performed:

in the process of repeatedly generating the candidate delivery plan until the upper limit of the preset search frequency is reached according to the preset search algorithm, if the number of empty container returning tasks, to which delivery vehicles different from the associated cargo delivery tasks are assigned, in the candidate delivery plan obtained when the generation frequency reaches the preset frequency is larger than a preset value, then:

dividing distribution tasks in an original task group into two groups, wherein empty container return tasks and related distribution tasks of different distribution vehicles allocated to the related goods distribution tasks are divided into a first task group, the rest distribution tasks are divided into a second task group, and the initial value of the original task group is the distribution tasks to be distributed;

according to a preset search algorithm, respectively generating candidate delivery sub-plans for the first task group and the second task group to obtain a first candidate delivery sub-plan and a second candidate delivery sub-plan;

if an empty container return task to which a delivery vehicle different from the associated cargo delivery task is assigned exists in the first candidate delivery sub-plan, taking the first task group as the original task group, and returning to the step of dividing the delivery tasks in the original task group into two groups;

if there is no empty container return task to which a delivery vehicle different from the associated cargo delivery task is assigned in the first candidate delivery sub-plan, the first candidate delivery sub-plan and all the second candidate delivery sub-plans are aggregated to obtain a candidate delivery plan of the delivery task to be assigned.

Through the mode, the embodiment of the invention can accelerate the convergence process of the algorithm and improve the search efficiency.

The delivery plan generating method of the delivery vehicle of the embodiment of the invention is described above. It can be seen that, in the above embodiments of the present invention, by adding the associated empty container return task to the cargo delivery task having the empty container return requirement, and setting different task costs for the empty container return task in the delivery plan search process, the search algorithm can automatically generate and output the delivery plan of the desired delivery order, thereby improving the generation efficiency of the delivery plan including the delivery requirement for returning the empty container to the supplier after delivery.

An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps in the delivery plan generating method in any one of the above-mentioned method embodiments.

Based on the method, the embodiment of the invention also provides a device for implementing the method. Referring to fig. 2, a delivery plan generating apparatus 20 according to an embodiment of the present invention includes:

a delivery plan evaluation unit 21 for evaluating the candidate delivery plan to obtain an evaluation result, based on whether or not an empty container return task and a related cargo delivery task in the candidate delivery plan are assigned to the same delivery vehicle and whether or not the empty container return task and the related cargo delivery task are executed within a predetermined time when assigned to the same delivery vehicle;

a delivery plan output unit 22 that outputs one or more candidate delivery plans as a final delivery plan based on the evaluation results of the candidate delivery plans;

Preferably, the delivery plan evaluation unit 21 includes:

the task cost counting unit is used for setting different task costs for the empty container returning task according to whether the empty container returning task and the associated cargo distribution task are distributed to the same distribution vehicle or not and whether the empty container returning task and the associated cargo distribution task are executed within preset time or not; the task costs in the candidate delivery plan are summed up to obtain the total cost of the candidate delivery plan as the evaluation result of the candidate delivery plan.

Preferably, the delivery plan generating device further includes:

a delivery plan analysis unit for determining the number of empty container return tasks of delivery vehicles different from the associated cargo delivery tasks, which are present in the candidate delivery plan; and when the number exceeds a preset threshold, adjusting the delivery tasks in the candidate plans, or abandoning the candidate delivery plans.

Preferably, the delivery plan generating device further includes:

the system comprises a capacity setting unit and a mixed loading unit, wherein the capacity setting unit is used for setting a delivery capacity for judging whether mixed loading is possible or not for a delivery vehicle in advance, and setting a mixed loading capacity for judging whether mixed loading is possible or not for delivery tasks in advance, the mixed loading capacity has an upper limit value, and the mixed loading capacity of the delivery tasks which are not mixed loading is set to be the upper limit value.

Preferably, the delivery plan generating device further includes:

a mixed load judgment unit for judging whether there is a delivery vehicle exceeding the mixed load capacity in the candidate delivery plan after the candidate delivery plan is generated by the search algorithm; when there is a delivery vehicle exceeding the mixed capacity in the candidate delivery plan, the delivery task in the candidate plan is adjusted or the candidate delivery plan is discarded.

Specifically, the mixed loading determination means may determine, for the delivery vehicles of the candidate delivery plan, the links between adjacent stops through which the delivery vehicle passes, when determining whether or not there is a delivery vehicle exceeding the mixed loading capacity, accumulate the mixed loading capacity of all the delivery tasks of the delivery vehicle on the link, and determine that there is a delivery vehicle exceeding the mixed loading capacity if the mixed loading capacity is greater than or equal to an upper limit value of the mixed loading capacity; alternatively, one or more delivery vehicles passing through the link between the adjacent stations of the candidate delivery plan are identified, the mixed loading capacity of all delivery tasks of each delivery vehicle on the link is respectively accumulated, and if the mixed loading capacity is larger than or equal to the upper limit value of the mixed loading capacity, the delivery vehicles exceeding the mixed loading capacity are identified.

Preferably, the delivery plan generating device further includes:

a delivery plan generating unit configured to repeat generation of the candidate delivery plan until reaching an upper limit of a preset number of search times according to a predetermined search algorithm, and if the number of empty container return jobs to which delivery vehicles different from the associated cargo delivery jobs are allocated in the candidate delivery plan obtained when the number of generation times reaches the predetermined number of times is greater than a predetermined value:

Preferably, in the delivery plan generating device, the delivery plan evaluating means 21 is further configured to calculate a sum of the total cost and a delivery distance cost of the delivery task in the candidate delivery plan as an evaluation result of the candidate delivery plan.

An embodiment of the present invention further provides a system for generating a delivery plan of a delivery vehicle, including: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps of the delivery plan generating method in any of the above-described method embodiments.

Fig. 3 is a block diagram showing an example of the overall configuration of the delivery plan generating system according to the embodiment of the present invention. Fig. 13 illustrates a computer alone as an example. The computer 100 is composed of a processor (CPU)104, a main storage 105, a secondary storage 106, a main bus 103, a video card 107, a Network Interface Card (NIC)108, and a video output port 109. The computer 100 can input and output data to and from the outside of the computer through the NIC108 and can output a screen to an external display device through the video output port 109. In actual structure, besides the modules listed in fig. 3, an input device such as a keyboard and a mouse may be included.

The secondary storage device 106 stores various input data and program modules required for arithmetic processing in the embodiment of the present invention, such as a data input processing module 1061, a calculation condition setting processing module 1062, an optimal solution search processing module 1063, a delivery plan output processing module 1064, site management data 1065, vehicle management data 1066, delivery task data 1067, and road vector data 1068. When the arithmetic processing is executed, the data of the secondary storage device 106 is read as appropriate by the i/o/calculation execution processing unit 1051 in the main storage device 105, and the search processing is performed in conjunction with the inter-site distance data 1052, thereby outputting the delivery plan.

To assist in understanding the above aspects of the embodiments of the present invention, the following describes the method of the embodiments of the present invention in more detail through several exemplary specific flows.

Referring to fig. 4, an exemplary process of a delivery plan generating method for delivering vehicles according to an embodiment of the present invention includes:

in the read data step 210, the site management data 1065, the vehicle management data 1066, and the delivery task data 1067 are read. Thereafter, the calculation condition setting 220 is performed as a preprocessing in the main arithmetic processing step 230. In the main calculation loop processing 230, the generation of the delivery plan is repeated in order to obtain the optimal delivery plan.

Before each time the delivery plan is generated, it is determined whether the upper limit of the predetermined number of search cycles is reached in step 231, and if so, the routine proceeds to step 240 to output the delivery plan, and if not, the delivery plan candidates are generated in step 232.

In step 232, a candidate delivery plan is obtained by searching with a search algorithm, such as an LNS algorithm or a GA algorithm, and in step 233, it is determined whether the generated candidate delivery plan violates a mandatory constraint, and if so, the current candidate delivery plan is adjusted, or the current candidate delivery plan is discarded and the process returns to step 232 to regenerate the candidate delivery plan; if not, the total cost of the current candidate delivery plan is calculated in step 234.

Here, the mandatory constraints may include the aforementioned preset vehicle restrictions. Further, the mandatory constraints may further include: a first number of empty container return assignments present in the candidate delivery plan that have different delivery vehicle assignments than the associated cargo delivery assignment is less than a first threshold. When the mandatory constraint is violated and the candidate delivery plan needs to be regenerated, the delivery job related to the violation of the mandatory constraint may be inserted into another position in the current candidate delivery plan or exchanged with another delivery job in the current candidate delivery plan in terms of delivery order.

In step 235, it is determined whether the search process can be ended in advance, and if so, step 240 is entered, and if not, step 231 is returned to. For example, if the delivery vehicles required by the current candidate delivery plan are below a predetermined first threshold and/or the number of empty container return jobs that are different from the delivery vehicles to which the associated cargo delivery jobs are assigned, which are present in the current candidate delivery plan, are below a predetermined second threshold, the search process may be terminated early.

In step 240, one or more delivery plans may be output as the final delivery plan according to the order of the total cost of the currently obtained candidate delivery plans from low to high.

Fig. 5 to 7 show an example of the data format read in the read data step 210.

The site management data 1065 in fig. 5 includes: the station name 411, the latitude 412 and longitude 413 indicating the station position, the area 414 to which the station belongs, the type of vehicle supported by the station (i.e., the type of vehicle that the station can accept delivery) 415, the operation start time 416 and the operation end time 417 of the station, and the time required for unloading 418.

The vehicle management data 1066 in fig. 6 includes: vehicle ID431 for uniquely identifying the vehicle, vehicle type 432 of the vehicle, driver or contact 433, departure station 434 and end station 435 of the vehicle, upper limit 436 of vehicle volume (number of cubic meters/pallet, etc.), upper limit 437 of vehicle load (t or kg, etc.), start time 438 of operation of the vehicle, end time 439 of operation, zone 440 of jurisdiction of the vehicle, and the like.

The delivery task data 1067 of fig. 7 includes: a delivery date 451 of the delivery task, a start site 452 as a delivery source, a destination site 453 as a delivery destination, a delivery deadline 454 for obtaining the shipment from the delivery source, a delivery deadline 455 for delivering the shipment to the delivery destination, a volume 456 of the shipment to be delivered, a model type 458 when there is a limitation on the model that can be delivered, whether or not it is necessary to return an empty container 459, whether or not it is mixable with other delivery tasks, and the like.

In the calculation condition setting step 220, the input data 500 shown in fig. 8 is generated using the site management and delivery task data. Since the delivery job data 1067 in fig. 7 cannot directly reflect the empty container return to the plan in the calculation processing of the delivery plan creation algorithm, the empty container return job is created by the processing of the calculation condition setting step 220 described in fig. 9 before the main calculation loop processing 230.

As shown in fig. 9, the calculation condition setting step 220 performs calculation loop processing for all delivery tasks to be delivered by the user. In step 221, it is determined whether all the distribution tasks have been traversed, and if so, the input data similar to that shown in fig. 8 is output; if not, selecting an unprocessed delivery task i in step 222, and determining whether the delivery task i needs to return an empty container in step 223, if not, returning to step 221; if necessary, an empty container returning task j is added to the delivery task i in step 224, and it is determined in step 225 whether or not the empty container returning task j can be mixed. The determination as to whether or not the delivery task i needs to return the empty container may be made by referring to fig. 7, which shows whether or not the task needs to return the empty container 459, and when the return is needed, the empty container return task is added.

Taking the delivery job data 461 in fig. 7 as an example, since the empty container return 459 is "main", the next empty container return job J001_01 is added to the first delivery job J001 in fig. 8. At this time, J001 is filled in the related task ID of fig. 8 in order to pair with the original distribution task J001. Here, the task order 519 represents the sequential relationship between the current task and the associated task ID 520. For example, NEXT541 indicates that the current task J001_01 is located after task J001 indicated by the associated task ID 520.

When determining whether or not the empty container return task j is mixable in step 225, the mixable possibility 521 in fig. 8 may be set with reference to the mixable possibility 460 in fig. 7, that is, in the mixable possibility determination processing 225 in fig. 9, if the original transfer is not mixable, the empty container is returned as a non-mixable. Of course, the embodiment of the present invention may also adopt an asymmetric processing mode, that is, the original dispensing is not mixable, and the empty container is returned and mixable.

In the task assignment process of the delivery plan creation algorithm, in order to prevent the empty container return task that cannot be mixed with other tasks from being mixed, another capacity different from the volume V and the weight W is introduced, which is referred to herein as mixed capacity M, and added to the delivery task. In the example of fig. 9, the upper limit of the mix capacity of all vehicles is set to 1.0, and the mix capacity of the empty container returning task i, which cannot be mixed, is set to 1.0 in step 226. Thus, when the mixed load capacity on the delivery task side is 1.0, the capacity is full, and at this time, even if the capacity V and the weight W are surplus, the mixed load with another task is no longer possible.

On the other hand, when the mixability determination process 225 determines that the mixability is acceptable, a very small value larger than 0, for example, smaller than M as described above is set for the mixability of the empty container returning task i in step 227_maxA value of/S. The volume 516 and the weight 517 of the empty container return job are individually specified, and for example, the volume may be set to 15% of the original distribution job in step 227.

Finally, for the original distribution task and the empty container return task, the completion processing is performed for the vacant place in the delivery deadline 454 and the delivery deadline 455 in fig. 7. In a place where there is no time in the deadline, the business completion time of the site may be input with reference to the site management data of fig. 5. For another example, since the empty container return task has substantially no time designation, the business hours of the site can be all entered. If the business hours of the respective sites are not specified, the sites are specified as default values (for example, 8:00 to 17: 00). Thereby, input data as shown in fig. 8 is obtained. Note that fig. 8 shows an example in which the mixed capacity setting process is performed before the main arithmetic processing step 230 after the input data is specified, but the input data itself may include the mixed capacity.

The processing of adding the empty container return task in fig. 9 is a case (case) where the empty container needs to be returned after the delivery task. As another case, before a delivery task, picking up of an empty container (pickup) needs to be performed at another site different from the starting site of the delivery task, which corresponds to the case (case) of the delivery task 462 of fig. 7, and one way of processing thereof is as shown in fig. 10. In the case (case) of the delivery task 462 in fig. 7, whether or not the empty container return 459 is required is "a priori", specifically, the empty container is first picked up at the delivery destination station B, then the goods are loaded again at the station C and delivered to the station B, and finally the empty container is returned to another station 1. That is, as shown in fig. 10, the calculation condition setting step 220 first performs calculation loop processing for all the delivery jobs to be delivered provided by the user, and determines whether or not an empty container pick-up job needs to be added. In step 221a, it is determined whether all the distribution tasks have been traversed to process the empty container pick-up task, and if so, step 221 of fig. 9 is entered to further determine whether all the distribution tasks have been traversed to process the empty container return task; if the empty container picking task is not traversed, an unprocessed delivery task is selected as the current delivery task in step 222a, and it is determined whether the current delivery task needs to pick up an empty container to another site in step 223a, if so, the empty container picking task is added to the current task in step 224a, and then the process returns to step 221 a. Specifically, when the empty container pickup task is added, the relevant parameters in the task may be set in a similar manner with reference to the empty container return task.

According to the delivery job 462 of fig. 7, a pick-up job J002 of empty containers and an empty container return job J002_02 of empty containers are generated for the delivery job of fig. 7, respectively. Here, in order to sequentially perform empty container pickup, cargo delivery, and empty container return, the previous task ID is set for the associated task ID of J002_01 and J002_ 02. In actual delivery, there may be a case where the delivery is completed at the stage of delivery to the destination site B without returning the empty container to a certain site 1 after the delivery task, or a case where the empty container is picked up at another site other than the delivery destination B, and for the above various possible cases, it is sufficient to change the configuration adaptively according to the traffic requirements and output appropriate input data 500. In this example, although the input data 500 is generated from the delivery job 1067 in the calculation condition setting step 220, in concrete implementation, the input data 500 may be directly input by skipping the calculation condition setting step 220, that is, the association relationship between a plurality of jobs such as the empty container return job may be defined by directly inputting the job order 519 and the associated job ID 520.

Fig. 11 shows one data form of the inter-site distance matrix data 1052 required in the main operation loop processing 230. The inter-site distance matrix data is two-dimensional row and column data formed by digitizing distances (or travel times) for all combinations of sites. Since the traveling routes to and from two stops are different, the number of all the distances is N × N (N-1) when the number of stops is N. The distance between 2 stations is obtained by a program using a shortest path calculation algorithm (such as dijkstra algorithm) with road vector data as input. This data 1052 is newly generated using the site management data 1065 before the main arithmetic cycle processing 230, or is read into the i/o/calculation execution processing unit 1051 of the main storage device by inputting the already generated data, so that high-speed arithmetic processing can be directly performed.

The parameter such as the loading capacity set in fig. 9 can be used in the violating mandatory constraint condition processing step 233 in the main calculation loop processing 230. Here, the mandatory constraints may be set with reference to the aforementioned preset vehicle restrictions, including: the total cargo volume of the vehicle does not exceed the upper volume limit of the vehicle, or the total cargo weight of the vehicle does not exceed the upper load limit of the vehicle, or the vehicle does not violate the set condition of the immiscible loads of the delivery tasks. If any one of the above conditions is violated, it indicates that the mandatory constraint condition is violated.

Fig. 12 shows an example of the mixable determination process including an empty container. In the output candidate delivery plan of the delivery plan candidate generation 232, the vehicles assigned to the delivery tasks are checked one by one (step 2331), and when the vehicle capacity exceeds the vehicle capacity upper limit (step 2332), the load upper limit (step 2333), or the turbid capacity upper limit (step 2334), it is determined that the mandatory constraint condition is violated (step 2336), and the process returns to the delivery plan candidate generation 232 again; otherwise, it is determined that the mandatory constraint is satisfied (step 2335) and the overall cost calculation is entered at step 234. Of course, the embodiment of the present invention may implement the above-described determination 233 process itself that violates the mandatory constraint condition in the delivery plan candidate generation 232.

Specifically, taking the output data 550 of fig. 15 as an example, for all delivery vehicles assigned by the current candidate delivery plan, the volume increases and decreases 570 are added in chronological order 564 to obtain the total volume, and the weight increases and decreases 571 are added to obtain the total weight, and when the state 585 is moving, it is determined whether or not the total volume and the total weight exceed the upper limit values of the volume V and the weight W of the vehicle (362, 363). Similarly, it is similarly determined that the mixed load capacity M does not exceed the upper limit value of the mixed load capacity. In addition, in processing step 227 in fig. 9, when the mixed capacity is set to zero, in the determination process in step 2334, the current vehicle can be mixed even if the mixed capacity is 1, and therefore, the mixed capacity of the vehicle allowed to be mixed is set to a small positive number (for example, 0.001) of 1 or less. In fig. 12, the time for returning to the delivery plan candidate generation step 232 may be a time point when it is found that a certain parameter of the vehicle does not satisfy the corresponding mandatory constraint condition, or when a certain number of vehicles exceeding the corresponding mandatory constraint condition are reached, or when all the vehicles are judged to be completed in the delivery plan candidate.

One implementation of the process flow for the total cost calculation 234 is shown in FIG. 13. In the total cost calculation 234, the candidate delivery plans output from the delivery plan candidate generation 232 have a certain difference in the order of distribution of the delivery jobs for each delivery job from the viewpoint of the optimal solution, and the difference is digitized and output as the total cost in the calculation loop processing. First, in step 23401, it is determined whether all the distribution tasks have been processed, and if the processing is completed, the total cost is output and the process proceeds to step 235; if not, an unprocessed delivery task is extracted as the current delivery task, and it is determined whether the current delivery task is an empty container return task in step 23402. In the example of fig. 8, whether or not the task is returned for an empty container can be determined by specifying a task ID paired with the associated task ID520 and having the task order 519 be NEXT.

If it is determined in step 23402 that the current delivery task is not an empty container return task, returning to step 23401; otherwise, the process proceeds to step 23403, where it is determined whether or not a delivery task (hereinafter referred to as an original delivery task) associated with the empty container return task is assigned to the same vehicle. Specifically, in the data format of the output data 550 to be described later, whether or not the paired delivery jobs belong to the same vehicle ID562 can be determined. If the vehicle is not the same vehicle, it is determined that there is no optimal solution (is far from the optimal solution), a preset cost α is added to the total cost (step 23404), and the process returns to step 23401; whereas in the case of the same vehicle, close to the optimal solution, α may be subtracted from the total cost, or an otherwise set value (e.g., 30% of α) may be subtracted (step 23405). Here, since the addition of α is reduced from the total cost, it may be performed only by one vehicle when the vehicles are not the same vehicle. After the same vehicle determination process is performed, the routine proceeds to step 23406, where it is determined whether or not the empty container return task is executed after the original task. In the data format of the output data 550, the sequence relation of the delivery jobs can be determined by the sequence 564 of the same vehicle ID 562. The determination of the order is determined by whether the return task is loaded after the unloading of the original matched pair of delivery tasks. In this determination, there may be other delivery tasks between unloading and loading, or there may be a time interval. When the empty container return task is performed before the original task, it is far from the optimal solution, so β is added to the total cost (step 23407), and then returns to step 23401. Further, when the empty container return task is performed after the original task, β is subtracted from the total cost as in the above determination (step 23408). Finally, it is determined in step 23409 whether the empty container return task and the associated goods delivery task are performed within the predetermined time, or whether the empty container return task is performed immediately after the goods delivery task paired with the empty container return task, that is, there is no other delivery task therebetween. Specifically, the determination as to whether or not the empty container returning task is executed immediately after the paired cargo delivery task may be determined by whether or not loading of the empty container returning task is executed immediately after unloading of the cargo delivery task paired therewith. When there are other delivery tasks between the two, γ is added to the total cost (step 23410) and then returned to step 23401, otherwise γ is subtracted from the total cost (step 23409) and then returned to step 23401.

In the 3 determination processes 23403, 23406, and 23409, the constants α, β, γ determined in advance are used as the numerical values of the costs, and in the search process of the optimal solution, different costs (preferably, α > > β > > γ) are set so as to gradually approach the optimal solution. Therefore, in the calculation loop 230, the original task and the empty container return task are preferentially distributed to the same vehicle, and then, the order of the distribution tasks and the empty container return task can be realized, and finally, the distribution order without other distribution tasks between the two tasks can be considered. Here, the cost β determination processes 23406 to 23408 are processes for quickly and reliably converging on the optimal solution.

In the case where the number of delivery tasks is large, it may be difficult to converge to the optimal solution by only the total cost calculation 234, and there may be a case where delivery orders are not consistent in the delivery plan. The order inconsistency here means that the empty container return task and the associated cargo delivery task are assigned different delivery vehicles. In this case, the embodiment of the present invention may combine the determination processing of the order inconsistency with the above-described processing to improve convergence, so as to reduce or zero the delivery order inconsistency. Fig. 14 shows an example of the procedure for determining the order inconsistency, in which the delivery plan candidates generated 232 output the delivery plan candidates are determined whether or not the order inconsistency exists, and if so, the procedure returns to the delivery plan candidate generation 232 step again, so that the procedure for determining the order inconsistency can be performed inside the delivery plan candidate generation 232.

Specifically, first, after obtaining one candidate delivery plan in the delivery plan candidate generation step 232, the delivery plan candidate is set as the current candidate delivery plan, and first, it is determined in step 2321 that all delivery jobs of the current candidate delivery plan have been processed in a traversal manner, and if the processing is completed, the routine proceeds to step 233; if not, an unprocessed delivery task is extracted as the current delivery task in step 2322, and it is determined whether the current delivery task is an empty container returning task in step 2323. If it is determined in step 2323 that the current delivery task is not an empty container return task, returning to step 2321; otherwise, the process proceeds to step 2324, and it is determined whether or not a delivery task (hereinafter referred to as an original delivery task) associated with the empty container returning task is assigned to the same vehicle. If the vehicles are assigned to the same vehicle, the process returns to step 2321, otherwise, the process proceeds to step 2325 to output the judgment result of inconsistent order, and returns to the delivery plan candidate generation step 232 to regenerate a delivery plan candidate. Returning to the time of the delivery plan candidate generation step 232, when any delivery tasks with inconsistent order are found, after the traversal processing of all the delivery tasks in the current candidate delivery plan is completed, or when the delivery tasks with inconsistent order reach a predetermined number. Since the above processing is performed, there is no case where the order of the subsequently output candidate delivery plans is inconsistent, and therefore, steps 23403, 23404, and 23405 in fig. 13 may be omitted when the total cost is calculated in fig. 13.

In the delivery plan candidate generating step, there may be a certain number or more of delivery tasks whose delivery order is inconsistent in the delivery plan candidates obtained after the execution of the calculation loop for a certain number of times, and in this case, the main calculation loop processing 230 may be terminated early in the middle, and the calculation loop processing may be executed again after being divided into several times by narrowing the range of the input delivery task data.

In the input data division, for example, 2 division may be performed by grouping delivery tasks including delivery tasks whose order is inconsistent and all the delivery tasks related thereto into one group and grouping the remaining delivery tasks into another group. Then, the distribution plan candidate generation process is performed for each group.

When the candidate delivery plan is generated for the group obtained by the first 2-division, if the delivery order does not match for each group, the delivery sub-plans for each group may be aggregated to obtain the total candidate delivery plan. For example, when the delivery sub-plans of 5 delivery vehicles and 7 delivery vehicles are obtained for two groups divided into 2, a total of 12 delivery process candidate delivery plans are obtained and output as a group. When a certain packet again has a delivery order mismatch, the packet may be divided into 2 segments as described above, and the above 2-segment processing may be performed a plurality of times until each packet has no delivery order mismatch.

After the main calculation loop processing 230, the delivery plan output 240 acquires the generated delivery plan data in the form of the output data 550 shown in fig. 15, and performs display processing and the like. The delivery plan to be output is not limited to 1, and the calculation result may be selected based on a plurality of factors, for example, an appropriate delivery plan may be selected based on one or more of the factors such as the total travel distance, the total delivery time, the number of vehicles, the number of unallocated delivery tasks, and the number of delivery tasks whose order is inconsistent, and may be output in the form of the output data 550. The output data 550 outputs the operation states 565 of the vehicles (vehicle IDs 562) delivered on the delivery date 561 in chronological order 564, and the output contents further include the vehicle type 562, the starting station/destination station (566/567) during travel, the start/end times (568, 569) of the operation states 565, the volume/weight increase/decrease (570, 571) according to the previous operation states 565, and the delivery job ID572 to be loaded/unloaded. A delivery task ID typically creates two different operational states for the reason that it includes a load and a unload.

Fig. 16A to 16B show an example of an output screen generated from the output data 550 in the delivery plan output 240. Fig. 16A is a delivery schedule table 600 showing the operation state of each delivery vehicle in a line graph in time series, and fig. 16B is a delivery route 700 showing delivery stops and delivery routes included in a delivery plan on a map. Here, fig. 15 illustrates an example in which the vehicle ID562 is an output of a 0123. On the display of the distribution schedule 600, the vehicle a0123(611) is represented as a label on the vertical axis, and the specific operation state is displayed on the right side in time series (sequence 564). The output data 550 outputs 8 operation states in total, such as loading, moving, waiting, unloading, loading, noon break, moving, and unloading, but the delivery schedule 600 displays: station 1, mobile, standby, station a, noon break, mobile, station 1 total 7 states. This is because the two operation states of unloading/loading are displayed as "station a".

The delivery schedule 600 and the delivery route 700 can be coordinated with each other. For example, when only a designated vehicle on the screen of the distribution schedule 600 is displayed on the distribution route 700 and the specific time 661 is designated by the time axis on the horizontal axis in the distribution schedule 600, the planned position 731 of the vehicle and the like are displayed on the distribution route 700. When the driving state of the vehicle is "moving", in order to specify the vehicle position 731 on the map, when the moving speed is constant, the route between the destination and the departure point is subdivided, and the point at which the vehicle arrives from the departure point at the time may be set as the display position. Although fig. 16A to 16B show examples of display screen output, the same display content may be output to an output medium such as PDF or paper.

Next, another embodiment of the system block diagram according to the embodiment of the present invention will be described with reference to the block diagram of fig. 17. Fig. 17 shows a scenario in which the computer 100 of fig. 3 is divided into a server/client configuration, and the configuration of 1 server 172 and a plurality of

client computers

171 and 173 is used as an example. The server 172 and the client 171 have substantially the same hardware configuration as the computer 100 of fig. 3. The client 171 includes a CPU 1711/main storage 1713, a secondary storage 1714, a main bus 1712, a display card 1715, a Network Interface Card (NIC)1816, a video output port (not shown in the figure), and the like; the client 171 includes a CPU 1711, a main storage device 1713, a secondary storage device 1714, a main bus 1712, a display card 1715, a Network Interface Card (NIC)1716, a video output port (not shown in the figure), and the like, wherein the main storage device 1713 includes an input/output processing module 17131; the secondary storage device 1714 includes a data input processing module 17141, a delivery plan output processing module 17142, and a delivery task data module 17143. The server 172 includes a CPU1721, a primary storage device 1723, a secondary storage device 1724, a primary bus 1722, a graphics card 1725, a Network Interface Card (NIC)1726, a video output port (not shown), and the like. The main storage device 1723 includes a calculation execution processing module 17231 and an inter-site distance data module 17232; the secondary storage device 1724 includes a calculation condition setting processing module 17241, a site management data module 17242, a best solution search processing module 17243, a vehicle management data module 17244, road vector data 17245, and a distribution task data module 17246. In fig. 17, a server 172 performs the arithmetic processing and output processing shown in fig. 4 in cooperation with a remote client 171 via a network 175 (intranet or internet).

Fig. 18 shows a connection relationship of the processing/data in fig. 17. Since the client 171 first establishes a connection with the server 172, it performs authentication processing such as ID/PW on the API 1727, connects 1:1, and enters an execution waiting state. At this time, the server side can process execution requests from a plurality of clients (for example, the client 117) in parallel by starting a process (process) or a thread (thread) that acts exclusively with the client 101. In the read data processing 210, the site management data 17242, the vehicle management data 17244, and the delivery task data 17246 may be read from the client 101, or the delivery task data 17143 may be read from the client 101 and the site management data 17242 and the vehicle management data 17244 may be read from the server 172, as in the example of fig. 18. Since the station information and the vehicle information are usually changed less frequently, they can be arranged on the server side as master (master) data to reduce the load of the data input processing 122 and improve the processing efficiency. The master data is typically maintained in the form of a CSV, table, database, etc. The result of the data input process 17141, the delivery task data 17143, is input via the network 175 through the API 1727 of the server 102.

Thereafter, the input data 500 is generated through the calculation condition setting process 17241, or the data input process 17141 may obtain the site management data 17242 through the API 116 to generate the input data 500 shown in fig. 8 so that the site management data is read through the API 116 of the server 172 as shown in fig. 18. That is, the partial operation corresponds to the execution of the calculation condition setting process 17241 by the data input process 17141. In this case, after the data 500 is input, it is only necessary to perform the setting of the possibility of mixing by the calculation condition setting process 17241. The inter-site distance data 17232 is generated on the server 102 using the road vector data 17245 and the site management data 17242. In addition, the road vector data 17245 may be collected in an on demand (on demand) manner from the map information providing service system 176 outside the internet or the like via the NIC 1726.

After that, the optimal solution search process 17243 corresponding to the main arithmetic loop process 230 is performed, and the generated one or more output data 550 are delivered to the client 171 via the API 116. In the delivery plan output process 17142, a process corresponding to the delivery plan output 240 of fig. 3 is executed, and a result such as a screen is output. The map used in the distribution route 700 output by the client 171 can be collected on demand from the external map information providing service 176 such as the internet through the NIC 1716.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment of the present invention.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A delivery plan generating method, comprising:

a step in which, when one or more delivery tasks associated with information that requires picking up of an empty container exist among delivery tasks represented by delivery task data including information relating to a plurality of delivery tasks, a computer generates, for each of the one or more delivery tasks, information relating to an empty container picking task associated with the delivery task;

a step in which the computer generates, by a predetermined delivery plan generation algorithm, a candidate delivery plan for assigning the plurality of delivery jobs and the generated empty container pick-up job to the plurality of delivery vehicles indicated by vehicle management data including information on the plurality of delivery vehicles;

a step in which the computer evaluates the candidate delivery plan based on whether or not the empty container pick-up job is executed before the delivery job associated with the empty container pick-up job and whether or not these jobs are executed within a predetermined time in the candidate delivery plan; and

and outputting one or more candidate delivery plans as delivery plans by the computer according to the evaluation of the candidate delivery plans.

2. The delivery plan generating method of claim 1, wherein the method comprises:

a step in which, when one or more delivery tasks associated with information that requires returning of an empty container exist among delivery tasks represented by delivery task data including information relating to a plurality of delivery tasks, a computer generates, for each of the one or more delivery tasks, information relating to an empty container returning task associated with the delivery task;

a step in which the computer generates, by a predetermined delivery plan generation algorithm, a candidate delivery plan for distributing the plurality of delivery jobs and the generated empty container return job to the plurality of delivery vehicles indicated by vehicle management data including information on the plurality of delivery vehicles;

a step in which the computer evaluates the candidate delivery plan based on whether or not the empty container return job is executed after the delivery job associated with the empty container return job and whether or not these jobs are executed within a predetermined time in the candidate delivery plan; and

3. The delivery plan generating method according to claim 1,

the step of evaluating the candidate delivery plan includes:

setting task costs of different sizes for empty container task groups according to whether an empty container task group of at least one of the delivery task and an empty container pick-up task and an empty container return task associated with the delivery task is assigned to one and the same delivery vehicle, and whether the empty container task group is executed before and/or after the delivery task associated with the empty container task group and these tasks are executed within a predetermined time; and

and setting the total cost of the candidate delivery plans obtained by summing up the task costs of the candidate delivery plans as the evaluation result of the candidate delivery plans.

4. The delivery plan generating method according to claim 1,

the method comprises the following steps:

determining the number of empty container task groups that are present in the candidate delivery plan and that are assigned to delivery vehicles different from delivery vehicles to which delivery tasks associated with an empty container task group of at least one of an empty container pick-up task and an empty container return task are assigned; and

and adjusting the delivery order of the empty container task group or the delivery order of the delivery tasks associated with the empty container task group, or excluding the candidate delivery plan, when the number exceeds a preset threshold value.

5. The delivery plan generating method according to claim 1,

the method comprises the following steps:

a step of setting a delivery capacity for determining whether or not to mix the vehicles in advance, and setting a mixing capacity having an upper limit value for determining whether or not to mix the vehicles in advance, for a delivery task; and

and setting the mixed loading capacity of the distribution tasks which cannot be mixed loaded as the upper limit value of the mixed loading capacity.

6. The delivery plan generating method according to claim 5,

the method comprises the following steps:

a step of determining whether or not there is a delivery vehicle exceeding a mixed capacity in one of the candidate delivery plans after one of the candidate delivery plans is generated;

a step of adjusting the delivery order of the delivery tasks or the delivery order of the empty container task group associated with the delivery tasks or excluding the candidate delivery plan when there is a delivery vehicle exceeding the mixed capacity in the candidate delivery plan,

wherein the empty container task group is at least one of an empty container pick-up task and an empty container return task.

7. The delivery plan generating method according to claim 6,

the step of determining whether or not there is a delivery vehicle exceeding the mixed capacity in one of the candidate delivery plans after one of the candidate delivery plans is generated includes:

determining a link between adjacent stations through which the delivery vehicle passes for the delivery vehicles of the candidate delivery plan, accumulating the mixed loading capacity of all delivery tasks of the delivery vehicle on the link, and determining that the delivery vehicle exceeding the mixed loading capacity exists when the mixed loading capacity is greater than or equal to the upper limit value of the mixed loading capacity;

alternatively, the first and second electrodes may be,

and determining one or more delivery vehicles passing through the link between the adjacent sites of the candidate delivery plan, respectively accumulating the mixed loading capacity of all delivery tasks of each delivery vehicle on the link, and determining that the delivery vehicles exceeding the mixed loading capacity exist when the mixed loading capacity is more than or equal to the upper limit value of the mixed loading capacity.

8. The delivery plan generating method of claim 1, prior to generating the candidate delivery plan, further comprising:

distributing a task identification ID which uniquely identifies the distribution task for all the distribution tasks, and establishing an association relation for the associated distribution tasks.

9. The delivery plan generating method according to claim 1,

in the case where the number of empty container task groups allocated to delivery vehicles other than the delivery vehicle to which the delivery task associated with the empty container return task is allocated exceeds a predetermined value in the candidate delivery plan obtained when the number of generation times reaches a preset number of times in the process of repeating generation of the candidate delivery plan until reaching a preset search number upper limit value based on a predetermined delivery plan generation algorithm, the method further includes:

dividing the distribution tasks in the original task group into two groups, wherein the empty container task group distributed to the distribution vehicles different from the distribution vehicle distributed with the distribution tasks related to the empty container task group and the distribution tasks related to the empty container task group form a first task group, the rest tasks form a second task group, and the original task group is the distribution task to be distributed with an initial value;

a step of obtaining a first candidate delivery sub-plan and a second candidate delivery sub-plan by generating candidate delivery sub-plans for the first task group and the second task group, respectively, based on a predetermined delivery plan generation algorithm;

if there is an empty container task group assigned to a delivery vehicle different from the delivery vehicle to which the delivery task associated with the empty container task group is assigned in the first candidate delivery sub-plan, setting the first task group as the original task group, and returning to the step of dividing the delivery tasks in the original task group into two groups; and

a step of obtaining a candidate delivery plan for the delivery task to be distributed by aggregating the first candidate delivery sub-plan and all the second candidate delivery sub-plans if there is no empty container task group allocated to a delivery vehicle other than the delivery vehicle to which the delivery task associated with the empty container task group is allocated in the first candidate delivery sub-plan,

10. The delivery plan generating method according to claim 9,

when evaluating the candidate delivery plan, a sum of the total cost and a delivery distance cost of a delivery task in the candidate delivery plan is also calculated as an evaluation result of the candidate delivery plan.

11. A delivery plan generating apparatus, comprising:

a storage device that stores vehicle management data including information on a plurality of delivery vehicles and delivery job data including information on a plurality of delivery jobs; and

a processor for processing the received data, wherein the processor is used for processing the received data,

the processor performs the following processing:

when one or more delivery tasks associated with information that it is necessary to pick up an empty container exist among the delivery tasks represented by the delivery task data, information relating to an empty container picking task associated with the delivery task is generated for each of the one or more delivery tasks,

generating a candidate delivery plan for assigning the plurality of delivery jobs and the generated empty container picking job to the plurality of delivery vehicles indicated by the vehicle management data by a predetermined delivery plan generating algorithm,

in the candidate delivery plan, the candidate delivery plan is evaluated based on whether or not the empty container picking task is executed before the delivery task associated with the empty container picking task and whether or not these tasks are executed within a predetermined time,

one or more of the candidate delivery plans are output as delivery plans based on the evaluation of the candidate delivery plans.

12. The delivery plan generating apparatus according to claim 11,

the processor performs the following processing:

when one or more delivery tasks associated with information that it is necessary to return an empty container exist among the delivery tasks represented by the delivery task data, information related to the empty container return task associated with the delivery task is generated for each of the one or more delivery tasks,

generating a candidate delivery plan for assigning the plurality of delivery jobs and the generated empty container return job to the plurality of delivery vehicles indicated by the vehicle management data by a predetermined delivery plan generation algorithm,

in the candidate delivery plan, the candidate delivery plan is evaluated based on whether or not the empty container returning task is executed after the delivery task associated with the empty container returning task and whether or not these tasks are executed within a predetermined time,

13. The delivery plan generating apparatus according to claim 11,

evaluating the candidate delivery plan includes:

setting task costs having different sizes for the empty container task groups according to whether the delivery tasks and the empty container task groups associated with the delivery tasks are assigned to the same delivery vehicle, and whether the empty container task groups are executed before and/or after the delivery tasks associated with the empty container task groups and whether the tasks are executed within a predetermined time; and

the total cost of the candidate delivery plans, which is obtained by summing up the task costs of the candidate delivery plans, is used as the evaluation result of the candidate delivery plans,

14. The delivery plan generating apparatus according to claim 11,

the processor performs the following processing:

determining the number of empty container task groups that are present in the candidate delivery plan and that are assigned to delivery vehicles other than the delivery vehicle to which the delivery task associated with the empty container task group is assigned; and

when the number exceeds a preset threshold value, the delivery order of the empty container task group or the delivery order of the delivery tasks associated with the empty container task group is adjusted or the candidate delivery plan is excluded,

15. A computer-readable recording medium storing a program, characterized in that,

the program causes a computer to execute the steps of:

a step of generating, for each of one or more delivery tasks, information relating to an empty container pickup task associated with the delivery task when the delivery task indicated by delivery task data including information relating to a plurality of delivery tasks includes one or more delivery tasks associated with information that requires picking up an empty container;

generating a candidate delivery plan for assigning the plurality of delivery jobs and the generated empty container picking job to the plurality of delivery vehicles indicated by vehicle management data including information on the plurality of delivery vehicles by a predetermined delivery plan generation algorithm;

a step of evaluating the candidate delivery plan based on whether or not the empty container pick-up job is executed before the delivery job associated with the empty container pick-up job and whether or not these jobs are executed within a predetermined time in the candidate delivery plan; and

and outputting one or more candidate delivery plans as delivery plans based on the evaluation of the candidate delivery plans.

16. The computer-readable recording medium of claim 15,

the program causes a computer to execute the steps of:

a step of, when one or more delivery tasks associated with information that requires returning of an empty container exist among delivery tasks indicated by delivery task data including information related to a plurality of delivery tasks, generating information related to the empty container returning task associated with the delivery task for each of the one or more delivery tasks;

generating a candidate delivery plan for distributing the plurality of delivery jobs and the generated empty container return job to the plurality of delivery vehicles indicated by vehicle management data including information on the plurality of delivery vehicles, by a predetermined delivery plan generation algorithm;

a step of evaluating the candidate delivery plan based on whether or not the empty container return job is executed after the delivery job associated with the empty container return job and whether or not these jobs are executed within a predetermined time in the candidate delivery plan; and