Delivery plan support system, delivery plan support method, and computer program

Abstract

A delivery plan assistance system 16 comprises an acceptance unit 22, a check unit 24, and an indication unit 28. The acceptance unit 22 accepts data that indicates a plurality of constraints regarding a delivery plan when a plurality of vehicles branch out and deliver luggage from a delivery base to a plurality of nodes. The check unit 24 determines whether or not the plurality of constraints match regarding a time and / or a resource allocation. The indication unit 28 inputs a delivery plan indication based on the plurality of constraints to a delivery plan generation unit 30 when it is determined that the plurality of constraints match.

Description

[Technical field]

[0001] The present disclosure relates to data processing technology, and in particular to a delivery plan support system, a delivery plan support method, and a computer program. [Background technology]

[0002] An example of a combinatorial optimization problem in the real world that finds an appropriate solution while considering a huge number of combinations of various factors is the traveling salesman problem. The traveling salesman problem is a problem of determining the order of cities to visit so as to minimize the travel distance when a salesman leaves a certain city and visits each of the other cities once before returning to the city from which he left. The following Patent Document 1 proposes a system that presents a route from a departure point to a destination point, taking into account the traffic conditions between each point that change depending on the time of day. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-56730 A Summary of the Invention [Problem to be solved by the invention]

[0004] In a delivery plan in which multiple mobile objects divide the work of delivering packages from a delivery center to multiple nodes, it is necessary to find a solution that satisfies various constraints, including travel time between nodes and business requirements. However, due to the existence of various constraints, it is not easy to find a feasible solution (in other words, a solution that satisfies multiple constraints). For example, even if a solution for a delivery plan is derived after much time, the derived solution may violate one of the constraints, in other words, the derived solution may not be a feasible solution.

[0005] The present disclosure has been made based on the inventor's recognition of the above problem, and one objective is to provide a technology for detecting, before generating a delivery plan, when there is no solution that satisfies multiple constraints on the delivery plan. [Means for solving the problem]

[0006] In order to solve the above problems, a delivery plan support system according to one aspect of the present disclosure includes a reception unit that receives data indicating multiple constraints related to a delivery plan when multiple mobile objects divide up to deliver packages from a delivery center to multiple nodes, a determination unit that determines whether the multiple constraints are consistent with respect to at least one of time and resource allocation, and an instruction unit that inputs delivery plan instructions based on the multiple constraints to a delivery plan generation unit when the determination unit determines that the multiple constraints are consistent.

[0007] Another aspect of the present disclosure is a delivery plan support method, which includes a step of receiving data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile bodies distribute packages from a delivery base to a plurality of nodes by dividing the work, a step of determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation, and a step of inputting a delivery plan instruction based on the plurality of constraints to a delivery plan generating unit when it is determined in the determining step that the plurality of constraints are consistent.

[0008] Any combination of the above components and any conversion of the expressions of the present disclosure between an apparatus, a computer program, a recording medium storing a computer program, etc. are also valid as aspects of the present disclosure. Effect of the Invention

[0009] According to the present disclosure, when there is no solution that satisfies multiple constraints on a delivery plan, this can be detected before the delivery plan is generated. [Brief description of the drawings]

[0010] [Figure 1]FIG. 1 illustrates an example of multiple constraints on a dispatch plan. [Diagram 2] FIG. 1 is a diagram illustrating a configuration of an information processing system according to an embodiment. [Diagram 3] FIG. 13 is a diagram showing check items to be checked by a checking unit. [Figure 4] FIG. 13 is a diagram for explaining the inconsistencies that are detected by the check of ID10. [Diagram 5] FIG. 13 is a diagram showing an example implementation of the ID10 check algorithm. [Figure 6] FIG. 13 is a diagram for explaining the inconsistency that is the target of detection by the check of ID11. [Figure 7] FIG. 11 is a diagram for explaining the check algorithm of ID11. [Figure 8] FIG. 13 is a diagram showing an example of an implementation of the ID11 check algorithm. [Figure 9] FIG. 13 is a diagram for explaining the inconsistencies that are the object of detection by the check of ID12. [Figure 10] FIG. 13 is a diagram for explaining the check algorithm for ID12. [Figure 11] FIG. 13 is a diagram showing an example implementation of the check check algorithm of ID12. [Figure 12] FIG. 13 is a diagram for explaining the inconsistencies that are detected by checking ID14. [Figure 13] FIG. 11 is a diagram explaining the check algorithm for ID14. [Figure 14] FIG. 13 is a diagram showing an example implementation of the ID14 check algorithm. [Figure 15] FIG. 13 is a diagram for explaining the inconsistencies that are the subject of detection when checking ID15. [Figure 16] FIG. 13 is a diagram for explaining the check algorithm for ID15. [Figure 17] FIG. 13 is a diagram for explaining the check algorithm for ID15. [Figure 18] FIG. 13 is a diagram for explaining the check algorithm for ID15. [Figure 19] FIG. 13 is a diagram showing an example of an implementation of the ID15 check algorithm. [Figure 20]FIG. 13 is a diagram for explaining the inconsistencies that are detected by checking ID26. [Figure 21] FIG. 13 is a diagram explaining the check algorithm of ID26. [Figure 22] FIG. 13 is a diagram explaining the check algorithm of ID26. [Figure 23] FIG. 13 is a diagram showing an example implementation of the ID26 check algorithm. [Figure 24] FIG. 13 is a diagram for explaining the inconsistencies that are detected by the check of ID27. [Diagram 25] FIG. 13 is a diagram explaining the check algorithm of ID27. [Figure 26] FIG. 13 is a diagram showing an example implementation of the ID27 check algorithm. [Figure 27] FIG. 13 is a diagram for explaining inconsistencies that are detected by checking ID28. [Figure 28] FIG. 13 is a diagram showing an example implementation of the ID28 check algorithm. [Figure 29] FIG. 13 is a diagram for explaining the inconsistencies that are detected by checking ID29. [Diagram 30] FIG. 13 is a diagram showing an example implementation of the ID29 check algorithm. [Diagram 31] FIG. 13 is a diagram for explaining the inconsistencies that are detected by the ID30 check. [Diagram 32] FIG. 13 is a diagram explaining the check algorithm of ID30. [Diagram 33] FIG. 13 is a diagram explaining the check algorithm of ID30. [Diagram 34] FIG. 13 is a diagram showing an example implementation of the ID30 check algorithm. [Diagram 35] FIG. 13 is a diagram showing an example implementation of the ID30 check algorithm. [Diagram 36] FIG. 13 is a diagram showing an example implementation of the ID30 check algorithm. [Figure 37] FIG. 13 is a diagram for explaining the inconsistencies that are detected by the ID31 check. [Figure 38] FIG. 13 is a diagram for explaining the ID31 check algorithm. [Figure 39] FIG. 13 is a diagram for explaining the ID31 check algorithm. [Diagram 40] FIG. 13 is a diagram showing an example implementation of the ID31 check algorithm. [Diagram 41] 13 is a diagram for explaining inconsistencies that are detected by the ID32 check. [Diagram 42] FIG. 13 is a diagram illustrating an example of an implementation of the ID32 check algorithm. [Diagram 43] FIG. 13 is a diagram illustrating an example of an implementation of the ID32 check algorithm. [Diagram 44] FIG. 13 is a diagram illustrating an example of an implementation of the ID32 check algorithm. [Diagram 45] FIG. 1 is a diagram explaining the ID32 check algorithm. [Diagram 46] FIG. 13 is a diagram illustrating an example of an implementation of the ID32 check algorithm. [Figure 47] FIG. 13 is a diagram illustrating an example of an implementation of the ID32 check algorithm. [Figure 48] FIG. 13 is a diagram illustrating an example of route derivation using a nearest neighbor method. [Figure 49] FIG. 13 is a diagram illustrating an example of vehicle allocation to a final visited node. [Figure 50] FIG. 13 is a diagram illustrating an example of vehicle allocation to a final visited node. [Figure 51] FIG. 11 is a diagram illustrating an example of vehicle allocation to a first-time visited node. [Figure 52] FIG. 11 is a diagram illustrating an example of vehicle allocation to a first-time visited node. [Figure 53] FIG. 13 is a diagram illustrating an implementation example of a conversion unit. [Figure 54] FIG. 13 is a diagram illustrating an implementation example of a conversion unit. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] The subject of the device or method in the present disclosure includes a computer. The computer executes a computer program to realize the function of the subject of the device or method in the present disclosure. The computer includes a processor that operates according to the computer program as a main hardware configuration. The type of the processor is not important as long as the function can be realized by executing the computer program. The processor is composed of one or more electronic circuits including a semiconductor integrated circuit (IC, LSI, etc.). The computer program is recorded on a non-transitory recording medium such as a computer-readable ROM, an optical disk, or a hard disk drive. The computer program may be stored in the recording medium in advance, or may be supplied to the recording medium via a wide area communication network including the Internet.

[0012] An overview of the embodiment will be described. In a delivery plan in which multiple mobile objects divide the work to deliver parcels from a delivery base (hereinafter also referred to as a "depot") to multiple nodes, a solution must be found that satisfies various constraints (which can also be called constraint conditions), including travel time between nodes and business requirements. In the embodiment, the mobile objects are vehicles (trucks, etc.) that deliver parcels, and the nodes are stores to which the parcels are delivered. The delivery plan can be said to be a plan that specifies which vehicles will visit which stores and in what order, and can also be said to be a plan that specifies the delivery route (which can also be called the travel path) from when each vehicle leaves the depot to when it returns to the depot, passing through one or more stores.

[0013] Figure 1 shows examples of multiple constraints on a delivery plan. Constraint 1 "loading time" is the time it takes to load a vehicle at the depot. Constraint 2 "departure time" is the time when the vehicle can leave the depot. Constraint 3 "delivery time frame" is the time frame when the vehicle can visit each store. Constraint 4 "store residence time" is the time when the vehicle can stay at the store. Constraint 5 "cargo volume" is the amount of cargo that can be loaded into each vehicle and the amount of cargo that needs to be delivered to each store.

[0014] Constraint 6 "Route time subtotal" is the maximum possible delivery time per route (in other words, the time from leaving the depot to visiting the stores and then returning to the depot). Constraint 7 "Number of berths" is the number of garages (hereinafter also referred to as "berths") that can be used simultaneously for loading operations at the depot. Constraint 8 "Number of vehicles" is the number of vehicles that will be divided up and visit multiple stores. Although not shown in Figure 1, the constraints in the embodiment include a distance matrix that indicates the distance between the depot and each store and the distance between stores (specifically, the time distance, which can also be said to be travel time).

