Automobile logistics full-scene agv collaborative scheduling method and system

Abstract

The present application relates to the technical field of automobile intelligent logistics scheduling, in particular to a kind of automobile logistics full scene AGV collaborative scheduling method and system.This scheme obtains target task event after target task event is structured modeling, generates task model, then, obtain the availability information of schedulable resource, so as to match target task in task model with schedulable resource, obtain matching result.Afterwards, according to constraint model, the matching result is constrained joint solution, and the scheduling decision for target task is output, and finally according to the scheduling decision, AGV is driven to target task execution state migration operation.By using the above scheme, a unified scheduling hub is constructed around the whole process of automobile logistics, and the tasks, resources, states and constraints of each scene in the whole process of automobile logistics are modeled into the same semantic space, realizing end-to-end collaborative scheduling and continuous optimization from chain plate offline to departure area.

Description

Technical Field

[0001] This invention relates to the field of intelligent logistics scheduling technology for automobiles, specifically to a collaborative scheduling method and system for AGVs across all scenarios of automobile logistics. Background Technology

[0002] In the automotive logistics sector, AGVs are used to handle transport operations from the production line to the departure area, encompassing multiple scenarios such as in-plant repair areas, inspection areas, delivery areas, sunken tunnels / ramp areas, storage yards, and departure areas. Existing AGV scheduling systems typically model single scenarios or single stages, lacking a unified task model, resource model, state model, and constraint model covering the entire process, making it difficult to form an end-to-end scheduling loop. Furthermore, the lack of unified definitions for task handover events, state codes, temporal semantics, and exception codes between different scenarios leads to asynchronous states and poor scheduling continuity between systems. Simultaneously, existing rule engines typically only support local conflict resolution, making it difficult to coordinate and handle multiple types of constraints such as platform occupancy, path conflicts, passage timing, and parking space resources within the same solution framework, thus failing to achieve collaborative optimization scheduling across all scenarios. Summary of the Invention

[0003] This invention provides a collaborative scheduling method and system for AGVs across all automotive logistics scenarios, which effectively solves the problem that existing automotive logistics scheduling systems cannot achieve collaborative optimization scheduling across all scenarios.

[0004] According to the first aspect, one embodiment provides a collaborative scheduling method for AGVs in a full-scenario automotive logistics process, including: Obtain target task events, perform task structure modeling on the target task events to generate a task model; the task model is used to record at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships; Obtain availability information of schedulable resources; the availability information includes at least one of the following: number, set of serviceable scenarios, current availability status, occupancy status, and capacity limit; The task model is matched with the availability information of the schedulable resources to obtain the matching result; The matching results are subjected to joint constraint solving based on a preset constraint model, and a scheduling decision is output for the target task. The scheduling decision includes at least one of the following: task orchestration result, resource allocation result, and path and timing decision result. The scheduling decision drives the AGV to perform a state transition operation for the target task.

[0005] In one embodiment, driving the AGV to perform a state transition operation on the target task according to the scheduling decision includes: Based on the scheduling decision, the cross-scenario handover node is scheduled in a specific time sequence, and the AGV is driven to reach the cross-scenario handover node for handover. Obtain the feedback information from the cross-scenario handover node, and update the availability information of the schedulable resources based on the feedback information.

[0006] In one embodiment, before driving the AGV to the cross-scene handover node for handover, the method further includes: Determine whether the current occupancy status of the cross-scenario handover node is idle; If so, a time window is reserved for the AGV and locked; otherwise, the current target task is placed in the waiting queue.

[0007] In one embodiment, the feedback information returned by the cross-scenario handover node includes at least one of the following: handover node status information, timeout rollback information, or retry control information; after obtaining the feedback information returned by the cross-scenario handover node, the method further includes: The receipt information is sent back to the preset constraint model, and the receipt information is verified through the preset constraint model to obtain the verification result.

[0008] In one embodiment, the verification result includes verification success or verification failure; When the verification result is successful, the resource occupation status of the completed target task is updated to released, and the next waiting target task is notified that it can initiate a reservation. When the verification result is a verification failure, a timeout rollback mechanism is triggered, the current task status of the target task is rolled back to the pending scheduling state, and the current target task is re-constrained and jointly solved.

[0009] In one embodiment, the preset constraint model includes a rule engine unit, an optimization solver unit, and a conflict resolver unit; the step of performing joint constraint solving on the matching results according to the preset constraint model includes: The rule engine unit sorts the target tasks according to the task priority, allocates usage time periods for mutually exclusive resources, and prohibits issuing access permits to the AGV for handover nodes that have not yet completed their reservations. The optimization solver unit generates an ordered sequence of access permits for the restricted road segment and embeds a corresponding time window for each access permit to ensure that the AGVs do not conflict in time sequence. The conflict resolution unit detects the temporal and spatial occupancy conflicts of each AGV and resolves the occupancy conflicts.

[0010] In one embodiment, after outputting the scheduling decision for the target task, the method further includes: The scheduling decisions are periodically evaluated to obtain evaluation results; The constraint model is updated based on the evaluation results.

