JP2021106036A - Method, device, and system for creating delivery plan for delivery vehicle - Google Patents

Abstract

To provide a method, a device, and a system for creating a delivery plan for a delivery vehicle that satisfies needs for returning empty containers in a physical distribution scene, avoids creation of a delivery plan by human to reduce cost for creating the delivery plan, and improves efficiency in creating the delivery plan.SOLUTION: A delivery plan creation device 20 is provided with: delivery plan evaluation means 21 for evaluating delivery plan candidates to obtain an evaluation result on the basis of whether an empty container returning task in the delivery plan candidates and a baggage delivery task related thereto are allocated to a same delivery vehicle, or whether, when the tasks are allocated to the same delivery vehicle, the empty container returning task and the baggage delivery task related thereto are executed within a predetermined period; and delivery plan output means 22 for outputting one or more delivery plan candidates as a final delivery plan on the basis of the results of evaluation on the delivery plan candidates.SELECTED DRAWING: Figure 2

Description

The present invention relates to a technical field of a vehicle route problem (VRP: Vehicle Routing Problem), and specifically relates to a delivery plan generation method, an apparatus, and a system for a delivery vehicle.

The vehicle route problem (VRP) meets the needs of a certain number of customers, each with a different number of package delivery needs, and can achieve the goals of shortest distance, minimum cost, and minimum time under certain restrictions. As described above, the person in charge of delivering the package is determined, the appropriate travel route is designed, and then the package is provided to the customer from the distribution center.

Currently, algorithms related to vehicle path problems include strict algorithms (exact algorithms) such as branch limiting method, branch cutting method, and collective covering method, saving method, pseudo-annealing method, deterministic annealing method, taboo search method, and genetic algorithm. , Neural networks, ant colony methods, heuristics algorithms such as genetic algorithms (GA). In the automatic generation of a vehicle delivery plan, a giant neighborhood search (LNS) algorithm, which is usually one of the neighborhood search methods, is relatively effective, and an optimal delivery task assignment method for a vehicle is used using LNS. To search for. The search is usually performed by quantifying the difference (sum of costs) from the optimum solution by a method approaching the optimum solution, and gradually repeating the search toward cost reduction.

In some application scenes of VRP, it is necessary to put the delivery package in a delivery container and deliver it. In such a scene, it is usually necessary to return the empty container after the package delivery is completed. For example, in the distribution scheduling of the manufacturing industry including the delivery of automobile parts, since the delivery container differs depending on the manufacturer and the number of delivery containers is limited, the empty container is often returned to the manufacturer immediately after delivery. Due to such special needs, it is technically difficult to realize the optimum order between delivery tasks only by the neighborhood search method for the above application scene. Therefore, conventional algorithms have not yet reached a practical level in creating delivery plans that include returning empty containers. Currently, in the logistics industry, it is still common to personally create delivery plans for the above application scenes.

The technical problem to be solved by the embodiment of the present invention is to automatically generate a delivery plan including a delivery requirement of returning an empty container to the manufacturer after delivery to improve the generation efficiency of the delivery plan and reduce human cost. To provide delivery plan generation methods, devices and systems for delivery vehicles to reduce.

In order to solve the above technical problem, an embodiment of the present invention provides a delivery plan generation method for picking up a package between a plurality of bases using a plurality of delivery vehicles and outputting a delivery order for delivery. do. In the delivery plan generation method, whether or not the empty container return task in the delivery plan candidate and the related package delivery task are assigned to the same delivery vehicle, and whether the empty container return task and the related package delivery are performed. Based on whether or not the task is executed within a predetermined time, the delivery plan candidate is evaluated and the evaluation result is obtained. Further, based on the evaluation result of the delivery plan candidate, one or a plurality of delivery plan candidates are output as the final delivery plan. Among them, to be executed within the above-mentioned predetermined time, the empty container return task and the related package delivery task are executed at the same time, or the empty container return task is executed after the related package delivery task. And it includes the fact that there is no other delivery task between the two.

An embodiment of the present invention further provides a delivery plan generation device for picking up packages between a plurality of bases using a plurality of delivery vehicles and outputting a delivery order for delivery. In the delivery plan generator, whether or not the empty container return task in the delivery plan candidate and the related package delivery task are assigned to the same delivery vehicle, and if they are assigned to the same delivery vehicle, the delivery plan generator is used. A delivery plan evaluation means for evaluating a delivery plan candidate and obtaining an evaluation result based on whether or not the empty container return task and the related package delivery task are executed within a predetermined time, and the above delivery plan. It includes a delivery plan output means for outputting one or more delivery plan candidates as a final delivery plan based on the evaluation result of the candidates, and it is said that the delivery plan output means is executed within the predetermined time. Includes that the empty container return task and the associated package delivery task are executed at the same time, or that the empty container return task is executed after the related package delivery task and there is no other delivery task between them. ..

The embodiments of the present invention further provide a delivery plan generation system. The system includes a storage device, a processor, and a computer program stored in the storage device and executed by the processor. When the computer program is executed by the processor, the delivery plan generation method is realized. ..

The embodiments of the present invention further provide a computer-readable storage medium. When the computer program stored in the storage medium is executed by the processor, the delivery plan generation method described above is realized.

Compared with the prior art, in the delivery plan generation method, apparatus and system according to the embodiment of the present invention, the task cost of the empty container return task is introduced into the total cost of the delivery plan candidates, and the task cost in the first delivery method is introduced in advance. By setting to be optimal, the algorithm automatically outputs the desired empty container return delivery order, satisfying the empty container return needs in the actual logistics scene, and avoiding the human creation of delivery plans. It is possible to reduce the cost of creating a delivery plan and improve the efficiency of generating a delivery plan.

In order to more clearly explain the technical means of the examples of the present invention, the drawings required for the description of the examples of the present invention will be briefly introduced below. Obviously, the drawings relating to the following description are merely examples of a portion of the present invention. For those skilled in the art, other drawings can be obtained from these drawings on the premise that they do not work creatively.

FIG. 1 is a flowchart of a delivery plan generation method according to an embodiment of the present invention. FIG. 2 is a schematic structural diagram of a delivery plan generator according to an embodiment of the present invention. FIG. 3 is a block diagram showing the overall structure of the delivery plan generation system according to the embodiment of the present invention. FIG. 4 is an exemplary flowchart of a delivery plan generation method according to an embodiment of the present invention. FIG. 5 is a diagram showing an example of base management data in the embodiment of the present 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 showing an example of delivery task data in the embodiment of the present invention. FIG. 8 is a diagram showing an example of input data generated in the embodiment of the present invention. FIG. 9 is an exemplary flowchart of adding an empty container return task in an embodiment of the present invention. FIG. 10 is an exemplary flowchart for adding an empty container pick-up task in an embodiment of the present invention. FIG. 11 is a diagram showing an example of distance matrix data between bases in the embodiment of the present invention. FIG. 12 is an exemplary flowchart of the empty container mixed loading possibility determination process in the embodiment of the present invention. FIG. 13 is an exemplary flowchart of the total cost calculation process according to the embodiment of the present invention. FIG. 14 is an exemplary flowchart of the same vehicle compulsory constraint violation processing in the embodiment of the present invention. FIG. 15 is a diagram showing an example of output data in the embodiment of the present invention. 16A to 16B are diagrams showing an example of an output screen generated in the embodiment of the present invention. FIG. 17 is another schematic structural diagram of a block diagram of the delivery plan generation system according to the embodiment of the present invention. FIG. 18 is a schematic diagram of a processing and data connection relationship in another system block diagram shown in FIG.

In order to further clarify the technical problems, technical means and advantages to be solved by the present invention, the following will be described in detail together with drawings and specific examples. In the following description, providing specific settings and specific details of the components is merely an aid to a full understanding of the embodiments of the present invention. Therefore, as will be apparent to those skilled in the art, various changes and modifications can be made to the examples described herein without departing from the scope and gist of the present invention. Also, for clarification and conciseness, the description of well-known functions and structures will be omitted.

As used throughout the specification, "one embodiment" or "one embodiment" means that a particular feature, structure or property relating to an embodiment is included in at least one embodiment of the present invention. Then it should be understood. Therefore, "in one embodiment" and "in one embodiment" appearing in each part of the specification do not necessarily refer to the same embodiment. Also, these particular features, structures or properties can be optionally combined with one or more embodiments as appropriate.

In each embodiment of the present invention, the magnitude of the numbers of each process described later does not mean before or after the execution order. It should be understood that the order of execution of each process is determined by its function and internal logic and should not constitute any limitation on the process of implementation of the embodiments of the present invention.

