A method and device for near connection of port vehicle operation

Abstract

The application provides a wharf vehicle operation near connection method and device, which is applied to the field of information technology, maps intersections, lanes, vehicles, tasks and matching relations into Actor instances based on an Actor distributed model, responds to vehicle and task messages in real time, predicts the time for each vehicle to reach a target loading point by searching for the fastest driving path in combination with all state vehicles in the task allocation range, establishes the association between operation vehicles and tasks under the condition of meeting the task time window, constructs one or more groups of weighted bipartite graphs with controllable scales by taking the inverse number of the predicted empty driving time as the weight, solves the maximum weight matching by using the Hungarian algorithm in parallel, eliminates the multi-task matching conflicts caused by graph segmentation by the vehicle Actor, and cyclically executes the above process when the vehicle or task state changes, so that the global empty driving total time is minimized, the operation energy consumption and operation cost are significantly reduced, and the overall efficiency and resource utilization of the wharf loading and unloading operation are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, in particular to a method and device for near connection of terminal vehicle operation. BACKGROUND

[0002] In the process of terminal loading and unloading operation, the key to improving the overall operation efficiency of the terminal, reducing operation energy consumption and operation cost lies in optimizing the scheduling of horizontal transport vehicles, that is, minimizing the empty running time of the vehicles. The ideal solution should start from the whole terminal vehicle, connect nearby, dynamically allocate tasks to the most suitable vehicles to minimize the total empty running time of the whole terminal vehicle and maximize the utilization rate.

[0003] Although the existing scheme has improved the near operation connection method, there are still the following problems:

[0004] Firstly, the task allocation range is narrow, only the vehicles without tasks at the moment are allocated tasks, while those vehicles that have not executed tasks or will complete tasks are ignored, among which there may be more suitable ones;

[0005] Secondly, only the static path is matched, the shortest driving path is equated to the fastest driving path, and the congestion on the shortest driving path is not considered, so it is difficult to arrive at the destination within the task specified time window, thereby disrupting the order of loading and unloading operation, even causing the waiting of loading and unloading equipment, affecting the overall operation efficiency of the terminal;

[0006] Thirdly, the existing scheme usually uses genetic algorithm, ant colony algorithm and other methods to find approximate solutions to the problem by guessing and searching, and only feasible solutions can be obtained within a limited time, but the deviation of feasible solutions from optimal solutions cannot be predicted, which brings a series of defects such as unstable performance and slow convergence speed, so that in real complex scenes with high requirements for real-time performance and accuracy, the problem cannot be completely solved, and it is difficult to meet the high requirements for real-time performance and accuracy in complex scenes of the terminal.

[0007] Therefore, a new terminal vehicle operation near connection scheme is needed. SUMMARY

[0008] Therefore, the embodiments of the present application provide a method and device for near connection of terminal vehicle operation, in order to reduce the empty running time of the whole terminal vehicle in the process of terminal loading and unloading operation by the near connection method of terminal vehicle operation, maximize the utilization rate of the terminal vehicle, improve the overall operation efficiency of the terminal, and reduce operation energy consumption and operation cost.

[0009] The embodiments of the present application provide the following technical solutions:

[0010] The embodiment of the present specification provides a port vehicle operation near connection method, comprising:

[0011] Step S1, mapping the port road network structure, operation vehicle, task, and matching relationship between the task and the operation vehicle into Actor instances based on an Actor distributed parallel computing model respectively, and deploying into an Actor service container;

[0012] Step S2, subscribing to event messages through the Actor instances to update the state of the corresponding Actor, and refreshing the space-time data and statistical data of the operation vehicle in the road network;

[0013] Step S3, dynamically predicting the predicted arrival time of each operation vehicle to the target loading point by using the fastest driving path search method; and when the predicted arrival time meets the task loading time window, establishing the association relationship between the operation vehicle and the task, and assigning a weight value to each association relationship;

[0014] Step S4, constructing one or more weighted bipartite graphs with the vehicle and the task as the vertex, the association relationship as the edge, and the weight of the association relationship as the weight of the edge, and managing the size of the weighted bipartite graph, wherein the size of the weighted bipartite graph includes: when the vertex size of the graph exceeds a first threshold, performing a graph partitioning operation, and when the vertex size of the graph is lower than a second threshold, performing a graph merging operation to control the size of the graph;

[0015] Step S5, solving the maximum weight matching for each weighted bipartite graph to obtain an initial matching result; and resolving the matching conflicts occurring in the solving process to obtain a final matching result;

[0016] Step S6, publishing the final matching result, and when detecting that the operation vehicle state, the task state, a new task or a new vehicle occurs, repeating steps S3 to S5 to realize dynamic real-time optimization of task allocation.

[0017] The embodiment of the present specification also provides a port vehicle operation near connection device, comprising:

[0018] A model construction and deployment module is configured to map the port road network structure, operation vehicle, task, and matching relationship between the task and the operation vehicle into Actor instances based on an Actor distributed parallel computing model respectively, and deploy into an Actor service container;

[0019] A subscription receiving module is configured to subscribe to event messages through the Actor instances to update the state of the corresponding Actor, and refresh the space-time data and statistical data of the operation vehicle in the road network;

[0020] The association relationship establishing module is configured to dynamically predict an estimated arrival time of each work vehicle to a target loading point by using a fastest driving path searching method, and establish an association relationship between the work vehicle and the task when the estimated arrival time meets a task loading time window, and assign a weight value to each association relationship;

[0021] The weighted bipartite graph management module is configured to construct one or more weighted bipartite graphs with the work vehicles and the tasks as vertices, the association relationships as edges, and the weights of the association relationships as edge weights, and manage the size of the weighted bipartite graphs, wherein the size of the weighted bipartite graphs includes performing a graph splitting operation when the vertex size of the graph exceeds a first threshold value, and performing a graph merging operation when the vertex size of the graph is below a second threshold value, so as to control the size of the graph;

[0022] The conflict resolution module is configured to solve each weighted bipartite graph by using a maximum weight matching method to obtain an initial matching result, and resolve a matching conflict occurring in the solving process to obtain a final matching result.

[0023] The optimization module is configured to publish the final matching result, and re-call the association relationship establishing module, the weighted bipartite graph management module and the conflict resolution module when detecting that the state of the work vehicle, the state of the task, a new task or a new vehicle occurs, so as to realize dynamic real-time optimization of task allocation.

[0024] Compared with the prior art, the above at least one technical solution adopted by the embodiments of the present application can achieve at least the following beneficial effects:

[0025] By using the Actor distributed parallel framework, all the vehicles in idle, allocated but not executed, and about to complete a task are included in a real-time matching pool, a weighted bipartite graph is continuously constructed and maintained by combining dynamic fastest driving path prediction and negative empty driving time weight, and a maximum weight matching is solved based on the Hungarian algorithm, and a graph splitting / merging and redundant vertex conflict resolution mechanism is used to ensure high concurrency and low delay in a large-scale scenario, so as to minimize the total empty driving time of all vehicles in the field, break through the 20% lower limit of the empty driving rate of the traditional improvement method, basically eliminate the phenomenon of unreasonable empty driving, realize the near connection, dynamic real-time optimization and maximum utilization of the wharf horizontal transportation task, significantly reduce the operation energy consumption and operation cost, and improve the overall efficiency and resource utilization rate of the wharf loading and unloading operation. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0027] Figure 1 This is a flowchart of a method for nearby connection of dock vehicle operations in this application;

[0028] Figure 2 This is the class diagram of the extended fastest driving path search method in this application;

[0029] Figure 3 This is a class diagram of a method for connecting dock vehicle operations nearby, as described in this application.

[0030] Figure 4 This is a schematic diagram illustrating the estimated arrival time at the new mission loading point in this application;

[0031] Figure 5 This is a schematic diagram of cutting redundant vertices in this application;

[0032] Figure 6 This is a schematic diagram of finding redundant vertices in this application. Detailed Implementation

[0033] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0034] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0036] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0037] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.

[0038] Improving overall operational efficiency and reducing energy consumption and operating costs are key concerns for dockside businesses during loading and unloading operations. One approach is to address the coordination issues between dockside vehicles, minimizing empty runs for horizontal transport tasks. This requires considering all vehicles at the dock to maximize utilization and ultimately reduce costs while increasing efficiency.

[0039] To ensure efficient coordination across all vehicles at the terminal, it's necessary to identify which vehicles currently without assignments, not yet performing assignments, or about to complete assignments can reach the loading point for new assignments within the designated time window. These assignments need to be distributed as widely as possible, forming matching relationships, with the overall total empty running time as minimal as possible. These matching relationships can be dynamically adjusted because new assignments or more suitable vehicles may emerge at any time, disrupting the original optimal matching. A new optimal matching needs to be found to address these changes, and the final decision on which vehicle should perform the assignment can only be made at the last minute (before the vehicle performs its assignment).

[0040] Based on the above needs and the problems to be solved, the terminal has made every effort to improve its loading and unloading processes. For example, when two ships are loading and unloading simultaneously, vehicles can be arranged to proceed to the second ship for loading and unloading after completing the loading and unloading operations on the first ship, including "loading and unloading simultaneously" on a single ship. These improvements can indeed reduce the empty running time of individual vehicles, but their implementation is quite demanding. They only achieve certain effects when the timing is right under specific conditions, and are not comprehensive.

[0041] In view of this, through in-depth research and improvement of the nearest-operation-connection method, the inventors discovered that although existing solutions have improved the nearest-operation-connection method, the following problems still exist:

[0042] First, tasks are only assigned to idle vehicles: This means tasks are only assigned to vehicles currently without tasks, ignoring vehicles that haven't yet started a task or are about to finish one. There might be more suitable vehicles among them. For example, a vehicle about to complete its unloading task might be near the loading point of a new task, and its unloading would perfectly coincide with the loading window of the new task. There's no better match, but current technology excludes these vehicles and doesn't match them. Expanding the matching range requires predicting when these vehicles will complete their current task, i.e., predicting when they will arrive at the unloading point. This requires estimating the remaining travel time based on the driving path and predicting the estimated arrival time. This is not achieved in current technology.

[0043] Secondly, matching is based solely on static paths: equating the shortest travel path with the fastest travel path fails to consider that congestion on the shortest path may render it unusable, making it difficult to reach the destination within the designated time window. This disrupts the loading and unloading sequence, potentially causing equipment delays and impacting overall terminal efficiency. Such idealized solutions cannot adapt to dynamic environmental changes or determine if the empty-trip time is truly the shortest possible. Achieving optimal matching requires predicting when these components will arrive at the new loading point, planning their fastest travel paths dynamically based on time and space, estimating the total travel time, and predicting the estimated arrival time. This is not yet achieved in existing technologies.

[0044] Third, some technical solutions use genetic algorithms and ant colony algorithms. These methods often find approximate solutions to the problem through guessing and searching, and can only obtain feasible solutions within a limited time. The deviation between feasible and optimal solutions is generally unpredictable, leading to a series of defects such as unstable performance and slow convergence speed. Therefore, in real-world complex scenarios with high requirements for real-time performance and accuracy, they often fail to completely solve the problem. If possible, it is best to use exact methods to find the optimal solution. When encountering performance bottlenecks in large-scale data processing, advanced technologies such as distributed parallel computing and distributed graph partitioning can be used to break down the problem into smaller parts and overcome the bottleneck.

[0045] The following are explanations of technical terms:

[0046] The horizontal transport tasks (hereinafter referred to as tasks) refer to the tasks of moving goods between ship loading and unloading equipment (such as quay cranes) and yard loading and unloading equipment (such as yard cranes) within the entire terminal area, such as ship to yard (unloading and loading goods from ship to yard), yard to ship (transshipment), and yard to yard (transshipment).

