Quantum-classical solution stack for vehicle routing problems

Abstract

The present invention relates to a quantum-classical solution stack for vehicle routing problems. A method and system for generating routes includes receiving information about a set of nodes to be served, determining one or more parameters for each node, and determining the capacity of each of the one or more vehicles. A classical computer is used to generate a set of feasible routes based on the one or more parameters for each node and the capacity of each of the one or more vehicles. A number N of packets is determined for partitioning the set of feasible routes. The feasible routes are allocated into the N packets. The N packets are sent to a quantum computer to calculate the most efficient combination of feasible routes that covers all the nodes to be served.

Description

Technical Field

[0001] The present disclosure relates generally to routing technology and, more particularly, to an advanced computing architecture configured to handle complex routing scenarios. Background Art

[0002] The vehicle routing problem (VRP) involves a combinatorial optimization and integer programming task that attempts to provide an optimal set of routes for a fleet of vehicles traveling to a predetermined set of destination points. Capacity VRP with time windows (time windows) involves finding the optimal set of routes that results in minimum cost given the capacity of the vehicle, the demand at each destination location, the service time, and the time window for delivery. Obtaining an efficient solution to this problem is significant for different industries (such as, but not limited to, transportation, manufacturing, telecommunications, utilities, and energy) as well as the public sector. The problem is highly complex and is known to be NP-hard (non-deterministic polynomial time hard), and may not be effectively solved using traditional computing architectures, if at all. Summary of the Invention

[0003] According to various exemplary embodiments, a computing device, a non-transitory computer-readable storage medium, and a method for determining a route combination are provided. Information regarding a set of nodes to be served is received. One or more parameters of each node are determined. The capacity of each of the one or more vehicles is determined. A classical computer is used to generate a set of feasible routes based on the one or more parameters of each node and the capacity of each of the one or more vehicles. A number of packages N are created to allocate the set of feasible routes based on the number of feasible routes. The feasible routes are allocated into the N packages. The N packages are sent to a quantum computer to calculate the most efficient combination of feasible routes that covers the nodes to be served.

[0004] According to one embodiment, the nodes to be served are divided into a predetermined number of clusters.

[0005] According to one embodiment, each cluster is based on proximity between nodes to be served.

[0006] According to one embodiment, the number of feasible routes for a packet is based on the capacity of the quantum computer.

[0007] According to one embodiment, the number of feasible routes in a packet is equal to the number of qubits in the quantum computer.

[0008] According to one embodiment, the one or more parameters of each node include at least one of: a time window for arrival of vehicles of the one or more vehicles, a service duration requested by the node, or a size of a package to be delivered to the node.

[0009] According to one embodiment, the distribution of feasible routes to the N packets is based on random selection from the feasible routes.

[0010] According to one embodiment, the distribution of feasible routes into the N packets is based on each packet containing each node in the set of nodes to be served.

[0011] According to one embodiment, computing the most efficient combination of feasible routes includes computing, by a quantum computer, one or more feasible routes that have a lowest total cost when serving each node in a predetermined cluster.

[0012] In one embodiment, a hybrid quantum-classical computing platform for route management includes a classical computing device and a quantum computing device having N qubits. The classical computing device is configured to receive information about a set of nodes to be served; determine one or more parameters of each node; determine the capacity of each of one or more vehicles; generate a set of feasible routes based on the one or more parameters of each node and the capacity of each of the one or more vehicles; create a number of packages N to distribute the set of feasible routes based on a number of feasible routes; and distribute the feasible routes into the N packages. The quantum computing device is configured to: for each of the N packages, apply a feasible route to the corresponding qubit; and calculate the most efficient combination of feasible routes that covers the nodes to be served.

[0013] In one embodiment, the classical computing device is further configured to divide the nodes to be serviced into a predetermined number of clusters, each cluster being based on proximity between the nodes to be serviced.

[0014] In one embodiment, the distribution of the feasible routes into the N packets is based on a random selection from the feasible routes or each packet containing each node in the set of nodes to be served.

[0015] These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings are illustrative embodiments. They do not show all embodiments. In addition or alternatively, other embodiments may be used. Details that may be obvious or unnecessary may be omitted to save space or for more effective description. Some embodiments may be practiced with additional components or steps and / or without all components or steps shown. When the same number appears in different figures, it refers to the same or similar components or steps.

[0017] Figure 1 provides an overview of example limitations of using classical computing devices alone, consistent with illustrative embodiments;

[0018] Figure 2 A graph and table showing a plurality of nodes versus a plurality of mixed integer programming variables presented to a computing platform according to an illustrative embodiment;

[0019] Figure 3 An example architecture for implementing a hybrid quantum classical computing platform consistent with the illustrative embodiments is shown;