See FIG. An embodiment of the present invention provides a delivery plan generation method. The method can output the optimum order of delivery tasks for picking up and delivering packages by patrol of multiple locations by multiple delivery vehicles. As shown in FIG. 1, the method includes the following steps.

In step 11, whether or not the empty container return task in the delivery plan candidate and the related package delivery task are assigned to the same delivery vehicle, and the empty container return task and the related package delivery task are determined. The delivery plan candidate is evaluated based on whether or not it is executed within a predetermined time, and the evaluation result is obtained.

The delivery task in the embodiment of the present invention includes a cargo delivery task of delivering a package from one base (for example, a delivery departure base) to another base (delivery destination base), and delivers an empty container to the package delivery task. It may also include an empty container return task to return from the destination location to the delivery departure point. Therefore, for each empty container return task, there is one associated package delivery task, but for the package delivery task, there may be an empty container return task associated with it, and there may be an empty container return task associated with it. It is possible that the task does not exist. Here, to be executed within the above-mentioned predetermined time, the empty container return task and the related package delivery task are executed at the same time, or the empty container return task is executed after the related package delivery task. And include the absence of any other delivery task between the two.

In the embodiment of the present invention, when evaluating the delivery plan candidate, whether or not the empty container return task and the related package delivery task are assigned to the same delivery vehicle, and the empty container return task. Based on whether the related package delivery task is executed within the specified time, each empty container return task has a task cost of different size, and then the task costs in the delivery plan candidates are totaled. The total cost of the obtained delivery plan candidate is used as the evaluation result of the delivery plan candidate.

In step 12, one or a plurality of delivery plan candidates are output as the final delivery plan based on the evaluation result of the delivery plan candidates.

Here, one or a plurality of delivery plan candidates are selected from the delivery plan candidates having the lowest total cost in ascending order of the total cost of the delivery plan candidates, and output as the final delivery plan.

By the above steps, the embodiment of the present invention considers the task cost of the empty container return task in different delivery formats in the total cost of the delivery plan candidate, so that the algorithm automatically sets the delivery order of the desired empty container return. It is possible to satisfy the empty container return needs in the actual distribution scene, avoid the human creation of the delivery plan, reduce the creation cost of the delivery plan, and improve the generation efficiency of the delivery plan.

In the embodiment of the present invention, the delivery plan candidate includes the execution order of the delivery task and the assigned delivery vehicle. Specifically, for delivery tasks waiting to be allocated (including baggage delivery tasks and empty container return tasks), a search algorithm such as a genetic algorithm (GA: Genetic Algorithm) or a huge neighborhood search (LNS: Large Neighborhood Search) is used. Then, the optimum solution is approached by multiple searches, multiple delivery plans are acquired by the search, and these delivery plans are used as delivery plan candidates.

The search may be executed until the predetermined search count upper limit is reached and then terminated, or may be terminated ahead of schedule before reaching the predetermined search count upper limit. For example, if the acquired delivery plan candidate satisfies a predetermined condition and the delivery vehicle specifically required for the delivery plan candidate is equal to or less than the predetermined first threshold value, the search is interrupted and the acquired delivery plan candidate is output. do. Further, for example, the number y1 of the empty container return tasks assigned to the delivery vehicle different from the related package delivery task existing in the delivery plan candidate, and the number y1 assigned to the same delivery vehicle as the related package delivery task. With the related package delivery task, if the sum of the number y2 of the empty container return tasks that are not executed within the predetermined time is equal to or less than the predetermined second threshold value, the search may be completed ahead of schedule.

During the search by the search algorithm, if the number of empty container return tasks assigned to the delivery vehicle different from the related package delivery task existing in the current delivery plan candidate is equal to or more than the predetermined second threshold value, the current delivery Make adjustments to the delivery task in the planning candidate or exclude the current delivery planning candidate. The above adjustment includes adjusting the delivery order of the empty container return task assigned to the delivery vehicle different from the related package delivery task. For example, the empty container return task may be inserted at another position in the current delivery plan candidate, or the delivery order may be exchanged with another delivery task.

The total cost includes the task cost of the empty container return task. In order to achieve the object of returning an empty container immediately after delivery of a package, in the embodiment of the present invention, task costs of different sizes are provided for each empty container return task. When the empty container return task and the related package delivery task are assigned to the same delivery vehicle, and the empty container return task and the related package delivery task are executed within the above-mentioned predetermined time, the empty container return task is executed. Has the lowest task cost. By introducing the above task cost into the delivery plan candidate, the embodiment of the present invention considers the influence of the order of delivery tasks on the delivery plan so as to obtain the desired delivery plan.

In the embodiment of the present invention, whether or not the empty container return task and the related cargo delivery task are assigned to the same delivery vehicle, and whether the empty container return task and the related cargo delivery task are assigned to the same delivery vehicle for a predetermined time. Based on whether or not it is executed within, the empty container return task is provided with task costs of different sizes, and the desired delivery method is output to the algorithm. As one concrete implementation form, regarding the empty container return task in advance, the first delivery method is the first task cost, the second delivery method is the second task cost, the third delivery method is the third task cost, and the fourth delivery. The method is set to have a fourth task cost. Here, as the first delivery method, the empty container return task and the related package delivery task are assigned to the same delivery vehicle, and the empty container return task and the related package delivery task are within a predetermined time. Will be executed. As the second delivery method, the empty container return task and the related package delivery task are assigned to the same delivery vehicle, and the empty container return task is executed after the related package delivery task, and another delivery is performed between the two. The task exists. As the third delivery method, the empty container return task and the related package delivery task are assigned to the same delivery vehicle, but the empty container return task is executed before the related package delivery task. As the fourth delivery method, the empty container return task and the related package delivery task are assigned to different delivery vehicles.

Here, the first task cost, the second task cost, the third task cost, and the fourth task cost increase in order. The different task costs of the different delivery methods indicate that the first delivery method is the most desired delivery method for the empty container return task in the embodiments of the present invention.

In addition to the task cost of the empty container return task, the delivery distance cost is also considered in the total cost of the delivery plan candidates in the embodiment of the present invention. Different delivery plan candidates may have different delivery vehicle routes, resulting in different delivery distances to accommodate different delivery distance costs. In step 12, the delivery distance cost of each delivery task in the delivery plan candidate is statistic, the task cost of the empty container return task in the delivery plan candidate is statistic, and the delivery is made based on the delivery distance cost and the task cost. Acquire the evaluation result of the plan candidate. For example, the delivery distance cost and the task cost are weighted with different magnitudes, and the evaluation results of the delivery plan candidates are obtained by performing a polymerization meter of both.

In the embodiment of the present invention, there are many factors such as the time required for delivery, the delivery road cost (for example, different roads may incur different costs, and in the case of an expressway, a separate toll cost is required). May be taken into consideration in the evaluation result. These factors are considered in the search by the search algorithm, but are not described in more detail in the text.

As one embodiment, the embodiment of the present invention is related to the delivery plan candidates existing in the delivery plan candidates when one delivery plan candidate (hereinafter referred to as the current delivery plan candidate) generated by the search algorithm is acquired. Determine the number of empty container return tasks assigned to different delivery vehicles than the package delivery tasks to be performed. If the number exceeds a preset threshold, adjustments are made to the delivery tasks in the delivery plan candidates, or delivery plan candidates are excluded.

In the embodiment of the present invention, _{a mixed loading capacity having an upper limit value M max} is set in advance, and the mixed loading capacity of a delivery task that cannot be mixed is set to the above upper limit value M _max , which is used for determining whether or not mixed loading is possible. Set the mixed loading capacity of the task to a positive number K, which is much smaller than _{M max.} The value of the positive number K is set with reference to the number S of delivery tasks, and is, for example, a value smaller than _{M max / S.} In addition, the delivery capacity used for determining whether or not mixed loading is possible for the delivery vehicle is set, and the cargo volume of the delivery vehicle at the same time must not exceed the delivery capacity. As one example, the upper limit value M _max of the mixed loading capacity is set to 1, and the mixed loading capacity of the delivery task that can be mixed is set to 0.01. In determining a delivery vehicle that violates certain restrictions during the current delivery plan candidates, the mixed loading capacity of all delivery tasks delivered by the delivery vehicle is accumulated for each delivery vehicle in the delivery plan candidate, and the above mixed loading capacity or more. If, it is determined that the delivery vehicle violates the setting condition that the delivery task cannot be mixedly loaded.

Further, whether or not the delivery task can be mixedly loaded may be determined by the task attribute of the delivery task. In the acquisition of the delivery task waiting to be assigned, the task attribute can be specified, and the task attribute can include the instruction information of whether or not mixed loading is possible. If the related package delivery task cannot be mixed with the empty container return task, the empty container return task also cannot be mixed by default. Of course, if the package delivery task related to the empty container return task cannot be mixed, it is possible to specially instruct that the empty container return task can be mixed.