[0047] The task comprises a set of instructions requiring the vehicle assigned to the task to arrive at the loading point within a specified time window, load the cargo, and then transport it to the designated unloading point. Task status is categorized as: Pending Assignment, Assigned, Executing, Completed, and Cancelled. Assigned tasks, as long as they haven't been executed, can continue to participate in task allocation (i.e., dynamic matching) and be assigned to more suitable vehicles. For example, at the loading point, if the task order of vehicles doesn't match the queue order, the tasks of the vehicles ahead and behind will be swapped.

[0048] The loading and unloading points refer to the operational points distributed along the driveways of the terminal road network structure, providing facilities for vehicles to load and unload goods. At the quayside, this means the driveways lead to the loading and unloading positions under the ship's loading and unloading equipment; in the container yard, it means the driveways lead to the loading and unloading positions under the yard's loading and unloading equipment. The terminal road network structure is an interconnected, interwoven road system composed of driveways and intersections within the terminal. Mapped to a computer data structure, this is a directed graph with intersections as vertices and driveways as directed edges.

[0049] The empty driving time refers to the time it takes for a vehicle to travel from its current location to the loading point when it is not currently carrying a task or has been matched but has not yet executed a task, i.e., it is in an empty state. When a vehicle is about to complete a task but is still in a heavily loaded state, the empty driving time refers to the time it takes to travel from the unloading point of the current task to the loading point of the new task after the unloading of the current task is completed.

[0050] The phrase "having the conditions to receive a task" refers to whether a vehicle's condition allows it to be assigned a specific task. For example, a hazardous materials transport task cannot be assigned to an unqualified vehicle, or a vehicle already carrying a 20-foot container cannot carry a 40-foot container before unloading. These are all hard conditions that must be followed when assigning tasks.

[0051] Based on this, this specification proposes a method for connecting terminal vehicle operations in close proximity: The overall idea is as follows: Based on the Actor distributed model, intersections, lanes, vehicles, tasks, and matching relationships are mapped to parallel-computable Actor instances, which respond to vehicle and task messages in real time. By including all vehicles in the "to be assigned" task broadcast range, the estimated time for each vehicle to reach the target loading point is predicted by combining the fastest travel path search, and the association between operating vehicles and tasks is established under the condition of meeting the task time window. One or more sets of appropriately sized weighted bipartite graphs are constructed using the negative of the estimated empty running time as the weight. Then, the maximum weight matching is solved in parallel using the Hungarian (Kuhn-Munkres) algorithm, and the multi-task matching conflicts caused by graph segmentation are resolved by the vehicle Actor to obtain the final matching result. The above process is executed cyclically when the vehicle or task status changes, realizing dynamic real-time optimization to minimize the total global empty running time. This breaks through the 20% lower limit of the empty running rate of traditional improved methods, basically eliminating unreasonable empty running phenomena, significantly reducing operational energy consumption and operating costs, and improving the overall efficiency and resource utilization of terminal loading and unloading operations.

[0052] The technical solutions provided by the various embodiments of this application are described below with reference to the accompanying drawings.

[0053] like Figures 1-3 As shown in the embodiments of this specification, a method for nearby connection of dock vehicle operations is provided, including:

[0054] Step S1: Map the dock road network structure, operating vehicles, tasks, and the matching relationship between tasks and operating vehicles to Actor instances based on the Actor distributed parallel computing model, and deploy them to the Actor service container.

[0055] In implementation, the intersections of the dock are mapped to intersection Actor instances of the fastest travel path search method; the lanes of the dock are mapped to lane Actor instances of the fastest travel path search method.

[0056] Define a task actor, which is responsible for creating new instances and marking and activating them with task IDs;

[0057] Define a vehicle actor, map all vehicle entities at the dock to vehicle actors and label them with vehicle IDs;

[0058] Define a bipartite graph Actor. The bipartite graph Actor that has undergone a natural split or graph partitioning operation, or the task Actor that has not found its own bipartite graph, is responsible for adding new instances and marking and activating them with the bipartite graph ID. The bipartite graph ID is taken from a distributed ID generation algorithm (such as Snowflake algorithm).

[0059] Step S2: Subscribe to event messages through the Actor instance to update the status of the corresponding Actor and refresh the spatiotemporal data and statistics of the working vehicle in the road network.

[0060] During implementation, subscribing to and receiving vehicle messages:

[0061] Events that trigger the intersection Actor and lane Actor when they receive a message of an actual / expected vehicle entering, or when they receive a message of an actual vehicle exiting;

[0062] Dynamically refresh the list of density fluctuations and feature combination count records for intersection Actors and lane Actors to provide spatiotemporal and statistical data for the fastest driving path search method;

[0063] For a lane actor, if the received message is an actual vehicle entering the lane when the vehicle is empty, or an actual / expected vehicle entering the lane when the vehicle is loaded, and the unloading point of the loaded vehicle is in this lane, then if the driving situation deviates from the previous prediction, the vehicle message will be pushed to the vehicle actor (if the vehicle actor instance does not exist, a new one will be created and marked and activated with the vehicle ID).

[0064] Subscribing to and receiving task messages:

[0065] The event that triggers the lane actor when it receives a task message; if it is a new task, a new task actor instance is created and marked with the task ID and activated.

[0066] Push the task message to the task actor;

[0067] It should be noted that the vehicle information in this application includes at least: vehicle ID, lane ID, location, and status; the task information includes at least: task ID, task status, loading point, unloading point, and loading time window.

[0068] Step S3: Using the fastest travel path search method, dynamically predict the estimated arrival time of each work vehicle to the target loading point; and when the estimated arrival time meets the task loading time window, establish the association between the work vehicle and the task, and assign a weight value to each association.

[0069] Specifically, for tasks with a status of "pending assignment", the task message is broadcast to all vehicle actors through the corresponding task actor. Each vehicle actor uses the fastest travel path search method to dynamically predict the estimated arrival time of the working vehicle to the target loading point. The working vehicles include idle vehicles, vehicles that have been assigned but have not yet executed tasks, and vehicles that are about to complete their current tasks.

[0070] If the estimated arrival time is within the loading time window specified by the task, an association is established between the work vehicle and the task, and the negative of the estimated empty driving time of the work vehicle to the target loading point is used as the weight of the association.

[0071] In implementation, the task actor subscribes to and receives task messages from the lane actor, triggering the task actor's event when a task message is received; the vehicle actor subscribes to and receives task messages from the task actor, triggering the vehicle actor's event when a task message is received; the task actor subscribes to and receives associated messages from the vehicle actor, triggering the task actor's event when an associated message is received; the vehicle actor subscribes to and receives vehicle messages from the lane actor, triggering the vehicle actor's event when a vehicle message is received; if the task status is pending assignment:

[0072] The task actor broadcasts the task message to the vehicle actors. After receiving the task message, all vehicle actors determine whether they are not disabled and meet the conditions to receive the task. If so, they use the fastest driving path search method to estimate the estimated empty driving time and the estimated total driving time. Based on the estimated total driving time and their own driving status, the vehicle actors assess whether they can reach the loading point within the task's specified time window. If so, they initialize the association message and feed it back to the task actor to form an association relationship. After the task actor confirms and provides the bipartite graph to which it belongs, it is then pushed to the bipartite graph actor to register the association relationship.

[0073] If the task status is in progress / completed / cancelled, it will no longer participate in dynamic matching. The task Actor will remotely call the remove task method of the relevant vehicle Actor and bipartite graph Actor to remove the association.

[0074] If a vehicle is disabled, it will no longer participate in dynamic matching. The vehicle Actor will remotely call the vehicle removal method of the relevant task Actor and bipartite graph Actor to sever the association.

[0075] If the vehicle's driving conditions deviate, the vehicle actor will reassess the correlation.

[0076] Step S4: Construct one or more weighted bipartite graphs with vehicles and tasks as vertices, the relationships as edges, and the weights of the relationships as edge weights, and manage the size of the weighted bipartite graphs. The size of the weighted bipartite graphs includes: performing graph splitting when the vertex size of the graph exceeds a first threshold, and performing graph merging when the vertex size of the graph is lower than a second threshold, so as to control the size of the graph.

[0077] In practice, the new task Actor searches for the bipartite graph with the most concentrated associations and adds it. If it cannot be found, a new bipartite graph Actor is added. The new bipartite graph Actor is marked and activated with a bipartite graph ID, which is taken from a distributed ID generation algorithm.

[0078] If the number of vertices of a bipartite graph Actor exceeds a certain threshold (default is 200), a graph splitting operation is performed to find suitable redundant vertices and cut them, the new graph is migrated to a new bipartite graph Actor instance, and the relevant attributes of the task Actor and vehicle Actor are synchronized; if the number of vertices of a bipartite graph Actor is below a certain threshold (default is 76), a graph merging operation is attempted.

[0079] Step S5: Perform maximum weight matching for each weighted bipartite graph to obtain the initial matching result; and resolve the matching conflicts that occur during the solution process to obtain the final matching result.

[0080] In practice, after the bipartite graph actor senses a change in the association relationship, it uses the Hungarian (Kuhn-Munkres) algorithm to find the best matching result from the constructed weighted bipartite graph adjacency matrix.

[0081] Based on the best matching result, the bipartite graph Actor remotely calls the vehicle Actor's method to confirm the best matching result one by one. If the vehicle is a redundant vertex and there is already a matching task, the vehicle Actor uses the method of resolving matching conflicts to leave the best matching, thereby obtaining the final matching result.

[0082] Step S6: Publish the final matching result, and repeat steps S3 to S5 when the status of the work vehicle or the task status changes or a new task or a new vehicle appears, so as to achieve dynamic real-time optimization of task allocation.

[0083] Specifically, the external system drives the Actor instances deployed in the Actor service container through push messages. These Actor instances then collaboratively process the messages and feed back the final confirmed matching results to the external system.

[0084] For example, when a new task appears, a corresponding task Actor instance is mapped. The fastest path search method is used to find which vehicles it is associated with, and then it is connected to these vehicle Actors, added to the weighted bipartite graph containing these vehicles. This triggers the bipartite graph Actors to find the best match again. Similarly, if a task is canceled externally (e.g., the yard bridge cancels an existing task after adjusting its work order), the bipartite graph Actors are triggered to remove the corresponding vertices from the weighted bipartite graph. If a match has already been found, the best match is found again.

[0085] For example, when a new vehicle appears, a corresponding vehicle Actor instance is mapped. The fastest path search method is used to find which tasks it is associated with, and then it is connected to these task Actors, added to the weighted bipartite graph containing these tasks. This triggers the bipartite graph Actors to find a new best match. Similarly, if a vehicle is disabled by external factors (e.g., the vehicle needs refueling or the driver needs a rest or meal), the bipartite graph Actors are triggered to remove the corresponding vertices from the weighted bipartite graph, and if a match has already been found, a new best match is found.

[0086] For example, when a real-time message is received that a vehicle has entered the lane, if there is a deviation from the previous prediction (early arrival, late arrival, or change of route), the existing relationships need to be reassessed to see if they need to be unbound, or if there are new relationships that need to be connected. If so, the relevant bipartite graph actors need to be triggered to find the best match for these changes.

[0087] For example, if a task / vehicle is removed or an association is unbound, causing a natural split in the weighted bipartite graph, the newly split graph needs to be moved into the newly added bipartite graph Actor. The method for detecting natural splits is to use the Union-Find technique to find vertices that are directly or indirectly connected to the affected vertices. If there are multiple trees or multiple root nodes—that is, multiple sets that cannot be merged—these are the multiple split graphs.