[0020] Figure 4 is a conceptual block diagram of determining routing using a hybrid quantum-classical approach consistent with an illustrative embodiment;

[0021] Figure 5 is a block diagram of the partitioning of processing between a classical computing device and a quantum simulator for determining the most efficient combination of routes to serve a set of nodes in a service domain, consistent with illustrative embodiments;

[0022] Figure 6 is a block diagram of a packing architecture that may be used to solve smaller problems on a quantum computer, consistent with illustrative embodiments;

[0023] Figure 7 is a conceptual block diagram for processing routing requests for a group of nodes using a hybrid quantum-classical computing process in accordance with an illustrative embodiment;

[0024] Figure 8A and 8B Provides a mathematical framework for the calculation of a capacity VRP with time windows for a single warehouse consistent with the illustrative embodiments;

[0025] Figure 9 An illustrative process for translating memory addresses while supporting parallel table walks consistent with illustrative embodiments is presented;

[0026] Figure 10 Provides a way to implement Figure 3 Functional block diagram of a computer hardware platform of a routing server and / or a classical computer;

[0027] Figure 11 depicts a cloud computing environment according to an illustrative embodiment; and

[0028] Figure 12 Abstract model layers are depicted in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0029] Overview

[0030] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings can be practiced without such details. In other instances, well-known methods, procedures, components, and / or circuits have been described at a relatively high level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

[0031] The present disclosure generally relates to advanced computing architectures configured to handle complex routing scenarios. Routing problems today cover a wide range of tasks in logistics and operations research. These tasks generally involve the optimal management of a fleet of vehicles (e.g., how each vehicle should be dispatched to meet some objective while minimizing time or resources (e.g., cost)). There are many variations and specifications of the problem for certain scenarios. The teachings herein include the Vehicle Routing Problem with a Time Window (VRPTW). Typical solution methods for VRPTW on classical computing devices include mathematical formulations involving discrete variables. As a result, classical methods tend to have worst-case solution times that are exponentially proportional to the number of decision variables. In this regard, reference is made to Figure 1 , which provides an overview of example limitations of using classical computing devices alone consistent with illustrative embodiments. More specifically, Figure 1 A graph 100 is shown indicating how long it may take to determine a suitable routing solution for different numbers of destinations (sometimes referred to herein as nodes or clients). If the number of nodes exceeds approximately 100, a classical computing platform may take too long to resolve the routing problem, if at all. Figure 1 Also shown is a graph 102 showing that as the number of nodes increases, the gap between the solution identified by the classical computing platform and the ideal route increases. As shown in graph 102, for reasonable computation time, the gap for 100 nodes is staggered by 55%, making the classical computing platform itself an unfeasible option in many situations.

[0032] Figure 2 The weaknesses of classical computing platforms are further explained in Figure 2 A graph 200 and a table 202 are shown of a plurality of nodes and a plurality of mixed integer programming variables presented to a computing platform. Figure 2 We demonstrate that the number of variables for a node-based MIP formulation increases binomially with the number of nodes, which may exhaust the capabilities of a classical computing platform when the number of nodes (e.g., clients) exceeds a predetermined threshold.

[0033] Thus, the teachings herein provide a hybrid quantum-classical computing platform that efficiently and accurately facilitates the processing of relatively large (e.g., over 5000) routing problems of practical size. The inventors have recognized that conventional formulations for using quantum computers to solve routing problems of significant size may overwhelm such platforms (e.g., requiring millions of qubits). The teachings herein provide a technical solution to this problem by promoting compatibility with quantum computers having different numbers of qubits. The routing optimization problem is decomposed into a feasible routing problem and an optimal routing selection problem presented as an exact set cover problem, which is also NP-hard. Novel decomposition methods (such as "packing") can be used to solve the set cover problem, which further reduces the qubit requirements while ensuring minimal loss of quality at the performance limit. In one aspect, the hybrid quantum-classical computing platform is highly flexible (e.g., as quantum hardware evolves) and adapts to future versions of any quantum hardware and software, and provides integration of quantum computing with existing classical computing-based workflows. The technology described herein can be implemented in several ways. Exemplary implementations are provided below with reference to the following figures.

[0034] Example System

[0035] Figure 3 An example architecture 300 for implementing a hybrid quantum-classical computing platform consistent with the illustrative embodiments is shown. Architecture 300 includes a network 306 that allows a routing engine 322 to access different computing devices and databases. Network 306 can be, but is not limited to, a local area network ("LAN"), a virtual private network ("VPN"), a cellular network, the Internet, or a combination thereof. For example, network 306 can include a mobile network that is communicatively coupled to a private network (sometimes referred to as an intranet) that provides different ancillary services, such as communication with different databases, such as a customer relationship manager (CRM) 312, a classical computer 350, a quantum computer 340, and different nodes (represented by circles) and repositories (represented by squares) in service domain 302. For the purposes of this discussion, by way of example and not limitation, network 306 will be described as a mobile network that can be operated by a service provider to provide a wide range of mobile communication services and supplementary services or features to its subscriber customers and associated mobile device users.