In one embodiment, in the embodiment of the present invention, when one delivery plan candidate (hereinafter referred to as the current delivery plan candidate) is acquired, there is a delivery vehicle exceeding the mixed loading capacity among the delivery plan candidates. If there is a delivery vehicle that exceeds the mixed loading capacity in the delivery plan candidate, the delivery task in the delivery plan candidate is adjusted or the delivery plan candidate is excluded.

In determining whether there is a delivery vehicle that exceeds the mixed loading capacity among the delivery plan candidates, the route between the adjacent bases through which the delivery vehicle passes is determined for the delivery vehicle of the delivery plan candidate, and the route of the delivery vehicle is determined. If the mixed loading capacity of all the delivery tasks in the above is accumulated and is equal to or more than the upper limit of the mixed loading capacity, it is determined that there is a delivery vehicle exceeding the mixed loading capacity. Alternatively, for the route between adjacent bases of the delivery plan candidate, one or more delivery vehicles via the route are determined, and the mixed loading capacity of all the delivery tasks in the route of each delivery vehicle is accumulated and mixed. If it is equal to or greater than the upper limit of the capacity, it is determined that there is a delivery vehicle that exceeds the mixed loading capacity.

Further, in the embodiment of the present invention, many limited conditions other than the above-mentioned mixed loading capacity can be set, and it can be determined whether or not the delivery vehicle satisfies these conditions. In this case, first, it is determined whether or not there is a delivery vehicle that violates the predetermined vehicle restriction condition among the current delivery plan candidates. If there is a delivery vehicle that violates the predetermined vehicle restriction conditions among the current delivery plan candidates, adjustments are made to the delivery task in the delivery plan candidate, or the current delivery plan candidate is excluded and the current delivery plan candidate is excluded. Do not calculate the total cost of delivery plan candidates. If there is no delivery vehicle that violates the predetermined vehicle restriction conditions, the cost of each delivery task in the current delivery plan candidate is statistic to obtain the total cost of the delivery plan candidate.

Here, the predetermined vehicle restriction condition is that the total load volume of the vehicle does not exceed the volume upper limit of the vehicle, the total load weight of the vehicle does not exceed the load upper limit of the vehicle, or the vehicle delivers. Includes that it does not violate the setting conditions that prevent mixed loading of tasks.

Further, in the embodiment of the present invention, after obtaining one delivery plan candidate (current delivery plan candidate), it is determined that there is no delivery vehicle in the current delivery plan candidate that violates the predetermined vehicle restriction condition. Then, the first number of empty container return tasks assigned to the delivery vehicle different from the related package delivery task existing in the current delivery plan candidate is subsequently determined. When the first number exceeds a predetermined first threshold value, the delivery task in the delivery plan is adjusted or the current delivery plan candidate is excluded. When the first value is equal to or less than the predetermined first threshold value, the task cost of each delivery task in the current delivery plan candidate is statistic to obtain the total cost of the delivery plan candidate. Here, a predetermined first threshold value is set based on factors such as the total number of delivery tasks and cost requirements.

The delivery task waiting for allocation in the embodiment of the present invention may be a delivery task that is generated based on the package delivery task provided by the user and includes a package delivery task and an empty container return task. Specifically, for example, when the delivery task provided by the user includes only the package delivery task, in the embodiment of the present invention, the package delivery task for which the empty container needs to be returned after the package is delivered is determined, and the empty container is returned. Add a related empty container return task to the required package delivery task, and the execution order of the related empty container return task is after the package delivery task that requires the return of the empty container after the above package delivery. Sign.

Here, the task attribute of the package delivery task is analyzed, and it is determined whether the empty container needs to be returned for the package delivery task. When providing a package delivery task, the user must specify the task attributes of the task, usually the departure point, end point, delivery time request, package volume and weight information, mixed loading availability, empty of the package delivery task. Information such as whether or not the container needs to be returned is included.

Considering that the empty container may not be located at the departure base of the cargo delivery task, the empty container is first picked up from another base, then the cargo is loaded at the departure base and delivered to the destination base. Therefore, in the embodiment of the present invention, after acquiring at least one package delivery task provided by the user, it is necessary to collect the empty container from a base other than the delivery departure base before the package delivery. Determine the task. A related empty container pick-up task is added to the package delivery task that needs to pick up empty containers from other bases other than the above delivery departure base, and the execution order of the related empty container pick-up task is changed. Mark that it is before a package delivery task that requires the collection of empty containers from other bases other than the delivery departure base.

According to the above method, the embodiment of the present invention can generate a delivery task waiting for allocation based on the package delivery task provided by the user, but specifically includes the package delivery task and is empty. It may include one or both of the container pick-up task and the empty container return task.

In order to label a delivery task in a search algorithm, in an embodiment of the present invention, all delivery tasks are assigned a task marker ID that uniquely labels the delivery task, and the delivery task is associated with a related delivery task. Establish a relationship. For example, establish the relationship between the related empty container pick-up task and the package delivery task, and establish the relationship between the related package delivery task and the empty container return task.

In the embodiment of the present invention, when the search algorithm generates the delivery plan candidate of the delivery task waiting for allocation, the upper limit of the number of searches is set. When the number of searches reaches the upper limit, the search is terminated and delivery plan candidates are output. During the search, processing can be performed by the following method in order to accelerate convergence.

In the process of repeating the generation of delivery plan candidates up to the preset upper limit of the number of searches based on a predetermined search algorithm, the delivery plan candidates obtained when the number of generations reaches the preset number of times are related. If the number of empty container return tasks assigned to a delivery vehicle different from the package delivery task exceeds a predetermined value, the delivery task in the original task group whose initial value is the above-mentioned pending delivery task is combined with the related package delivery task. A predetermined search is divided into two groups, a first task group consisting of empty container return tasks assigned to different delivery vehicles and related delivery tasks, and a second task group consisting of other delivery tasks. Based on the algorithm, delivery subplan candidates are generated for the first task group and the second task group, respectively, the first delivery subplan candidate and the second delivery subplan candidate are acquired, and the first delivery subplan candidate is acquired. If there is an empty container return task assigned to a delivery vehicle different from the related package delivery task in the delivery sub-plan candidate, the first task group is set as the above-mentioned original task group, and the delivery task in the above-mentioned original task group is set. If there is no empty container return task assigned to a delivery vehicle different from the related package delivery task in the first delivery sub-plan candidate, the first delivery sub-plan candidate is returned to the step of dividing the above into two groups. And all the second delivery subplan candidates are put together, and the delivery plan candidate of the delivery task waiting for allocation is acquired.

According to the above method, the embodiment of the present invention can accelerate the convergence of the algorithm and improve the search efficiency.

The delivery plan generation method of the delivery vehicle according to the embodiment of the present invention has been introduced above. In each of the above-described embodiments of the present invention, a related empty container return task is added to the package delivery task for which the empty container return request is made, and a task having a different size from the empty container return task during the search for the delivery plan is added. By setting the cost, the delivery plan of the desired delivery order can be automatically generated and output by the search algorithm, and the efficiency of generating the delivery plan including the delivery requirement of returning the empty container to the manufacturer after delivery is improved. Let me.

The embodiments of the present invention further provide a computer-readable storage medium. When the computer program stored in the storage medium is executed by the processor, the delivery plan generation method of any one of the above method embodiments is realized.

Based on the above method, the examples of the present invention further provide an apparatus for carrying out the above method. As shown in FIG. 2, in the delivery plan generation device 20 according to the embodiment of the present invention, whether or not the empty container return task in the delivery plan candidate and the related package delivery task are assigned to the same delivery vehicle. And, when assigned to the same delivery vehicle, the delivery plan candidate is evaluated and the evaluation result is evaluated based on whether the empty container return task and the related package delivery task are executed within a predetermined time. The delivery plan evaluation means 21 for obtaining the delivery plan, and the delivery plan output means 22 for outputting one or more delivery plan candidates as the final delivery plan based on the evaluation result of the delivery plan candidate. Among them, to be executed within the above-mentioned predetermined time, the empty container return task and the related package delivery task are executed at the same time, or the empty container return task is executed after the related package delivery task. Moreover, it includes that there is no other delivery task between the two.

In the delivery plan evaluation means 21, whether or not the empty container return task and the related cargo delivery task are assigned to the same delivery vehicle, and the empty container return task and the related cargo delivery task are predetermined. Based on whether or not it is executed in time, task costs of different sizes are set for each empty container return task, and the total cost of the delivery plan candidate obtained by totaling the task costs of the delivery plan candidates is calculated as the delivery plan candidate. It is preferable to include a task cost statistical means for obtaining the evaluation result of.