[0015] It is not easy to find a solution (hereinafter referred to as a "feasible solution") for a delivery plan that simultaneously satisfies various constraints as shown in Figure 1, and it takes time to search for a solution. For example, (Problem 1) It takes a lot of time to find a solution for a delivery plan in 10 100 Even if we derive 10 solutions, each of them may violate some constraint (hereafter referred to as an "infeasible solution"). 800 In a vehicle routing problem with solutions, 10 600 Even if all of these are feasible solutions, the remaining (10 800 -10 600 ) solutions.

[0016] In the embodiment, a technology is proposed that supports the reliable acquisition of a feasible solution for a delivery plan. In the delivery plan support system of the embodiment, in order to solve the above problem 1, a process is run to detect when a feasible solution does not exist before the process of generating a delivery plan for multiple vehicles (which can also be called a delivery route determination process or a delivery route optimization process). Specifically, a process is run to detect when multiple constraints are mutually contradictory (in other words, inconsistent). In addition, in order to solve the above problem 2, the constraint data is converted so that the delivery route can be efficiently solved, taking into account the nature of the algorithm applied to determine the delivery route.

[0017] An embodiment will now be described in detail. Fig. 2 shows the configuration of an information processing system 10 according to the embodiment. The information processing system 10 includes a user terminal 12, a front system 14, and a delivery plan support system 16. These are connected via a communication network including a LAN, a WAN, the Internet, and the like.

[0018] The user terminal 12 is an information processing terminal operated by a person in charge (hereinafter also referred to as a "user") of a business operator involved in the delivery of packages to nodes (hereinafter also referred to as a "delivery business operator"). The user creates multiple constraints related to the delivery plan as shown in FIG.

[0019] The front system 14 transmits data indicating a plurality of constraints transmitted from the user terminal 12 to the delivery plan support system 16. The front system 14 may set constraint data based on the data transmitted from the user terminal 12. In addition, the front system 14 transmits data based on the delivery plan transmitted from the delivery plan support system 16 to the user terminal 12. The data based on the delivery plan may include, for example, a course chart indicating nodes that each of a plurality of vehicles should visit.

[0020] The delivery plan support system 16 is a system that supports the formulation of a delivery plan. The delivery plan support system 16 includes a preprocessing unit 20 and a delivery plan generating unit 30. The delivery plan support system 16 may be realized by one computer, or may be realized by a plurality of computers working together. In an embodiment, the preprocessing unit 20 and the delivery plan generating unit 30 are realized by separate computers, and the computer in which the function of the preprocessing unit 20 is implemented and the computer in which the function of the delivery plan generating unit 30 is implemented are connected via a communication network. For example, the function of the delivery plan generating unit 30 may be provided as a cloud service (e.g., SaaS).

[0021] The delivery plan generating unit 30 generates a delivery plan, in other words, determines (solves) an optimal delivery route for a plurality of vehicles. The delivery plan generating unit 30 can apply various algorithms in generating the delivery plan. The delivery plan generating unit 30 may also be realized using a quantum computer capable of solving combinatorial optimization problems at high speed. In the embodiment, the delivery plan generating unit 30 generates the delivery plan using a nearest neighbor algorithm, which is a known clustering method. The delivery plan generating unit 30 also sequentially determines delivery routes for a plurality of vehicles according to a predetermined order.

[0022] The pre-processing unit 20 executes pre-processing for generating a delivery plan. The pre-processing unit 20 includes a reception unit 22, a check unit 24, a conversion unit 26, and an instruction unit 28. The functions of these multiple functional blocks (which may include the delivery plan generating unit 30) may be implemented in a computer program. The computer program may be stored in the storage of a computer constituting the delivery plan support system 16. The processor (CPU, etc.) of the computer constituting the delivery plan support system 16 may fulfill the functions of the above multiple functional blocks by reading the computer program into a main memory and executing it.

[0023] The reception unit 22 receives data indicating multiple constraints related to the delivery plan transmitted from the front system 14. The check unit 24 can also be called a judgment unit, and judges whether the multiple constraints related to the delivery plan are consistent with respect to at least one of time and resource allocation (in other words, whether they are contradictory).

[0024] The conversion unit 26 accepts a first visited node constraint, a last visited node constraint, and a node vehicle constraint. The first visited node constraint is a constraint that specifies a first visited node that is a node that should be visited first on a route from a depot. The last visited node constraint is a constraint that specifies a last visited node that is a node that should be visited last on a route from a depot. The node vehicle constraint is a constraint that specifies a vehicle that should visit the first visited node or the last visited node. The conversion unit 26 converts the node vehicle constraint so that the last visited node is preferentially assigned to a vehicle that is relatively later in the route determination order. Moreover, the conversion unit 26 converts the node vehicle constraint so that the first visited node is preferentially assigned to a vehicle that is relatively earlier in the route determination order.

[0025] When the checking unit 24 determines that the multiple constraints related to the delivery plan are consistent (in other words, not contradictory), the instructing unit 28 inputs a delivery plan instruction to the delivery plan generating unit 30 to generate a delivery plan based on the multiple constraints. In the embodiment, the instructing unit 28 transmits data of the delivery plan instruction including the multiple constraints to the delivery plan generating unit 30 via a communication network. The multiple constraints included in the delivery plan instruction include node vehicle constraints converted by the converting unit 26.

[0026] Next, the check process performed by the check unit 24 of the delivery plan support system 16 will be described in detail.

[0027] FIG. 3 shows check items by the check unit 24. The check items by the check unit 24 include 32 check items shown in FIG. 3. FIG. 3 shows whether each check item corresponds to the time consistency check, the resource allocation check, and the business constraint check. In FIG. 3, a double circle ◎ is used when it strongly corresponds, a single circle ○ is used when it weakly corresponds, and no mark is used when it does not correspond. The time consistency check is a check of whether multiple constraints regarding time, such as the departure time frame of a depot or node, are consistent. The resource allocation check is a check of whether multiple constraints regarding resource allocation, such as the number of berths, the number of vehicles, and the amount of cargo, are consistent. The business constraint check is a check of whether multiple constraints regarding the business constraints of the delivery company are consistent.

[0028] In the check of ID1, even if the vehicle departs from the node at the earliest time within the possible departure time frame set for the node, if the vehicle cannot return to the depot within the maximum delivery time (e.g., 5 hours) set for the node, an error is detected. If an error is detected in this check, the check unit 24 determines that multiple constraints are inconsistent (in other words, contradictory). Note that in the embodiment, the possible departure time frame for a node is also the time frame in which a vehicle can arrive at the node, and can also be said to be the possible arrival time frame.

[0029] When checking ID2, an error is detected if a delivery vehicle specified at a node is unable to return to the depot within the maximum delivery time set for that vehicle, even if it departs the node at the earliest possible time within the departure time frame set for that node.

[0030] The ID3 check detects an error if the number of nodes at which a vehicle can depart at the earliest possible time within the departure window and return to the depot within the maximum delivery time exceeds the number of vehicles.

[0031] In the check of ID4, if the node cannot arrive within the possible departure time frame of the first visited node even if it departs from the depot at the latest time (arrives earlier than the possible departure time frame), an error is detected.

[0032] The ID5 check detects an error if there are no more possible departure time slots when taking into account the possible departure time slots set for the node and the impossible departure time slots (time slots during which it is impossible to arrive at or depart from a node).

[0033] The ID6 check takes into account the possible departure time slots and impossible departure time slots set for the node, and detects an error if the earliest possible departure from the depot does not make it within the possible departure time slot for the node.

[0034] The ID7 check detects an error if a vehicle can return to the depot within the maximum delivery time if it departs from the node at the earliest time within the possible departure time frame set for the node, but if it cannot return to the depot within the maximum delivery time due to the impossible departure time frame set for the node.

[0035] The ID8 check detects an error if a deliverable vehicle specified at a node can return to the depot within the maximum delivery time if it departs from the node at the earliest time within the possible departure time frame set for that node, but cannot return to the depot within the maximum delivery time due to the impossible departure time frame set for that node.

[0036] In the ID9 check, if the non-possible departure time slots are excluded from the possible departure time slots of the first-time visited node, an error will be detected if the vehicle cannot arrive within the possible departure time slot of the first-time visited node even if it leaves the depot at the latest time (it arrives earlier than the possible departure time slot).

[0037] The ID10 check takes into account the number of berths at the depot, the berth occupancy time, and the depot's available departure time frame, and detects an error if a vehicle is unable to depart the depot within the depot's available departure time frame.

[0038] When checking ID11, if the number of nodes that cannot arrive in time unless they depart the depot berth on the first rotation exceeds the number of berths, an error will be detected (because there will be nodes that cannot arrive within the departure time frame).

[0039] The ID12 check detects an error if the number of nodes that can arrive within the departure time frame exceeds the number of berths if the depot departs late (because there will be nodes that arrive earlier than the departure time frame).

[0040] In the check of ID13, when the departure times of all vehicles from a depot are specified, an error is detected if the departure times of the specified vehicles deviate from the possible departure time frame of the depot.

[0041] The check of ID14 detects an error if the departure times of all vehicles from a depot are specified and there is a node that cannot arrive within the possible departure time frame at the specified departure time of the vehicle.

[0042] The check of ID15 detects an error if the departure times of all vehicles from the depot are specified and the specified departure times of the vehicles do not allow arrival at the first-time visited node within the available departure time slot.

[0043] The check of ID16 corresponds to the check of ID13. The check of ID16 detects an error when the departure time of some vehicles from a depot is specified and the specified departure time of the vehicle deviates from the possible departure time frame of the depot.

[0044] The check of ID17 corresponds to the check of ID10. The check of ID17 detects an error when the departure time of some vehicles from a depot is specified, and when there are vehicles that cannot depart from the depot within the depot's possible departure time frame, taking into account the number of berths at the depot, the berth occupancy time, and the depot's possible departure time frame.

[0045] The check for ID18 corresponds to the check for ID11. The check for ID18 detects an error when the departure time of some cars from a depot is specified and the number of nodes that will not be in time unless the car leaves the depot berth on the first rotation exceeds the number of berths.

[0046] The check for ID19 corresponds to the check for ID12. The check for ID19 detects an error when the departure time of some vehicles from a depot is specified, and the number of nodes that can arrive within the departure time frame if the vehicle departs the depot later exceeds the number of berths.

[0047] In the check of ID20, an error is detected if the departure time of some vehicles from the depot and the first visited node are both specified, and if a node cannot arrive within the possible departure time frame occurs.

[0048] The ID21 check detects an error if the departure time of some vehicles from the depot and the vehicles available for delivery to a node are both specified, resulting in a node that cannot arrive within the departure time frame.