[0036] Service domain 302 includes different nodes, sometimes referred to herein as customers, that can be served by one or more warehouses. Each warehouse can include one or more service vehicles. Each vehicle can have the same capacity, or the capacity can vary between vehicles. However, each vehicle has a finite capacity, which can be described as the number of uniform packages that can be carried by it. For example, a standard vehicle (e.g., a truck) can carry 120 standard packages. Larger packages can be described by multiple standard unit packages (e.g., 2, 3, etc.).

[0037] exist Figure 3 In the context of [ 1 ], the vehicle routing problem with time windows (VRPTW) can be defined as selecting the number of vehicles to use from a set of available vehicles to serve a cluster of nodes (e.g., customers) within a predetermined time window. Clusters are depicted as circles with uniform patterns. By way of example only and not limitation, service domain 302 includes three clusters and four depots. Each vehicle has a finite capacity. It originates from and terminates at a depot. Each node should be served exactly once.

[0038] Routing engine 322 can be a program stored in routing server 320 that is configured to coordinate routing between vehicles and nodes in service domain 302. Routing engine 322 can receive as input 319 a set of nodes and depot locations in service domain 302, travel times and distances between locations, demand and allowed time windows at each location, capacity of each vehicle, proximity to the depot, and associated costs involved. In one embodiment, routing engine 322 determines restrictions for each node from CRM 312, which is coupled for communication via network 306. In one example, CRM database 312 provides online access to various features associated with the account holder's account (e.g., a user of the services described herein), such as hours of service / delivery, any obstacles that may delay access to a node (e.g., a number of stairs to climb, etc.), password controls, etc. CRM database 312 can provide an interface to the account holder via the Internet to update any preferences and / or restrictions.

[0039] The routing engine 322 facilitates a set of routes that start from the warehouse, visit all node locations, and return to the warehouse while adhering to capacity and time constraints. The problem described represents a time window capacity carrier routing problem. The arc-based formulation of this problem is a mixed integer linear programming (MILP) problem.

[0040] Classical solvers on the classical computing platform 350 (such as ) can converge slowly to optimality (if at all) when solving radian-based formulas. Moreover, a classical computer 350 with such a solver becomes increasingly incapable of handling relatively large-sized problems. In this regard, the routing engine 322 orchestrates the hybrid quantum-classical computing platform by using the classical solver 350 to relatively quickly generate a "good" (e.g., initial) pool of feasible routes without having to solve for optimality. For example, the pool may include a set of routes {R1, R2, ..., R n}, where each route R i represents the route taken by a vehicle, starting from the warehouse, visiting a set of node locations, and returning to the warehouse.

[0041] Such a "good" (e.g., initially unoptimized) set of routes can then be sent by routing engine 322 to quantum solver 340 to find an optimal subset of routes that incurs the minimum total cost (i.e., is most efficient) while collectively being able to visit all node locations. This scenario presents a weighted set cover problem and is NP-complete.

[0042] To make this framework suitable for solving relatively large-scale problems, routing engine 322 provides data resizing at different levels, thereby providing compatibility with quantum computer 340. First, clusters can be used to cluster locations, allowing classical solver 350 to process relatively small, tractable, radian-based formulations of the routing task to generate a set of possible routes. In a separate phase, routing engine 322 uses quantum computer 340 to solve the weighted set cover problem. To this end, a packing architecture can be used, which allows running smaller problems that fit on and are adaptable to existing quantum hardware. Each of these concepts will be discussed in more detail later.

[0043] Although the historical CRM 312, routing server 320, and classic computer 350 have been illustrated as being on different platforms by way of example, it will be understood that in various embodiments, their functionality described herein may be combined in different combinations. In other embodiments, these computing platforms may be implemented as virtual computing devices in the form of virtual machines or software containers hosted in the cloud 330, thereby providing a resilient architecture for processing and storage.

[0044] Example Block Diagram