The delivery plan generator determines the number of empty container return tasks assigned to a delivery vehicle different from the related package delivery task existing in the delivery plan candidate, and if the number exceeds a preset threshold, It is preferable to further include a delivery plan analysis means for adjusting the delivery task in the delivery plan candidate or excluding the delivery plan candidate.

The delivery plan generation device presets the delivery capacity used for determining whether or not the delivery vehicle can be mixedly loaded, and is used for determining whether or not the delivery task can be mixedly loaded. The mixed loading capacity having an upper limit is set in advance and cannot be mixedly loaded. It is preferable to further include a capacity setting means for setting the mixed loading capacity of the delivery task of the above to the upper limit value of the mixed loading capacity.

After generating one delivery plan candidate by the search algorithm, the delivery plan generator determines whether or not a delivery vehicle exceeding the mixed loading capacity exists in the delivery plan candidate, and the delivery vehicle exceeding the mixed loading capacity is the delivery plan. When present in the candidates, it is preferable to further include a mixed loading determination means for adjusting the delivery task in the delivery plan candidate or excluding the delivery plan candidate.

Specifically, the above-mentioned mixed loading determination means determines a route between adjacent bases through which the delivery vehicle is routed to the delivery vehicle of the delivery plan candidate when determining whether or not there is a delivery vehicle exceeding the mixed loading capacity. Then, the mixed loading capacity of all the delivery tasks in the route of the delivery vehicle is accumulated, and if it is equal to or more than the upper limit of the mixed loading capacity, it is determined that there is a delivery vehicle exceeding the mixed loading capacity. Alternatively, for a route between adjacent bases of a delivery plan candidate, one or a plurality of delivery vehicles via the route are determined, and the mixed loading capacities of all delivery tasks in the route of each delivery vehicle are accumulated and described above. If it is equal to or greater than the upper limit of the mixed loading capacity, it is determined that there is a delivery vehicle that exceeds the mixed loading capacity.

It is preferable that the delivery plan generation device further includes a delivery plan generation means. The delivery plan generation means repeatedly generates delivery plan candidates up to a preset upper limit of the number of searches based on a predetermined search algorithm, and the delivery obtained when the number of generations reaches a preset number of times. If the number of empty container return tasks assigned to a delivery vehicle different from the related package delivery task during the plan candidate exceeds a predetermined value, the delivery task in the original task group whose initial value is the delivery task waiting to be assigned is selected. , A first task group consisting of an empty container return task assigned to a delivery vehicle different from the related package delivery task and its related delivery task, and a second task group consisting of other tasks. Based on a predetermined search algorithm, delivery sub-planning candidates are generated for the first task group and the second task group, respectively, and the first delivery sub-planning candidate and the second delivery sub-planning candidate are generated. If there is an empty container return task assigned to a delivery vehicle different from the related package delivery task in the first delivery subplan candidate, the first task group is set as the above source task group, and the above source is set as the above source. Returning to the step of dividing the delivery task in the task group into two groups, if there is no empty container return task assigned to the delivery vehicle different from the related package delivery task in the first delivery subplan candidate, the first delivery subplan is concerned. The delivery sub-plan candidate of 1 and all the second delivery sub-plan candidates are put together, and the delivery plan candidate of the delivery task waiting for allocation is acquired.

The delivery plan evaluation means 21 in the delivery plan generator further calculates the total of the total cost and the delivery distance cost of each delivery task in the delivery plan candidate to obtain the evaluation result of the delivery plan candidate.

The embodiments of the present invention further provide a delivery plan generation system for delivery vehicles. The system includes a storage device, a processor, and a computer program stored in the storage device and executed by the processor. When the computer program is executed by the processor, the delivery of any one of the above method embodiments. Realize the plan generation method.

FIG. 3 shows one example of the overall structural block diagram of the delivery plan generation system according to the embodiment of the present invention. In FIG. 3, a computer alone will be described as an example. The computer 100 includes a processor (CPU) 104, a main storage device 105, a secondary storage device 106, a main bus 103, a video card 107, a network interface card (NIC) 108, and a video output port 109. NS. The computer 100 can input / output data to / from the outside of the computer via the NIC 108, and can output the screen to an external display device via the video output port 109. In the actual structure, in addition to the module shown in FIG. 3, an input device such as a keyboard and a mouse may be further included.

The secondary storage device 106 includes, for example, a data input processing module 1061, a calculation condition setting processing module 1062, an optimum solution search processing module 1063, a delivery plan output processing module 1064, a base management data 1065, and a vehicle management data. Each type of input data and program module required for the arithmetic processing of the embodiment of the present invention, such as 1066, delivery task data 1067, and road vector data 1068, are stored. In the execution of the arithmetic processing, the data of the secondary storage device 106 is appropriately read by the input / output / calculation execution processing means 1051 in the main storage device 105, and the search process is performed together with the inter-site distance data 1052 to perform the delivery plan. Output.

In order to understand the above technical means of the examples of the present invention, the methods of the examples of the present invention will be described more specifically below by the specific flow of some examples.

With reference to FIG. 4, an exemplary flow of a delivery plan generation method for a delivery vehicle according to an embodiment of the present invention includes:

In the data reading step 210, the base management data 1065, the vehicle management data 1066, and the delivery task data 1067 are read. After that, the calculation condition setting step 220 is performed as the preprocessing of the main calculation processing step 230. In the main arithmetic processing step 230, the delivery plan is repeatedly generated in order to obtain the optimum delivery plan.

Before generating the delivery plan each time, in step 231 it is determined whether the upper limit of the predetermined number of search loops has been reached. If it is reached, the process proceeds to step 240 to output the delivery plan, but if it is not reached, a delivery plan candidate is generated in step 232.

In step 232, a search algorithm such as an LNS algorithm or GA is used to obtain a delivery plan candidate, and in step 233, it is determined whether the generated delivery plan candidate violates the compulsory restriction condition. If the violation occurs, adjustments are made to the current delivery plan candidate, or the current delivery plan candidate is excluded, and the process returns to step 232 to generate a new delivery plan candidate. If not violated, proceed to step 234 to calculate the total cost of the current delivery plan candidate.

Here, the compulsory restriction condition may include the predetermined vehicle restriction condition described above. Further, the compulsory restriction condition includes that the first number of empty container return tasks existing in the delivery plan candidate and being assigned to a delivery vehicle different from the related package delivery task is smaller than the first threshold value. If you need to generate a new delivery plan candidate in violation of the mandatory restriction condition, insert the delivery task related to the violation of the above mandatory restriction condition in another position in the current delivery plan candidate, or insert the current delivery plan. Exchange delivery order with other delivery tasks in the candidate.

In step 235, it is determined whether the search can be completed ahead of schedule. If it is determined that it is possible, the process proceeds to step 240, but if it is determined that it is not possible, the process returns to step 231. For example, the delivery vehicle required for the current delivery plan candidate is less than or equal to a predetermined first threshold and / or is empty assigned to a delivery vehicle that is present in the delivery plan candidate and is different from the associated package delivery task. If the number of container return tasks is equal to or less than a predetermined second threshold value, the search can be completed ahead of schedule.

In step 240, one or a plurality of delivery plans are output in ascending order of the total cost of each delivery plan candidate currently acquired to be the final delivery plan.

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

The base management data 1065 in FIG. 5 includes a base name 411, a latitude 412 and a longitude 413 indicating the location of the base, a location area 414 of the base, and a vehicle type compatible with the base (that is, a vehicle type that can accept delivery at the base) 415. It includes parameters such as the start time 416 and end time 417 of the base and the unloading time 418.

The vehicle management data 1066 of FIG. 6 includes a vehicle ID 431 for uniquely marking a vehicle, a vehicle type 432 of the vehicle, a driver and a contact method 433, a base 434 at the time of departure of the vehicle, and a base 435 at the end of the vehicle. , Vehicle volume upper limit 436 (cubic meter / number of pallets (cargo handling platform), etc.), vehicle loading upper limit 437 (t or kg, etc.), vehicle operation start time 438, and operation end time 439. , Includes parameters such as the vehicle's jurisdiction 440.

The delivery task data 1067 of FIG. 7 includes a delivery date 451 of the delivery task, a departure base 452 of the delivery source, a target base 453 of the delivery destination, a pick-up deadline 454 for acquiring the package at the delivery source, and a delivery destination. Parameters such as the delivery deadline 455 to be delivered to, the volume of the delivery package 456, the vehicle type 458 when the deliverable vehicle type is limited, the necessity of returning the empty container 459, and the possibility of mixed loading with other delivery tasks 460. include.

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. From the delivery task data 1067 of FIG. 7, since the empty container return cannot be directly reflected in the plan by the calculation process of the delivery plan generation algorithm, the calculation condition setting step 220 shown in FIG. 9 is performed prior to the main calculation process step 230. Generate an empty container return task by processing.