[0049] In checking ID22, an error is detected if the total number of the specified first visited nodes and the specified last visited nodes exceeds the number of vehicles. The check unit 24 prohibits assigning both the specified first visited node and the specified last visited node to one vehicle. This is because if both the first visited node and the last visited node are assigned to one vehicle, the delivery route of the vehicle is likely to become distorted, which hinders the generation of an efficient delivery route.

[0050] The check for ID23 detects an error when a node is specified as both the first visited node and the last visited node.

[0051] When checking ID24, an error is detected if the total of the number of first visited nodes, last visited nodes, and fixed routes exceeds the number of vehicles. This is because the first visited node, last visited node, and fixed routes are assigned to different vehicles. Fixed routes are routes in which at least some of the node combinations are fixed, and include all fixed routes and forward-match fixed routes. All fixed routes are routes in which all node combinations are fixed, for example, a route in which "depot → node A → node B → node C → depot" is specified. Forward-match fixed routes are routes in which the node combinations at the front of the route are fixed, for example, a route in which "depot → node A → node B" is specified, and nodes after node B are unspecified.

[0052] The ID25 check detects an error if a node is specified in at least two of the following: the first visited node, the last visited node, and the fixed route.

[0053] The ID26 check detects an error if, when each node is assigned to a vehicle, a vehicle has a load that exceeds the load limit.

[0054] In checking ID27, an error is detected if, when each node is assigned to a vehicle, the number of nodes to be visited by a vehicle exceeds the maximum number of nodes that the vehicle can visit.

[0055] In the check of ID28, when a fixed route is assigned to a vehicle based on the designation of vehicles capable of delivery at each node, an error is detected if there is no vehicle that can be assigned to the fixed route due to load restrictions.

[0056] In the ID29 check, when a fixed route is assigned to a vehicle based on the specifications of vehicles capable of delivery at each node, an error is detected if there is no vehicle that can be assigned to the fixed route due to the limit on the maximum number of visited nodes.

[0057] The ID30 check detects an error when a fixed route is assigned to a vehicle and there is no vehicle that satisfies the departure time slot of each node in the fixed route.

[0058] The ID31 check detects an error if the sum of the number of first-visited nodes and the number of last-visited nodes exceeds the number of vehicles that can be assigned to those nodes.

[0059] The ID32 check checks whether any inconsistencies arise when the individual checks above are taken together.

[0060] Some of the check items will be explained in more detail below. The check of ID10, "Inconsistency between berth rotation speed and depot departure time frame," will be described in detail. FIG. 4 is a diagram explaining the inconsistency that is the target of the check of ID10 to detect. When the check unit 24 detects that a vehicle cannot depart from the depot within the depot's departure time frame based on the constraint of the number of berths at the depot, it determines that multiple constraints are inconsistent. When the check unit 24 considers the number of berths and berth occupancy time at the depot, and the depot's departure time frame, and there is a vehicle that cannot depart within the depot's departure time frame, it detects an inconsistency.

[0061] Specifically, the checking unit 24 uses a first-fit algorithm to solve a bin-packing problem in which the depot's available departure time frame is regarded as the capacity. The bin-packing problem is a problem of determining the minimum number of bins required to pack all blocks into bins that have a specific capacity. The first-fit algorithm is also called "First-Fit-Decreasing" and is an algorithm that packs blocks into the bin with the smallest subscript among the bins into which the blocks can be packed. The checking unit 24 checks that the calculated number (the number of bins) does not exceed the number of berths.

[0062] Figure 5 shows an example of the implementation of the check algorithm of ID 10. In the embodiment, the source code of Python is shown as an example of the implementation of each check algorithm. The input data showing the relevant constraints is as follows: data.depot_index: Depot index (int) data.time_windows.available_time: Available time window for departure for each node (dict) ·data.berth.berth_control:“auto” data.berth.depot_capacity: Number of berths (int) data.berth.loading_time: Berth occupancy time per vehicle (dict) If the number of vertices required exceeds the number of vertices as a constraint, the check unit 24 detects an error and detects an inconsistency between the constraints.

[0063] The check for ID11, "Revealing a node that exceeds the possible departure time frame by considering the second and subsequent rotations of the berth," will be described in detail. When the check unit 24 detects that a node occurs where a vehicle does not arrive within a predefined possible arrival time frame based on the constraint on the number of berths in the depot, it determines that multiple constraints are inconsistent. As mentioned above, the "possible arrival time frame" in the embodiment is synonymous with the "possible departure time frame."

[0064] Fig. 6 is a diagram explaining the inconsistencies that are the target of detection by the check of ID11. The figure shows an example in which, when there are more nodes that cannot make it unless they depart on the first rotation of the berth than there are number of berths, a node will be unable to arrive within the possible departure time frame. The figure shows a simple example. In reality, the possible departure time frame differs for each node, so the values ​​obtained by subtracting the time distance from the upper limit of the possible departure time frame are sorted in ascending order and checked. Also, since there is a possibility of reaching node C via node B or node A, the check is performed up to the second rotation.

[0065] 7 is a diagram explaining the check algorithm of ID11. The check unit 24 detects an error when the number of nodes that will not be able to be completed in the nth rotation exceeds (number of ports x n). However, since there is a possibility that it will be possible to make it via nodes up to the n-1th rotation, the check is limited to the second rotation.

[0066] Figure 8 shows an example implementation of the check algorithm for ID 11. The input data showing the relevant constraints are: data.depot_index: Depot index (int) data.edge.time: Distance matrix between depots and nodes, and between nodes (2-dimensional list) data.time_windows.available_time: Available time window for departure for each node (dict) ·data.berth.berth_control:“auto” data.berth.depot_capacity: Number of berths data.berth.loading_time: Berth occupancy time per vehicle (dict)

[0067] The check for ID12, “insufficient nodes allocated for berth 1st rotation”, will now be described in detail. When the check unit 24 detects that a node occurs at which a vehicle does not arrive within a predefined possible arrival time frame based on predefined constraints on departure times from a depot for multiple vehicles, the check unit 24 determines that the multiple constraints are inconsistent.

[0068] FIG. 9 is a diagram for explaining the inconsistency to be detected by the check of ID12. When there are only nodes where the vehicle can make it in time if it departs from the depot berth later, if the number of corresponding nodes is greater than the number of berths, a node will occur where the vehicle arrives earlier than the possible departure time frame. The figure shows a simple example. In reality, the possible departure time frame differs for each node, so the values ​​obtained by subtracting the time distance from the lower limit of the possible departure time frame for each node are sorted in descending order and checked. Strictly speaking, the earliest depot departure time is found for each node, and if there are not enough allocated nodes for the first rotation of the berth, an error is detected. Since the berth is the most important resource related to the delivery of goods, in the embodiment, it is assumed that the first rotation of the berth is used up.

[0069] Fig. 10 is a diagram explaining the check algorithm of ID12. If the number of nodes that arrive within the possible departure time frame due to the vehicle departing on the first rotation of the berth is less than the number of berths, an error is detected. This is because the first rotation of the berth cannot be used up, and if an attempt is made to use up the first rotation of the berth, a node will arise where the vehicle arrives earlier than the possible departure time frame.

[0070] Figure 11 shows an example implementation of the check check algorithm with ID 12. The input data showing the relevant constraints are as follows: data.num_vehicles: Number of vehicles (int) data.depot_index: Depot index (int) data.edge.time: Distance matrix between depots and nodes, and between nodes (2-dimensional list) data.num_nodes: Number of nodes (int) data.time_windows.available_time: Available time window for departure for each node (dict) ·data.berth.berth_control:“auto” data.berth.depot_capacity: Number of berths data.berth.loading_time: Berth occupancy time per vehicle (dict)

[0071] The check for ID14, "Setting strict early delivery conditions with all depot departure times fixed," will be explained in detail. If the check unit 24 detects that a node occurs where a vehicle does not arrive within a predefined possible arrival time frame based on predefined constraints on departure times from a depot for multiple vehicles, the check unit 24 determines that the multiple constraints are inconsistent.

[0072] Fig. 12 is a diagram explaining the inconsistencies that are the target of detection by the check of ID14. In a situation where the departure times from the depot for all vehicles are fixed, and there are many nodes where a vehicle can just make it in time by departing the depot earlier, there may be a node where the vehicle cannot arrive within the possible departure time frame. This diagram shows a simple example. In reality, each node has a different possible departure time frame, so the values ​​obtained by subtracting the time distance from the upper limit of the possible departure time frame for each node are sorted in ascending order and checked.

[0073] Fig. 13 is a diagram explaining the check algorithm for ID14. The latest departure time from the depot that will fit within the node's possible departure time frame (hereinafter referred to as the "latest departure time") is calculated and sorted in ascending order. A comparison of the latest departure time for each node with the departure time of the vehicle (all fixed) is made to see if there are any nodes where the vehicle will not arrive within the possible departure time frame. In the example of Fig. 13, node A is a node where the vehicle will not arrive within the possible departure time frame.

[0074] Figure 14 shows an example implementation of the check algorithm for ID 14. The input data showing the relevant constraints are: data.depot_index: Depot index (int) data.edge.time: Distance matrix between depots and nodes, and between nodes (2-dimensional list) data.time_windows.available_time: Available time window for departure for each node (dict) ·data.berth.berth_control:“auto” data.berth.const_berth: Depot departure time for each vehicle (all fixed) (list)

[0075] The check for ID15, "Setting strict early / late delivery conditions with completely fixed depot departure times," will be described in detail. For a first-time visited node, the check unit 24 compares the time at which the depot should be departed to arrive at the node in the reachable time frame with the departure times of multiple vehicles from the depot in descending order to determine whether or not a vehicle can be assigned to the node. The first-time visited node is a node that is specified by a constraint as the first node to be visited on the vehicle's travel route from the depot. On the other hand, for nodes other than the first-time visited node, the check unit 24 compares the time at which the depot should be departed to arrive at the node in the reachable time frame with the departure times of multiple vehicles from the depot in ascending order to determine whether or not a vehicle can be assigned to the node. If a node to which a vehicle cannot be assigned occurs, the check unit 24 determines that multiple constraints are inconsistent.

[0076] FIG. 15 is a diagram explaining the inconsistency that is the target of the check of ID15 to be detected. In a situation where the depot departure times of all vehicles are fixed, if the node is not set as a first-time visited node, the vehicle would be able to arrive in the possible departure time slot, but because the node is set as a first-time visited node, a node may arise where the vehicle cannot arrive in the possible departure time slot. The figure shows a simple example. In reality, the possible departure time slot differs for each node, so the values ​​obtained by subtracting the time distance from the lower limit of the possible departure time slot for each node are sorted in descending order and checked. Hereinafter, the earliest departure time from the depot at which the vehicle can arrive within the possible departure time slot of the node is called the "earliest departure time."