[0011] In one embodiment, the periodic evaluation of the scheduling decision to obtain the evaluation result includes: Based on the task orchestration results, resource allocation results, and path and timing decision results, an event log and a state transition chain are generated. The actual statistical values ​​of scheduling performance indicators are aggregated and calculated from the event logs and state transition chains; the actual statistical values ​​include at least the task on-time rate, average waiting time, handover success rate, rescheduling frequency, and anomaly recovery time. The actual statistical value is compared with a preset standard. When the actual statistical value meets the triggering condition of the preset standard, the evaluation conclusion and the cause code are output.

[0012] In one embodiment, updating the constraint model based on the evaluation result includes: Based on the evaluation conclusions and cause coding, policy recommendations containing rule parameters, constraint weights, and policy routing configurations are generated and fed back to the constraint model for updating.

[0013] According to the second aspect, one embodiment provides an AGV collaborative scheduling system for all scenarios of automotive logistics, including: The modeling module is used to acquire target task events and perform task structure modeling on the target task events to generate a task model; the task model is used to record at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships. The resource acquisition module is used to acquire availability information of schedulable resources; the availability information includes at least one of the following: number, set of serviceable scenarios, current availability status, occupancy status, and capacity limit. The matching module is used to match the task model with the availability information of the schedulable resources to obtain a matching result; The joint solution module is used to perform constraint joint solution on the matching results according to the preset constraint model, and output a scheduling decision for the target task; the scheduling decision includes at least one of the following: task orchestration result, resource allocation result, and path and timing decision result; The state transition module is used to drive the AGV to perform state transition operations on the target task based on the scheduling decision.

[0014] According to the above embodiment, a collaborative scheduling method / system for AGVs in a full-scenario automotive logistics process involves obtaining a target task event, performing structured modeling of the target task event to generate a task model, and then acquiring availability information of schedulable resources to match the target task in the task model with the schedulable resources to obtain a matching result. This matching result enables standardized task handover event types, state codes, and temporal semantics to be defined across scenario handover nodes, and executes time-series reservation, resource interlocking, state synchronization, timeout rollback, and retry control. This transforms the concurrent race condition problem of handover nodes into deterministic serialization, solving the problems of system-to-system state asynchrony, duplicate dispatching, and task suspension caused by inconsistent task handover protocols in existing technologies, and ensuring cross-system consistency of task handover states. Subsequently, the matching result is constrained and jointly solved according to a constraint model to output a scheduling decision for the target task. Finally, based on this scheduling decision, the AGV is driven to perform a state transition operation for the target task. By adopting the above-mentioned solution of this application, a unified scheduling hub is built around the entire process of automobile logistics. The tasks, resources, states and constraints of each scenario in the entire process of automobile logistics are uniformly modeled into the same semantic space, which fundamentally eliminates the problem of cross-system information inconsistency caused by independent modeling of scheduling systems in each scenario in the prior art, and realizes end-to-end collaborative scheduling and continuous optimization from the offline of the chain plate to the departure area. Attached Figure Description

[0015] Figure 1 This is a flowchart of a collaborative scheduling method for AGVs in a full-scenario automotive logistics application, as described in this embodiment. Figure 2 This is a flowchart of the state transition operation performed on the target task provided in this embodiment; Figure 3 This is a schematic diagram of the structure of an AGV collaborative scheduling system for the entire automotive logistics scenario provided in this embodiment.

[0016] Figure labels: 10, Modeling module; 20, Resource acquisition module; 30, Matching module; 40, Joint solution module; 50, State transition module. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of the invention. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to the present invention are not shown or described in the specification. This is to avoid obscuring the core parts of the invention with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0018] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0019] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this invention, unless otherwise specified, include both direct and indirect connections (linkages).

[0020] This application addresses the problems of fragmented scheduling systems across different stages of the entire automotive logistics process (from the chain conveyor belt offline through the repair area, inspection area, delivery area, sunken tunnel / ramp area, storage yard, to the departure area), inconsistent cross-scenario task handover protocols, inability to solve multiple constraints within a unified framework, and the inability to form a closed loop of operational data throughout the entire process. It constructs a collaborative scheduling method centered on a unified scheduling domain model. This method advances cross-scenario processes through event-driven and state machine mechanisms, ensures the determinism of task handover through standardized handover node collaboration protocols, handles multiple types of scheduling constraints within the same solution process through a joint solution engine, and constructs a closed loop of data throughout the entire process through single-vehicle granular event logs and state transition chains. It fundamentally eliminates the problem of inconsistencies in cross-system information caused by independent modeling of scheduling systems in existing technologies, achieving end-to-end collaborative scheduling and continuous optimization from the chain conveyor belt offline to the departure area. Specific implementation methods are described below.