[0088] Explanation of technical terms in this embodiment:

[0089] Union-Find is an efficient data structure for solving dynamic connectivity problems. It supports two operations: Union: merging the sets to which two elements belong (merging their corresponding trees); and Find: retrieving the set to which a given element belongs (retrieving the root node of its corresponding tree). Initially, each element resides in a separate set, represented as a tree with only a root node. Through continuous querying and merging, it eventually becomes a forest, where each tree represents a set, and the nodes in the trees represent elements within their respective sets. Union-Find technology can utilize optimization techniques such as path compression and union by rank to achieve fast merging and query operations in near constant time. It is a highly efficient technique for processing large-scale data and is widely used in graph theory, dynamic connectivity detection, network connection analysis, cluster analysis, and other fields.

[0090] The fastest travel path search method is a dynamic path planning method based on an Actor distributed parallel computing model. Specifically, it maps the road network structure to instances and connectivity relationships of lane Actors and intersection Actors. Intersection Actors prepare multiple candidate paths to other intersections, sorted from shortest to longest, based on the K-shortest path algorithm. Each Actor, after being activated, subscribes to actual / expected vehicle entry and / or exit messages. Upon receiving a message, it dynamically updates spatiotemporal data and statistical data (a list of density fluctuation time series records and a list of feature combination count records). Once a request to search for the fastest travel path is received, the Actor instances on each candidate path are triggered sequentially, either forward or backward, according to the vehicle's departure or arrival time. The estimated travel time for vehicles on the candidate paths is spatiotemporally deduced, and the candidate path with the shortest estimated travel time is the fastest travel path to be searched. This method, if specifying the departure time and location, infers the estimated arrival time at the destination; if specifying the arrival time at the destination, it infers the estimated departure time from a certain location. This achieves the goal of precise task allocation. Even during actual vehicle travel, this method can still continuously calculate the estimated entry and exit times of the vehicle at intersections and lanes on the remaining path; the closer the distance, the higher the calculation accuracy.

[0091] The Actor distributed parallel computing model originated from Carl Hewitt's conceptual model of parallel computing proposed in 1973. Today's mainstream cloud-native tools and runtime environments can build, register, address, activate, run, and release virtual Actor computing units in distributed system architectures, automatically troubleshoot and restore normal operation, and implement event-driven and parallel computing of virtual Actor computing units in distributed system environments based on the Publish-Subscribe Pattern (Pub-Sub). It possesses technical characteristics such as real-time performance, reliability, robustness, and scalability, and can support large-scale real-time data processing and high-performance computing. For example, the open-source Dapr is the preferred Actor distributed parallel computing platform for this invention. Dapr is a language-independent, event-driven microservice runtime that runs in a Sidecar pattern, helping developers construct portable, scalable, and easily maintainable stateless and stateful applications that run on cloud platforms or edge computing.

[0092] A Virtual Actor (Actor for short), also known as a distributed virtual state machine, is a distributed computing unit that is independent of computation and state. It is deployed in a distributed computing hosting service cluster and registered on a hosting service instance (Actor service container) within the cluster. An Actor instance has its own behavior and data, and can subscribe to external messages. Upon receiving a message or being remotely invoked, it can execute appropriate actions based on its own state. It can also periodically activate itself using its own timers and reminders, executing preset processes and influencing the outside world. Actors are transparent to the outside world; external entities can access a specific Actor instance through an agreed-upon Actor keyword (ID) without needing to know where it runs. Generally, an Actor instance is not immediately released after activation; it retains its own data until no new access or messages are received, at which point it is released by the hosting service instance. This achieves high-performance response and computation, significantly reducing the operational pressure on the database from system services.

[0093] Furthermore, to address the optimal matching problem among multiple tasks and vehicles, this invention maps tasks and vehicles to instances of task Actors and vehicle Actors in an Actor distributed parallel computing model and connects them based on association relationships. Using vehicle Actors and task Actors as vertices of a weighted bipartite graph, and the connections between them as edges, with the negative of the expected idle time as the edge weight, the Kuhn-Munkres algorithm (Hungarian algorithm) can be used to find the optimal match. The search for the optimal match is performed by bipartite graph Actor instances built on the Actor distributed parallel computing model, with each instance handling a specified set of weighted bipartite graphs.

[0094] In some embodiments, the dynamic prediction of the estimated arrival time of each work vehicle to the target loading point includes:

[0095] The estimated empty running time is determined based on the current status of the work vehicle, including:

[0096] If the work vehicle is an idle vehicle, the estimated empty driving time includes: the estimated driving time from the current location of the work vehicle to the target loading point;

[0097] If the work vehicle is a heavy-duty vehicle that is performing a task, the estimated empty driving time includes: the estimated driving time from the current unloading point of the work vehicle to the target loading point.

[0098] Based on the above embodiments, the fastest travel path search method mentioned in patent CN120489165A, "A Method and Device for Searching the Fastest Travel Path of a Terminal Vehicle," is used to estimate the estimated empty travel time. If the working vehicle is currently in an idle state (i.e., an empty vehicle), then it is only necessary to estimate the estimated time for the empty vehicle to reach the new task loading point; that is, the time required is the estimated empty travel time.

[0099] If the working vehicle is currently performing a task (i.e., a heavily loaded vehicle), then it is necessary to estimate the estimated time for the heavily loaded vehicle to reach the current task unloading point (the estimated remaining travel time), and then estimate the estimated empty travel time for the heavily loaded vehicle from the current task unloading point to the target loading point, i.e., the estimated empty travel time.

[0100] like Figure 4 As shown, assuming a heavy-duty vehicle about to complete its current task is eligible to receive a new task, it's necessary to calculate when it will arrive at the new task loading point to determine whether it's appropriate to assign the new task to this vehicle. Specifically:

[0101] Since the fastest path search method continuously updates the estimated entry and exit times of vehicles at intersections and lanes on the remaining paths, the estimated entry time of the vehicle can be obtained from the Actor of the lane where the current task unloading point is located. Then, adding the estimated entry time to the estimated unloading time in that lane gives the estimated exit time of the vehicle after the current task is completed, which is the estimated entry time at the intersection at the end of the lane. Using the estimated entry time at that intersection as the departure time, the fastest path search method finds the fastest path from the current task unloading point to the new task loading point, estimating the estimated arrival time at the new task loading point. The corresponding shortest estimated travel time is the estimated empty travel time. If the estimated arrival time at the new task loading point is within the specified new task loading time window, the vehicle is suitable for assignment to the new task, and the negative of the estimated empty travel time is used as the matching value to determine whether this association can become a matching relationship.

[0102] In some embodiments, mapping the wharf road network structure to Actor instances includes mapping lanes in the wharf road network to lane Actors of a fast-moving path search method, and extending the attributes of the lane Actors, including:

[0103] Add a new unloading operation feature to the properties of the lane actor to calculate the estimated unloading time. The unloading operation feature includes at least: unloading point identifier and cargo type.

[0104] The lane actor is configured to: based on the unloading operation characteristics in the received vehicle messages and combined with the current unloading point density data, obtain the estimated unloading time required for a heavy-duty vehicle to complete the unloading operation at the lane unloading point.

[0105] In conjunction with the above embodiments, the attributes of the lane actor are extended (the original functions are retained and continue to be used). These attributes are initialized by retrieving data from the database when the lane actor is activated by the managed service, and written to the database when there are updates:

[0106] Expand the feature combination count record list and add features for unloading operations to vehicle features. The content includes, but is not limited to, unloading point ID and cargo type, in order to calculate the estimated unloading time when a heavy-load vehicle is converted to an empty vehicle. These vehicle features are obtained from vehicle messages pushed by external systems.

[0107] Define a task ID list to store the received task IDs related to the loading point of this lane;

[0108] Extend the events of the lane actor. These events begin subscribing to messages identified by the lane ID when the lane actor is activated by the hosting service. The message sender is an external system.

[0109] Extend the events triggered when a message about an actual / expected vehicle entering is received, including:

[0110] Execute the original method of the expanded event;

[0111] Based on the changes in data before and after the event, determine whether the actual / expected driving status of the vehicle deviates from the previous prediction. If so, further determine whether the vehicle message is the actual entry message of an empty vehicle or the actual / expected entry message of a loaded vehicle. If the unloading point of the loaded vehicle is on this lane, then use the vehicle ID as the message identifier to push the vehicle message to the vehicle Actor (if the vehicle Actor instance does not exist, add one and mark and activate it with the vehicle ID). The vehicle message includes, but is not limited to: vehicle ID, lane ID, actual / expected entry time, vehicle characteristics, driving path, and disabled flag.

[0112] This incident is now concluded.

[0113] In practice, the estimated unloading time is the time it takes for a heavy-load vehicle to enter the unloading lane, unload at the unloading point, and then exit the lane. This time is estimated using the fastest path search method, specifically calculated using density and transit features. During the calculation, new vehicle features specific to unloading operations were added to the transit features, including but not limited to: unloading point ID and cargo type (e.g., for container operations, "single small container / single large container / double container"). Based on this, it can be predicted which vehicles eligible for tasks can arrive at the loading point within the designated time window. Furthermore, the scope of vehicles that can be assigned tasks—that is, vehicles related to tasks—has been expanded to include all vehicles currently without tasks, not yet performing tasks, or about to complete tasks. Both heavy-load and empty vehicles can participate in task allocation as long as they can arrive at the loading point within the time window. Thus, a series of many-to-many / one-to-many / one-to-one relationships are formed between multiple tasks and multiple vehicles, from which the best match is found.

[0114] In some embodiments, step S4 involves performing graph segmentation when the vertex size of the graph exceeds a first threshold, based on a vertex cutting or edge differentiation strategy, including:

[0115] The tasks with established relationships in the current weighted bipartite graph are sorted according to a preset sorting condition to generate a task sequence; wherein, the preset sorting condition is based on the estimated total travel time of the associated vehicles of the task, sorted from shortest to longest.

[0116] Traverse within a preset range of the task sequence to gradually construct a subset of tasks;

[0117] During the traversal, vehicles that are associated with tasks in the task subset and also with tasks outside the task subset are identified, thus obtaining the external vehicle set.

[0118] During the traversal, the set of external vehicles with the fewest vehicles is retained. When the size of the set of external vehicles is 0 or 1, or when the traversal reaches the end of the preset interval, the set of external vehicles is determined as the graph partition boundary.

[0119] The vehicle vertices in the external vehicle set are cut as redundant vertices to generate a first clone vertex and a second clone vertex, so that the current weighted bipartite graph is divided into a first subgraph and a second subgraph; wherein, the first subgraph retains the first clone vertex and its association with the remaining task vertices in the original graph; the second subgraph includes the task subset, the second clone vertex and its association;

[0120] Move the second subgraph to the newly added bipartite graph Actor;

[0121] The estimated total travel time is determined based on the current status of the work vehicle, including:

[0122] If the operating vehicle is an idle vehicle, then the estimated total travel time includes: the estimated empty travel time of the idle vehicle;

[0123] If the work vehicle is a heavy-duty vehicle performing a task, the estimated total travel time includes: the estimated remaining travel time from the current location of the work vehicle to the current task unloading point, the estimated unloading time to complete the unloading operation at the current task unloading point, and the estimated empty travel time of the heavy-duty vehicle.