As shown in FIG. 9, in the calculation condition setting step 220, the calculation loop process is performed for all the delivery tasks waiting for delivery provided by the user. In step 221 it is determined whether the traverse of all delivery tasks has been completed. When the traverse is completed, the input data as shown in FIG. 8 is output, but when the traverse is not completed, one unprocessed delivery task i is selected in step 222, and the delivery task i is set in step 223. On the other hand, it is judged whether or not the empty container needs to be returned. If it is not necessary, the process returns to step 221. If necessary, an empty container return task j is added to the delivery task i in step 224 to generate the empty container return task j, and in step 225, it is determined whether or not mixed loading is possible for the empty container return task j. For the determination of the necessity of returning the empty container of the delivery task i, refer to the setting of the necessity of returning the empty container 459 for the task in FIG. 7. If you need to return it, add an empty container return task.

Taking the delivery task data 461 of FIG. 7 as an example, since the empty container return 459 is “required”, the next empty container return task J001_01 is added to the first delivery task J001 of FIG. In this case, J001 is entered in the related task ID of FIG. 8 in order to correspond to the original delivery task J001. Here, the task order 519 indicates the order relationship between the current task and the related task ID 520. For example, NEXT541 indicates that the current task J001_01 is located after the task J001 indicated by the associated task ID 520.

In step 225, when determining whether or not mixed loading is possible for the empty container return task j, the possibility of mixed loading 521 of FIG. 8 is set with reference to the possibility of mixed loading 460 of FIG. That is, in the mixed loading possibility determination process 225 of FIG. 9, if the original delivery cannot be mixed, the empty container return cannot be mixed. Of course, in the embodiment of the present invention, an asymmetric processing method may be used, that is, the original delivery may not be mixed-loaded, whereas the empty container return may be mixed-loaded.

In the task allocation process of the delivery plan generation algorithm, since the empty container return task that cannot be mixed is not mixed with other tasks, a capacity different from the volume V and weight W is introduced and added to the delivery task, but in the text, it is added. The mixed loading capacity is M. In the example of FIG. 9, the upper limit of the mixed loading capacity of all vehicles is set to 1.0, and the mixed loading capacity of the empty container return task i that cannot be mixed is set to 1.0 in step 226. As a result, when the mixed loading capacity of the delivery task is 1.0, the capacity is full, and at this time, even if there is a margin in the volume V and the weight W, for example, the mixed loading with other tasks cannot be performed.

On the other hand, when it is determined by the mixed loading possibility determination process 225 that mixed loading is possible, in step 227, the mixed loading capacity of the empty container return task i is set to a value larger than 0 and extremely small, for example, a value smaller than _{M max / S described above.} Set to. The volume 516 and weight 517 of the empty container return task are individually determined, and for example, in step 227, they are uniformly set to 15% of the original delivery task.

Finally, the original delivery task and the empty container return task are complemented during the vacant time zone of the collection deadline 454 and the delivery deadline 455 in FIG. 7. If there is no time in the deadline, the closing time of the base may be entered with reference to the base management data of FIG. Further, for example, since the time is basically not specified for the empty container return task, the business hours of the relevant base may be input. If the business hours of each base are not specified, specify the default value (for example, 8:00 to 17:00). Therefore, the input data shown in FIG. 8 is acquired. Further, FIG. 8 shows an example of the mixed loading capacity setting process after the input data is determined and before the main calculation process step 230. Of course, the input data itself may also include the mixed loading capacity.

The additional process of the empty container return task of FIG. 9 is a case (case) in which the empty container needs to be returned after delivery. As another case, before delivering the task, it is necessary to pick up an empty container (Pickup) from another base different from the departure base of the delivery task, and in the case of the delivery task 462 (case) of FIG. Correspondingly, one of the processing methods is shown in FIG. In the case of the delivery task 462 of FIG. 7, the necessity of returning the empty container 459 is "advance required". Specifically, first, the empty container is picked up at the delivery destination base B, the cargo is loaded again at the base C, the package is delivered to the base B, and finally the empty container is returned to another base l. That is, as shown in FIG. 10, in the calculation condition setting step 220, first, the calculation loop processing is performed for all the delivery tasks waiting for delivery provided by the user, and it is determined whether or not the empty container pick-up task needs to be added. .. In step 221a, it is determined whether the traverse of the empty container pick-up process has been completed for all the delivery tasks. When the traverse is completed, the process proceeds to step 221 of FIG. 9, and it is determined whether the traverse of the empty container return process is completed for all the delivery tasks. If the traverse of the empty container pick-up process has not been completed, one unprocessed delivery task is selected as the current delivery task in step 222a, and in step 223a, the empty container is selected from another base for the current delivery task. Determine if pick-up is required. If it is determined that it is necessary, an empty container pick-up task is added to the current task in step 224a, and the process returns to step 221a. Specifically, when adding an empty container pick-up task, the related parameters in the task may be set with reference to a similar method in the empty container return task.

Based on the delivery task 462 of FIG. 7, an empty container pick-up task J002 and an empty container return task J002_02 are generated for the delivery task of FIG. 7, respectively. Here, in order to pick up the empty container, deliver the package, and return the empty container in order, the task ID of the task to be performed before that is set for the related task IDs of J002_01 and J002_02. In the actual delivery, there is no need to return the empty container to the base l after delivery, and the scene ends when the empty container is delivered to the destination base B, or the empty container is picked up at a base other than the delivery destination base B. There are scenes and so on. Appropriate input data 500 may be output by adaptively changing the above various possible scenes according to business requirements. In this example, the scene where the input data 500 is generated based on the delivery task 1067 by the calculation condition setting step 220 is shown. However, when the specific implementation is performed, the calculation condition setting step 220 may be skipped and the input data 500 may be directly input. That is, by directly inputting the task order 519 and the related task ID 520, the relational relationship between a plurality of tasks such as the empty container return task may be defined.