[0021] refer to Figure 3This embodiment provides an AGV collaborative scheduling system for a full-scenario automotive logistics system, including a modeling module 10, a resource acquisition module 20, a matching module 30, a joint solution module 40, and a state transition module 50. The modeling module 10 acquires target task events and performs task-structured modeling on these events to generate a task model. The task model records at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships. The resource acquisition module 20 acquires availability information for schedulable resources. Availability information includes at least one of the following: number, set of serviceable scenarios, current available status, occupancy status, and capacity limit. The matching module 30 matches the task model with the availability information of schedulable resources to obtain a matching result. The joint solution module 40 performs constraint joint solution on the matching result according to a preset constraint model, outputting a scheduling decision for the target task. The scheduling decision includes at least one of the following: task orchestration result, resource allocation result, and path and timing decision result. The state transition module 50 drives the AGV to perform state transition operations on the target task based on the scheduling decision.

[0022] Specifically, the scheduling domain modeling module 10 is responsible for establishing, persisting, and maintaining a unified scheduling domain model in real time. This model serves as a "real-time panoramic map" for the entire AGV scheduling system, transforming on-site vehicles, tasks, paths, and constraint rules into standardized information that the system can process. All scheduling decisions, including dispatching, reservation, interlocking, release, rescheduling, and anomaly rollback, must rely solely on the current state of this model as their sole source of information. The modeling module 10 establishes task models by performing structured modeling on the acquired target task events. These task models record each task's unique ID, task type, starting scenario, target scenario, priority, time window, and pre- and post-dependent relationships to answer questions such as "what to do, when to do it, and the order of priority." The resource acquisition module 20 records the ID of each schedulable resource, the range of scenarios it can serve, its current availability, occupancy status, and capacity limit to answer questions such as "who should do it, and can it be done now?" The matching model, after matching the task model with the availability information of schedulable resources, defines the task status, handover node status, and process stage status in the matching result, as well as the legal paths allowed to jump between each status. It answers the question "What step are we currently at? What is the next step?", thus preventing illegal state transitions. The joint solution module 40 defines various business and operational rules that must be satisfied during the solution process, covering at least platform occupancy constraints, path conflict constraints, passage timing constraints, parking space resource constraints, and departure priority constraints, answering the question "Which rules cannot be violated?" The linkage logic between the above modules is as follows: After the MES system issues a task trigger event, the scheduling domain modeling module 10 first performs structured modeling of the task, forming task model entries. Then, it matches these entries with the resource availability information in the resource acquisition module 20 and the current resource / task process state maintained by the state model. The state model primarily manages the legality of state transitions; availability information is provided by the resource acquisition module to determine resource availability, and a state transition is requested from the state model when a resource is actually occupied. For example, if the current target task needs to use a certain AGV, it first checks if the resource is available, then verifies whether the relevant state transition is allowed (whether the code logic allows it). Only after both are passed is the occupancy changed and the request result is returned. After successful request, the AGV is only occupied, not actually running. After matching, under the constraints of the constraint model, the task enters the joint solution module 40 for joint calculation. After the joint solution module 40 outputs an executable scheduling decision, it writes the result back to the state model and switches the task state (e.g., switching from a pending scheduling state to an allocated state). Then, the execution end control system executes the generated scheduling decision-related instructions and reports the running status and task completion receipt. This feedback data re-enters the state model and task model, forming a closed-loop iteration. Since all scheduling decisions are based on a unified scheduling domain model as the sole source of information, the tasks, resources, states, and constraints of each scenario are uniformly modeled into the same semantic space. This fundamentally eliminates the problem of inconsistent information across systems when scheduling systems of different scenarios are modeled independently, and realizes an end-to-end scheduling closed loop from the offline of the chain board to the departure area.

[0023] Specifically, the modeling module 10 receives standardized events from the MES system, various scenario operation systems, and the execution control system, including task assignment events, handover confirmation events, permission events, exception alarm events, and completion receipt events. Upon receiving each event, the module uses the state model to find the legally allowed transition paths for the current state. If the transition path corresponding to the event is legal, it drives the state to jump to the target state and notifies the relevant modules to perform subsequent processing. If the transition path corresponding to the event is invalid, it rejects the state change and triggers an exception handling process. Through the combination of event-driven and state machine mechanisms, every state transition in the cross-scenario process is constrained by a legal path, ensuring the determinism of process progress and avoiding process anomalies caused by out-of-order or concurrent events.

[0024] In some implementations, the modeling module 10 establishes a task triggering event interface with the MES system to receive production cycle time, vehicle master data, and task triggering events; the resource acquisition module 20 establishes a workstation status and execution feedback interface with each scenario operation system to acquire workstation status and scenario constraint information and send back execution feedback; the joint solving module 40 establishes an instruction issuance and status feedback interface with the execution control system to issue scheduling instructions and receive running status and task completion receipts. Through the above standardized interface definitions, the information interaction boundaries between the scheduling system and external systems are clear, which is conducive to system integration and expansion.

[0025] The following section provides a detailed explanation of the implementation methods of each module and the collaborative scheduling method for AGVs across the entire automotive logistics scenario.

[0026] Referring to Figure 1, this embodiment provides a collaborative scheduling method for AGVs in a full-scenario automotive logistics application, which specifically includes the following steps: Step 100: Obtain the target task event and perform task structure modeling on the target task event to generate a task model; the task model is used to record at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships.