[0124] In implementation, the maximum weight matching problem is transformed into a perfect matching problem by assigning a label (called vertex label) to each vertex. The algorithm guarantees that for all edges, the sum of the vertex labels of the two vertices is not less than the weight of the edge. Under this condition, if a perfect matching exists in the constructed equal subgraph, then this matching is the maximum weight matching of the original graph. Since the time complexity of the algorithm is O(n^3), the computational performance drops significantly when the number of vertices exceeds a certain scale (e.g., more than 1000). If the vertex size of the weighted bipartite graph is higher than a certain threshold (e.g., a maximum of 200), a vertex-cut / edge-partition strategy is adopted to divide the large-scale graph into multiple subgraphs without losing the association relationship. This allows the classic Kuhn-Munkres algorithm to continue to be used in the distributed parallel computing model and can still obtain the optimal solution efficiently and quickly. Under the premise of preserving all relationships, a new graph is created from the current graph by cutting vertices and moved into the newly added bipartite graph Actor. Both the current graph and the new graph have clones of the cut vertices, which can be called redundant vertices. The cut vertices can be called clone vertices. The edges connecting the redundant vertices will naturally be merged into their respective graphs along with the clone vertices and the other end vertices.

[0125] like Figure 5As shown, here's an example of creating a new graph from the current graph by cutting redundant vertices: The left side is a bipartite graph containing task set A and vehicle set A, along with their relationships. When a vehicle vertex (black dot) in vehicle set A is deemed a valid vertex to be cut, it is treated as a redundant vertex and split into two clones. One clone (the upper black semicircle on the right) remains in vehicle set A, along with task vertices directly or indirectly connected to it, and vehicle vertices indirectly connected to it. The other clone (the lower black semicircle on the right) is placed in vehicle set B, with task vertices directly or indirectly connected to it placed in the new task set B, and vehicle vertices indirectly connected to it placed in the new vehicle set B. Task set B, vehicle set B, and their relationships together form a new graph B.

[0126] Determining which vertices are reasonably separable requires graph segmentation operations, specifically identifying reasonable segmentation boundaries. "Reasonable" means that after segmentation, the graph will not quickly merge and then re-segment, nor will it frequently encounter redundant vertices with multiple matching relationships requiring resolution. Therefore, this invention, based on the objective fact that the closer the distance from the vehicle to the loading point, or the shorter the estimated total travel time, the higher the accuracy of the estimated arrival time calculation and the more stable the matching relationships, segments a portion of tasks about to enter the execution phase and their associated vehicles from the current graph. The specific method is as follows:

[0127] 1. Sort the matched tasks in the current graph according to their estimated total travel time from shortest to longest and put them into an array. ;

[0128] 2. Traverse the array Each step will extract the current task and the tasks traversed before it and put them into a task subset;

[0129] 3. When traversing to the th Step index in When the interval is within a certain range, find the subset that is related to the current task. The vehicles that are related to the tasks in the current task subset are then identified, and the vehicles that are also related to other tasks that are not in the current task subset are then identified and denoted as the external vehicle set.

[0130] 4. During the traversal, retain the smallest set of external vehicles. When the size of the set of external vehicles is 0 or 1, or when the traversal reaches the end of the interval (comparison is only performed within the interval to avoid creating new graphs that are too small or too large), this set of external vehicles is the segmentation boundary we are looking for.

[0131] 5. Vehicles in the external vehicle set are cut into clone vertices as redundant vertices, causing the current graph to be divided into two graphs. The corresponding task subset is the task set of the new graph, and the associated vehicles are the vehicle set of the new graph.

[0132] like Figure 6 As shown, an example of finding reasonable vertices that can be partitioned, i.e., finding redundant vertices, is to use graph partitioning operations: Tasks within task set A are sorted from shortest to longest according to their estimated total travel time; when traversing to a task... Traversal stops when the set of external vehicles contains only one vehicle (black dot); the vertex of that vehicle is considered a valid vertex that can be cut.

[0133] It should be noted that during graph segmentation, the matched tasks traversed in the current graph are sorted by default according to their estimated total travel time from shortest to longest. The estimated total travel time is determined based on the current status of the working vehicle. In conjunction with the above embodiments, the fastest travel path search method mentioned in patent CN120489165A, "A Method and Device for Searching the Fastest Travel Path for Dock Vehicles," is used to estimate the estimated total travel time.

[0134] If the working vehicle is currently in an idle state (i.e., an empty vehicle), then we only need to estimate the estimated time for the empty vehicle to arrive at the new task loading point. That is, the estimated total travel time is the formula: Estimated total travel time = Estimated empty travel time of the empty vehicle.

[0135] If the vehicle is currently performing a task (i.e., a heavily loaded vehicle), then it is necessary to estimate the estimated time for the heavily loaded vehicle to reach the current unloading point (the estimated remaining travel time), the estimated unloading time to complete the unloading operation at the current unloading point (the estimated unloading time), and the estimated empty travel time from the current unloading point to the target loading point (the estimated empty travel time). Then, the estimated time for the heavily loaded vehicle to reach the new loading point (the estimated total travel time) can be estimated using the following formula: Estimated total travel time = Estimated remaining travel time when heavily loaded + Estimated unloading time when switching from heavy to empty + Estimated empty travel time when unloaded.

[0136] If the vehicle is currently unloading, the estimated remaining driving time when heavily loaded is 0. If the vehicle has just finished unloading, the estimated remaining driving time when heavily loaded and the estimated unloading time when switching from heavy to empty are both 0.

[0137] In some embodiments, when sorting tasks with established relationships in the current graph, the preset sorting conditions can be replaced by using an external sorting rule plugin.

[0138] The sorting rule plugin is embedded into the bipartite graph Actor through a standard interface.

[0139] In some embodiments, step S4, which involves performing a graph merging operation when the vertex size of the graph is below a second threshold, includes:

[0140] When the vertex size of any weighted bipartite graph is lower than the second threshold, the bipartite graph Actor corresponding to the weighted bipartite graph initiates a graph merge request to the other bipartite graph Actors, and selects the merge object that simultaneously meets the following conditions:

[0141] The size of the merged vertices is no greater than the first threshold, and the proportion of the number of shared redundant vertices to the total number of redundant vertices in the target bipartite graph is greater than the golden ratio.

[0142] After obtaining confirmation of the target bipartite graph Actor, the initiator's weighted bipartite graph is merged into the target bipartite graph Actor, and the initiator's bipartite graph Actor is released;

[0143] Synchronously update the bipartite graph attributes of the task actor and vehicle actor.

[0144] In practice, if the sum of the vertex sizes of two bipartite graph actors is not higher than the golden ratio threshold (e.g., a maximum of 200) (slightly lower than the threshold is to avoid frequent graph splitting and merging), and there are redundant vertices shared beyond the golden ratio, then their relationship is relatively close, and graph merging can be performed. Specifically:

[0145] By merging the duplicate vertices, the graph in one bipartite Actor is merged into the graph in another bipartite Actor, releasing the bipartite Actor that has become an empty set. If the merged redundant vertices no longer have other connections, these redundant vertices are restored to ordinary vertices.

[0146] In some embodiments, resolving matching conflicts includes:

[0147] According to the preset conflict resolution rules, select one from all the conflicting matching tasks as the final matching task for the work vehicle.

[0148] The notified bipartite graph actor that the unmatched vertex has cancelled the current matching for the vertex of the work vehicle;

[0149] Upon receiving the notification, the bipartite graph Actor temporarily removes the clone vertex of the work vehicle vertex from the weighted bipartite graph managed by the bipartite graph Actor, and re-solves for the maximum weight matching.

[0150] After the solution is completed, the bipartite graph Actor adds the cloned vertices back into the weighted bipartite graph until all matching conflicts are resolved.

[0151] In implementation, if a redundant vertex is identified as the best matching vertex by two or more bipartite graph actors, only one of these matching relationships can be retained. This needs to be resolved using methods to eliminate matching conflicts. Specifically:

[0152] First, the redundant vertex Actor (specifically the vehicle Actor) is responsible for deciding which matching relationship to keep. Then, the bipartite graph Actors that lost the competition temporarily remove their clone vertices from their respective weighted bipartite graphs, find the best matching again, and then add the clone vertices back, until all matching conflicts are resolved.

[0153] In some embodiments, the preset rules include:

[0154] Select the matching relationship with the shortest expected empty driving time. If multiple tasks have the same expected total driving time, select the matching relationship with one vehicle associated with the task.

[0155] Alternatively, a custom matching rule plugin can be used, which is embedded into the vehicle Actor through a pre-defined standard interface.

[0156] In practice, redundant vertices (Actors) default to retaining the match with the shortest expected empty driving time. If the matched task is associated with only one vehicle, it will be retained first. For example, if vehicle A is selected as the best match by both task 1 and task 2:

[0157] The estimated empty driving time for vehicle A to both Task 1 and Task 2 is 5 minutes. However, Task 1 is only associated with vehicle A, while Task 2 is associated with vehicle B and vehicle C in addition to vehicle A. Therefore, vehicle A will be prioritized to retain its matching relationship with Task 1.

[0158] Alternatively, the default judgment logic can be replaced by an external matching rule plugin. The matching rule plugin is embedded into the redundant vertex Actor through a standard interface.

[0159] It should be noted that the database used in this invention is a relational database, with PostgreSQL being the preferred open-source database, but other databases can also be used.

[0160] This invention abstracts and summarizes the terminal road network structure and operation points, and provides a plug-in interface for the scalable introduction of unknown logic that can be tailored to different vehicle characteristics and operation rules. It is applicable not only to traditional or automated container terminals, but also to bulk cargo and general cargo terminals where vehicles are used to transport goods within the terminal.

[0161] This invention minimizes the total global empty running time by solving for the optimal matching of each subgraph, and adjusts the graph structure and resolves conflicts in real time. This ensures that the entire system maintains efficient and real-time connection of nearby operations in a dynamic environment. It breaks through the 20% lower limit of the empty running rate of traditional improvement methods, basically eliminates unreasonable empty running, significantly reduces operational energy consumption and operating costs, and improves the overall efficiency and resource utilization of terminal loading and unloading operations.

[0162] The concept of this invention is based on the Actor distributed parallel computing model, which can realize large-scale real-time data processing and high-performance computing, which is sufficient to support large-scale dock on-site production operation scenarios.

[0163] Below is another example of a method for connecting dock vehicle operations to the nearest location, which is a schematic illustration combining the previous examples.

[0164] Step S1: Build the Actor distributed parallel computing model and deploy it to the Actor service container:

[0165] S1.1, map the intersections of the dock to intersection Actor instances of the fastest travel path search method;

[0166] S1.2 maps the dock's lanes to lane Actor instances of the fastest travel path search method and extends their functionality (the original functionality is retained for continued use):

[0167] S1.2.1, Extend the lane actor's attributes. These attributes are initialized by retrieving data from the database when the lane actor is activated by the managed service, and written to the database when there are updates:

[0168] S1.2.1.1, Expand the feature combination count record list, add features for unloading operations to vehicle features, including but not limited to: unloading point ID, cargo type, to calculate the estimated unloading time when a heavy-load vehicle is converted to an empty vehicle. These vehicle features are obtained from vehicle messages pushed by external systems.

[0169] S1.2.1.2, Define a task ID list to store the received task IDs related to the loading point of this lane;

[0170] S1.2.2, Extended Lane Actor Events: These events begin subscribing to messages identified by the lane ID when the lane actor is activated by the managed service. The message sender is an external system.

[0171] S1.2.2.1, Extends the event triggered when a message indicating an actual / expected vehicle is received:

[0172] S1.2.2.1.1, Execute the original method of the extended event;