[0045] Now refer to Figure 4 , Figure 4is a conceptual block diagram of determining routing using a hybrid quantum classical approach consistent with an illustrative embodiment. In system 400, routing engine 322 receives a list of nodes to be served in the form of data packets. The nodes are divided into clusters 402, represented by clusters 401(1) to 401(N). In one embodiment, the number of clusters is based on a predetermined limit of nodes in the cluster (e.g., 200 nodes per cluster). In one embodiment, the number of nodes in each cluster is substantially equal (e.g., if there is an odd number of nodes, a cluster can have additional nodes to be served). The clusters can be based on predetermined criteria, discussed in more detail later. For each cluster, a set of feasible routes is determined (e.g., 404) by a classical computing device. In one embodiment, an arc-based formulation is used. Feasibility can be based on the capacity of the vehicle and / or parameters (e.g., constraints) of each node served by the vehicle. For example, each permutation (e.g., route) must meet the timing requirements of the delivery and the capacity of the vehicle (e.g., whether the package or service is compatible with the vehicle). The feasible routes can be based on a single vehicle from a warehouse, multiple vehicles from a warehouse, multiple warehouses with one or more vehicles, or any combination thereof.

[0046] It will be appreciated that the generation of feasible routes can result in many (e.g., millions) of permutations that can overwhelm the processing power of a quantum computer to provide reliable results within a reasonable timeframe. Therefore, the different permutations are grouped into a predetermined number of packets. The number of routes in each packet can be based on the power of the quantum computer. In one embodiment, the number of routes in each packet is based on the number of qubits in the quantum computer.

[0047] The routing engine 322 then determines the number of runs 408. In one embodiment, the routing engine 322 uses classical computing devices to perform this function. For example, routes are sampled for inclusion in the packet. A set of covering problems is solved for each packet by a quantum computer. Each cluster then provides the routing engine with the best route in terms of overall efficiency. In various embodiments, efficiency may be based on the amount of energy, time, and effort involved. In some embodiments, efficiency is based on a cost analysis, including but not limited to cost per mile (which may be different for each type of vehicle), cost per hour or mile of vehicle used, any associated labor costs per unit time, etc. Therefore, the results from each cluster are combined 430, and the best route or combination of routes is then selected based on the calculated efficiency. These concepts will be discussed in more detail later.

[0048] Figure 55 is a block diagram 500 of dividing processing between a classical computing device 530 and a quantum simulator 510 to determine the most efficient routing combination to serve a set of nodes in a service domain according to an illustrative embodiment. In one embodiment, nodes (e.g., customers) of the service domain are divided into clusters based on node distance to the nearest warehouse (e.g., by applying a proximity-based clustering algorithm to cluster the node locations into clusters of substantially equal size), as shown in block 502. By way of example only, and not by way of limitation, in Figure 5 In the example of , assume there are 1200 nodes to be served. For the example of five clusters (i.e., block 506), there will be 240 nodes in each cluster. An arc-based problem is established on a classical solver (e.g., a computer) 530 in each cluster.

[0049] At block 504, for each cluster, a set of feasible routes is generated by the classical computer 530. The classical computer 530 may be run for a predetermined time without concern for optimality to produce a set of routes for each cluster. For example, each cluster may have 10 to 25 routes. Another set of routes may be created for each cluster. In various embodiments, the second set of routes for each cluster The routes can be generated by a classical computer 530 by: (i) randomly permuting nodes on the routes; (ii) by swapping nodes between a pair of routes; and / or (iii) by fusing multiple pairs of routes together. Each of these options can be performed without violating time constraints (e.g., arrival time) and capacity constraints (e.g., vehicle capacity). and Provide cluster routing The ultimate "good" pool.

[0050] In this example, the number of packets is 20. In one embodiment, the number of packets can be set by the user based on the packet size (e.g., the number of qubits on the quantum computer) and the probability of a success event. The success event may involve finding the best set of routes among at least one of these packets. In this regard, it is noted that the quantum computer 510 solves the weighted set cover problem on the pool of routes generated during the route generation step. If such a pool The size of is relatively large (larger than the problem size that the quantum solver can handle), we Select a set of routes where i∈{0, 1, ..., n bag}. Such a subset Referred to herein as "packets," these can be formed by randomly drawing elements from a pool, either from a uniform distribution or using a suitable rule. For each cluster, quantum computer 510 processes each packet associated with the cluster. In one embodiment, quantum computer 510 uses quadratic unconstrained binary optimization (QUBO) to identify the efficiency (e.g., cost) of each solution (i.e., route). The most efficient solution is then selected by classical computer 530.

[0051] Now refer to Figure 6 , Figure 6 is a block diagram of a packing architecture 600 that can be used to solve smaller problems (e.g., for a single cluster) on a quantum computer 610, consistent with an illustrative embodiment. For example, the packing architecture facilitates solving routing problems on a quantum computer based on the multiple qubits provided by the hardware. Block 602 is related to Figure 2 The blocks of block 502 are substantially similar and therefore are not repeated herein for the sake of brevity.