[0027] The MES system sends task trigger events to the modeling module 10 through an information interaction interface. Trigger sources include vehicle off-line signals and manual order creation. Upon receiving the events, the modeling module 10 performs structured task modeling, sequentially completing task creation, task decomposition (breaking down composite tasks into several atomic scheduling tasks), and task enqueueing. The generated task model instances are written to the task queue, awaiting subsequent orchestration processing. Specifically, the MES system provides the AGV scheduling system with production cycle time, vehicle master data, process status, and task trigger events as scheduling input sources. The scenario operation system provides the AGV scheduling system with workstation status and scenario constraint information for the maintenance area, inspection area, delivery area, tunnel / ramp area, storage yard, and departure area, and sends back execution feedback. The task model defines a unique task identifier, task type, source scenario, target scenario, priority, time window, and pre- and post-dependent attributes to express "what to do, when to do it, and the order of execution," providing a unified semantic foundation for cross-scenario task orchestration.

[0028] In some implementations, the attributes of the task model are further refined. A unique task identifier is used to uniquely locate a scheduling task instance throughout the entire process; task type distinguishes different business types such as handling tasks, maintenance stay tasks, inspection stay tasks, yard warehousing tasks, and dispatch tasks; the starting scenario and target scenario record the starting and target scenario nodes of the task, respectively, for example, the starting scenario is the chain conveyor offline area, and the target scenario is the maintenance area connection platform; the priority attribute is used to determine the initial order of tasks during the joint solution phase; the time window attribute records the earliest executable time and the latest completion time of the task for use by the constraint solving engine; the pre- and post-dependency attribute records the pre-completion constraints between the current task and other tasks, ensuring that task orchestration conforms to the business process sequence. Through the complete definition of the above attributes, the task model can provide a unified semantic foundation for cross-scenario task orchestration, enabling the scheduling system to clearly express the complete business semantics of each scheduling task at any time.

[0029] Step 200: Obtain availability information for schedulable resources; availability information includes at least one of the following: number, set of serviceable scenarios, current availability status, occupancy status, and capacity limit.

[0030] Specifically, the resource acquisition module 20 acquires the resource identifier (i.e. number), service scenario set, availability status, occupancy status, and capacity limit attributes of the schedulable resources, which are used to express "who does it and whether it can be done", so that the scheduling system can grasp the capability boundaries and current status of each AGV and connecting platform in real time.

[0031] In some implementations, the attributes of schedulable resources are further refined. A resource number uniquely identifies a schedulable resource, such as an AGV or a connecting platform; the serviceable scenario set records the range of scenarios in which the resource can perform tasks; for example, the serviceable scenario set for a certain type of AGV includes maintenance areas, inspection areas, and delivery areas; the current availability status indicates that the resource is currently idle and available for dispatch; the occupied status indicates that the resource is currently occupied by a task; and the capacity limit attribute records the maximum number of tasks the resource can handle at any given time. For a single-vehicle temporary storage area, the capacity limit is one; for a multi-vehicle storage area, the capacity limit is the number of corresponding vehicles. By defining the capacity boundaries of schedulable resources, the scheduling system can monitor the availability of each resource in real time, thereby supporting globally optimal task allocation decisions.

[0032] Step 300: Match the task model with the availability information of schedulable resources to obtain the matching results.

[0033] Specifically, the matching results obtained by matching the task model with the availability information of schedulable resources include task status, handover node status, process stage status, and legal state transition paths. Task status includes legal states such as pending dispatch, dispatched, executing, handover in progress, completed, and abnormally suspended. Handover node status includes legal states such as idle, scheduled, interlocked, handover in progress, and released. Process stage status records the current stage of the vehicle across various scenario nodes throughout the entire process, such as the off-line area, repair area, inspection area, temporary storage area in the delivery area, tunnel passage, yard parking, and departure area. Legal state transition paths define the preconditions and triggering events required to transition from one state to another. For example, transitioning from "dispatched" to "executing" requires the execution end control system to report a confirmation event that the AGV has started; transitioning from "executing" to "handover in progress" requires the AGV to arrive at the handover node and the handover node to be in an interlocked state.

[0034] Step 400: Perform constraint joint solution on the matching results according to the preset constraint model, and output the scheduling decision for the target task; the scheduling decision includes at least one of the following: task orchestration result, resource allocation result, path and timing decision result.

[0035] In practical applications, the pre-defined constraint model covers at least five types of constraints: platform occupancy constraints, path conflict constraints, passage sequence constraints, parking space resource constraints, and departure priority constraints. Specifically, platform occupancy constraints stipulate that only one task can occupy the same connection platform at any given time, preventing multiple tasks from vying for the same platform; path conflict constraints stipulate that no two AGVs can overlap in time and space on the same road segment at the same time, preventing path collisions; passage sequence constraints stipulate that in restricted sections with one-way passage (such as sunken tunnels or ramps), AGVs must pass through in sequence according to the permitted road segments; parking space resource constraints stipulate that each parking space in the yard can only hold one vehicle at a time, and this is cross-checked with the entry sequence; departure priority constraints stipulate that when multiple tasks are concurrent, the initial order of tasks is determined according to the priority of the departure plan, ensuring that high-priority departure tasks receive resource allocation first. The constraint model transforms the above on-site operating rules into computable constraints, providing a complete solution boundary definition for the multi-constraint joint solution engine.