[0173] S1.2.2.1.2, based on the changes in data before and after the event, determine whether the actual / expected driving status of the vehicle deviates from the previous prediction. If so, continue to determine whether the vehicle message is the actual entry message of an empty vehicle or the actual / expected entry message of a loaded vehicle. If the unloading point of the loaded vehicle is on this lane, then use the vehicle ID as the message identifier to push the vehicle message to the vehicle Actor (if the vehicle Actor instance does not exist, then add one and mark and activate it with the vehicle ID). The vehicle message includes, but is not limited to: vehicle ID, lane ID, actual / expected entry time, vehicle characteristics, driving path, and disabled flag.

[0174] S1.2.2.1.3, End this event;

[0175] S1.2.2.2 defines the event triggered when a task message is received. If an external system adds a new task or the task status changes, it pushes a task message to the Actor in the lane where the loading point is located to trigger the execution of this event. The task message includes, but is not limited to: task ID, loading lane ID, loading point ID, unloading lane ID, unloading point ID, task status, loading time window, cargo type, and condition judgment plugin ID (used to load the plugin pointed to by the ID and call the API interface to determine whether the vehicle meets the conditions).

[0176] S1.2.2.2.1, Retrieve the task ID and task status from the task message;

[0177] S1.2.2.2.2, if the task ID does not exist in the task ID list, then:

[0178] S1.2.2.2.2.1, Add a new task Actor instance and mark and activate it with the task ID;

[0179] S1.2.2.2.2.2, Add the task ID to the task ID list;

[0180] S1.2.2.2.3, Use the task ID as the message identifier to push the task message to the task Actor;

[0181] S1.2.2.2.4 If the task status is completed / cancelled, then delete the task ID from the task ID list;

[0182] S1.2.2.2.5, End this event;

[0183] S1.3, define the task actor, which is responsible for adding new instances and marking and activating them with task IDs:

[0184] S1.3.1 defines the attributes of the task actor. These attributes are initialized by retrieving data from the database when the task actor is activated by the managed service, and written to the database when there are updates:

[0185] S1.3.1.1, Define task messages, used to store received task messages;

[0186] S1.3.1.2 defines the ID of the bipartite graph to which the task belongs, which is used to store the ID of the bipartite graph Actor. It will be filled when the corresponding bipartite graph is found, and updated when the graph is split or merged.

[0187] S1.3.1.3 defines a dictionary table for associated messages, which is used to store the associated messages of vehicles that are related to this task. The messages are accessed by key-value pairs (key=vehicle ID, value=associated message). The associated messages include, but are not limited to: task ID, vehicle ID, estimated empty driving time, estimated total driving time, list of bipartite map IDs to which the vehicle belongs, and bipartite map ID to which the task belongs.

[0188] S1.3.1.4 defines the time for finding the belonging bipartite graph, used to determine whether it is necessary to start searching for the belonging bipartite graph;

[0189] S1.3.2, Methods for defining task actors:

[0190] S1.3.2.1 defines a method for removing vehicles, which is provided for the vehicle Actor to call:

[0191] S1.3.2.1.1, Retrieve the vehicle ID from the input parameters;

[0192] S1.3.2.1.2, use the vehicle ID as the key to delete the key-value pair in the dictionary table of associated messages;

[0193] S1.3.2.1.3, End of this method;

[0194] S1.3.3 defines the events for the task actor, which begin subscribing to messages identified by the task ID when the task actor is activated by the hosting service:

[0195] S1.3.3.1 defines the event triggered when a task message is received. This event is triggered by the task message forwarded from the external system by the lane actor.

[0196] S1.3.3.1.1, Retrieve the task status from the task message and perform a judgment:

[0197] S1.3.3.1.1.1, If ​​the task status is pending assignment, broadcast the task message to the vehicle Actor and try to find the relationship with this task;

[0198] S1.3.3.1.1.2, if the task status is in progress / completed / cancelled, it will no longer participate in dynamic matching:

[0199] S1.3.3.1.1.2.1, asynchronously call the task removal method of the bipartite graph Actor marked with the corresponding bipartite graph ID, pass in the task ID, and organize the association relationship;

[0200] S1.3.3.1.1.2.2, Traverse the dictionary table of associated messages, asynchronously call the vehicle Actor marked with vehicle ID to remove the task method, pass in the task ID, and organize the association relationship;

[0201] S1.3.3.1.1.2.3, assign an empty value to the ID attribute of the corresponding bipartite graph;

[0202] S1.3.3.1.1.2.4 Clear the dictionary table attribute values ​​of the associated messages;

[0203] S1.3.3.1.2, assign the task message attribute to the received task message;

[0204] S1.3.3.1.3, End this event;

[0205] S1.3.3.2 defines the event triggered when an associated message is received. This event is triggered by an associated message pushed by a vehicle Actor that is associated with this task.

[0206] S1.3.3.2.1 If the task status is in progress / completed / cancelled, then the following steps will not be continued;

[0207] S1.3.3.2.2, Extract the vehicle ID from the received association message;

[0208] S1.3.3.2.3, use the vehicle ID as the key to find the associated message in the dictionary table of associated messages, and compare it with the received associated message. If no difference is found, the following steps are not continued.

[0209] S1.3.3.2.4, use the vehicle ID as the key to refresh the received associated messages to the dictionary table of associated messages;

[0210] S1.3.3.2.5, Determine if the ID attribute value of the corresponding bipartite graph is empty:

[0211] S1.3.3.2.5.1, if so, will assign the time attribute of the search for the corresponding bipartite graph to the current time and start the timer for searching the corresponding bipartite graph;

[0212] S1.3.3.2.5.2, otherwise, fill the bipartite graph ID attribute value into the bipartite graph ID of the associated message task, and then use the vehicle ID as the message identifier to push the filled associated message to the vehicle Actor;

[0213] S1.3.3.2.6, End this event;

[0214] S1.3.4 defines a timer for the task Actor. The Actor activates itself to execute a preset process at regular intervals according to the set timer period, avoiding unnecessary consumption and performance bottlenecks caused by frequent calculations.

[0215] S1.3.4.1 defines a timer for finding the corresponding bipartite graph, with a default timeout of 200 milliseconds:

[0216] S1.3.4.1.1, compare the current time to find the time of the corresponding bipartite graph. If the difference is lower than the set threshold (default is 400 milliseconds), it means that it is continuously receiving the associated messages of N vehicle actors, which need to be accumulated and will not be processed for the time being. Ignore this cycle.

[0217] S1.3.4.1.2, Traverse the dictionary table of related messages, find the bipartite graph ID that appears most frequently in the list of bipartite graph IDs to which the vehicle belongs (indicating that this bipartite graph contains all or most of the related vehicles), and then identify it as the bipartite graph to which this task belongs, and fill the bipartite graph ID into the attribute of the corresponding bipartite graph.

[0218] S1.3.4.1.3 If no corresponding bipartite graph is found, a new bipartite graph Actor instance is created and marked and activated with the bipartite graph ID. This instance is the corresponding bipartite graph for this task, and the bipartite graph ID is populated into the corresponding bipartite graph ID attribute.

[0219] S1.3.4.1.4, traverse the dictionary table of related messages, fill the bipartite graph ID attribute value into the bipartite graph ID of the task to which the related message belongs, and then use the vehicle ID as the message identifier to push the filled related message to the vehicle Actor;

[0220] S1.3.4.1.5, Turn off the timer;

[0221] S1.4, Define the vehicle Actor, map all vehicle instances at the dock to vehicle actors and mark them with vehicle IDs;

[0222] S1.4.1 defines the attributes of the vehicle Actor. These attributes are initialized by retrieving data from the database when the vehicle Actor is activated by the managed service, and written to the database when there are updates:

[0223] S1.4.1.1 defines vehicle messages, which are used to store received vehicle messages;

[0224] S1.4.1.2 defines a list of bipartite graph IDs to which the vehicle belongs, which stores the IDs of the bipartite graph Actors to which the vehicle belongs. This list is updated when performing association tasks, graph splitting, or graph merging. When the number of IDs exceeds one, it means that the vehicle is a redundant vertex (it has clone vertices in these bipartite graphs).

[0225] S1.4.1.3 defines a dictionary table for associated messages, which stores key-value pairs (key=task ID, value=associated message) of associated or associatable tasks. The value is the associated message returned after being processed by the task Actor. When it is empty, it represents a task that can be associated but is not associated.

[0226] S1.4.1.4 defines the matched task ID, which stores the IDs of the matched task Actors;

[0227] S1.4.2, Method for defining vehicle Actors:

[0228] S1.4.2.1 defines a method for removing tasks, which is provided for the task actor to call:

[0229] S1.4.2.1.1, Retrieve the task ID from the input parameters;

[0230] S1.4.2.1.2, use the task ID as the key to delete the key-value pair in the dictionary table of the associated message;

[0231] S1.4.2.1.3, End this method;

[0232] S1.4.2.2 defines a method for confirming the best match, which is provided to the bipartite graph Actor that is to perform the matching task:

[0233] S1.4.2.2.1, Extract the ID of the task to be matched from the input parameters;

[0234] S1.4.2.2.2 If the value of the matched task ID attribute is empty, then the ID of the task to be matched is filled into the matched task ID attribute;

[0235] S1.4.2.2.3, If the matched task ID attribute value is different from the task ID to be matched, then the matching conflict is resolved:

[0236] S1.4.2.2.3.1, use the ID of the task to be matched as the key to find the associated message from the dictionary table of associated messages as the associated message to be matched;

[0237] S1.4.2.2.3.2, use the matched task ID as the key to find the associated message from the dictionary table of associated messages and use it as the matched associated message;

[0238] S1.4.2.2.3.3, Determine if there is an external matching rule plugin:

[0239] S1.4.2.2.3.3.1, if applicable, the proposed matching association message and the already matched association message will be passed to the plugin, which will then select the best matching task ID;

[0240] S1.4.2.2.3.3.2, if none, the associated message with the shortest expected empty driving time will be selected by default between the associated message to be matched and the associated message that has been matched. If the matched task is associated with only one vehicle, it will be selected first, and its task ID will be used as the best matching task ID.

[0241] S1.4.2.2.3.4, if the selected task ID is the one intended to be matched, then:

[0242] S1.4.2.2.3.4.1, fill the ID of the task to be matched into the attribute of the matched task;

[0243] S1.4.2.2.3.4.2, If the bipartite graph IDs to which the old and new matching tasks belong are different, the best matching method of the bipartite graph Actor marked by the bipartite graph ID to which the old matching task belongs is called asynchronously, and the vehicle ID is passed in to pause the matching of this vehicle and find the best match again based on other vehicles;

[0244] S1.4.2.2.4 returns the value of the matched task ID attribute;

[0245] S1.4.2.2.5, End of this method;

[0246] S1.4.3 defines the events for the vehicle Actor, which begin subscribing to messages identified by the vehicle's ID and broadcast task messages when the vehicle Actor is activated by the managed service:

[0247] S1.4.3.1 defines an event triggered when a vehicle message is received. This event is triggered by vehicle messages filtered and forwarded from external systems by the lane actor.

[0248] S1.4.3.1.1, Determine if a disabled flag exists in the vehicle message; if yes:

[0249] S1.4.3.1.1.1 Find the task IDs in the dictionary table of related messages where the value of the key-value pair is not empty (i.e., there is a relationship), asynchronously call the task Actor marked by the task ID to remove the vehicle method, pass in the vehicle ID, and sort out the relationship;

[0250] S1.4.3.1.1.2, assign the value of the key-value pair in the dictionary table of the associated message to empty, and remove the association relationship;

[0251] S1.4.3.1.1.3, iterate through the list of bipartite graph IDs, asynchronously call the bipartite graph Actor's "Remove Vehicle" method marked by the bipartite graph ID, pass in the vehicle ID, and organize the association relationships;