[0052] At block 604, for a given cluster (e.g., cluster 1), a set of feasible routes is generated by the classical computer 630. In one embodiment, the classical computer 630 uses a distributed parallel algorithm for a mixed integer programming solver to generate a set of routes for the cluster. The resulting routes provide a pool of "good" routes for the cluster. Operating the routing engine of the classical computer 630 with an appropriate number of packets (e.g., based on the number of qubits in the quantum computer) and an appropriate packet size can help Figure 6 In Chinese The optimal routing set has a probability (p d ) occurs with probability, as discussed in more detail below.

[0053] The number of routes in each packet may be based on the number of qubits in the quantum computer (simulator) 610. For example, if the quantum simulator has 5 qubits (i.e., N=5), then the number of routes in the packet will also be 5 (i.e., N).

[0054] In one embodiment, the routing engine can create packets in such a way that each packet includes a route that provides complete coverage of the node. To this end, a greedy algorithm can be used to create such packets. Such an algorithm can randomly draw routes from a pool without replacement and continue drawing until complete coverage is achieved. In one embodiment, the algorithm is linear in the input size. For example, the input size can be the number of routes generated by a classical computer. To form a packet with complete coverage, an algorithm that can be linear in the input size can be used.

[0055] The determination of the number of packets with a value above a predetermined threshold (p d) with a probability of appearing, to be applied to the quantum simulator 610, the packet including an optimal routing set In one embodiment, an upper bound on the number of packets may be determined by considering the case where packets are created by drawing a set of routes at random (eg, without complete coverage).