[0036] By employing a constraint joint solution engine within a unified solution framework, the constraint model collaboratively processes multiple types of constraints, outputting executable scheduling decisions that include vehicles, resources, paths, and times. Specifically, as a constraint joint solution method, the first step involves the joint solution module 40 reading the set of tasks to be solved from the task model, arranging the initial order of tasks according to departure priority, and allocating time slots for mutually exclusive resources such as temporary storage locations and connecting platforms. For tasks that have not yet completed their time-series reservations or whose interlocks have not yet been released, no road segment permits are issued to the execution control system, ensuring that resource exclusivity is guaranteed at the solution entry point. The second step involves, under the traffic sequence constraints, the joint solution module 40 generating sequential road segment permits for restricted sections such as sunken tunnels and ramps and embedding them with time windows. Each road segment permit includes an entry time and an exit time. Subsequent AGVs can only obtain road segment permits after the preceding AGV has completed its passage and released the road segment, thereby ensuring orderly passage in one-way traffic sections. Third, under path conflict constraints, the joint solution module 40 detects the spatiotemporal occupancy of each AGV. When two AGVs are detected to have overlapping paths within the same time window, the conflict is resolved sequentially using time window shifting, yielding, or rerouting. Time window shifting refers to postponing the departure time of the low-priority task, causing the two AGVs to be staggered in the time dimension. Yielding refers to setting a waiting instruction for the low-priority AGV at the intersection. Rerouting refers to replanning a detour path for the low-priority AGV. Fourth, under parking space resource constraints, the joint solution module 40 verifies the yard parking space and entry sequence. When the target parking space is occupied at the target time, the process is handled sequentially using delayed entry, changing parking space, or backtracking. Delayed entry refers to postponing the entry time until the target parking space is released. Changing parking space refers to allocating other available parking spaces for the task. Backtracking refers to reverting the task to the waiting queue for re-queueing. In the fifth step, the joint solution module 40 merges and verifies the sub-results from the first four steps. If the merged scheduling scheme satisfies all constraints, it outputs an executable scheduling decision including vehicle identification, resource allocation, path sequence, and key moments. If the merged verification yields no solution, it sequentially executes methods such as narrowing the solution domain, downgrading the strategy, or reverting to a stable solution before recalculating, until a feasible solution is obtained and then output. By processing various constraints and merging and verifying them sequentially within a unified solution framework, it overcomes the shortcomings of existing rule engines that can only resolve conflicts locally and cannot achieve global linkage, thus realizing collaborative optimization scheduling across the entire scenario.

[0037] Step 500: Drive the AGV to perform state transition operations for the target task based on the scheduling decision.

[0038] Specifically, the joint solution module 40 sends the assembled scheduling instructions to the execution control system and the scenario operation system respectively; after receiving the scheduling instructions, the execution control system sends motion control instructions such as picking up, moving, and placing vehicles to the corresponding AGV equipment; after receiving the scheduling instructions, the scenario operation system sends connection instructions to the corresponding workstations, driving the workstation equipment in scenarios such as maintenance area, inspection area, delivery area, and storage yard to perform coordinated actions.

[0039] By adopting the AGV collaborative scheduling method for the entire automotive logistics scenario proposed in this application, a unified scheduling hub is constructed around the entire automotive logistics process. The tasks, resources, states, and constraints of each scenario in the entire automotive logistics process are uniformly modeled into the same semantic space, which fundamentally eliminates the problem of cross-system information inconsistency caused by the independent modeling of each scenario scheduling system in the prior art. This realizes end-to-end collaborative scheduling and continuous optimization from the offline of the chain plate to the departure area.

[0040] refer to Figure 2 Based on the scheduling decision, the AGV performs state transition operations for the target task, specifically including the following steps: Step 510: Based on the scheduling decision, schedule the cross-scene handover node in a timely manner and drive the AGV to the cross-scene handover node for handover. Step 520: Obtain the feedback information from the cross-scenario handover node, and update the availability information of the schedulable resources based on the feedback information.

[0041] In the process of driving the AGV to perform state transition operations for the target task, the collaborative processing of cross-scene handover nodes is specifically involved. The specific processing mechanism is as follows: First, before the AGV arrives at the cross-scene handover node to hand over the task, it is necessary to determine whether the current occupancy status of the cross-scene handover node is idle; if so, a time window is reserved for the AGV and locked; otherwise, the current target task is placed in the waiting queue.

[0042] Specifically, before the AGV arrives at the handover node, the handover node coordination module queries the scheduling domain modeling module 10 for the current occupancy status of the target handover node; if the node is idle, a time window is reserved for the AGV and the node status is locked as "reserved", and the reservation information is written to the resource acquisition module 20; if the node has been occupied or reserved, the current task is placed in the waiting queue and will be allocated after the lock is released.