[0077] FIG. 16 is a diagram explaining the check algorithm for ID15. As mentioned above, the check is divided into a check for the first visited node and a check for other nodes. For the first visited node, the vehicle allocation possibility is checked in descending order of time, while for the other nodes, the vehicle allocation possibility is checked in ascending order of time. In FIG. 16, a vehicle with a departure time after the earliest departure time for the first visited node can be assigned, and a vehicle with a departure time before the latest departure time for the other nodes can be assigned, so it is determined that multiple constraints are consistent (no error is detected).

[0078] Figure 17 is also a diagram explaining the check algorithm for ID 15. The distance between node E, which is the first visited node, and the depot is 15 minutes. In the example of Figure 17, there is no vehicle that departs from the depot at a time after the earliest departure time for node E among the vehicles that can be assigned to node E, so an error is detected.

[0079] Figure 18 is also a diagram explaining the check algorithm for ID 15. In the example of Figure 18, a vehicle was successfully assigned to the first-visit node. However, an error is detected because there is no vehicle that departs from the depot at a time before the latest departure time for node A among the vehicles that can be assigned to node A.

[0080] Figure 19 shows an example implementation of the check algorithm for ID 15. The input data showing the relevant constraints are: data.depot_index: Depot index (int) data.edge.time: Distance matrix between depots and nodes, and between nodes (2-dimensional list) ·data.berth.berth_control:“auto” data.berth.const_berth: Depot departure time for each vehicle (all fixed) (list) data.time_windows.available_time: Available time window for departure for each node (dict) data.routing_order.node_after_depot:Specify first visited node (list)

[0081] A detailed description will be given of the check of ID 26 "Exceeding upper load limit due to delivery vehicle designation." If the load of goods corresponding to one or more nodes assigned to a certain vehicle based on a constraint (also called "delivery vehicle designation") that defines a vehicle that should visit a specific node exceeds the upper load limit of the vehicle, the check unit 24 judges that multiple constraints are inconsistent.

[0082] FIG. 20 is a diagram for explaining the inconsistency to be detected by checking ID 26. In the figure, vehicle a is specified as a vehicle that can visit node A and node B. However, the total amount of cargo to be delivered to node A and node B (hereinafter also referred to as "demand amount") is 250, and if node A and node B are assigned to vehicle a, the cargo limit of vehicle a (here, 200) will be exceeded. In this way, if vehicles are assigned to nodes while taking into account the delivery vehicle designation, the constraint of the vehicle's cargo limit may be violated. The check unit 24 solves the assignment of vehicles to nodes as a general assignment problem (also called a generalized assignment problem) and checks whether a solution exists.

[0083] We will explain the general allocation problem. Consider that there are n jobs (e.g., nodes) and they are to be assigned to m resources (e.g., vehicles). There is a compatibility between jobs and resources, and the cost of assigning job j to resource i is c ij Resource i has an upper limit on the amount of available capacity (e.g., load limit) b i is defined, and when task j is assigned to resource i, ij The general allocation problem is the problem of minimizing the total cost when one resource is assigned to each job, under the condition that the sum of the resource usage of the jobs assigned to the resource does not exceed the capacity of the resource.

[0084] A 0-1 variable x that is 1 when task j is assigned to resource i and 0 otherwise. ij Using this, the general assignment problem can be formulated as follows:

number

[0085] Fig. 21 is a diagram explaining the check algorithm of ID 26. When allocating vehicles to nodes, the relationship between the nodes and vehicles can be defined as shown in the table in Fig. 21. For example, when allocating one of vehicles d, e, or f to node A (here, demand amount 30), the corresponding location (cell) aij Let be 30, and the remainder be INF (infinity). Since INF is not below the load limit, in a feasible solution, node A is assigned to one of vehicles d, e, or f.

[0086] Each node x vehicle cell is represented by x, which takes the value 0 or 1. ij For example, the row of node A is defined as equation 5. x aA +x bA +x cA x gA =1...(Formula 5) Moreover, the train of vehicle c is defined as in Equation 6. INFx cA +40x cD +25x cK 30x cU ≦90 (Formula 6)

[0087] FIG. 22 is also a diagram explaining the check algorithm of ID26. This figure shows a state where sufficient allocation has been made for vehicles a to e. A cell with a value of "1" indicates an allocated state, and a cell with no value indicates an unallocated state. As shown in this figure, a feasible solution is one in which there is only one cell with a value of "1" in the row direction, and the total load in the column direction is equal to or less than the load limit. If a solver that returns an error if allocation is not possible is used for the solution process, the error is detected. Also, when formulating with QUBO (Quadratic Unconstrained Binary Optimization) in a quantum computer, etc., the value of the INF cell becomes "1" if allocation is not possible, so an error is detected if the objective function (Equation 1) becomes INF or more.

[0088] Figure 23 shows an example implementation of the check algorithm for ID 26. The input data showing the relevant constraints are: data.num_nodes: Number of nodes (int) data.vertex.demands: Demand per node (list) · data.vehicle_capacities: Cargo capacity limit for each vehicle (list) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict)

[0089] In an actual implementation, this is a binary problem of maximum nodes × vehicles. In the embodiment, a Python mathematical optimization solver Pulp is used. If the status of the execution result of Pulp indicates an abnormality, that is, if a feasible solution is not obtained, the check unit 24 detects an error and determines that multiple constraints are inconsistent.

[0090] The check for ID27 "Exceeding the maximum number of visited nodes due to delivery vehicle designation" will be explained in detail. The above-mentioned check for ID26 determines whether a vehicle can be assigned from the perspective of cargo volume, whereas the check for ID27 determines whether a vehicle can be assigned from the perspective of the number of visited nodes. If the number of nodes assigned to a vehicle exceeds the maximum number of visited nodes for the vehicle based on a constraint (delivery vehicle designation) that defines the vehicle that should visit a specific node, the check unit 24 determines that multiple constraints are inconsistent.

[0091] Fig. 24 is a diagram explaining the inconsistencies that are the target of detection by checking ID 27. In the figure, vehicle b is specified as a vehicle that can visit nodes B, C, and D. However, if nodes B, C, and D are assigned to vehicle b, the maximum number of nodes that vehicle b can visit (2 nodes in this case) will be exceeded. In this way, when vehicles are assigned to nodes while taking into account the delivery vehicle designation, the constraint on the maximum number of nodes that a vehicle can visit may be violated.

[0092] The check unit 24 executes the check of ID27 by solving the general allocation problem, similar to the check of ID26. The main changes are that the value of each element becomes 1, and the vehicle limit becomes the maximum number of visited nodes. Figure 25 is a diagram explaining the check algorithm of ID27. For example, when assigning one of vehicles d, e, or f to node A, the corresponding part a ijLet be 1 and the rest be INF. Since INF is not less than the maximum number of visited nodes, in a feasible solution, node A is assigned to one of vehicles d, e, or f.

[0093] Figure 26 shows an example implementation of the check algorithm for ID 27. The input data showing the relevant constraints are: data.max_num_visits: Maximum number of visited nodes per vehicle (list) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict) In FIG. 26, the changes to the code of ID26 shown in FIG. 23 are underlined.

[0094] The check for ID 28, “Exceeding upper load limit for fixed route”, will be described in detail. Based on the constraint that defines the vehicle that should visit a specific node and the route constraint that defines the visiting order of multiple nodes, if the load of a certain route exceeds the upper load limit of a vehicle that can be assigned to the route, the check unit 24 judges that the multiple constraints are inconsistent.

[0095] FIG. 27 is a diagram explaining the inconsistencies that are the object of the ID28 check to be detected. The "Se" in fixed route means center, and is synonymous with depot. When a fixed route is created without any contradictions based on the vehicle designation of each node and route fixing (all route fixed, forward matching route fixed), there may be no vehicles that can be assigned to the fixed route from the viewpoint of cargo volume. In the example of FIG. 27, vehicle a is designated as a vehicle that can deliver to node A. Therefore, the fixed route α including node A can be assigned only to vehicle a, but in that case, the constraint of the cargo volume limit of vehicle a will be violated.

[0096] Figure 28 shows an example implementation of the check algorithm for ID 28. The relevant constraint data are as follows: data.vertex.demands: Demand per node (list) · data.vehicle_capacities: Cargo capacity limit for each vehicle (list) ·data.routing_order.const_route.prefix: Prefix fixed route specification (dict) data.routing_order.const_route.all: All fixed route specification (dict) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict) · data.vehicle_assignment.available_vehicle_route.prefix: Prefix matching vehicle assignment for each fixed route (dict) data.vehicle_assignment.available_vehicle_route.all: Vehicle assignment for all fixed routes (dict)

[0097] data.vehicle_assignment.available_vehicle_route.prefix:An example of vehicle assignment for each prefix-match fixed route is shown. {route ID:[vehicle ID, , vehicle ID],} ={0:[2,4,5,7],1:[3,6,9],···} In this example, vehicles with vehicle IDs 2, 4, 5, and 7 are specified in the prefix-match fixed route (route ID 0).

[0098] data.routing_order.const_route.prefix:An example of a prefix-matching fixed route specification. {Root ID: [node ID, ,node ID],} ={0:[1,2,3,4],1:[5,6,7,8],···} In this example, the prefix-match fixed route (route ID 0) is a route that visits node 1, node 2, node 3, and node 4 in that order, and the prefix-match fixed route (route ID 1) is a route that visits node 5, node 6, node 7, and node 8 in that order.

[0099] data.vehicle_assignment.available_vehicle: An example of vehicle assignment per node. {node ID: [vehicle ID, , vehicle ID],} ={1:[2,4,7],5:[3],···} In this example, vehicles IDs 2, 4, and 7 are specified at node 1.

[0100] 28, vehicle candidates that can be assigned to each forward-match fixed route are identified based on the vehicle designation for each forward-match fixed route, the forward-match fixed route designation, and the vehicle designation for each node. In the above example, the vehicle candidates that can be assigned to the forward-match fixed route (ID0) are vehicle IDs 2, 4, and 7, and the vehicle candidate that can be assigned to the forward-match fixed route (ID1) is only vehicle ID 3. In this case, the following dictionary instance is generated in code 100. {route ID:[vehicle ID, , vehicle ID],} ={0:[2,4,7],1:[3],···}