[0056] For example, consider that there is an optimal route (which may not be known in advance) and randomly draw a set of k (i.e., packet sizes, assuming all packets are of equal size) routes to create a packet. Without loss of generality, the routing engine can assume that m < k. Draw the optimal set The probability of , where the symbol The creation of each packet can be described as a Bernoulli trial, where after t of these trials, at least one succeeds (i.e., sees the best routing group The probability of at least one packet of the packet is 1-(1-p)^t.

[0057] It can be seen by calculation that at least one packet with the best routing set is always greater than p d The probability of providing the number of packets that ensure that the packet includes at least one optimal route is provided by the following expression:

[0058] 1-(1-p) t ≥p d

[0059]

[0060] where t is the minimum number of packets required when the routes are drawn uniformly at random.

[0061] When routes are drawn so that they have full coverage When providing an upper limit on the number of packets.

[0062] Now refer to Figure 7 , which shows a conceptual block diagram for processing routing requests for a set of nodes (e.g., clients) using a hybrid quantum classical computing process consistent with an illustrative embodiment. System 700 includes a plurality of service nodes (e.g., clients) represented by circles to be accommodated by a routing service.

[0063] The routing engine may receive multiple nodes to be served. It determines how many repositories are available (e.g., Figure 7 701). Warehouse 701 may represent a warehouse or storage facility where one or more vehicles are located. In the present case, a single warehouse 701 with three carriers is shown, however, it should be understood that additional (or fewer) carriers and additional warehouses are within the scope of the present disclosure.

[0064] At block 706, the nodes are clustered based on predetermined criteria. In various embodiments, the predetermined criteria may include being in the same zone, having similar requirements (e.g., vehicle type), ecological considerations (e.g., only allowing electric vehicles), proximity to a warehouse, proximity to each other, etc. In this example, the nodes are clustered based on their geographic location (i.e., proximity to each other), which is represented by differently patterned circles. Each cluster is then individually solved to determine one or more ideal routes, as shown in block 710.

[0065] At block 712, the routing engine may use classical computing devices to generate different possible routing solutions, sometimes referred to herein as unique feasible routes. As previously described, feasibility may be based on the constraints of the vehicle and / or the constraints of each node to be served by the vehicle. It will be appreciated that in some scenarios, the number of different permutations may be very large (e.g., for classical and / or quantum computers to process). To this end, these unique feasible routes are distributed into a predetermined number of packets before the remaining permutations are applied to the quantum computer. This is because applying the selected route directly to the quantum computer may overwhelm the processing power (e.g., qubit count) of the quantum computer.

[0066] In one embodiment, a determination is made as to the number of qubits available in the quantum computer. The size of the packet (the number of feasible routes) is then based on the number of qubits. In one example, if a quantum computer has N qubits, then N routes are placed in each packet. In one embodiment, the path for each packet is randomly selected. In other embodiments, the routes are selected so that each packet includes every node to be served in the cluster. For example, a first routing scheme applied to the first packet 730 (1) may involve two carriers from a single depot, where the carriers travel (D-1-2-5-D) and (D-3-4-D), respectively, thereby covering all nodes. Another feasible routing scheme may include 3 separate carriers with a single depot, where the carriers travel (D-1-2-D), (D-3-5-D), and (D-4-D), respectively, all returning to the same depot 701 that was applied to packet 73 (4). In this way, each qubit of the quantum computer receives a set of routes to perform the computation. The solutions are collected by the routing engine 322, and the one with the highest efficiency (e.g., Figure 7 The example of the 730(3)) package.

[0067] Figure 8A and 8B A mathematical framework for the calculation of a capacity VRP with time windows for a single warehouse is provided consistent with the illustrative embodiments. Figure 8A The objective function provided in Equation 1 can be obtained by Figures 8A to 8BThe constraints governing the context of Equations 2 to 9 are provided.

[0068] Example Process

[0069] Utilizing example systems and architectures 300 to 700 and Figure 8A and Figure 8B Having outlined the mathematical formula for , it may be helpful to now consider a high-level discussion of the example process. To this end, Figure 9 An illustrative process 900 for translating memory addresses while supporting parallel table walks, consistent with an illustrative embodiment, is presented. The process 900 is shown as a collection of boxes in a logical flow graph that represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, a box represents a computer-executable instruction that performs the described operation when executed by one or more processors. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, etc. that perform functions or implement abstract data types. In each process, the order in which the operations are described is not intended to be construed as a limitation, and any number of the described boxes may be combined in any order and / or executed in parallel to implement the process. For purposes of discussion, reference is made to Figure 3 The architecture of the process 900 is described.

[0070] At block 902 , routing engine 322 receives information regarding a set of nodes 302 to be served in service domain 302 .

[0071] At block 904, the routing engine 322 determines one or more parameters for each node. For example, the parameters may include at least one of a time window for vehicle arrival, a type of service to be delivered, or a package size.

[0072] At block 906 , a capacity of each of the one or more vehicles is determined.

[0073] At block 908 , the classical computer 350 is used to generate a set of feasible routes based on one or more parameters of each node and the capacity of each of the one or more vehicles.

[0074] At block 910, routing engine 322 determines the number of packets N used to partition the set of feasible routes. In one embodiment, the number of packets is based on the capacity of the quantum computer. For example, the number of packets can be based on the number of qubits of the quantum computer, such that the number of routes generated in each packet is substantially equal to the number of qubits of the quantum computer.

[0075] At block 912, the feasible routes are distributed among the N packets. In various embodiments, the distribution of the feasible routes among the N packets may be based on random selection (eg, by classical computing means), or based on each packet containing each node to be served.

[0076] At block 914, the N packets are sent to the quantum computer.

[0077] At block 916 , quantum computer 340 computes the most efficient combination of routes that covers all nodes to be served.

[0078] Example computer platform

[0079] In one embodiment, functionality associated with a hybrid quantum-classical computing platform involves one or more computing devices. Figure 10 Provides a way to implement Figure 3 Functional block diagram of a computer hardware platform 1000 of a routing server 320 and / or a classic computer 350.

[0080] Computer platform 1000 may include a central processing unit (CPU) 1004 , a hard disk drive (HDD) 1006 , random access memory (RAM) and / or read-only memory (ROM) 1008 , a keyboard 1010 , a mouse 1012 , a display 1014 , and a communication interface 1016 , which are connected to system bus 1002 .

[0081] In one embodiment, HDD 1006 has the capability to store programs that can perform various processes in the manner described herein, such as routing engine 1040. Routing engine 1040 may have various modules configured to perform various functions, such as Figures 3 to 7 Those modules discussed in the context of . For example, there may be an interaction module 1042 that is operable to interact with different nodes in the service domain and warehouses, CRMs, classical computers, quantum computers, and / or clouds in the service domain. There may be a parameter module 1044 that is operable to determine node parameters from various nodes in the service domain or CRMs associated with the service domain. There may be a capacity module 1046 that is operable to determine the capacity of each vehicle. There may be a clustering module 1048 that is operable to cluster nodes in the service domain based on predetermined criteria. There may be a packing module 1050 that is operable to calculate the number of packages to be used to allocate feasible routes to accommodate the capabilities of the quantum computer. There may be a selection module 1052 that is operable to select one or more routes that have the highest efficiency while accommodating every node in the cluster.

[0082] Sample Cloud Platform

[0083] As discussed above, the functionality involved in providing a hybrid quantum classical computing platform may include distributed computing and / or storage architectures, such as in the cloud. It should be understood that while this disclosure includes detailed descriptions regarding cloud computing, implementation of the teachings cited herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.

[0084] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0085] Features are as follows:

[0086] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0087] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0088] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0089] Rapid elasticity: The ability to quickly and elastically provision capacity, in some cases automatically scaling down and releasing capacity to scale up quickly. To the consumer, the capacity available for provisioning typically appears unlimited and can be purchased in any quantity at any time.

[0090] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0091] The service model is as follows:

[0092] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0093] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and the configuration of the application hosting environment.

[0094] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0095] The deployment model is as follows:

[0096] Private cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0097] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0098] Public cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by the organization that sells cloud services.

[0099] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0100] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that consists of a network of interconnected nodes.

[0101] Now see Figure 11, describes an illustrative cloud computing environment 1100. As shown, the cloud computing environment 1100 includes one or more cloud computing nodes 1110, with which local computing devices used by cloud consumers (such as, for example, personal digital assistants (PDAs) or cell phones 1154A, desktop computers 1154B, laptop computers 1154C, and / or automobile computer systems 1154N) can communicate. The nodes 1110 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or a combination thereof, as described above. This allows the cloud computing environment 1150 to provide infrastructure, platforms, and / or software as services for which cloud consumers do not need to maintain resources on local computing devices. It should be understood that Figure 11 The types of computing devices 1154A-N shown in are intended to be illustrative only, and computing nodes 1110 and cloud computing environment 1150 may communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0102] Now see Figure 12 , showing the cloud computing environment 1150 ( Figure 11 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 12 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. As described, the following layers and corresponding functions are provided:

[0103] Hardware and software layer 1260 includes hardware and software components. Examples of hardware components include: host 1261; server 1262 based on RISC (Reduced Instruction Set Computer) architecture; server 1263; blade server 1264; storage device 1265; and network and network components 1266. In some embodiments, software components include network application server software 1267 and database software 1268.

[0104] The virtualization layer 1270 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 1271 ; virtual storage 1272 ; virtual networks 1273 , including virtual private networks; virtual applications and operating systems 1274 ; and virtual clients 1275 .

[0105] In one example, the management layer 1280 may provide the functionality described below. Resource provisioning 1281 provides dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 1282 provides cost tracking when utilizing resources within a cloud computing environment and bills or invoices the consumption of those resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 1283 provides access to the cloud computing environment for consumers and system administrators. Service level management 1284 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 1285 provides pre-arrangement and procurement of cloud computing resources in anticipation of future requirements for the cloud computing resources based on the SLA.

[0106] The workload layer 1290 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 1291; software development and lifecycle management 1292; virtual classroom education delivery 1293; data analytics processing 1294; and, as discussed herein, transaction processing 1295 and routing engine 1296.

[0107] in conclusion

[0108] The description of various embodiments of the present teachings has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0109] While the foregoing has described what is considered to be the best state and / or other examples, it should be understood that various modifications may be made therein, and that the subject matter disclosed herein may be embodied in different forms and embodiments, and that the teachings may be applied to many applications, only some of which have been described herein. It is intended that the appended claims claim any and all applications, modifications, and variations that fall within the true scope of this teaching.

[0110] The components, steps, features, objectives, benefits, and advantages discussed herein are illustrative only. They and the discussion related thereto are not intended to limit the scope of protection. Although various advantages have been discussed herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise indicated, all measurements, values, ratings, positions, amplitudes, sizes, and other specifications set forth in this specification (including in the following claims) are approximate and imprecise. They are intended to have a reasonable range consistent with the functions to which they are related and with the functions customary in the field to which they belong.

[0111] Many other embodiments are also contemplated. These include embodiments with fewer, additional, and / or different components, steps, features, objects, benefits, and advantages. These also include embodiments in which components and / or steps are arranged and / or sequenced differently.

[0112] Various aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer-readable program instructions.

[0113] These computer-readable program instructions can be provided to a processor of a suitably configured computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in the flowchart and / or block diagram or multiple blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a certain manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in the flowchart and / or block diagram or multiple blocks.

[0114] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.

[0115] The call flow, flow chart and block diagram in the figure herein illustrate the architecture, function and operation of the possible implementation of the system, method and computer program product according to different embodiments of the present disclosure. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, depending on the functions involved, the two blocks shown in succession can actually be executed substantially simultaneously, or the blocks can sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart, can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0116] Although the above has been described in conjunction with exemplary embodiments, it should be understood that the term "exemplary" is merely meant to serve as an example, not the best or optimal. Except as immediately stated above, nothing stated or shown is intended or should be construed as conferring upon or providing public equivalence to any component, step, feature, object, benefit, advantage, whether or not recited in the claims.