[0043] After the AGV enters the handover node and completes the handover action, the handover node collaboration module receives execution feedback from the scenario operation system, updates the current handover node status to "released", and notifies the next waiting task that it can initiate a reservation.

[0044] If the AGV fails to arrive on time within the scheduled time window, a timeout rollback mechanism is triggered: the handover node coordination module releases the scheduled time window, rolls the task status back to the pending scheduling state, and re-initiates the reservation request according to the preset retry strategy. Through the combination of time-sequenced reservation and resource locking mechanism, the concurrent race condition of the handover node is transformed into deterministic serialization, eliminating the problems of duplicate order assignment and task suspension caused by multiple tasks competing for the same handover node at the same time, and ensuring the consistency of the task handover status between the scheduling system and the operation systems of each scenario.

[0045] In one implementation, the feedback information from the cross-scenario handover node includes at least one of the following: handover node status information, timeout rollback information, or retry control information; after obtaining the feedback information from the cross-scenario handover node, the system further includes: The receipt information is sent back to the preset constraint model, which verifies the receipt information to obtain the verification result. Specifically, the verification result includes verification success or verification failure. When the verification result is successful, the occupation status of the resources occupied by the completed target task is updated to release, and the next waiting target task is notified that it can initiate a reservation. When the verification result is unsuccessful, a timeout rollback mechanism is triggered, the task status of the current target task is rolled back to the pending scheduling state, and the constraint joint solution for the current target task is re-performed.

[0046] Specifically, in practical applications, after the AGV completes its execution action, the execution-end control system sends the AGV's operating status and alarm information back to the joint solving module 40; the scenario operation system sends the workstation status and alarm information back to the joint solving module 40; the joint solving module 40 verifies the above-mentioned feedback content based on the saved instruction snapshot, and the verification result is divided into two branches: success and rollback. When the verification result is successful, the joint solving module 40 triggers a resource release process to the resource model, updates the resource status occupied by the completed task from hard occupancy to release or transfer, and wakes up subsequent tasks in the waiting queue that are blocked due to their dependence on the resource, triggering them to re-enter the joint solving process in order of priority; when the verification result is unsuccessful, the joint solving module 40 performs a rollback operation, cancels the current resource hard occupancy record, resets the status of the affected task to pending dispatch, and re-triggers the joint solving process, ensuring high fault tolerance in scheduling decisions.

[0047] In some implementations, the preset constraint model includes a rule engine unit, an optimization solver unit, and a conflict resolver unit; the constraint joint solution of the matching results according to the preset constraint model includes: The rule engine unit sorts target tasks according to task priority, allocates usage time periods for mutually exclusive resources, and prohibits issuing access permits to AGVs for handover nodes that have not yet completed their reservations. By optimizing the solver unit, an ordered sequence of access permits is generated for the restricted road segment, and a corresponding time window is embedded for each access permit to ensure that the AGVs do not conflict in time sequence. The conflict resolution unit detects the space-occupancy conflicts of each AGV in time and space, and resolves the space-occupancy conflicts.

[0048] Specifically, the joint solution module 40 is connected to the modeling module 10 and is responsible for handling multiple scheduling constraints simultaneously in the same solution process, ultimately outputting a feasible scheduling decision containing vehicle number, resource allocation, travel route, and execution time. The joint solution module 40 consists of three parts: a rule engine unit, an optimization solver unit, and a conflict resolver unit, which work collaboratively in the same solution process. Specifically, the rule engine unit is responsible for sorting tasks according to departure priority and allocating usage time periods for mutually exclusive resources such as temporary storage positions and tunnel / ramp connection platforms; for road segments that have not yet completed reservations or whose interlocks have not yet been released, no passage permits are issued. Under the constraints of passage time sequence, the optimization solver unit generates an ordered sequence of passage permits for restricted road segments (such as tunnels, ramps, and other one-way passage sections) and embeds a corresponding time window into each passage permit to ensure that there are no time sequence conflicts among the AGVs. The conflict resolution unit is responsible for detecting temporal and spatial conflicts among AGVs. When two or more AGVs are detected planning to occupy the same road segment during the same time period, the conflict resolution unit resolves the conflict by adjusting the time window to allow vehicles to pass at different times, making lower-priority vehicles wait to give way, or replanning detour routes for conflicting vehicles. During the parking space resource constraint processing stage, the joint solution module 40 verifies whether the availability and timing of the yard parking spaces meet the requirements. If not, it performs delayed entry, changes the parking space, or returns the corresponding task to the waiting process. After summarizing the solutions to the above sub-problems, the joint solution module 40 merges and verifies all sub-results. If a feasible solution exists in the merged result, a feasible scheduling decision is output. If no feasible solution exists, the solution scope is narrowed, the strategy level is reduced, or the solution is recalculated from the previous stable solution until a feasible solution is found and then output. Because platform occupancy constraints, path conflict constraints, passage timing constraints, parking space resource constraints, and departure priority constraints are processed collaboratively within the same solution process, the solution results of each constraint subproblem are merged and verified before outputting a globally feasible scheduling decision, thus avoiding the problem of mutual conflicts when each constraint is processed separately.