[0101] Code 101 in Figure 28 calculates the load for each forward-match fixed route (the sum of the loads of the nodes on the route, called "route load"), and for each forward-match fixed route, from among the allocatable vehicle candidates, finds vehicles (called "allocable vehicles") for which the route load is less than or equal to the load limit. In the above example, if the load limit for vehicle ID4 is extremely small, code 101 generates a dictionary instance like the one below. {route ID:[vehicle ID, , vehicle ID],} ={0:[2,7],1:[3],···} In code 102 of FIG. 28, if there is no vehicle available for allocation to at least one forward-matching fixed route, an error is detected.

[0102] Code 103, code 104, and code 105 in Figure 28 correspond to code 100, code 101, and code 102, respectively. Code 103 identifies vehicle candidates that can be assigned to each of all fixed routes based on the vehicle designation for each of the all fixed routes, the all fixed route designation, and the vehicle designation for each node. Code 104 calculates the route load for each of the all fixed routes, and calculates, from among the allocatable vehicle candidates for each of the allocatable routes, vehicles that satisfy the route load≦load limit. Code 105 detects an error if there is no vehicle that can be assigned to at least one of the allocatable routes.

[0103] The check for ID29 "Exceeding the maximum number of visited nodes for a fixed route" will be explained in detail. The above-mentioned check for ID28 judges whether a vehicle can be assigned from the viewpoint of the load amount, whereas the check for ID29 judges whether a vehicle can be assigned from the viewpoint of the number of visited nodes. If the number of nodes in a certain route exceeds the maximum number of visited nodes for a vehicle that can be assigned to the route, based on the constraint that defines the vehicle that should visit a specific node and the route constraint that defines the order in which multiple nodes are visited, the check unit 24 judges that the multiple constraints are inconsistent.

[0104] FIG. 29 is a diagram explaining the inconsistencies that are the object of the ID29 check to be detected. When a fixed route is created without any contradictions based on the vehicle designation of each node and route fixing (all route fixed, prefix match route fixed), there may be cases where no vehicle can be assigned to the fixed route in terms of the number of nodes. In the example of FIG. 29, vehicle a is designated as a vehicle that can visit node A. Therefore, the fixed route α including node A can be assigned only to vehicle a, but in that case, the constraint on the maximum number of visited nodes of vehicle a is violated.

[0105] Figure 30 shows an example implementation of the check algorithm for ID 29. The relevant constraint data are as follows: data.max_num_visits: Maximum number of visited nodes per vehicle (list) ·data.routing_order.const_route.prefix: Prefix match fixed route specification (dict) data.routing_order.const_route.all: All fixed route specification (dict) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict) · data.vehicle_assignment.available_vehicle_route.prefix: Prefix matching vehicle assignment for each fixed route (dict) data.vehicle_assignment.available_vehicle_route.all: Vehicle assignment for all fixed routes (dict)

[0106] Code 110 in Fig. 30 identifies vehicle candidates that can be assigned to each forward-match fixed route based on the vehicle designation for each forward-match fixed route, the forward-match fixed route designation, and the vehicle designation for each node. Code 111 finds the number of nodes for each forward-match fixed route (the number of nodes on the route, called the "number of route nodes"), and finds vehicles for which the number of route nodes is less than or equal to the maximum number of visited nodes as assignable vehicles from among the assignable vehicle candidates for each forward-match fixed route. Code 112 detects an error if there is no assignable vehicle for at least one forward-match fixed route.

[0107] Code 113 in Fig. 30 identifies vehicle candidates that can be assigned to each fixed route based on the vehicle designation for each fixed route, the fixed route designation, and the vehicle designation for each node. Code 114 finds the number of route nodes for each fixed route, and finds vehicles that satisfy the number of route nodes≦maximum number of visited nodes as assignable vehicles from among the assignable vehicle candidates for each fixed route. Code 115 detects an error if there is no assignable vehicle for at least one fixed route.

[0108] The check for ID 30, “Route specification causing time-based inconsistency”, will be described in detail. If the check unit 24 detects that there is no vehicle that can be assigned to the route based on the route constraint that defines the visiting order of multiple nodes and the constraint of the possible arrival time frame that is predefined for each of the multiple nodes, it determines that the multiple constraints are inconsistent.

[0109] FIG. 31 is a diagram for explaining the inconsistency that is the object of the ID30 check to be detected. In the ID30 check, it is confirmed whether or not there is a vehicle that can be assigned to a fixed route (all fixed routes and forward-match fixed routes) when time-based constraints are taken into consideration. In the example of FIG. 31, the possible departure time frame at the center (depot) is set to 11:00 to 11:30. Also, the distance from the center to node A is set to 30 minutes, and the distance from node A to node B is set to 45 minutes. Even if the vehicle departs from the center at 11:30, which is the latest departure time, it will arrive at node B at 12:45, which deviates from the possible departure time frame (13:00 to 14:00) of store B. Therefore, in the example of FIG. 31, it is not possible to assign a vehicle that satisfies the departure time frame of a node (for example, node B) of the fixed route α.

[0110] 32 is a diagram for explaining the check algorithm of ID 30. The check unit 24 checks whether the earliest departure time (synonymous with the earliest arrival time) and the latest departure time (synonymous with the latest arrival time) at each node of the fixed route 120 satisfy the possible departure time frame at each node.

[0111] (1) to (5) in Fig. 32 show the flow of the process. As shown in (1), the earliest departure time (11:30) and latest departure time (12:00) of node A are calculated based on the earliest departure time and latest departure time of the center and the distance from the center to node A (30 minutes). Then, the difference between the earliest departure time of node A and the possible departure time frame is calculated as +10 minutes. +10 minutes means that the arrival needs to be delayed by 10 minutes.

[0112] Next, as shown in (2), the difference of +10 minutes is reflected in the earliest departure time of the center and store A. Specifically, the earliest departure time of the center is changed to 11:10, and the earliest departure time of node A is changed to 11:40.

[0113] Next, as shown in (3), the earliest departure time (12:25) and latest departure time (12:45) of node B are calculated based on the earliest departure time and latest departure time of node A and the distance (45 minutes) from node A to node B. Then, the difference between the earliest departure time of node B and the available departure time slot is calculated as +5 minutes, and the difference between the latest departure time of node B and the available departure time slot is calculated as -5 minutes. -5 minutes means that the arrival needs to be advanced by 5 minutes.

[0114] Next, as shown in (4), the +5 minute difference is reflected in the earliest departure times of the center, store A, and store B. Specifically, the center's earliest departure time is changed to 11:15, the node A's earliest departure time to 11:45, and the node B's earliest departure time to 12:30. In addition, the -5 minute difference is reflected in the latest departure times of the center, store A, and store B. Specifically, the center's latest departure time is changed to 11:25, the node A's latest departure time to 11:55, and the node B's latest departure time to 12:40.

[0115] As shown in (5), the above process is repeated for node D, node E, and the center. If the relationship of earliest departure time≦latest departure time is maintained for the center and all nodes, the check unit 24 determines that there is a vehicle that can be assigned to the fixed route 120, in other words, that multiple constraints are consistent.

[0116] Figure 33 is also a diagram explaining the check algorithm of ID30. As shown in (1), the earliest departure time (11:30) and latest departure time (12:00) of node A are calculated based on the earliest departure time and latest departure time of the center and the distance (30 minutes) from the center to node A. Then, the difference between the earliest departure time of node A and the available departure time frame is calculated as +30 minutes.

[0117] Next, as shown in (2), the difference of +30 minutes is reflected in the earliest departure time of the center and store A. Specifically, the earliest departure time of the center is changed to 11:30, and the earliest departure time of node A is changed to 12:00.

[0118] Next, as shown in (3), the earliest departure time (12:45) and latest departure time (12:45) of node B are calculated based on the earliest departure time and latest departure time of node A and the distance (45 minutes) from node A to node B. Then, the difference between the latest departure time of node B and the available departure time frame is calculated as -5 minutes.

[0119] Next, as shown in (4), the difference of -5 minutes is reflected in the latest departure times of the center, store A, and store B. Specifically, the latest departure time of the center is changed to 11:25, the latest departure time of node A to 11:55, and the latest departure time of node B to 12:40. As a result, in FIG. 33, the earliest departure times of the center and each node become later than the latest departure time. If the earliest departure time>latest departure time occurs at the center or at least one node, the check unit 24 detects an error, that is, determines that there is no vehicle that can be assigned to the fixed route 120, in other words, determines that multiple constraints are inconsistent.

[0120] Figure 34 shows an example implementation of the check algorithm for ID 30. The relevant constraint data are as follows: data.berth.berth_control:“auto” or “manual” data.depot_index: Depot index (int) data.edge.time: Distance matrix between depots and nodes, and between nodes (2-dimensional list) · data.max_delivery_time: Maximum delivery time per vehicle (list) data.time_windows.available_time: Available time window for departure for each node (dict) ·data.routing_order.const_route.prefix: Prefix match fixed route specification (dict) data.routing_order.const_route.all: All fixed route specification (dict) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict) · data.vehicle_assignment.available_vehicle_route.prefix: Prefix matching vehicle assignment for each fixed route (dict) data.vehicle_assignment.available_vehicle_route.all: Vehicle assignment for all fixed routes (dict)

[0121] The check for ID30, like the check for ID28 "Exceeding upper load limit for fixed route", checks whether there are any vehicles that can be assigned to a fixed route. When berth_control is "auto", that is, when the berth departure time of each vehicle is automatically determined, code 130 in Fig. 34 sets the depot's possible departure time frame from the depot's earliest departure time to the latest departure time [a, b]. Also, when berth_control is "manual", that is, when the berth departure time of each vehicle is fixed (fixed time specified by the user), the depot's possible departure time frame is set to the fixed time [c, c] of each vehicle specified by the user.

[0122] Code 131 in Fig. 34 sets the latest arrival time of each vehicle at the depot to the lower limit of the time frame during which each vehicle can depart from the depot (latest departure time) + the maximum delivery time of each vehicle when berth_control is "auto". Also, when berth_control is "manual", the latest arrival time of each vehicle at the depot is set to the lower limit of the time frame during which each vehicle can depart from the depot (here, the fixed time of each vehicle) + the maximum delivery time of each vehicle.

[0123] Code 132 in Fig. 34 stores vehicle IDs that can be assigned to forward-matching fixed routes in a dictionary based on the above check algorithm, and detects an error if there is no vehicle that can be assigned to at least one forward-matching fixed route. Code 133 in Fig. 34 stores vehicle IDs that can be assigned to all fixed routes in a dictionary based on the above check algorithm, and detects an error if there is no vehicle that can be assigned to at least one full fixed route.