[0252] S1.4.3.1.1.4, clear the attribute values ​​of the ID list of the corresponding bipartite graph;

[0253] S1.4.3.1.1.5, assign the vehicle message attribute to the received vehicle message;

[0254] S1.4.3.1.1.6, do not continue with the following steps;

[0255] S1.4.3.1.2, traverse the dictionary table of associated messages, asynchronously and remotely obtain the task actor task message attribute value marked by the task ID, extract the condition judgment plugin ID from the task message, if the plugin ID is not empty, load the plugin pointed to by the ID and call the API interface to pass in the vehicle message and task message, the return result is that the vehicle has the conditions to obtain the task, or if the plugin ID is empty, use the fastest driving path search method to estimate the estimated empty driving time and the estimated total driving time, and determine whether it can reach the loading point within the time window specified by the task:

[0256] S1.4.3.1.2.1 initializes the associated messages with the task message, vehicle message, list of the corresponding bipartite graph IDs, and the estimated empty driving time and estimated total driving time, and pushes the associated messages to the task Actor using the task ID as the message identifier;

[0257] S1.4.3.1.2.2, otherwise, if the key-value pair value is not empty (i.e., there is an association):

[0258] S1.4.3.1.2.2.1, asynchronously call the task Actor marked with the task ID to remove the vehicle method, pass in the vehicle ID, and organize the association relationship;

[0259] S1.4.3.1.2.2.2, asynchronously call the vehicle removal method of the bipartite graph Actor marked by the task's ID, pass in the vehicle ID, and organize the association relationships;

[0260] S1.4.3.1.2.2.3, assigns an empty value to the key-value pair, thus breaking the association;

[0261] S1.4.3.1.3, assign the vehicle message attribute to the received vehicle message;

[0262] S1.4.3.1.4, End this event;

[0263] S1.4.3.2 defines the event triggered when a task message is received. The task actor broadcasts the task message to be assigned to trigger the execution of this event:

[0264] S1.4.3.2.1, retrieve the condition judgment plugin ID from the task message. If the ID is not empty, load the plugin pointed to by the ID and call the API interface to pass in the vehicle message and task message. If the return result is that the vehicle does not meet the conditions to obtain the task, then do not continue the following steps.

[0265] S1.4.3.2.2, retrieve the task ID from the task message, and add a key-value pair to the dictionary table of the associated message using the task ID as the key;

[0266] S1.4.3.2.3 If a disabled flag is present in the vehicle message, the following steps will not be continued;

[0267] S1.4.3.2.4, Based on task messages and vehicle messages, the estimated empty driving time and estimated total driving time are estimated using the fastest driving route search method. If the loading point cannot be reached within the time window specified in the task, the following steps will not be continued.

[0268] S1.4.3.2.5 Initialize the associated messages with task messages, vehicle messages, the list of IDs of the corresponding bipartite graph, and the estimated empty driving time and estimated total driving time. Push the associated messages to the task actor using the task ID as the message identifier.

[0269] S1.4.3.2.6, End this event;

[0270] S1.4.3.3 defines an event triggered when a related message is received. The task actor processes the related message and then sends it back to trigger the execution of this event.

[0271] S1.4.3.3.1 If a disabled flag is present in the vehicle message, the following steps will not be continued;

[0272] S1.4.3.3.2, extract the task ID and the bipartite graph ID to which the task belongs from the received association message;

[0273] S1.4.3.3.3, use the task ID as the key to refresh the received associated messages to the associated message dictionary table;

[0274] S1.4.3.3.4 If the bipartite graph ID to which the task belongs does not exist in the list of bipartite graph IDs, then add it to the list of bipartite graph IDs and traverse the dictionary table of related messages to refresh the list of bipartite graph IDs to which the vehicle belongs.

[0275] S1.4.3.3.5, use the bipartite graph ID to which the task belongs as the message identifier, push the vehicle ID, and provide the dictionary table of associated messages to the bipartite graph Actor;

[0276] S1.4.3.3.6, End this event;

[0277] S1.5 defines a bipartite graph Actor. A bipartite graph Actor that has undergone a natural split or graph partitioning operation, or a task Actor that has not found its own bipartite graph, is responsible for adding instances and marking and activating them with the bipartite graph ID. The bipartite graph ID is taken from a distributed ID generation algorithm (such as Snowflake algorithm):

[0278] S1.5.1 defines the properties of the bipartite graph Actor. These properties are initialized by retrieving data from the database when the bipartite graph Actor is activated by the managed service, and written to the database when there are updates.

[0279] S1.5.1.1, Define a dictionary table for vehicle association messages, which is used to store the dictionary table of the received vehicle Actor association messages, and access them by key-value pairs (key=vehicle ID, value=dictionary table of vehicle association messages).

[0280] S1.5.1.2 defines the latest change time of the association relationship, which is used to process the timer for changes in the association relationship;

[0281] S1.5.1.3 defines the merged bipartite graph ID, which is used to store the IDs of the actors that have been merged and migrated into the bipartite graph;

[0282] S1.5.1.4 defines a list of vehicle IDs to be temporarily suspended from matching, which is used to store vehicle IDs that are not currently participating in the best matching;

[0283] S1.5.1.5 defines the matched results, which are used to store the task ID array and vehicle ID array of the matched relationships;

[0284] S1.5.2, Method for defining a bipartite graph Actor:

[0285] S1.5.2.1 defines a method for removing vehicles, which is provided to the vehicle Actor for calling:

[0286] S1.5.2.1.1, Retrieve the vehicle ID from the input parameters;

[0287] S1.5.2.1.2, use the vehicle ID as the key to delete the key-value pair in the dictionary table of vehicle-related messages;

[0288] S1.5.2.1.3, assign the latest change time attribute of the association relationship to the current time;

[0289] S1.5.2.1.4, Start the timer for handling changes in association relationships;

[0290] S1.5.2.1.5, End of this method;

[0291] S1.5.2.2 defines a method for removing tasks, which is provided for the task actor to call:

[0292] S1.5.2.2.1, Retrieve the task ID from the input parameters;

[0293] S1.5.2.2.2, Traverse the dictionary table of vehicle-related messages and delete key-value pairs in the dictionary table of related messages using the task ID as the key;

[0294] S1.5.2.2.3, assign the latest change time attribute of the association relationship to the current time;

[0295] S1.5.2.2.4, Start the timer for handling changes in association relationships;

[0296] S1.5.2.2.5, End of this method;

[0297] S1.5.2.3 defines the method for confirming the merging, which is provided to the bipartite graph Actor for calling:

[0298] S1.5.2.3.1, retrieve the fitted bipartite graph ID from the input parameters;

[0299] S1.5.2.3.2, Determine if the ID attribute value of the merged bipartite graph is empty:

[0300] S1.5.2.3.2.1, if so, assign the merged bipartite graph ID attribute to the fitted bipartite graph ID, and return the dictionary table of the current vehicle association messages (i.e., the dictionary table of vehicle association messages to be merged).

[0301] S1.5.2.3.2.2, otherwise the result will be empty (indicating that it was merged by another bipartite graph first);

[0302] S1.5.2.3.3, End of this method;

[0303] S1.5.2.4 defines a method to cancel the best match, which is provided to the vehicle Actor that resolves the matching conflict:

[0304] S1.5.2.4.1, Add the incoming vehicle ID to the list of suspended matching vehicle IDs;

[0305] S1.5.2.4.2, assign the latest change time attribute of the association relationship to the current time;

[0306] S1.5.2.4.3, Start the timer for handling changes in association relationships;

[0307] S1.5.2.4.4, End of this method;

[0308] S1.5.3 defines the events for a bipartite graph Actor. These events begin subscribing to messages identified by the bipartite graph ID, as well as broadcast merge request messages, when the bipartite graph Actor is activated by the managed service.

[0309] S1.5.3.1 defines an event triggered when a vehicle association message is received, which is pushed by the vehicle Actor whose association relationship has changed to trigger the execution of this event:

[0310] S1.5.3.1.1, extract the vehicle ID and the dictionary table of associated messages from the incoming message;

[0311] S1.5.3.1.2, use the vehicle ID as the key to refresh the dictionary table of associated messages to the dictionary table of vehicle associated messages;

[0312] S1.5.3.1.3, assign the latest change time attribute of the association relationship to the current time;

[0313] S1.5.3.1.4, Start the timer for handling changes in association relationships;

[0314] S1.5.3.1.5, End this event;

[0315] S1.5.3.2 defines an event triggered when a merge request message is received. This event is triggered by the bipartite graph Actor that needs to be merged broadcasting the merge request message.

[0316] S1.5.3.2.1, Extract the dictionary table of the bipartite graph ID to be merged and the vehicle association messages to be merged from the merge request message;

[0317] S1.5.3.2.2, if the ID of the bipartite graph to be merged is different from the ID of its own bipartite graph, then the determination is made based on the dictionary table of the vehicle association messages to be merged and the dictionary table of its own vehicle association messages:

[0318] S1.5.3.2.2.1 If the number of vertices in the merged graph exceeds a certain threshold (default is 200), or the proportion of shared redundant vertices does not exceed the golden ratio, then the following steps will not be continued.

[0319] S1.5.3.2.2.2, call the bipartite graph Actor with the ID of the bipartite graph to be merged to confirm the merging method, pass in its own bipartite graph ID as the fitting bipartite graph ID, and if the returned result is a dictionary table of vehicle association messages to be merged, then merge the dictionary table of vehicle association messages to be merged into its own vehicle association message dictionary table, and update the bipartite graph ID attribute of the task Actor and the bipartite graph ID list attribute of the vehicle Actor;

[0320] S1.5.3.2.3, End this event;

[0321] S1.5.4 defines a timer for the bipartite graph Actor. The Actor activates itself to execute a preset process at regular intervals according to the set timer period, avoiding unnecessary consumption and performance bottlenecks caused by frequent calculations.

[0322] S1.5.4.1 defines a timer for handling changes in association relationships, with a default timer period of 200 milliseconds:

[0323] S1.5.4.1.1, compare the current time with the latest change time of the association relationship. If the difference is lower than the set threshold (default is 400 milliseconds), it means that N vehicle association messages of vehicle actors are being received continuously. It needs to continue to accumulate and will not be processed for the time being. Ignore this cycle.

[0324] S1.5.4.1.2, traverse the dictionary table of vehicle association messages, ignore the vehicle IDs in the list of paused matching vehicle IDs, use the vehicle ID and task ID as two sets of vertices of the weighted bipartite graph, use the key-value pairs of task ID and vehicle ID as the edges of the weighted bipartite graph, and use the negative of their expected empty driving time as the weight of the edges to construct the adjacency matrix of the weighted bipartite graph.

[0325] S1.5.4.1.3 uses the disjoint-set data structure to find a new graph that has naturally split in the bipartite graph. If found, a graph migration operation is performed based on the task ID list and vehicle ID list of the new graph.

[0326] In version S1.5.4.1.3.1, a new bipartite graph Actor is added and marked and activated using the new bipartite graph ID;

[0327] S1.5.4.1.3.2, migrate the dictionary table of vehicle association messages of the new graph from the dictionary table of the current bipartite graph Actor vehicle association messages, and populate it into the dictionary table of the new bipartite graph Actor vehicle association messages. During the migration process, update the bipartite graph ID of the task and the list of bipartite graph IDs of the vehicle in the dictionary table, as well as update the bipartite graph ID attribute of the task Actor and the list of bipartite graph IDs of the vehicle Actor.

[0328] S1.5.4.1.4, if the vertex size of the weighted bipartite graph to be constructed exceeds a certain threshold (default is 200), then a graph partitioning operation is performed:

[0329] S1.5.4.1.4.1, Find redundant vertices and find the task ID list and external vehicle ID list of the new graph:

[0330] S1.5.4.1.4.1.1, using the task ID array (i.e. the matched task) in the matched result attribute, extract and convert it into a dictionary table of task-related messages (key=task ID, value=dictionary table of task-related messages).

[0331] S1.5.4.1.4.1.2, iterate through the dictionary table of task-related messages, by default iterating from shortest to longest according to the estimated total travel time, or calling the external sorting rule plugin embedded in the bipartite graph Actor for traversal:

[0332] S1.5.4.1.4.1.3.1, Add the task ID to the task ID list;

[0333] S1.5.4.1.4.1.3.2, traversing to the... Step index in When the interval is within the range, find the vehicles that are associated with the tasks in the task ID list in the dictionary table of vehicle association messages, and then find the vehicles that are associated with other tasks that are not in the task ID list. Combine these vehicle IDs into an external vehicle ID list.

[0334] S1.5.4.1.4.1.4, during the traversal, the smallest list of external vehicle IDs is retained after comparison. When the size of the external vehicle ID list is 0 or 1, or when the traversal reaches the end of the interval, the external vehicle ID list is the segmentation boundary to be found.

[0335] S1.5.4.1.4.2, cut redundant vertices and construct a new graph:

[0336] Version S1.5.4.1.4.2.1 adds a new bipartite graph Actor and marks and activates it with the new bipartite graph ID;

[0337] S1.5.4.1.4.2.2, based on the task ID list and external vehicle ID list of the new graph, migrate the dictionary table of vehicle association messages of the new graph from the dictionary table of the current bipartite graph Actor vehicle association messages, and populate it into the dictionary table of the new bipartite graph Actor vehicle association messages. During the migration process, the vehicle IDs belonging to the external vehicle ID list are cloned into the dictionary table, and the relevant task-to-bipartite graph ID and vehicle-to-bipartite graph ID list in the dictionary table are updated, as well as the task Actor-to-bipartite graph ID attribute and vehicle Actor-to-bipartite graph ID list attribute are updated.

[0338] S1.5.4.1.5 If the number of vertices in the weighted bipartite graph to be constructed is less than a certain threshold (76 by default), then attempt to perform a graph merging operation, broadcasting a merge request message to other bipartite graph actors using its own bipartite graph ID and the dictionary table of vehicle association messages, and no longer continuing the following steps;

[0339] S1.5.4.1.6 uses the Kuhn-Munkres algorithm to find the best matching result from the constructed weighted bipartite graph adjacency matrix, which contains an array of task IDs and an array of vehicle IDs;

[0340] S1.5.4.1.7, if there are differences between the attribute values ​​of the best match and the already matched results, then:

[0341] S1.5.4.1.7.1, iterate through the best matching results, find the matching relationships that differ, call the vehicle Actor marked by the vehicle ID to confirm the best matching method, and pass in the task ID (the task ID to be matched). If the returned result (the matched task ID) is inconsistent with the task ID to be matched, add the vehicle ID to the list of paused matching vehicle IDs and start executing this timer from the beginning.

[0342] S1.5.4.1.7.2, using the matching relationships that identify differences, publish matching messages to external systems, the content of which includes but is not limited to: task ID, vehicle ID, estimated empty driving time, and estimated total driving time;

[0343] S1.5.4.1.7.3, assign the attribute of the matched result to the best matching result;

[0344] S1.5.4.1.8, Clear the list of paused vehicle ID matching attributes;

[0345] S1.5.4.1.9, Turn off the timer;

[0346] S2, Subscribe to and receive vehicle messages:

[0347] S2.1, triggering events for intersection Actor and lane Actor when they receive a message of an actual / expected vehicle entering, or when they receive a message of an actual vehicle exiting;

[0348] S2.2, dynamically refresh the list of density fluctuation time sequence records and feature combination count records of intersection Actors and lane Actors, providing spatiotemporal data and statistical data for the fastest driving path search method;

[0349] S2.3 For the lane actor, if the received message is an actual vehicle entering the lane for an empty vehicle, or an actual / expected vehicle entering the lane for a loaded vehicle, and the unloading point of the loaded vehicle is in this lane, then if the driving situation deviates from the previous prediction, the vehicle message will be pushed to the vehicle actor (if the vehicle actor instance does not exist, a new one will be created and marked and activated with the vehicle ID).

[0350] S3, subscribe to and receive task messages:

[0351] S3.1, triggers the event when the lane actor receives a task message;

[0352] S3.2, If it is a new task, add a new task Actor instance and mark and activate it with the task ID;

[0353] S3.3, push the task message to the task actor;

[0354] S4, clarify the relationship and weight between tasks and vehicles in the distributed architecture:

[0355] S4.1, Messages and events related to the Task Actor and Vehicle Actor:

[0356] S4.1.1, the task actor subscribes to and receives task messages from the lane actor, triggering the task actor's event when it receives a task message;

[0357] S4.1.2, the vehicle actor subscribes to and receives task messages from the task actor, triggering the vehicle actor's event when it receives a task message;

[0358] S4.1.3, the task actor subscribes to and receives associated messages from the vehicle actor, triggering the task actor's event when it receives an associated message;

[0359] S4.1.4, Vehicle Actor subscribes to and receives vehicle messages from Lane Actor, triggering events for Vehicle Actor when a vehicle message is received;

[0360] S4.2, If the task status is pending assignment:

[0361] S4.2.1, the task actor broadcasts the task message to the vehicle actor;

[0362] S4.2.2 After receiving the task message, all vehicle actors determine whether they are not disabled and have the conditions to obtain the task. If so, they use the fastest driving path search method to estimate the estimated empty driving time and the estimated total driving time.

[0363] S4.2.3 Based on the estimated total travel time and its own driving conditions, the vehicle Actor assesses whether it can reach the loading point within the task-specified time window. If so, it initializes the association message and feeds it back to the task Actor to form an association relationship. After the task Actor confirms and provides the corresponding bipartite graph, it pushes the message to the bipartite graph Actor to register the association relationship.

[0364] S4.3 If the task status is in progress / completed / cancelled, it will no longer participate in dynamic matching. The task Actor will remotely call the remove task method of the relevant vehicle Actor and bipartite graph Actor to remove the association.

[0365] S4.4 If a vehicle is disabled, it will no longer participate in dynamic matching. The vehicle Actor will remotely call the vehicle removal method of the relevant task Actor and bipartite graph Actor to sever the association.

[0366] S4.5, If the vehicle's driving conditions deviate, the vehicle actor will reassess the correlation:

[0367] S4.5.1 If there is a new association with a task, the association message is initialized and pushed to the task actor to form an association. After the task actor confirms and provides the bipartite graph to which it belongs, it is then pushed to the bipartite graph actor to register the association.

[0368] S4.5.2 If the relationship with a task changes (e.g., the weight value changes), the updated relationship message will be pushed to the task Actor and the bipartite graph Actor to synchronize the data.

[0369] S4.5.3 If the association with a task can no longer be maintained, the vehicle removal method of the task Actor and the bipartite graph Actor is remotely invoked to sever the association.

[0370] S5 is a weighted bipartite graph consisting of tasks and vehicles, with weights being the negative of the expected idle time.

[0371] S5.1, the new task is for the Actor to find the bipartite graph with the most concentrated associations and add it. If it cannot be found, a new bipartite graph Actor is added. The new bipartite graph Actor is marked and activated with a bipartite graph ID, which is taken from a distributed ID generation algorithm.

[0372] S5.2 After the bipartite graph Actor senses a change in the relationship, it forms two sets of vertices in the weighted bipartite graph using the vehicles that are not disabled and the tasks to be assigned / assigned. It uses their relationship as the edges and the negative of their expected empty driving time as the edge weights to construct the adjacency matrix of the weighted bipartite graph.

[0373] S6 dynamically controls and adjusts the number and size of graphs through graph partitioning and graph merging methods:

[0374] S6.1 If the number of vertices of the bipartite graph Actor exceeds a certain threshold (default is 200), then a graph splitting operation is performed to find suitable redundant vertices and cut them, the new graph is migrated to a new bipartite graph Actor instance, and the relevant attributes of the task Actor and the vehicle Actor are synchronized.

[0375] S6.2 If the vertex size of a bipartite graph Actor is lower than a certain threshold (default is 76), then attempt to perform a graph merging operation to find another bipartite graph Actor whose vertex size after merging is lower than a certain threshold (default is 200) and whose shared redundant vertex ratio exceeds the golden ratio. After confirmation by the original graph Actor, the original graph is merged into it, and the relevant attributes of the task Actor and vehicle Actor are synchronized.

[0376] S7. Find the best matching in the weighted bipartite graph and resolve matching conflicts using redundant vertices:

[0377] S7.1 After the bipartite graph Actor senses a change in the association relationship, it uses the Kuhn-Munkres algorithm to find the best matching result from the constructed weighted bipartite graph adjacency matrix.

[0378] S7.2, Based on the best matching result, the bipartite graph Actor remotely calls the vehicle Actor's method to confirm the best matching result one by one, so as to finally confirm the matching result;

[0379] S7.3 If the vehicle is a redundant vertex and there is already a matching task, the vehicle Actor uses the method of resolving matching conflicts to leave the best match. Then, the bipartite graph Actor that failed the competition temporarily removes the clone vertex from its respective weighted bipartite graph, finds the best matching result again, and adds the clone vertex back until all matching conflicts are resolved.

[0380] S7.4 compares the changes in the old and new best matching results and publishes the new or changed matching results to the external system by the bipartite graph Actor.

[0381] The above describes how the external system drives the Actor instances deployed in the Actor service container through push messages. These Actor instances then collaboratively process the messages and feed back the final confirmed matching results to the external system.

[0382] Based on the same inventive concept, this application also provides a dock vehicle operation nearby connection device, comprising:

[0383] The model building and deployment module is used to map the dock road network structure, operating vehicles, tasks, and the matching relationship between tasks and operating vehicles into Actor instances based on the Actor distributed parallel computing model, and deploy them into the Actor service container.

[0384] The subscription receiving module is used to subscribe to event messages through the Actor instance to update the status of the corresponding Actor and refresh the spatiotemporal data and statistics of the working vehicle in the road network;

[0385] The association establishment module is used to dynamically predict the estimated arrival time of each work vehicle to the target loading point using the fastest travel path search method; and when the estimated arrival time meets the task loading time window, establish the association between the work vehicle and the task, and assign a weight value to each association.

[0386] The weighted bipartite graph management module is used to construct one or more weighted bipartite graphs with vehicles and tasks as vertices, the relationships as edges, and the weights of the relationships as the weights of the edges, and to manage the size of the weighted bipartite graphs. The size of the weighted bipartite graphs includes: performing graph splitting operations when the vertex size of the graph exceeds a first threshold, and performing graph merging operations when the vertex size of the graph is lower than a second threshold, so as to control the size of the graph.

[0387] The conflict resolution module is used to solve the maximum weight matching problem for each weighted bipartite graph to obtain the initial matching result; and to resolve the matching conflicts that occur during the solution process to obtain the final matching result.

[0388] The optimization module is used to publish the final matching results, and when changes in the status of the work vehicle or the task are detected, or when a new task or a new vehicle appears, it re-invokes the association establishment module, the weighted bipartite graph management module, and the conflict resolution module to achieve dynamic real-time optimization of task allocation.

[0389] In some embodiments, the association establishment module further includes: an estimated total travel time generation module;

[0390] The estimated total travel time generation module is configured as follows:

[0391] When the work vehicle is an idle vehicle, the estimated travel time from the current location of the work vehicle to the target loading point is taken as the estimated total travel time and the estimated empty travel time.