[0049] In some implementations, after outputting the scheduling decision for the target task, the following steps are also included: The scheduling decisions are periodically evaluated to obtain the evaluation results.

[0050] The specific implementation steps include: generating event logs and state transition chains based on task orchestration results, resource allocation results, and path and timing decision results; The actual statistical values ​​of scheduling performance metrics are aggregated from event logs and state transition chains; the actual statistical values ​​include at least the task on-time rate, average waiting time, handover success rate, rescheduling frequency, and anomaly recovery time. The actual statistical value is compared with the preset standard. When the actual statistical value meets the triggering condition of the preset standard, the evaluation conclusion and the cause code are output.

[0051] The system continuously collects operational event logs for each vehicle, reconstructs state transition chains, and calculates scheduling performance metrics from this data according to a set evaluation cycle. The statistical results are compared with preset standards, and if a metric exceeds a limit or meets optimization trigger conditions, the rule parameters are automatically updated iteratively. Specifically, for each vehicle, key events such as task issuance, handover confirmation, release permission, anomaly alarms, and completion receipts are collected, along with the occurrence time, resource number, scenario number, task number, and execution result. This raw event data forms the foundational input for the entire data loop. Based on the collected event sequence, the task state machine's transition chain is reconstructed, forming a complete time-series record of "starting state—trigger event—target state." This time-series record can be used to locate process bottlenecks, abnormal state transitions, or suspended tasks, enabling the scheduling system to verify the historical execution process. The state transition chain and driving trajectory are transformed into a visual traceability view, supporting multi-dimensional queries and playback by vehicle, task, scenario, or time period. Operators can use this view to quickly locate the time node and context of the problem, improving problem location efficiency. For anomalies such as timeouts, conflicts, resource occupancy failures, and handover failures, the system automatically associates contextual events with the decision-making process, providing candidate root causes and suggested solutions. This step transforms anomaly review from manual analysis to system-assisted analysis, reducing the time cost of anomaly troubleshooting. Scheduling performance metrics are aggregated and calculated from event logs and state transition chains according to a set evaluation cycle and compared with preset standards. Scheduling performance metrics include at least task on-time rate, average waiting time, handover success rate, rescheduling frequency, and anomaly recovery time; preset standards include target thresholds or allowable upper and lower limits for each metric. When a metric exceeds its limit, deteriorates continuously, or meets preset optimization trigger conditions, the system outputs an evaluation conclusion and cause code, providing a quantitative basis for subsequent rule parameter updates.

[0052] The constraint model is updated based on the evaluation results. Specifically, this includes generating policy recommendations containing rule parameters, constraint weights, and policy routing configurations based on the evaluation conclusions and cause codes, and feeding these recommendations back to the constraint model for updating.

[0053] Specifically, based on the evaluation conclusions and cause codes, a set of adjustable parameters is found through pre-defined mapping. The rule engine parameters, constraint weights, and policy routing configurations are then updated and deployed. Specifically, on the rule engine side, timeout thresholds, retry backoff strategies, and priority coefficients are adjusted; in the constraint model, the weights of constraints such as platform occupancy, path conflicts, passage sequence, parking spaces, and departure are adjusted; and on the policy routing side, effective rules are switched according to scenario, time period, or operating mode, forming a complete software closed loop of "data collection—state reconstruction—traceability analysis—policy optimization." This ensures the scheduling system has full-process observability, anomaly traceability, and policy iterability. Because the iterative updates of rule parameters are based on quantified scheduling performance indicators, the direction and magnitude of parameter adjustments are supported by data, avoiding the problem of blindly adjusting parameters based on experience.

[0054] On the strategy routing side, the system dynamically switches between rule sets corresponding to different operating modes based on real-time task queues, resource usage, and path status, and triggers rescheduling in the event of an anomaly. The strategy routing module receives operating mode change requests from the field control system, equipment alarm signals, or manual operations, and switches the corresponding rule sets and parameters based on the current task queue, resource usage, and path constraints. When an anomaly occurs, the strategy routing module freezes traffic on the affected road segment and associated handover nodes, releases the reserved time windows, and reassigns blocked tasks to backup time windows or alternative paths; after the fault is resolved and confirmed on-site, sorting and release are restored. Taking a tunnel section as an example: when a tunnel section reports AGV stagnation or continuous communication timeouts, the strategy routing module freezes traffic on that section and associated connecting platforms, releases subsequent reserved time windows, reassigns blocked tasks to backup time windows or detour paths, and unfreezes and restores sorting and release after the fault is resolved and confirmed on-site. The operation mode switching includes switching between human-machine collaborative mode and fully automatic unmanned mode, as well as switching between unidirectional channel strategy and bidirectional channel strategy, thus being compatible with semi-automatic operation methods that retain manual intervention. Because the policy routing module dynamically switches between rule sets corresponding to different operation modes based on real-time status, and implements passage freezing and task reassignment for affected sections when abnormal events are triggered, the scheduling system can smoothly transition between different operation modes and quickly restore scheduling continuity in abnormal scenarios.