[0124] FIG. 35 also shows an implementation example of the check algorithm for ID30. This figure shows details of "self.__remove_time_range_inconsistency_const_route_all()" in FIG. 34. Note that "self.__remove_time_range_inconsistency_const_route_prefix()" in FIG. 34 is also implemented in a similar manner. The code in FIG. 35 sets the possible departure time frame for each node in the fixed route 120 shown in FIG. 32 and FIG. 33. The code in FIG. 35 also sets in the dictionary only vehicles that satisfy the possible departure time frame for each node in the fixed route 120.

[0125] FIG. 36 also shows an implementation example of the check algorithm of ID30. This figure shows the details of "self.__const_route_check(route, available_time_list)" in FIG. 35. The code in FIG. 36 implements the processes (1) to (5) in FIG. 32 and the processes (1) to (4) in FIG. 33. In other words, the code in FIG. 36 executes a process of editing the departure time frames of the center and each node based on the center-node distance and the node-node distance, and checking whether the earliest departure time>latest departure time occurs at the center or at least one node.

[0126] The check for ID 31 "Exceeding the number of specified delivery orders (specifying vehicles that can deliver)" will be described in detail. Based on the first constraint that defines the first visited node, the second constraint that defines the last visited node, and the third constraint that defines the vehicles that should visit the first visited node and the last visited node, if the number of first visited nodes and last visited nodes exceeds the number of moving bodies defined by the third constraint, the check unit 24 determines that the multiple constraints are inconsistent.

[0127] FIG. 37 is a diagram explaining the inconsistencies that are the target of detection when checking ID31. If the number of first visited nodes and last visited nodes to be assigned to a specific vehicle group based on the deliverable vehicle designation for each node is greater than the number of vehicles in that vehicle group, vehicle assignment to each node cannot be performed correctly. In the example of FIG. 37, there are three node designations for two vehicles, so vehicle assignment cannot be performed correctly. The three node designations here are the designation of two first visited nodes (node ​​A, node B) and one last visited node (node ​​D).

[0128] In checking ID 31, the check unit 24 solves an assignment problem (different from the general assignment problem described above) and checks whether a solution exists. The assignment problem is given by a set V={1, , n} and an n×n matrix C=[c ij ], the problem is to find a permutation π:V → {1, , n} that minimizes the following equation 7.

number

[0129] For ease of understanding, we interpret the assignment problem as a problem of assigning tasks to resources. Consider that there are n tasks (e.g., nodes) and assign them to n resources (e.g., vehicles). There is a compatibility between tasks and resources, and the cost of assigning task i to resource j is c ij When one resource can process at most one job and one resource is always assigned to one job, the assignment problem is the problem of minimizing the total cost.

[0130] A 0-1 variable x that is 1 when task i is assigned to resource j and 0 otherwise ij Using this, the assignment problem can be formulated as follows:

number

[0131] Figure 38 is a diagram explaining the check algorithm of ID31. When assigning a first visited node and a last visited node to a vehicle, the relationship between each node and the vehicle can be defined as shown in the table in Figure 38. Nodes A, C, D, and E in the figure are first visited nodes, and nodes B and F are last visited nodes. Also, for vehicles a to g in the figure, the delivery route is determined in the order of vehicle g, vehicle f, ..., vehicle b, and vehicle a.

[0132] When vehicles d, e, and f are specified in node A (first visit node), the cells a corresponding to these vehicles ij The values ​​of the cells (which can also be considered costs) are set to 3, 2, and 1 in descending order, and the values ​​of the remaining cells are set to INF. The values ​​of the cells corresponding to vehicles that can deliver to the last visited node are set to 2, 4, and 6 in ascending order, that is, double the value of the first visited node. The reason for changing the cell values ​​will be explained later. Note that if we are only checking ID31, the cell a corresponding to vehicles that can deliver will be set to 2, 4, and 6 in ascending order, that is, double the value of the first visited node. ij The values ​​may all be 1.

[0133] Each node x vehicle cell is represented by x, which takes the value 0 or 1. ij For example, the row of node A is defined as in Equation 12. x aA +x bA +x cA x gA =1...(Equation 12) Moreover, the train of vehicle c is defined as in Equation 13. x cA +x cB +x cC x cF=1 (Equation 13)

[0134] In the embodiment, ij is regarded as a cost, and the number of nodes is corrected so that number of nodes≦number of vehicles. Specifically, if (number of first visited nodes+number of last visited nodes)>number of vehicles (constraint violation at this point), additional virtual vehicles with INF set in all rows are prepared. In this case, no matter how much optimization is performed, the objective function value will be INF. If the objective function value becomes INF or more when vehicles are assigned to each node, the check unit 24 detects an error as a constraint violation.

[0135] FIG. 39 is also a diagram for explaining the check algorithm of ID31. This diagram shows that nodes A to F are correctly assigned to vehicles a, c to g. In this embodiment, the solution is obtained using the Python numerical calculation library scipy (applying the Hungarian method implemented in scipy). The Hungarian method in scipy rejects columns where the constraint conditions are not satisfied and outputs a feasible solution. If there are more rows than columns, an INF column is added to create a state where the objective function value automatically exceeds INF. Also, if there are more columns than rows, the operation of scipy means that there are no columns that are more than rows, and vehicles are assigned.

[0136] Figure 40 shows an example implementation of the check algorithm for ID31. The input data showing the relevant constraints are: data.num_nodes: Number of visited nodes (int) data.depot_index: Depot index (int) data.num_vehicles: Number of vehicles (int) data.vehicle_assignment.available_vehicle: Vehicle assignment for each node (dict) data.routing_order.node_after_depot:Specify first visited node (list) data.routing_order.node_before_depot:Specify last visited node (list)

[0137] Code 140 in FIG. 40 sets that data for the first visited node is stored in descending order, and that data for the last visited node is stored in ascending order. Code 141 in FIG. 40 sets data corresponding to the table shown in FIG. 38. The "liner_sum_assignment" function of scipy shown in code 142 in FIG. 40 solves the problem (assignment problem) shown by the formula corresponding to Equations 8 to 11. In addition, the scale of calculation can be reduced by using the Hungarian method. If the final objective function value exceeds INF, the check unit 24 detects an error, that is, determines that multiple constraint conditions are inconsistent.

[0138] The ID32 check "time-based x allocation-based" will be described in detail. FIG. 41 is a diagram explaining the inconsistencies that the ID32 check detects. The check unit 24 judges whether or not it is possible to allocate vehicles that simultaneously satisfy the designation of deliverable vehicles for each node, the load limit for each vehicle, the maximum number of visited nodes for each vehicle, the time frame for possible departure for each node, the maximum delivery time for each vehicle, the designation of first visited node, the designation of last visited node, and the fixed route (all fixed and prefix-match fixed). In other words, the check unit 24 judges whether or not it is possible to simultaneously satisfy multiple constraints other than the constraints related to berths. The ID32 check includes checks (1) to (6) shown in FIG. 41.

[0139] Fig. 42 shows an example of the implementation of the ID32 check algorithm. Code 150 in Fig. 42 generates a list of vehicles to which a forward-match fixed route can be assigned and a list of vehicles to which a full fixed route can be assigned. Codes 151 to 156 perform individual checks on the forward-match fixed route and the full fixed route, and sequentially remove vehicles that violate the constraints from the vehicle list.

[0140] Specifically, code 151 executes a process (self.__remove_time_inconsistency_node_after_depot()) to remove vehicles that cannot be assigned when the departure time from the depot is taken into consideration for the specified first visited node. Code 152 executes a process (self.__remove_time_inconsistency_node_before_depot()) to remove vehicles that cannot be assigned when the latest arrival time at the depot is taken into consideration for the specified last visited node.

[0141] Code 153 performs the same process as the check for ID 30, "Route assignment causing time system conflict," and excludes vehicles that cannot be assigned to a fixed route from the vehicle list for that fixed route. Code 154 performs the same process as the check for ID 26, "Load limit exceeded due to delivery vehicle assignment," and excludes vehicles that cannot be assigned to a fixed route from the vehicle list for that fixed route.

[0142] Code 155 executes the same process as the check for ID 28 "Exceeding upper load limit for fixed route" and excludes vehicles that cannot be assigned to a certain fixed route from the vehicle list for that fixed route. Code 156 executes the same process as the check for ID 29 "Exceeding maximum number of visited nodes for fixed route" and excludes vehicles that cannot be assigned to a certain fixed route from the vehicle list for that fixed route.

[0143] Code 157 detects an error when there is no vehicle available for allocation for each of the forward-matching fixed routes. Code 158 detects an error when there is no vehicle available for allocation for each of the total fixed routes.

[0144] Figure 43 also shows an example of the implementation of the ID32 check algorithm. This figure shows the details of "self.__remove_time_inconsistency_node_after_depot()" in Figure 42. This function removes from the vehicle list the vehicles that depart earliest from the depot and cannot make it to the latest possible departure time slot of the first visited node, or the vehicles that depart latest from the depot and arrive earlier than the earliest possible departure time slot of the first visited node.

[0145] Figure 44 also shows an example of the implementation of the ID32 check algorithm. It shows the details of "self.__remove_time_inconsistency_node_before_depot()" in Figure 42. This function removes from the vehicle list the vehicles whose earliest departure from the last visited node does not meet the latest arrival time at the depot.

[0146] Returning to the explanation of Figure 42, code 159 in Figure 42 solves the allocation problem by creating a table based on vehicles that can be assigned to the first visited node, the last visited node, and the fixed route, in the same way as the check for ID 31 "Exceeding the number of specified delivery orders (specifying deliverable vehicles)". As data on vehicles that can be assigned to fixed routes, dictionary data of vehicles that can be assigned to prefix-match fixed routes (self.available_vehicle_const_route_prefix) and dictionary data of vehicles that can be assigned to all fixed routes (self.available_vehicle_const_route_all) shown by code 156 in Figure 42 are used.

[0147] Figure 45 is a diagram explaining the ID32 check algorithm. When checking ID32, all fixed routes (fixed routes A and B in the figure) and forward-matching fixed routes (forward fixed routes A and B in the figure) are also taken into consideration. Values ​​are set in cells corresponding to the first visited node and the last visited node according to the same rules as for the ID31 check. Meanwhile, a value of twice the number of vehicles is set in cells corresponding to all fixed routes and forward-matching fixed routes.

[0148] Code 159 in Figure 42 generates the table (cost matrix) shown in Figure 45 based on the vehicle specification at the first visited node, the vehicle specification at the last visited node, and the vehicle specification on the fixed route (self.__map_cost_matrix()), sets the cost of each cell in the cost matrix (self.__create_cost_matrix()), and solves the allocation problem based on the cost matrix (self.__execute()). Either function performs the same process as the check for ID31 "Exceeding the number of specified delivery orders (specifying deliverable vehicles)."