FIG. 11 shows an example of the data format of the inter-site distance matrix data 1052 required for the main arithmetic processing step 230. The inter-base distance matrix data is two-dimensional matrix data formed by quantifying the distance (or traveling time) for all combinations of bases. Since the traveling route to and from the two bases may be different, when the number of bases is N, the number of all distances is N * (N-1). The distance between two bases is calculated by a program using the shortest path calculation method (for example, Dijkstra's algorithm) using the road vector data as input. The data 1052 is generated by using the site management data 1065 prior to the main arithmetic processing step 230, or the generated data is input and read into the input / output / calculation execution processing means 1051 of the main storage device. , Can directly perform high-speed arithmetic processing.

The parameters such as the mixed loading capacity set in FIG. 9 are used in the compulsory restriction condition violation processing step 233 in the main arithmetic processing step 230. Here, the compulsory restriction condition may be set with reference to the predetermined vehicle restriction condition described above, and the total load volume of the vehicle does not exceed the upper limit of the volume of the vehicle, or the total load weight of the vehicle is This includes not exceeding the load limit of the vehicle or the vehicle not violating the non-consolidated setting condition of the delivery task. Violation of any one of the above conditions indicates a violation of the mandatory restriction conditions.

FIG. 12 shows an example of the empty container mixed loading possibility determination process. For the delivery plan candidate which is the output of the delivery plan candidate generation 232, the vehicles assigned to each delivery task are checked one by one (step 2331), the capacity upper limit of the vehicle is exceeded (step 2332), and the cargo upper limit is exceeded. If the upper limit of the mixed loading capacity is exceeded (step 2333) or the upper limit of the mixed loading capacity is exceeded (step 2334), it is determined that the compulsory restriction condition has been violated (step 2336), and the process returns to the delivery plan candidate generation 232 again. In the opposite case, it is determined that the compulsory restriction condition is satisfied (step 2335), and the process proceeds to the total cost calculation step 234. Of course, in the embodiment of the present invention, the determination 233 itself for violating the compulsory restriction condition may be carried out in the delivery plan candidate generation 232.

Specifically, taking the output data 550 of FIG. 15 as an example, the total volume is obtained by adding the volume increase / decrease 570 according to the chronological order 564 for all the delivery vehicles assigned by the current delivery plan candidates. , Weight increase / decrease 571 is added to obtain the total weight, and when the state 565 is moving, the total volume and the total weight are the upper limit of the volume V and the upper limit of the weight W of the vehicle (362, 363). To determine if it exceeds. Similarly, for the mixed loading capacity M, it is determined whether or not the upper limit value of the mixed loading capacity is exceeded. Further, if the mixed loading capacity is set to 0 in the processing step 227 of FIG. 9, even if the mixed loading capacity is 1 in the determination of step 2334, the current vehicle can be mixedly loaded, so that the mixed loading is possible. Set the mixed loading capacity of the vehicle to a small positive number of 1 or less (for example, 0.001). In FIG. 12, the timing of returning to the delivery plan candidate generation step 232 is when a certain parameter of the vehicle violates the corresponding compulsory restriction condition, or when the number of vehicles violating the corresponding compulsory restriction condition reaches a certain number. Or, it is the time when the judgment about all the vehicles in the delivery plan candidate is completed.

One realization form of the processing flow of the total cost calculation 234 is shown in FIG. In the total cost calculation 234, for each delivery task of the delivery plan candidate output by the delivery plan candidate generation 232, there is a certain difference in the order of allocation of the delivery tasks from the viewpoint of the optimum solution, and the difference is quantified. Output as total total cost in arithmetic loop processing. First, in step 23401, it is determined whether all the delivery tasks have been processed. If it has been processed, the total cost is output and the process proceeds to step 235. If it has not been processed, one unprocessed delivery task is extracted and used as the current delivery task, and in step 23402, it is determined whether the current delivery task is an empty container return task. In the example of FIG. 8, it can be determined whether the task is an empty container return task by specifying that the task order 519 is NEXT and the task ID corresponding to the related task ID 520 is specified.

If it is determined in step 23402 that the current delivery task is not the empty container return task, the process returns to step 23401, but in the opposite case, the process proceeds to step 23403 and the delivery task related to the empty container return task (hereinafter referred to as the original). Determine if you want to assign the delivery task) to the same vehicle. Specifically, in the data format of the output data 550 described later, it is possible to determine whether the two corresponding delivery tasks described above belong to the same vehicle ID 562 and are the same vehicle. If the vehicles are not the same, it is determined that there is no optimum solution (far from the optimum solution), the preset cost α is added to the total cost (step 23404), and the process returns to step 23401. In the case of the same vehicle, since it is close to the optimum solution, α is subtracted from the total cost or another set value (for example, 30% of α) is subtracted (step 23405). Here, since α is added to or subtracted from the total cost with respect to the total cost, if the vehicles are not the same, only one of them may be added or subtracted. After the same vehicle determination process, the process proceeds to step 23406 to determine whether the empty container return task is executed after the original task. In the data format of the output data 550, the front-back order relationship of each delivery task can be determined by the order 564 of the same vehicle ID 562. The front-back determination is determined by whether there is a shipment of the return task after the unloading of the corresponding original delivery task. In the determination, there may be other delivery tasks between unloading and loading, or there may be time to spare. If the empty container return task is executed before the original task, it is far from the optimal solution, so β is added to the total cost (step 23407), and the process returns to step 23401. Further, when the empty container return task is executed after the original task, β is subtracted from the total cost in the same manner as in the above determination (step 23408). Finally, in step 23409, it is determined whether the empty container return task and the related package delivery task are executed within the above-mentioned predetermined time, and the empty container return task and the package delivery task corresponding to the empty container return task are performed. Determine if there are no other delivery tasks in between and the empty container return task is performed immediately after the package delivery task corresponding to the empty container return task. Specifically, in determining whether the empty container return task is executed immediately after the corresponding package delivery task, it can be determined whether the empty container return task is loaded immediately after the unloading of the corresponding package delivery task. If there is another delivery task between the two, add γ to the total cost (step 23410) and return to step 23401. In the opposite case, γ is subtracted from the total cost (step 23411), and the process returns to step 23401.

In the above three determination processes 23403, 23406, and 23409, predetermined constants α, β, and γ are set as cost values, and different costs are set by a method of gradually approaching the optimum solution in the optimum solution search process. (Α >> β >> γ is preferable). Therefore, in the main arithmetic processing step 230, the assignment of the original task to the same vehicle and the task of returning the empty container are preferentially executed. Next, the context of the delivery task and the empty container return task can be realized. Finally, consider a delivery order with no other delivery tasks between them. Here, the determination processes 23406 to 23408 regarding the cost β are processes for accelerating and surely converging to the optimum solution.

If the number of delivery tasks is relatively large, it may be difficult to converge to the optimal solution with the total cost calculation 234 alone, and there may be a delivery order mismatch in the delivery plan. Out of order here means that the empty container return task and the associated package delivery task are assigned to different delivery vehicles. In this case, in the embodiment of the present invention, the convergence is improved in combination with the above-mentioned order mismatch determination process, and the delivery order mismatch is reduced or set to zero. FIG. 14 shows an example of combining with the above-mentioned order mismatch determination process. Here, it is determined whether or not there is an order mismatch for the delivery plan candidate output in the delivery plan candidate generation step 232. If there is, the process returns to the step of generating the delivery plan candidate 232 again, and the order mismatch determination process is executed in the delivery plan candidate generation 232.

Specifically, first, after acquiring one delivery plan candidate in the delivery plan candidate generation step 232, the delivery plan candidate is set as the current delivery plan candidate. First, in step 2321, it is determined whether the traverse is completed for all the delivery tasks of the current delivery plan candidate. If it has been processed, the process proceeds to step 233. If it has not been processed, one unprocessed delivery task is extracted in step 2322 to be the current delivery task, and in step 2323 it is determined whether the current delivery task is an empty container return task. If it is determined in step 2323 that the current delivery task is not the empty container return task, the process returns to step 2321. In the opposite case, the process proceeds to step 2324 to determine whether to assign the delivery task related to the empty container return task (hereinafter referred to as the original delivery task) to the same vehicle. When assigning to the same vehicle, the process returns to step 2321. In the opposite case, the process proceeds to step 2325, the determination result of the out-of-order order is output, and the process returns to the delivery plan candidate generation step 232 to generate one delivery plan candidate again. The timing to return to the delivery plan candidate generation step 232 is when the out-of-order delivery task is found, after the traverse processing of all the delivery tasks in the current delivery plan candidate is completed, or the out-of-order delivery task. Is when the number reaches a predetermined number. Since the above processing has been performed, there is no order mismatch in the delivery plan candidates output thereafter. Therefore, steps 23403, 23404, and 23405 of FIG. 13 may be omitted in the total cost calculation of FIG.

In the delivery plan candidate generation step, since there may be a certain number or more of delivery tasks whose delivery order does not match among the delivery plan candidates acquired after the calculation loop is executed a certain number of times, the main calculation process step 230 is performed in the middle. You may finish it ahead of schedule with, or you may divide it into several times and execute the calculation loop process again by reducing the range of the input delivery task data.

In the division of the input data, for example, the delivery task in which the order mismatch occurs and all the delivery tasks related thereto are divided into one group, and the remaining delivery tasks are divided into two groups. Then, the delivery plan candidate generation process is performed for each group.

When generating delivery plan candidates for the groups acquired in the first two divisions, if there is no delivery order mismatch in each group, the delivery subplans of each group are collectively acquired as an overall delivery plan candidate. For example, when acquiring the delivery sub-plans of 5 and 7 delivery vehicles for two groups divided into two, a total of 12 delivery plan candidates for performing delivery processing are acquired and output. On the other hand, if the delivery order does not match again in a certain group, the group may be divided into two by the above method. The above two division processing may be performed a plurality of times until the delivery order mismatch does not occur in each group.

After the main calculation processing step 230, in the delivery plan output step 240, the generated delivery plan data is acquired in the data format of the output data 550 shown in FIG. 15 and display processing is performed. The output delivery plan is not limited to one, and the calculation result can be selected based on a plurality of elements. Select and output the appropriate delivery plan for one or more of several factors, such as total mileage, total delivery time, number of vehicles, number of unassigned delivery tasks, number of out-of-order delivery tasks, etc. It can be output in the format of data 550. In the output data 550, the operating status 565 of each delivery vehicle (vehicle ID 562) on the delivery date 561 is output according to the chronological order 564, and the output contents include the vehicle type 563 and the departure base / destination base (566) during traveling. / 567), the start / end time of the operating state 565 (568,569), the increase / decrease in volume / weight (570, 571) depending on the operating state 565 up to that point, and the delivery task ID 572 to be loaded / unloaded. Since one delivery task ID usually has cargo and unloading, two different operating states are generated.