[0055] This document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components for performing operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0056] While the principles herein have been illustrated in various embodiments, numerous modifications to the structures, arrangements, proportions, elements, materials, and components, particularly suited to specific environments and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document. Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the fundamental principles of the invention.

Claims

1. A collaborative scheduling method for AGVs across all automotive logistics scenarios, characterized in that, include: Obtain the target task event, perform task structure modeling on the target task event, and generate a task model; The task model is used to record at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships. Obtain availability information of schedulable resources; the availability information includes at least one of the following: number, set of serviceable scenarios, current availability status, occupancy status, and capacity limit; The task model is matched with the availability information of the schedulable resources to obtain the matching result; The matching results are subjected to joint constraint solving based on a preset constraint model, and a scheduling decision is output for the target task. The scheduling decision includes at least one of the following: task orchestration result, resource allocation result, and path and timing decision result. The scheduling decision drives the AGV to perform a state transition operation for the target task.

2. The cooperative scheduling method as described in claim 1, characterized in that, The step of driving the AGV to perform a state transition operation for the target task based on the scheduling decision includes: Based on the scheduling decision, the cross-scenario handover node is scheduled in a specific time sequence, and the AGV is driven to reach the cross-scenario handover node for handover. Obtain the feedback information from the cross-scenario handover node, and update the availability information of the schedulable resources based on the feedback information.

3. The cooperative scheduling method as described in claim 2, characterized in that, Before driving the AGV to the cross-scene handover node for handover, the process also includes: Determine whether the current occupancy status of the cross-scenario handover node is idle; If so, a time window is reserved for the AGV and locked; otherwise, the current target task is placed in the waiting queue.

4. The cooperative scheduling method as described in claim 2, characterized in that, The feedback information from the cross-scenario handover node includes at least one of the following: handover node status information, timeout rollback information, or retry control information; after obtaining the feedback information from the cross-scenario handover node, the process further includes: The receipt information is sent back to the preset constraint model, and the receipt information is verified through the preset constraint model to obtain the verification result.

5. The cooperative scheduling method as described in claim 4, characterized in that, The verification result includes whether the verification was successful or failed. When the verification result is successful, the resource occupation status of the completed target task is updated to released, and the next waiting target task is notified that it can initiate a reservation. When the verification result is a verification failure, a timeout rollback mechanism is triggered, the current task status of the target task is rolled back to the pending scheduling state, and the current target task is re-constrained and jointly solved.

6. The cooperative scheduling method as described in claim 1, characterized in that, The preset constraint model includes a rule engine unit, an optimization solver unit, and a conflict resolver unit; the step of performing joint constraint solving on the matching results according to the preset constraint model includes: The rule engine unit sorts the target tasks according to the task priority, allocates usage time periods for mutually exclusive resources, and prohibits issuing access permits to the AGV for handover nodes that have not yet completed their reservations. The optimization solver unit generates an ordered sequence of access permits for the restricted road segment and embeds a corresponding time window for each access permit to ensure that the AGVs do not conflict in time sequence. The conflict resolution unit detects the temporal and spatial occupancy conflicts of each AGV and resolves the occupancy conflicts.

7. The cooperative scheduling method as described in claim 6, characterized in that, The output, after the scheduling decision for the target task, also includes: The scheduling decisions are periodically evaluated to obtain evaluation results; The constraint model is updated based on the evaluation results.

8. The cooperative scheduling method as described in claim 7, characterized in that, The periodic evaluation of the scheduling decision to obtain the evaluation results includes: Based on the task orchestration results, resource allocation results, and path and timing decision results, an event log and a state transition chain are generated. The actual statistical values ​​of scheduling performance indicators are aggregated and calculated from the event logs and state transition chains; the actual statistical values ​​include at least the task on-time rate, average waiting time, handover success rate, rescheduling frequency, and anomaly recovery time. The actual statistical value is compared with a preset standard. When the actual statistical value meets the triggering condition of the preset standard, the evaluation conclusion and the cause code are output.

9. The cooperative scheduling method as described in claim 8, characterized in that, The step of updating the constraint model based on the evaluation results includes: Based on the evaluation conclusions and cause coding, policy recommendations containing rule parameters, constraint weights, and policy routing configurations are generated and fed back to the constraint model for updating.

10. A collaborative scheduling system for AGVs across all automotive logistics scenarios, characterized in that, include: The modeling module is used to acquire target task events and perform task structure modeling on the target task events to generate a task model; The task model is used to record at least one of the following for each target task: unique identifier, task type, starting scenario, target scenario, task priority, time window, and pre- and post-dependent relationships. The resource acquisition module is used to acquire availability information of schedulable resources; the availability information includes at least one of the following: number, set of serviceable scenarios, current availability status, occupancy status, and capacity limit. The matching module is used to match the task model with the availability information of the schedulable resources to obtain a matching result; The joint solution module is used to perform constraint joint solution on the matching results according to the preset constraint model, and output a scheduling decision for the target task; the scheduling decision includes at least one of the following: task orchestration result, resource allocation result, and path and timing decision result; The state transition module is used to drive the AGV to perform state transition operations on the target task based on the scheduling decision.

Images