[0149] FIG. 46 shows an example of implementation of the check algorithm of ID32. This figure shows details of "self.__create_cost_matrix()" in FIG. 42. FIG. 47 also shows an example of implementation of the check algorithm of ID32. This figure shows details of "self.__execute()" in FIG. 42. Code 160 in FIG. 47 derives a solution to the assignment problem using the "liner_sum_assignment" function of scipy. If the solution to the assignment problem exceeds INF, the check unit 24 detects an error because there is no feasible solution. Note that code 161 in FIG. 47 is not included in the implementation of the embodiment, and will be described in a modified example below.

[0150] Next, a detailed description will be given of the conversion process performed by the conversion unit 26 of the delivery plan support system 16. The conversion unit 26 converts the constraint data, taking into consideration the nature of the algorithm applied to the delivery plan generation unit 30 in determining the delivery route.

[0151] First, the nearest neighbor method, which is a route derivation algorithm used by the delivery plan generating unit 30, will be described. In the nearest neighbor method, a search is performed to connect a currently focused node with another node that is closest to the focused node. For example, the delivery plan generating unit 30 builds up a route that satisfies {Σ(route load)≦vehicle load limit} and {Σ(travel time+stay time)≦vehicle maximum delivery time}.

[0152] FIG. 48 shows an example of route derivation using the nearest neighbor method. In the example of FIG. 48, a route is set for a first vehicle that departs from a depot at (1), travels around multiple nodes 40, and then returns to the depot at (6). Next, a route for a second vehicle different from the first vehicle is created from (7). In this way, the delivery plan generation unit 30 sequentially determines delivery routes for multiple vehicles using the nearest neighbor method.

[0153] Figures 49 and 50 show examples of vehicle allocation to the final visited node. Figure 49 shows an example of allocating the final visited node to a vehicle that is relatively earlier in the order of delivery route determination by the delivery plan generation unit 30 (hereinafter also referred to as "first determined vehicle"). If the final visited node is assigned to a first determined vehicle, nodes close to the depot and nodes far from the depot tend to coexist within one route, which makes it more likely that constraints on the maximum delivery time of vehicles and constraints on the time frame in which nodes can depart will be violated. Also, many vehicles are required to comply with these time constraints, which can make it difficult to find a feasible solution.

[0154] FIG. 50 shows an example in which a final visited node is assigned to a vehicle that is relatively later in the order of determining a delivery route by the delivery plan generating unit 30 (hereinafter also referred to as a "later determined vehicle"). When a final visited node is assigned to a later determined vehicle, a route that connects only nodes far from the depot is likely to be created, and a route that includes only one node (here, the final visited node) (also referred to as a "one-node route") is likely to be created. This reduces rework when a constraint violation occurs, and makes it easier to derive a feasible solution.

[0155] 51 and 52 show examples of vehicle allocation to first-time visited nodes. FIG. 51 shows an example of allocating a first-time visited node to a later-determined vehicle. When a first-time visited node is assigned to a later-determined vehicle, a one-node route that includes only the first-time visited node is likely to be created, and a one-node route that includes only nodes other than the first-time visited node is likely to be created, making it easy for an inefficient route to be created. Also, as the number of routes increases, a shortage of vehicles is likely to occur, making it difficult to find a feasible solution.

[0156] Figure 52 shows an example of assigning a first-visit node to a first-visit vehicle. When determining the route of a first-visit vehicle, there are many nodes that have not been assigned to the vehicle, and it is easy to create an efficient route by connecting the route from the first-visit node to another node in its vicinity. This makes it easier to derive a feasible solution.

[0157] Considering the above, it can be said that it is better to assign the last visited node to a vehicle that is relatively later in the order in which the delivery route is determined (later determined vehicle), while it is better to assign the first visited node to a vehicle that is relatively earlier in the order in which the delivery route is determined (early determined vehicle). In addition, fixed routes (all fixed routes and forward-matching fixed routes) must be assigned to one of the vehicles. Of course, the load limit and the maximum number of visited nodes must be satisfied. In addition, the vehicle designation constraints specified at each node must be satisfied, and this is the same for both the first visited node and the last visited node.

[0158] In addition, for the first visited node, it is necessary to assign a vehicle that can arrive within the possible departure time frame of the first visited node. In addition, for the last visited node, it is necessary to assign a vehicle that can make it to the depot's latest arrival time. In addition, for fixed routes, it is necessary to assign vehicles that can meet the possible departure time frame of each node. If vehicles are assigned to the first visited node, the last visited node, and the fixed route so as to satisfy these conditions, the delivery route determination by the delivery plan generating unit 30 can be made more efficient.

[0159] Therefore, the conversion unit 26 converts the constraint that specifies a vehicle to visit the last visited node input from the front system 14 so as to preferentially assign the last visited node to the later determined vehicle. Also, the conversion unit 26 converts the constraint that specifies a vehicle to visit the first visited node input from the front system 14 so as to preferentially assign the first visited node to the earlier determined vehicle.

[0160] In the embodiment, the constraint specifying a vehicle to visit the last visited node and the constraint specifying a vehicle to visit the first visited node are common, and are hereinafter also referred to as a "vehicle designation constraint." That is, the vehicle designation constraint includes a constraint specifying a vehicle to visit the last visited node and a constraint specifying a vehicle to visit the first visited node, and the conversion unit 26 converts the vehicle designation constraint.

[0161] Specifically, the conversion unit 26 executes the same process as the check “time system×allocation system” of ID 32. The conversion unit 26 creates a cost matrix (a table such as that shown in FIG. 45) based on vehicles that can be allocated to the first visited node, the last visited node, and the fixed route, and solves the allocation problem.

[0162] Referring again to Figure 45, the cost matrix of the allocation problem will be explained. As described above, the order in which the delivery route is determined by the delivery plan generation unit 30 is vehicle g, vehicle f, ..., vehicle b, and vehicle a. Since it is better to allocate the first visited node to an earlier determined vehicle, a smaller cost (which can also be considered strength) is set for a vehicle specified at the first visited node that is earlier in the delivery route determination order. On the other hand, it is better to allocate the last visited node to a later determined vehicle, so a smaller cost (which can also be considered strength) is set for a vehicle specified at the last visited node that is later in the delivery route determination order.

[0163] Furthermore, according to the inventor's findings, from the viewpoint of facilitating the solution of a delivery route, it is more important to assign the last visited node to a later determined vehicle than to assign the first visited node to an earlier determined vehicle. Therefore, the cost set for the vehicle specified at the last visited node is made higher than the cost set for the vehicle specified at the first visited node. In the embodiment, the cost set for the vehicle specified at the last visited node is set to twice the cost set for the vehicle specified at the first visited node.

[0164] Since the fixed route can be assigned to any vehicle, the cost can be any value as long as it is less than INF. In this embodiment, in order to emphasize that the assigned vehicle is not very meaningful, the cost of the vehicle specified in the fixed route is set to the maximum possible value (specifically, the number of vehicles x 2).

[0165] Fig. 53 shows an example of implementation of conversion unit 26. Code 170 to code 176 in Fig. 53 are the same as code 150 to code 156 in Fig. 42 described in relation to the check of ID32. However, since the presence or absence of constraint inconsistency has already been confirmed in the check of ID32, error detection processing is not executed. Code 177 in Fig. 53 corresponds to code 159 in Fig. 42.

[0166] FIG. 54 also shows an implementation example of the conversion unit 26. This figure corresponds to FIG. 46 and shows details of "self.__execute()" in FIG. 53. Code 180 derives a solution to the assignment problem using the "liner_sum_assignment" function of scipy. By setting the costs in the cost matrix, a solution is derived in which the last visited node is preferentially assigned to the later determined vehicle, the first visited node is preferentially assigned to the earlier determined vehicle, and the fixed node is assigned to any vehicle.

[0167] Code 181 and code 182 in Figure 54 set data (output_available_vehicle) (also called "output node vehicle designation data") that specifies the available delivery vehicles for each node that are input to the delivery plan generation unit 30. Code 181 sets the vehicle to be assigned to the first visited node in the output node vehicle designation data, and code 182 sets the vehicle to be assigned to the last visited node in the output node vehicle designation data. The output node vehicle designation data can be said to be data that has been converted from the vehicle designation data (data.vehicle_assignment.availbale_vehicle) input from the front system 14.

[0168] Also, codes 183 and 184 in FIG. 54 set data (output_available_vehicle_route) (also called "output fixed route vehicle designation data") that specifies the assigned vehicles for each fixed route input to the delivery plan generation unit 30. Code 183 sets the vehicles to be assigned to the forward-matched fixed route in the output fixed route vehicle designation data. Code 184 sets the vehicles to be assigned to all fixed routes in the output fixed route vehicle designation data. The output fixed route vehicle designation data can be said to be data obtained by converting the vehicle designation data for each forward-matched fixed route (data.vehicle_assignment.available_vehicle_route.prefix) input from the front system 14 and the vehicle designation data for all fixed routes (data.vehicle_assignment.available_vehicle_route.all).

[0169] The operation of the information processing system 10 having the above configuration will now be described. The user terminal 12 transmits a delivery plan request including data indicating a plurality of constraints created by the user to the front system 14. The front system 14 transmits the data indicating the plurality of constraints transmitted from the user terminal 12 to the delivery plan support system 16. The front system 14 transmits the constraint data including data of a distance matrix (data.edge.time) indicating the time distance between depots and nodes and between nodes, which is derived based on the latitude and longitude information of the depots and nodes, to the delivery plan support system 16.

[0170] The reception unit 22 of the delivery plan support system 16 receives multiple constraint data transmitted from the front system 14. The check unit 24 of the delivery plan support system 16 executes a check process for multiple items to determine whether multiple constraints are consistent (in other words, whether there is a contradiction between the constraints). The check of multiple items includes checking the above 32 items.

[0171] If the check unit 24 detects an error in the check process, in other words, if it determines that multiple constraints are inconsistent, it transmits an error notification including information on the check item in which the error was detected and the constraint data in which the error was detected to the front system 14. The front system 14 transmits the error notification to the user terminal 12. The user corrects the constraint data based on the error notification. The user terminal 12 transmits a delivery plan request including the corrected constraint data to the front system 14, and thereafter, the above-mentioned processing is executed again.