16A to 16B show an example of an output screen generated based on the output data 550 in the delivery plan candidate 240. FIG. 16A is a delivery schedule table 600 showing the operating state of each delivery vehicle in a Gantt chart format in chronological order, and FIG. 16B is a delivery route 700 showing a delivery base and a delivery route included in the delivery plan on a map. Here, an output in which the vehicle ID 562 of FIG. 15 is A0123 will be described as an example. In the display of the delivery schedule table 600, the vehicle A0123 (611) is labeled on the vertical axis, and the specific operating status is displayed in chronological order (order 564) on the right side. In the output data 550, a total of 8 operating states of loading, moving, waiting, unloading, loading, lunch break, moving, and unloading are output, but in the delivery schedule table 600, base l, moving, waiting, base A, lunch break, A total of 7 states of movement and base l are shown. This is because "base A" is used on the display to indicate the two operating states of unloading and loading.

The delivery schedule table 600 and the delivery route 700 can correspond to each other. For example, in the delivery route 700, only the designated vehicle on the screen of the delivery schedule table 600 is displayed, and in the delivery schedule table 600, when the specific time 661 is specified on the time axis which is the horizontal axis, the delivery route 700 indicates the vehicle. The planned position 731 and the like are shown. When the operating state of the vehicle is "moving", the route between the destination and the starting point is subdivided when the moving speed is constant in order to determine the vehicle position 731 on the map, and from the starting point. The point at which the time is reached may be set as the display position. 16A to 16B are examples of display screen output. However, the same display contents may be output to an output medium such as PDF or paper.

Subsequently, another embodiment of the system block diagram of the embodiment of the present invention will be described with reference to the block diagram of FIG. FIG. 17 shows a structure in which the computer 100 of FIG. 3 is disassembled into servers / clients, and the structure of one server 172 and a plurality of clients 171 and 173 is taken as an example. The server 172 and the client 171 have basically the same hardware structure as the computer 100 of FIG. The client 171 includes a CPU 1711 / main storage device 1713, a secondary storage device 1714, a main bus 1712, a video card 1715, a network interface card (NIC) 1716, a video output port (not shown), 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 video card 1715, a network interface card (NIC) 1716, a video output port (not shown), and the like. .. Here, 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 CPU 1721, a main storage device 1723, a secondary storage device 1724, a main bus 1722, a video card 1725, a network interface card (NIC) 1726, a video output port (not shown), and the like. .. Here, 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 base management data module 17242, an optimum solution search processing module 17243, a vehicle management data module 17244, a road vector data 17245, and a delivery task data module 17246. .. In FIG. 17, the server 172 performs the arithmetic processing and the output processing shown in FIG. 4 in cooperation with the client 171 on the remote side via the network 175 (intranet or the Internet).

FIG. 18 shows the processing / data connection relationship of FIG. The client 171 first establishes a connection with the server 172. Therefore, authentication processing such as ID / PW is performed on API1727, the connection is 1: 1 and the execution standby state is entered. At this time, execution requests from a plurality of clients (for example, client 171) can be processed in parallel by invoking a process (process) or thread (thread) of the dedicated operation of the client 171 on the server side. In the data reading process 210, the base management data 17242, the vehicle management data 17244, and the delivery task data 17143 may be read from the client 171. As in the example shown in FIG. 18, the delivery task data 17143 is read from the client 101 and the server 172. The base management data 17242 and the vehicle management data 17244 may be read from. Since the base information and the vehicle information are usually changed infrequently, they are set on the server side as main (master) data to reduce the load of the data input process 122 and improve the processing efficiency. The main data is usually stored in CSV, table format, database format, or the like. As a result of the data input process 17141, the delivery task data 17143 is input by the API 1727 of the server 172 via the network 175.

After that, the input data 500 is generated by the calculation condition setting process 17241, or as shown in FIG. 18, the base management data 17242 is acquired via the API 1727 as the data input process 17141 and is read by the API 1727 of the server 172. The input data 500 shown in is generated. That is, it corresponds to executing a part of the calculation condition setting process 17241 by the data input process 17141. At this time, after inputting the data 500, it is sufficient to set whether or not mixed loading is possible only by the calculation condition setting process 17241. The inter-site distance data 17232 is generated by the server 172 using the road vector data 17245 and the base management data 17242. Further, the road vector data 17245 may be collected by an on-demand method from an external map information providing service system 176 such as the Internet via NIC1726.

After that, the optimum solution search process 17243 corresponding to the main arithmetic processing step 230 is executed, and one or more generated output data 550s are transmitted to the client 171 via the API 1727. 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 for the delivery route 700 output by the client 171 may be collected by an on-demand method from an external map information providing service 176 such as the Internet via NIC1716.

The present invention is realized by electronic hardware, or a combination of computer software and electronic hardware, in conjunction with the steps of each exemplary means and algorithm described in the examples disclosed in the text. Those skilled in the art can recognize that. Whether these functions are performed in hardware or software depends on the specific application of the technical means and design limitations. Those skilled in the art can realize the described functions in different ways depending on each specific application, but these realizations are not considered to be beyond the scope of the present invention.

For the convenience and conciseness of the description, those skilled in the art can refer to the corresponding process of the above-mentioned method embodiment for the specific work process of the system, device and means described above, which is obvious to those skilled in the art. It will not be described repeatedly here.

It should be understood that in the embodiments according to the present application, the disclosed devices and methods are feasible in other ways. For example, the examples of the devices described above are merely exemplary. For example, the classification of the above means is merely a classification of a logical function, and there may be another classification method when it is actually realized. For example, multiple means or components may be combined or integrated into another system, or some features may be ignored or not implemented. Also, the couplings, direct couplings and communication connections between the components shown and discussed here are via interfaces, and the indirect couplings or communication connections of devices or means are electrical connections, mechanical connections or other forms.

The means described as the separating parts may or may not be physically separated, and the member labeled as the means may or may not be the physical means. That is, it may be located in one place or distributed in a plurality of network means. Some or all means thereof are selected according to actual needs to realize the object of the embodiment of the present invention.

Further, each functional means in each embodiment of the present invention may be integrated in one processing means, or each means may be physically present individually, and two or more means may be one means. It may be accumulated in.

When the above functions are realized in the form of software functional means and sold and used as independent products, they can be stored in one computer-readable storage medium. Based on this understanding, the technical means of the present invention may be in the form of a software product in substance, or a portion that has contributed to the prior art, or a portion of the technical means. The computer software product is stored in one storage medium, and all of the methods described in each embodiment of the present invention in one computer device (personal computer, server, network device, etc.) including several instructions. Or have some steps performed. The storage medium includes a medium capable of storing various 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 merely a specific embodiment of the present invention, and the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the disclosure of the present invention are covered by the scope of protection of the present invention. Therefore, the scope of protection of the present invention is based on the scope of protection claimed by the patent.

Claims (16)