[0117] It should be understood that the terms and expressions used herein have ordinary meanings, as given to these terms and expressions for their corresponding corresponding queries and research fields, unless otherwise set forth herein in specific meanings. Relational terms such as first and second, etc. can be used only to distinguish one entity or action from another entity or action, without requiring or implying any actual such relationship or order between these entities or actions. The terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusions, so that the process, method, article, or device comprising a series of elements not only includes those elements, but also may include other elements that are not explicitly listed or inherent to such process, method, article, or device. Without further limitation, an element starting with "a" or "an" does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0118] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it is not used to interpret or limit the scope or meaning of the claims. Furthermore, in the above Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This approach of the disclosure should not be interpreted as reflecting an intention that the claimed embodiments have more features than expressly recited in each claim. On the contrary, as reflected in the following claims, the inventive subject matter lies in less than all the features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. A computing device comprising: processor; a network interface coupled to the processor to enable communication over a network; a routing engine coupled to the processor and configured to perform actions comprising: receiving information about a set of nodes to be served; determining one or more parameters of each node; determining a capacity of each of the one or more vehicles; generating, using a classical computer, a set of feasible routes based on the one or more parameters of each node and the capacity of each of the one or more vehicles; Creating N packets to distribute the set of feasible routes based on a number of feasible routes, where N>1; Distributing the feasible routes to the N packets; and The N packets are sent to a quantum computer to calculate the most efficient combination of feasible routes covering the nodes to be served.

2. The computing device of claim 1 , further comprising: Divide the nodes to be served into a predetermined number of clusters.

3. The computing device of claim 2, wherein: Each cluster is based on the proximity between the nodes to be served.

4. The computing device of claim 1, wherein: The number of possible routes for a packet is based on the capacity of the quantum computer.

5. The computing device of claim 1 , wherein the number of feasible routes in a packet is equal to the number of qubits in the quantum computer.

6. The computing device of claim 1, wherein: The one or more parameters of each node include at least one of the following: a time window for arrival of a vehicle of the one or more vehicles; The duration of service requested by the node; or The size of the data packet to be delivered to the node.

7. The computing device of claim 1, wherein: Allocating the feasible routes to the N packets is based on random selection from the feasible routes.

8. The computing device of claim 1, wherein: The allocation of the feasible routes into the N packets is based on each packet including each node in the set of nodes to be served.

9. The computing device of claim 2, wherein computing the most efficient combination of feasible routes comprises computing, by the quantum computer, one or more feasible routes that have a lowest total cost when serving each node in a predetermined cluster.

10. A computer-implemented method, comprising: receiving information about a set of nodes to be served; determining one or more parameters of each node; determining a capacity of each of the one or more vehicles; generating, using a classical computer, a set of feasible routes based on the one or more parameters of each node and the capacity of each of the one or more vehicles; Creating N packets to distribute the set of feasible routes based on a number of feasible routes, where N>1; Allocating the feasible routes to the N packets; The N packets are sent to a quantum computer to calculate the most efficient combination of feasible routes covering the nodes to be served.

11. The method of claim 10, further comprising: The nodes to be served are divided into a predetermined number of clusters, wherein each cluster is based on proximity between the nodes to be served.

12. The method of claim 10, wherein the plurality of feasible routes for a packet is based on the capacity of the quantum computer.

13. The method of claim 10, wherein the number of feasible routes in a packet is equal to the number of qubits in the quantum computer.

14. The method of claim 10, wherein the one or more parameters for each node include at least one of: a time window for arrival of a vehicle of the one or more vehicles; The duration of service requested by the node; or The size of the data packet to be delivered to the node.

15. The method of claim 10, wherein assigning the feasible routes to the N packets is based on random selection from among the feasible routes.

16. The method of claim 10, wherein: The allocation of the feasible routes into the N packets is based on each packet including each node in the set of nodes to be served.

17. The method of claim 11, wherein: Calculating the most efficient combination of feasible routes includes calculating, by the quantum computer, one or more feasible routes that have a lowest total cost when serving each node in the predetermined cluster.

18. A hybrid quantum-classical computing platform for routing management, comprising: A classical computing device configured to: receiving information about a set of nodes to be served; determining one or more parameters of each node; determining a capacity of each of the one or more vehicles; generating a set of feasible routes based on the one or more parameters of each node and a capacity of each of the one or more vehicles; creating N packets to distribute the set of feasible routes based on a number of feasible routes, where N>1; and Allocating the feasible routes to the N packets; A quantum computing device configured to: For each of the N packets, applying a feasible route to the corresponding qubit; and Calculate the most efficient combination of feasible routes that cover the node to be served.

19. The hybrid quantum-classical computing platform of claim 18, wherein: The classical computing device is further configured to divide the nodes to be served into a predetermined number of clusters, wherein each cluster is based on proximity between the nodes to be served.

20. The hybrid quantum-classical computing platform of claim 18, wherein: The allocation of the feasible routes to the N packets is based on: Randomly select from the feasible routes; or Each packet includes each node in the set of nodes to be served.

21. A computer program product comprising: Program instructions executable by a processor, comprising an instruction set for executing any step of any method according to claims 10-17.

Images