[0392] When the work vehicle is a heavy-duty vehicle performing a task, the sum of the estimated remaining travel time from the current location of the work vehicle to the current task unloading point, the estimated unloading time to complete the unloading operation at the current task unloading point, and the estimated empty travel time from the current task unloading point to the target loading point is taken as the estimated total travel time, wherein the estimated empty travel time is the estimated empty driving time.

[0393] This invention utilizes the fastest travel path search method to predict which vehicles with the necessary conditions to obtain tasks can reach the loading point within the task's specified time window. It establishes many-to-many / one-to-many / one-to-one relationships between multiple tasks and vehicles, using the negative of the expected empty-run time as the weight of each relationship. The Kuhn-Munkres algorithm is then used to find the optimal match in the resulting weighted bipartite graph. Addressing the performance bottleneck encountered by the Kuhn-Munkres algorithm when processing large-scale data, this invention, based on distributed graph partitioning and disjoint-set data structure, devises a method for graph partitioning and merging to dynamically control and adjust the number and size of the graph. The invention also employs a conflict resolution method to address the problem of redundant vertices being designated as optimal matches by multiple graphs. This allows the invention to handle large-scale vehicle task optimal matching and proximity-based job connection problems in real-time, with high performance and accuracy, and is sufficient to support various large-scale traditional or automated transformation dock on-site production operation scenarios.

[0394] The vehicles that can be assigned tasks according to this invention include all vehicles that are currently not assigned a task, have not yet performed a task, or are about to complete a task. Both heavily loaded and unloaded vehicles can participate in task assignment as long as they can arrive at the loading point within the time window.

[0395] This invention utilizes the fastest travel path search method, using the estimated empty driving time and estimated total travel time as dynamic weights for finding and selecting the best match, dynamically adjusting the relationship between vehicles and tasks, and achieving the effect of continuously finding more suitable matching relationships.

[0396] This invention is based on the Actor distributed parallel computing model, which builds a weighted bipartite graph structure and bipartite graph Actor under a distributed architecture. When redundant vertices are identified as the best match by multiple graphs, the method for resolving matching conflicts proposed in this invention can be used to resolve the problem. This allows the Kuhn-Munkres algorithm to still be applied when processing large-scale data, and to find the best match quickly and efficiently by dividing and conquering.

[0397] Based on distributed graph partitioning technology, disjoint-set data structure technology, and insights into the characteristics of port production operations, this invention devises a method for graph partitioning and merging, which can dynamically control and adjust the number and scale of graphs.

[0398] In this specification, the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the descriptions of the embodiments described later are relatively simple, and relevant parts can be referred to the descriptions of the foregoing embodiments.

[0399] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for nearby connection of dock vehicle operations, characterized in that, include: Step S1: Map the dock road network structure, operating vehicles, tasks, and the matching relationship between tasks and operating vehicles to Actor instances based on the Actor distributed parallel computing model, and deploy them to the Actor service container. Step S2: Subscribe to event messages through the Actor instance to update the status of the corresponding Actor and refresh the spatiotemporal data and statistics of the working vehicle in the road network; Step S3: Using the fastest travel path search method, dynamically predict the estimated arrival time of each work vehicle to the target loading point; and when the estimated arrival time meets the task loading time window, establish the association between the work vehicle and the task, and assign a weight value to each association. The dynamic prediction of the estimated arrival time of each work vehicle to the target loading point includes: determining the estimated empty-run time based on the current status of the work vehicle, including: If the work vehicle is an idle vehicle, the estimated empty driving time includes: the estimated driving time from the current location of the work vehicle to the target loading point; If the work vehicle is a heavy-duty vehicle that is performing a task, the estimated empty driving time includes: the estimated driving time from the current unloading point of the work vehicle to the target loading point; Step S4: Construct one or more weighted bipartite graphs with vehicles and tasks as vertices, the relationships as edges, and the weights of the relationships as the edge weights, and manage the size of the weighted bipartite graphs. The size of the weighted bipartite graphs includes: performing graph splitting when the vertex size of the graph exceeds a first threshold, and performing graph merging when the vertex size of the graph is lower than a second threshold, so as to control the size of the graph. Step S5: Solve the maximum weight matching problem for each weighted bipartite graph to obtain the initial matching result; and resolve the matching conflicts that occur during the solution process to obtain the final matching result; Step S6: Publish the final matching result, and repeat steps S3 to S5 when the status of the work vehicle or the task status changes or a new task or a new vehicle appears, so as to achieve dynamic real-time optimization of task allocation.

2. The method for nearby connection of dock vehicle operations according to claim 1, characterized in that, Mapping the wharf road network structure to Actor instances includes mapping lanes in the wharf road network to lane Actors for the fast-moving path search method, and extending the properties of the lane Actors, including: Add a new unloading operation feature to the properties of the lane actor to calculate the estimated unloading time. The unloading operation feature includes at least: unloading point identification and cargo type. The lane actor is configured to: based on the unloading operation characteristics in the received vehicle messages and combined with the current unloading point density data, obtain the estimated unloading time required for a heavy-duty vehicle to complete the unloading operation at the lane unloading point.

3. The method for nearby connection of dock vehicle operations according to claim 1, characterized in that, In step S4, when the vertex size of the graph exceeds a first threshold, a graph segmentation operation is performed, based on a vertex cutting or edge differentiation strategy, including: The tasks with established relationships in the current weighted bipartite graph are sorted according to a preset sorting condition to generate a task sequence; wherein, the preset sorting condition is based on the estimated total travel time of the associated vehicles of the task, sorted from shortest to longest. Traverse within a preset range of the task sequence to gradually construct a subset of tasks; During the traversal, vehicles that are associated with tasks in the task subset and also with tasks outside the task subset are identified, thus obtaining the external vehicle set. During the traversal, the set of external vehicles with the fewest vehicles is retained. When the size of the set of external vehicles is 0 or 1, or when the traversal reaches the end of the preset interval, the set of external vehicles is determined as the graph partition boundary. The vehicle vertices in the external vehicle set are cut as redundant vertices to generate a first clone vertex and a second clone vertex, so that the current weighted bipartite graph is divided into a first subgraph and a second subgraph; wherein, the first subgraph retains the first clone vertex and its association with the remaining task vertices in the original graph; the second subgraph includes the task subset, the second clone vertex and its association; Move the second subgraph to the newly added bipartite graph Actor; The estimated total travel time is determined based on the current status of the work vehicle, including: If the operating vehicle is an idle vehicle, then the estimated total travel time includes: the estimated empty travel time of the idle vehicle; If the work vehicle is a heavy-duty vehicle performing a task, the estimated total travel time includes: the estimated remaining travel time from the current location of the work vehicle to the current task unloading point, the estimated unloading time to complete the unloading operation at the current task unloading point, and the estimated empty travel time of the heavy-duty vehicle.

4. The method for nearby connection of dock vehicle operations according to claim 3, characterized in that, When sorting tasks that have established relationships in the current graph, the preset sorting conditions can be replaced by using an external sorting rule plugin. The sorting rule plugin is embedded into the bipartite graph Actor through a standard interface.

5. The method for nearby connection of dock vehicle operations according to any one of claims 1 or 3, characterized in that, In step S4, when the vertex size of the graph is lower than the second threshold, a graph merging operation is performed, including: When the vertex size of any weighted bipartite graph is lower than the second threshold, the bipartite graph Actor corresponding to the weighted bipartite graph initiates a graph merge request to the other bipartite graph Actors, and selects the merge object that simultaneously meets the following conditions: The size of the merged vertices is no greater than the first threshold, and the proportion of the number of shared redundant vertices to the total number of redundant vertices in the target bipartite graph is greater than the golden ratio. After obtaining confirmation of the target bipartite graph Actor, the initiator's weighted bipartite graph is merged into the target bipartite graph Actor, and the initiator's bipartite graph Actor is released; Synchronously update the bipartite graph attributes of the task actor and vehicle actor.

6. The method for nearby connection of dock vehicle operations according to claim 1, characterized in that, The resolution of matching conflicts includes: According to the preset conflict resolution rules, select one from all the conflicting matching tasks as the final matching task for the work vehicle. The notified bipartite graph actor that the unmatched vertex has cancelled the current matching for the vertex of the work vehicle; Upon receiving the notification, the bipartite graph Actor temporarily removes the clone vertex of the work vehicle vertex from the weighted bipartite graph managed by the bipartite graph Actor, and re-solves for the maximum weight matching. After the solution is completed, the bipartite graph Actor adds the cloned vertices back into the weighted bipartite graph until all matching conflicts are resolved.

7. The method for nearby connection of dock vehicle operations according to claim 6, characterized in that, The preset rules include: Select the matching relationship with the shortest expected empty driving time. If multiple tasks have the same expected total driving time, select the matching relationship with one vehicle associated with the task. Alternatively, a custom matching rule plugin can be used, which is embedded into the vehicle Actor through a pre-defined standard interface.

8. A dock vehicle operation nearby connection device, characterized in that, include: The model building and deployment module is used to map the dock road network structure, operating vehicles, tasks, and the matching relationship between tasks and operating vehicles into Actor instances based on the Actor distributed parallel computing model, and deploy them into the Actor service container. The subscription receiving module is used to subscribe to event messages through the Actor instance to update the status of the corresponding Actor and refresh the spatiotemporal data and statistics of the working vehicle in the road network; The association establishment module is used to dynamically predict the estimated arrival time of each work vehicle to the target loading point using the fastest travel path search method; and when the estimated arrival time meets the task loading time window, establish the association between the work vehicle and the task, and assign a weight value to each association. The dynamic prediction of the estimated arrival time of each work vehicle to the target loading point includes: determining the estimated empty-run time based on the current status of the work vehicle, including: If the work vehicle is an idle vehicle, the estimated empty driving time includes: the estimated driving time from the current location of the work vehicle to the target loading point; If the work vehicle is a heavy-duty vehicle that is performing a task, the estimated empty driving time includes: the estimated driving time from the current unloading point of the work vehicle to the target loading point; The weighted bipartite graph management module is used to construct one or more weighted bipartite graphs with vehicles and tasks as vertices, the relationships as edges, and the weights of the relationships as the weights of the edges, and to manage the size of the weighted bipartite graphs. The size of the weighted bipartite graphs includes: performing graph splitting operations when the vertex size of the graph exceeds a first threshold, and performing graph merging operations when the vertex size of the graph is lower than a second threshold, so as to control the size of the graph. The conflict resolution module is used to solve the maximum weight matching problem for each weighted bipartite graph to obtain the initial matching result; and to resolve the matching conflicts that occur during the solution process to obtain the final matching result. The optimization module is used to publish the final matching results, and when changes in the status of the work vehicle or the task are detected, or when a new task or a new vehicle appears, it re-invokes the association establishment module, the weighted bipartite graph management module, and the conflict resolution module to achieve dynamic real-time optimization of task allocation.

9. The dock vehicle operation nearby connection device according to claim 8, characterized in that, The association establishment module also includes: an estimated total travel time generation module; The estimated total travel time generation module is configured as follows: When the work vehicle is an idle vehicle, the estimated travel time from the current location of the work vehicle to the target loading point is taken as the estimated total travel time and the estimated empty travel time. When the work vehicle is a heavy-duty vehicle performing a task, the sum of the estimated remaining travel time from the current location of the work vehicle to the current task unloading point, the estimated unloading time to complete the unloading operation at the current task unloading point, and the estimated empty travel time from the current task unloading point to the target loading point is taken as the estimated total travel time, wherein the estimated empty travel time is the estimated empty driving time.

Images