It is a delivery plan generation method
If the computer has one or more delivery tasks associated with information that requires the collection of empty containers, among the delivery tasks represented by the delivery task data containing information about multiple delivery tasks, the one or more. For each delivery task, a step to generate information about the empty container pick-up task associated with the delivery task, and
A computer assigns the plurality of delivery tasks and the generated empty container pick-up task to the plurality of delivery vehicles represented by vehicle management data including information on the plurality of delivery vehicles by a predetermined delivery plan generation algorithm. Steps to create a plan candidate and
In the delivery plan candidate, the computer executes the empty container pick-up task before the delivery task associated with the delivery plan candidate, and based on whether there is another task between those tasks, the delivery plan candidate is selected. Steps to evaluate and
A delivery plan generation method comprising: that a computer outputs one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidate. It is a delivery plan generation method
If the computer has one or more delivery tasks associated with information that requires empty container return, among the delivery tasks represented by the delivery task data containing information about multiple delivery tasks, the one or more delivery tasks. For each of the steps to generate information about the empty container return task associated with the delivery task,
A delivery plan in which the computer assigns the plurality of delivery tasks and the generated empty container return task to the plurality of delivery vehicles represented by vehicle management data including information on the plurality of delivery vehicles by a predetermined delivery plan generation algorithm. Steps to create a candidate and
In the delivery plan candidate, the computer evaluates the delivery plan candidate based on whether the empty container return task is executed after the delivery task associated therewith and there are other tasks between those tasks. Steps and
A delivery plan generation method comprising: that a computer outputs one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidate. In the method according to claim 1 or 2.
In the step of evaluating the delivery plan candidate,
Whether or not the delivery task and the empty container task group which is at least one of the empty container pick-up task and the empty container return task associated with the delivery task are assigned to the same delivery vehicle, and the empty container task group The empty container task group is provided with task costs of different sizes, which are executed before and / or after the delivery task associated therewith, and based on whether there are other tasks between those tasks.
A delivery plan generation method comprising: using the total cost of the delivery plan candidate obtained by summing the task costs of the delivery plan candidate as an evaluation result of the delivery plan candidate. In the method according to any one of claims 1 to 3,
It is assigned to a delivery vehicle different from the delivery vehicle to which the delivery task associated with the empty container task group, which is at least one of the empty container pick-up task and the empty container return task, existing in the delivery plan candidate is assigned. Steps to determine the number of empty container tasks and
If the number exceeds a preset threshold, adjust the delivery order of such empty container tasks, or the delivery order of the delivery tasks with which such empty container tasks are associated, or deliver. A delivery plan generation method characterized by including steps to exclude plan candidates. In the method according to any one of claims 1 to 4,
A step of presetting the delivery capacity used for determining whether or not to allow mixed loading for a delivery vehicle, and a step of presetting a mixed loading capacity which is used for determining whether or not to allow mixed loading for a delivery task and has an upper limit value.
A delivery plan generation method comprising a step of setting the mixed loading capacity of a delivery task that cannot be mixed loading to the upper limit value of the mixed loading capacity. In the method according to claim 5,
After generating one delivery plan candidate, a step of determining whether or not a delivery vehicle exceeding the mixed loading capacity exists in the delivery plan candidate, and
If a delivery vehicle that exceeds the consolidated capacity is present in the delivery plan candidates, the delivery order of such a delivery task or the delivery order of the empty container tasks associated with such a delivery task is adjusted. Alternatively, a delivery plan generation method including the step of excluding the delivery plan candidate, wherein the empty container task group is at least one of an empty container pick-up task and an empty container return task. In the method according to claim 6,
After generating one delivery plan candidate, the step of determining whether or not a delivery vehicle exceeding the mixed loading capacity exists in the delivery plan candidate is a step.
For the delivery vehicle of the delivery plan candidate, the route between the adjacent bases through which the delivery vehicle passes is determined, the mixed loading capacity of all the delivery tasks on the route of the delivery vehicle is accumulated, and the upper limit value of the mixed loading capacity is accumulated. If so, determine that there is a delivery vehicle that exceeds the mixed loading capacity,
or,
For a route between adjacent bases of the delivery plan candidate, one or a plurality of delivery vehicles via the route are determined, and the mixed loading capacities of all the delivery tasks in the route of each delivery vehicle are accumulated. A delivery plan generation method comprising determining that there is a delivery vehicle that exceeds the mixed loading capacity when it is equal to or greater than the upper limit of the mixed loading capacity. In the method according to any one of claims 1 to 7.
Before generating the delivery plan candidate,
A delivery plan generation method comprising a step of distributing one task indicator ID that uniquely labels the delivery task to all delivery tasks and establishing a relational relationship with the related delivery tasks. In the method according to any one of claims 1 to 7.
In the process of repeating the generation of delivery plan candidates up to the preset upper limit of the number of searches based on the predetermined delivery plan generation algorithm, among the delivery plan candidates obtained when the number of generations reaches the preset number of times, If the number of empty container tasks assigned to a delivery vehicle that is different from the delivery vehicle to which the delivery task associated with the empty container return task exceeds a predetermined value,
The delivery task in the original task group whose initial value is the delivery task waiting to be assigned is the empty container task group and the empty container task group assigned to a delivery vehicle different from the delivery vehicle to which the delivery task to which the empty container task group is associated is assigned. A step of separating two groups, a first task group consisting of a delivery task to which an empty container task group is associated, and a second task group consisting of other tasks.
Based on a predetermined delivery plan generation algorithm, delivery sub-plan candidates are generated for the first task group and the second task group, respectively, and the first delivery sub-plan candidate and the second delivery sub-plan candidate are selected. Steps to get and
If there is an empty container task group assigned to a delivery vehicle different from the delivery vehicle to which the delivery task to which the empty container task group is associated exists in the first delivery sub-plan candidate, the first task group is assigned. A step of returning to the step of dividing the delivery task in the former task group into two groups as the former task group, and a step of returning to the step of dividing the delivery task in the former task group into two groups.
If there is no 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 delivery sub-plan candidate, the first delivery is performed. The empty container task group includes an empty container pick-up task and an empty container return task, including a step of collecting the sub-plan candidates and all the second delivery sub-plan candidates and acquiring the delivery plan candidates of the delivery task waiting to be assigned. A delivery plan generation method characterized by being at least one of. In the method according to any one of claims 1 to 9,
The evaluation of the delivery plan candidate is further characterized in that the total of the total cost and the delivery distance cost of the delivery task in the delivery plan candidate is calculated and used as the evaluation result of the delivery plan candidate. .. It is a delivery plan generator
A storage device that stores vehicle management data including information on a plurality of delivery vehicles and delivery task data including information on a plurality of delivery tasks.
If there is one or more delivery tasks associated with information that requires empty container collection among the delivery tasks represented by the delivery task data, each of the one or more delivery tasks is associated with the delivery task. Generate information about the empty container pick-up task
A delivery plan candidate is created by assigning the plurality of delivery tasks and the generated empty container pick-up task to the plurality of delivery vehicles represented by the vehicle management data by a predetermined delivery plan generation algorithm.
In the delivery plan candidate, the delivery plan candidate is evaluated based on whether the empty container pick-up task is executed before the delivery task associated therewith and there are other tasks between those tasks.
A delivery plan generator comprising a processor that outputs one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidates. It is a delivery plan generator
A storage device that stores vehicle management data including information on a plurality of delivery vehicles and delivery task data including information on a plurality of delivery tasks.
When there is one or more delivery tasks associated with the information that requires the return of empty containers among the delivery tasks represented by the delivery task data, each of the one or more delivery tasks is associated with the delivery task. Generate information about the empty container return task and
A delivery plan candidate is created by assigning the plurality of delivery tasks and the generated empty container return task to the plurality of delivery vehicles represented by the vehicle management data by a predetermined delivery plan generation algorithm.
In the delivery plan candidate, the empty container return task is executed after the delivery task associated therewith, and the delivery plan candidate is evaluated based on whether there are other tasks between those tasks.
A delivery plan generator comprising a processor that outputs one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidates. In the apparatus according to claim 11 or 12,
To evaluate the delivery plan candidate,
Whether the delivery task and the empty container task group associated therewith are assigned to the same delivery vehicle, and whether the empty container task group is executed before and / or after the delivery task associated therewith. Based on whether there are other tasks between those tasks, it is possible to set task costs of different sizes for each empty container task group.
The total cost of the delivery plan candidate obtained by summing the task costs of the delivery plan candidate is used as the evaluation result of the delivery plan candidate, and the empty container task group includes the empty container pick-up task and the empty container pick-up task. A delivery plan generator, characterized in that it is at least one of the empty container return tasks. In the apparatus according to any one of claims 11 to 13.
The processor
The number of empty container task groups assigned to a delivery vehicle different from the delivery vehicle to which the delivery task associated with the empty container task group exists in the delivery plan candidate is determined.
If the number exceeds a preset threshold, adjust the delivery order of such empty container tasks, or the delivery order of the delivery tasks with which such empty container tasks are associated, or deliver. Exclude plan candidates,
An empty container task group is a delivery plan generation device characterized in that it is at least one of an empty container pick-up task and an empty container return task. If there is one or more delivery tasks associated with information that requires empty container pick-up among the delivery tasks represented by the delivery task data containing information about multiple delivery tasks, each of the one or more delivery tasks. To generate information about the empty container pick-up task associated with the delivery task,
A delivery plan candidate that allocates the plurality of delivery tasks and the generated empty container pick-up task to the plurality of delivery vehicles represented by vehicle management data including information on the plurality of delivery vehicles by a predetermined delivery plan generation algorithm. Steps to create and
In the delivery plan candidate, the step of evaluating the delivery plan candidate based on whether the empty container pick-up task is executed before the delivery task associated therewith and there are other tasks between those tasks. When,
A computer program that causes a computer to execute a step of outputting one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidates. If there is one or more delivery tasks associated with information that requires empty container return among the delivery tasks represented by the delivery task data containing information about multiple delivery tasks, for each of the one or more delivery tasks. , Steps to generate information about the empty container return task associated with the delivery task, and
A predetermined delivery plan generation algorithm creates a delivery plan candidate that assigns the plurality of delivery tasks and the generated empty container return task to the plurality of delivery vehicles represented by vehicle management data including information on the plurality of delivery vehicles. Steps to do and
In the delivery plan candidate, a step of evaluating the delivery plan candidate based on whether the empty container return task is executed after the delivery task associated therewith and there are other tasks between those tasks.
A computer program that causes a computer to execute a step of outputting one or more delivery plan candidates as a delivery plan based on the evaluation of the delivery plan candidates.

Images