[0172] If the check unit 24 does not detect an error, that is, if the check unit 24 determines that multiple constraints are consistent, the conversion unit 26 of the delivery plan support system 16 converts a part of the constraint data input from the front system 14 so as to conform to a delivery route determination algorithm (in this embodiment, the nearest neighbor method). Specifically, the conversion unit 26 assigns the first visited node with priority to a first determined vehicle, and the last visited node with priority to a last determined vehicle, and generates output node vehicle designation data and output fixed route vehicle designation data so as to assign a fixed route to any vehicle that satisfies the constraints.

[0173] When the check unit 24 does not detect an error, that is, when the check unit 24 determines that a plurality of constraints are consistent, the instruction unit 28 of the delivery plan support system 16 inputs a delivery plan instruction based on the plurality of constraints input from the front system 14 to the delivery plan generation unit 30. At this time, the instruction unit 28 inputs output node vehicle designation data to the delivery plan generation unit 30 in place of the vehicle designation data input from the front system 14. Also, the instruction unit 28 inputs output fixed route vehicle designation data to the delivery plan generation unit 30 in place of the vehicle designation data for each forward-matching fixed route and the vehicle designation data for each total fixed route input from the front system 14.

[0174] The check unit 24 may generate constraint data (e.g., a list of vehicle IDs arranged from earliest to latest) that specifies the order in which delivery routes are determined by the delivery plan generating unit 30. In the example of Fig. 45, this constraint data may specify that the delivery route is to be determined in the order of vehicle g, vehicle f, ..., vehicle b, and vehicle a. The instruction unit 28 may input a delivery plan instruction including this constraint data to the delivery plan generating unit 30.

[0175] The delivery plan generation unit 30 of the delivery plan support system 16 uses a nearest neighbor method to determine delivery routes for multiple vehicles based on the constraint data input from the instruction unit 28. The delivery plan generation unit 30 transmits data indicating the delivery routes for multiple vehicles to the front system 14. The front system 14 appropriately processes the data indicating the delivery routes for multiple vehicles, and then transmits the processed data (e.g., a printable course chart for each vehicle, etc.) to the user terminal 12.

[0176] According to the delivery plan support system 16 of the embodiment, before executing a process of solving a delivery route for a plurality of vehicles while satisfying a plurality of constraints, if there is no feasible solution that simultaneously satisfies the plurality of constraints, this is detected. This makes it possible to avoid a situation in which a feasible solution cannot be obtained despite executing a long-term solution-finding process. Furthermore, according to the delivery plan support system 16 of the embodiment, the constraint data is converted so that the delivery route can be efficiently solved according to the nature of the algorithm applied to determine the delivery route. This makes it possible to support the rapid search for a feasible solution for the delivery route.

[0177] The present disclosure has been described above based on the embodiments. The contents described in the embodiments are merely examples, and it will be understood by those skilled in the art that various modifications are possible in the combination of the components and processing steps of the embodiments, and that such modifications are also within the scope of the present disclosure.

[0178] A first modified example will be described. In the above embodiment, the delivery plan generating unit 30 determines the delivery route using the nearest neighbor method, but the algorithm used by the delivery plan generating unit 30 to determine the delivery route is not limited to the nearest neighbor method. The conversion of the constraint data by the conversion unit 26 is useful when an algorithm that clusters nodes while taking into account the graph structure, similar to the nearest neighbor method, is used as the algorithm used to determine the delivery route. For example, the saving method or the Christofleis method may be used as the algorithm that performs clustering while taking into account the graph structure.

[0179] A second modified example will be described. The delivery plan support system 16 of the above embodiment includes both the check unit 24 and the conversion unit 26, but as a modified example, it may be configured to include only the check unit 24. According to the delivery plan support system 16 of the second modified example, when there is no feasible solution that simultaneously satisfies multiple constraints, this is detected before the delivery route is solved, thereby making it possible to avoid a situation in which a feasible solution cannot be obtained despite a long time spent on solution solving.

[0180] A third modified example will be described. The delivery plan support system 16 of the above embodiment includes both the check unit 24 and the conversion unit 26, but as a modified example, it may be configured to include only the conversion unit 26. The delivery plan support system 16 of the third modified example can support rapid determination of a feasible solution for a delivery route by converting constraint data so that the delivery route can be efficiently solved according to the nature of the algorithm applied to determine the delivery route.

[0181] A fourth modified example will be described. In the above embodiment, the delivery plan support system 16 sequentially checks the consistency between constraints and converts the constraint data. As a modified example, the check process and the conversion process may be executed in parallel. In this case, as shown in FIG. 47, the code for the check "time system x allocation system" of ID32 may include the code 161. According to this modified example, it is possible to eliminate overlapping processes between the check process and the conversion process, and it is possible to efficiently execute the check process and the conversion process.

[0182] Any combination of the above-mentioned examples and modifications is also useful as an embodiment of the present disclosure. A new embodiment resulting from the combination has the effects of each of the combined examples and modifications. In addition, it will be understood by those skilled in the art that the functions to be performed by each component described in the claims can be realized by each component shown in the examples and modifications alone or in cooperation with each other. [Industrial Applicability]

[0183] The technology disclosed herein can be applied to devices and systems that support package delivery planning. [Explanation of symbols]

[0184] 10 information processing system, 16 delivery plan support system, 20 preprocessing unit, 22 reception unit, 24 checking unit, 26 conversion unit, 28 instruction unit, 30 delivery plan generation unit.

Claims

1. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with When the determination unit detects that a mobile object cannot depart from the distribution base within a possible departure time frame at the distribution base based on a constraint on the number of berths at the distribution base, the determination unit determines that the plurality of constraints are inconsistent. Delivery planning support system.

2. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines that the plurality of constraints are inconsistent when detecting that a node occurs at which the mobile object does not arrive within a predefined arrival possible time frame based on a constraint on the number of berths at the delivery base. Delivery planning support system.

3. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with When the determination unit detects that a node occurs at which the mobile body does not arrive within a predefined arrival possible time frame based on a constraint of a departure time of the plurality of mobile bodies from the delivery base, the determination unit determines that the plurality of constraints are inconsistent. Delivery planning support system.

4. The determination unit, for a first visited node that is a node to be visited first on a route from the distribution base, compares in descending order the time at which the distribution base should be departed in order to arrive at the reachable time frame with the departure times of the multiple mobile bodies from the distribution base to determine whether the mobile body can be assigned, and, for a node other than the first visited node, compares in ascending order the time at which the distribution base should be departed in order to arrive at the reachable time frame with the departure times of the multiple mobile bodies from the distribution base to determine whether the mobile body can be assigned. The delivery plan support system according to claim 3.

5. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines that the plurality of constraints are inconsistent when a load amount corresponding to one or more nodes assigned to a certain mobile body exceeds a load upper limit of the mobile body based on a constraint that defines a mobile body that should visit a specific node; Delivery planning support system.

6. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines that the plurality of constraints are inconsistent when a number of nodes assigned to a certain mobile object exceeds a maximum number of visited nodes of the mobile object based on a constraint that defines a mobile object that should visit a specific node; Delivery planning support system.

7. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines, based on a constraint that defines a mobile object to visit a specific node and a route constraint that defines an order in which a plurality of nodes should be visited, that the plurality of constraints are inconsistent when a load of cargo on a certain route exceeds an upper load limit of a mobile object that can be assigned to the route; Delivery planning support system.

8. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines, based on a constraint that defines a mobile object to visit specific nodes and a route constraint that defines an order in which the multiple nodes are to be visited, that the multiple constraints are inconsistent when the number of nodes in a certain route exceeds a maximum number of visited nodes of a mobile object that can be assigned to the route; Delivery planning support system.

9. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit, when detecting that there is no moving object that can be assigned to the route based on a route constraint that defines an order in which a plurality of nodes are to be visited and a constraint of an arrival time frame that is predefined for each of the plurality of nodes, determines that the plurality of constraints are inconsistent; Delivery planning support system.

10. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; Equipped with the determination unit determines, based on a first constraint that defines a first visited node that is a node that should be visited first on a route from the distribution base, a second constraint that defines a last visited node that is a node that should be visited last on a route from the distribution base, and a third constraint that defines mobile objects that should visit the first visited node and the last visited node, that the number of the first visited node and the last visited node exceeds the number of mobile objects defined by the third constraint, that the plurality of constraints are inconsistent; Delivery planning support system.

11. A reception unit that receives data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; a determination unit for determining whether the plurality of constraints are consistent with respect to at least one of time and resource allocation; an instruction unit that inputs a delivery plan instruction based on the plurality of constraints to a delivery plan generation unit when the determination unit determines that the plurality of constraints are consistent; A conversion unit; Equipped with the plurality of constraints include a first constraint that specifies a final visited node that is a node to be visited last on a route from the distribution base, and a second constraint that specifies a mobile object that is to visit the final visited node, The delivery plan generation unit sequentially determines delivery routes of the plurality of moving objects, the conversion unit converts the second constraint so as to preferentially assign the final visited node to a moving object that is relatively late in the determination order of the delivery route. Delivery planning support system.

12. The plurality of constraints further includes a third constraint that specifies an initial visit node that is a node that should be visited first on the route from the distribution base; the second constraint specifies a mobile object to visit the first visited node or the last visited node, the conversion unit converts the second constraint so as to preferentially assign the last visited node to a moving object that is relatively later in the determination order of the delivery route, and to preferentially assign the first visited node to a moving object that is relatively earlier in the determination order of the delivery route. The delivery plan support system according to claim 11.

13. receiving data indicating a plurality of constraints related to a delivery plan in a case where a plurality of mobile objects divide the work and deliver packages from a delivery center to a plurality of nodes; determining whether the constraints are consistent with respect to at least one of time and resource allocation; inputting a delivery plan instruction based on the plurality of constraints to a delivery plan generating unit when it is determined in the determining step that the plurality of constraints are consistent; The computer executes The determining step determines that the plurality of constraints are inconsistent when it is detected that a mobile object cannot depart from the distribution base within a possible departure time frame at the distribution base based on a constraint on the number of berths at the distribution base. Delivery planning support method.

14. A function of accepting data indicating multiple constraints regarding a delivery plan in a case where multiple mobile objects are divided to deliver packages from a delivery center to multiple nodes; determining whether the constraints are consistent with respect to at least one of time and resource allocation; a function of inputting a delivery plan instruction based on the plurality of constraints to a delivery plan generating unit when the function of determining determines that the plurality of constraints are consistent; This is realized on a computer. The determining function determines that the plurality of constraints are inconsistent when it is detected that a mobile object cannot depart from the distribution base within a possible departure time frame at the distribution base based on a constraint on the number of berths at the distribution base. Computer program.

Images