Unmanned vehicle scheduling system and method based on strategy driving

Abstract

The invention belongs to the related technical field of vehicle control and scheduling, and particularly relates to an unmanned vehicle scheduling system and method based on strategy driving, and the system employs a three-layer architecture, and comprises a framework layer which comprises a visual human-computer interaction interface, a scheduling service system and an automatic driving system, data management, work order management, scheduling task execution and unmanned vehicle state feedback functions are provided, and the layer is kept unchanged when a service scene is newly added; the strategy layer supports three elements of dynamic configuration and strategy management and provides a customized interface of scheduling rules and parameters, and the three elements of the strategy comprise a scheduling algorithm plug-in program, a parameter configuration page and a new work order page; and the scheduling layer is used for instantiating and operating scheduling logic, associating a specific strategy, calling the function of the framework layer and the scheduling capability defined by the strategy layer to command the unmanned vehicle to complete scheduling operation, and realizing business work order fulfillment. The system and the method have the advantages of rapid scene adaptation, high system compatibility, low development cost, flexible service configuration and the like.

Description

Technical Field

[0001] The present invention mainly relates to the technical field related to vehicle control, and specifically to a policy-driven unmanned vehicle scheduling system and method. Background Art

[0002] Unmanned vehicles are currently widely used in logistics transport vehicles, road sweepers, park inspection vehicles and other fields. Different scheduling plans need to be implemented for unmanned vehicles for different application scenarios.

[0003] The existing unmanned vehicle dispatching system has the following core defects: High scenario coupling: Customized development for a single scenario requires the reconstruction of the underlying code for new requirements (for example, adding a new path optimization algorithm to a logistics scenario requires modifying the core scheduling module), resulting in a long development cycle and high costs (for example, logistics scenarios and cleaning scenarios require independent development of system modules).

[0004] Limited scalability: Business logic is deeply bound to the system architecture. Adding new algorithms or parameters requires intrusive modifications to the core modules, making it difficult to support parallel operations in multiple scenarios.

[0005] Weak fault tolerance: There is a lack of a layered recovery mechanism when an exception occurs, and the system is prone to global paralysis due to local failures. Summary of the Invention

[0006] In order to address the shortcomings of current technology, the present invention combines existing technologies and, based on practical applications, provides a policy-driven unmanned vehicle scheduling system and method. By introducing a policy configuration layer, the business scenario logic and system architecture are decoupled without changing the core modules of the system. With a small amount of development or configuration work, it can quickly adapt to multiple business scenarios, significantly shorten the development cycle, reduce development costs, and improve the scalability and compatibility of the system. It is suitable for the rapid deployment and operation of unmanned vehicle scheduling and management in multiple business scenarios.

[0007] The technical solutions of the present invention are as follows: According to one aspect of the present invention, a policy-driven unmanned vehicle dispatching system is provided. The system adopts a three-layer decoupling architecture, including: Framework layer: Provides basic services for data management and communication, as well as a general visual human-computer interaction interface. This layer remains unchanged when new business scenarios are added. Policy layer: supports dynamic configuration and independently encapsulates the three elements of a policy based on the scenario. The three elements include a scheduling algorithm plug-in, a parameter configuration page, and a new work order page. When expanding new business scenarios, only the three elements of the policy need to be developed and uploaded through the framework layer's web front-end. In similar business scenarios, only the scheduling rule parameters need to be modified and adjusted through the policy parameter configuration page. Scheduling layer: It can be instantiated and executes specific scheduling logic based on policy instances, directing unmanned vehicles to perform scheduling tasks and supporting parallel scheduling in multiple scenarios. Its operating mechanism is as follows: each scheduling instance is bound to an independent strategy, and an event-driven architecture is used to respond to instructions to realize scheduling task dispatch and exception recovery, and the state and process are ensured to be controllable through the state machine model.

[0008] Furthermore, the framework layer core module includes: Web front-end for maps, work orders, and vehicle management; Scheduling service system, used for data management, container management, scheduling instantiation and operation monitoring; Automatic driving system, used for unmanned vehicle positioning, control, and fault diagnosis.

[0009] Furthermore, among the three elements of the strategy, the scheduling algorithm plug-in uses Docker containerization for isolation and encapsulation, and is supported by a JAR package dynamic loading mechanism. This supports resource isolation and hot swapping, and implements work order parsing, scheduling task generation, and exception handling logic in different business scenarios. The parameter configuration page provides exclusive parameter setting interfaces according to different business scenario types. Based on page template rendering technology, different parameter configuration pages are rendered to achieve dynamic injection of scenario-differentiated parameters. The new work order page provides an exclusive work order entry interface based on different business scenario types. Based on page template rendering technology, different new work order pages are rendered to achieve scenario-differentiated work order entry.

[0010] Furthermore, the dynamic loading mechanism of the scheduling algorithm plug-in is as follows: The steps of the dynamic loading mechanism are: container startup, host program launch, plugin JAR loading, parameter injection, and component initialization; It uses a four-stage initialization component, including a scheduling executor, a vehicle feedback processor, a task dispatcher, and an anomaly monitor. Each module is loaded independently without interfering with each other. The scheduling executor is used to execute the scheduling algorithm, the vehicle feedback processor is used to synchronize the status, the task dispatcher is used to issue scheduling tasks, and the anomaly monitor is used for fault detection. The fault-tolerant design supports manual intervention and retry when loading fails.

[0011] Furthermore, the operation control implementation specifications of the scheduling algorithm plug-in are as follows: The event-driven architecture designs four core events. The event bus adopts an asynchronous processing mode. The core control events include user command events, system self-healing events, state transition events, and exception trigger events. User command events are used for starting, stopping, and resuming; system self-healing events are used for automatic recovery; state transition events are used for success and failure notifications; and exception trigger events are used to schedule exception triggers. The scheduling algorithm plug-in program adopts a dual closed-loop guarantee mechanism. Its forward closed-loop process is as follows: startup, operation, and monitoring. After the scheduling runs normally, the monitoring mechanism is immediately started to detect the scheduling execution status in real time; the fault-tolerant closed-loop process is as follows: anomaly detection, downgrade switching, recovery attempt, and manual intervention. When an abnormal scheduling operation is detected, the downgraded scheduling algorithm is switched and the automatic recovery mechanism is started to try to restore normal operation.

[0012] Furthermore, the scheduling system uses a state machine model to design the scheduling life cycle, which mainly includes the following processes and states: Core status flow: waiting to be loaded, loading, ready, starting, scheduling, stopping, stopped, archived, to ensure the normal scheduling life cycle flow.

[0013] Abnormal branch: loading failure, startup failure, abnormal, recovering, and stop failure. The flow of abnormal branch status supports user retry, automatic recovery mechanism and manual backup strategy to prevent system deadlock and abnormal spread; Constraint rules: The scheduling algorithm plug-in can customize the state switching conditions, but is prohibited from modifying the state flow direction to ensure system stability.

[0014] According to another aspect of the present invention, a scheduling method is provided, comprising the following steps: 1) Map and vehicle preparation: Create a semantic topological map of the scene and deploy autonomous vehicles; 2) Create a new policy: Create a policy on the Web front-end management page, including uploading the scheduling algorithm plug-in program JAR file, the parameter configuration page HTML file, the new work order page HTML file, and the back-end scheduling service system saves the three elements of the policy; 3) Create a new schedule: Create a new schedule on the Web front-end management page, and the back-end scheduling service system saves, loads and runs the schedule; 4) New work order: On the Web front-end management page, users submit scheduled work orders one after another; 5) Scheduling process: The scheduling algorithm plug-in defines itself according to the specific business scenario to complete the scheduling task.

[0015] Beneficial effects of the present invention: Rapid scenario adaptation: Only new policies need to be developed or configured without modifying the core system modules to achieve instant deployment in multiple scenarios, from logistics and luggage transportation to campus cleaning.

[0016] Reduce development costs: By reusing policies, you can quickly switch between similar business scenarios and reduce secondary development and testing investment.

[0017] Reduce development costs: Through the flexibility of "one scenario, one strategy" and "similar scenario reuse strategy", the scheduling logic of different or similar business scenarios can be implemented, reducing secondary development and testing investment.

[0018] Improve system scalability: The independent policy layer design allows for flexible integration of new business models without interfering with existing scenarios.

[0019] Enhanced system compatibility: Loading the scheduling algorithm in the form of a plug-in reduces the coupling between business logic and system architecture, ensuring stable operation of the overall system.

[0020] Flexible business configuration: The visual configuration interface enables users to dynamically adjust scheduling parameters according to specific needs, improving the usability and adaptability of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 : System network topology diagram, showing the communication relationship between the server, unmanned vehicle and user interface.

[0022] Figure 2 : System architecture diagram, showing the dependencies among the framework layer, strategy layer, and scheduling layer.

[0023] Figure 3 : A diagram of the system's functional structure, which intuitively displays the system's core modules (Web front-end, back-end scheduling services, and autonomous driving vehicles) and their functional divisions.

[0024] Figure 4 : Schematic diagram of the three elements of the strategy, explaining the scheduling algorithm plug-in program, parameter configuration page, and new work order page and their relationship.

[0025] Figure 5 : A diagram of the hierarchical structure of servers, Docker containers, scheduling algorithm host programs, and scheduling algorithm plug-in programs, showing the loading hierarchy of the scheduling algorithm host programs and scheduling algorithm plug-in programs in each Docker container in a containerized deployment environment.

[0026] Figure 6 : Scheduling state machine diagram, constrained state machine model of scheduling, including the flow logic of core states and exception branches.

[0027] Figure 7 :Schematic diagram of the scheduling algorithm plug-in program [dynamic loading] process, the plug-in program dynamic loading process, including container startup, host program launch, plug-in program loading and initialization.

[0028] Figure 8 :Scheduling algorithm plug-in program [Operation control specification] User instruction event processing flow diagram.

[0029] Figure 9 :Scheduling algorithm plug-in program [Operation control specification] System self-healing event processing flow diagram.

[0030] Figure 10 :Scheduling algorithm plug-in program [Operation control specification] Schematic diagram of the abnormal trigger event processing flow. DETAILED DESCRIPTION

[0031] The present invention will be further described with reference to the accompanying drawings and specific embodiments. It should be understood that these embodiments are intended only to illustrate the present invention and are not intended to limit the scope of the present invention. In addition, it should be understood that after reading the contents of the present invention, those skilled in the art may make various changes or modifications to the present invention, and these equivalent forms also fall within the scope defined by the present application.

[0032] This embodiment provides a policy-driven unmanned vehicle dispatch system. By introducing a policy configuration layer, this system decouples business scenario logic from the system architecture. This system requires no modifications to core system modules and can rapidly adapt to multiple business scenarios with minimal development or configuration effort. This significantly shortens development cycles and reduces development costs, while improving system scalability and compatibility, enabling rapid deployment and operation of unmanned vehicles. This embodiment provides a policy-driven modular architecture for different unmanned vehicle business scenarios. Scenario expansion is achieved through dynamic configuration or the addition of new policies (rather than modifying underlying code or restructuring the system framework).

[0033] The unmanned vehicle dispatching system provided in this embodiment is based on the three-element strategy model and the three-layer decoupling architecture (such as Figure 2 As shown in Figure 2), the system dynamically adapts business logic to the core system and improves system robustness through a dual closed-loop fault-tolerance mechanism. The system includes: Framework layer (unchanged): provides basic services (data management, communication, etc.) and a general visual human-computer interaction interface.

[0034] Core modules: Web front-end (map / work order / vehicle management), dispatch service system (data management / container management / dispatching instantiation and operation monitoring), and autonomous driving system (positioning / control / fault diagnosis).

[0035] Among them, the Web front-end management system: provides a visual human-computer interaction interface, and provides users with system function management and operation, including map module, work order module, cargo module, vehicle module, strategy module, scheduling module, etc.

[0036] Backend scheduling service system: data management services and policy scheduling engine services, including semantic topology map database, cargo feature database, vehicle information database, policy information database, scheduling information database, work order database, scheduling task database, Docker container management service, scheduling instantiation service, scheduling operation monitoring service, etc.

[0037] Autonomous driving unmanned vehicle: A mobile terminal device that performs scheduling tasks. Its autonomous driving system includes a scheduling task execution module, an environmental perception module, a high-precision positioning and mapping module, a decision-making and planning module, a control execution module, a communication module, a system fault monitoring module, etc. It is responsible for controlling the unmanned vehicle to complete scheduling tasks and feedback vehicle location, power, load, fault information, etc.

[0038] The policy layer (configurable) independently encapsulates the three policy elements (scheduling algorithm plug-in, parameter configuration page, and new ticket page) for each scenario. Key technologies employed include Docker container isolation, Java SPI mechanisms, dynamic parameter injection, and page template rendering. When developing new business scenarios, only the three policy elements need to be developed and uploaded through the web frontend. For similar business scenarios, only the scheduling rule parameters need to be modified through the policy parameter configuration page. This enables the flexibility of "one policy per scenario" and "reusing policies for similar scenarios."

[0039] Scheduling layer (instantiable): executes specific scheduling logic based on policy instances, directs unmanned vehicles to perform scheduling tasks, and supports multi-scenario parallel scheduling. Its operating mechanism is: each scheduling instance is bound to an independent strategy, adopts an event-driven architecture to respond to instructions, realizes scheduling task dispatch and abnormal recovery, and uses a state machine model ( Figure 6 (as shown) to ensure that the status and process are controllable.

[0040] In this example, a work order describes the work that needs to be completed in a specific business scenario. For example, a short-distance logistics connection between different workshops within a factory is a logistics work order, specifying when goods should be delivered from one address to another. A road cleaning order within the park is a cleaning work order, specifying when trash should be removed from certain sections of road.

[0041] A dispatch task describes the work that an unmanned vehicle needs to complete within a specific business scenario. For short-distance logistics transfers, the vehicle first travels to point A on the map, then to point B, at a speed of 2 m / s. For road sweeping, the vehicle traverses a block (a) on the map. Upon reaching point A, the vehicle activates the sweeping brushes and water jets to begin an I-shaped sweep. Upon reaching point B, the vehicle turns off the sweeping brushes and water jets and returns to its destination, traveling at a speed of 1 m / s.

[0042] In this embodiment, the three-element strategy model is as follows: Figure 4 As shown, it is used to meet the scheduling requirements of different business scenarios.

[0043] The three elements of the strategy include the scheduling algorithm plug-in, the parameter configuration page, and the new work order page.

[0044] 1) For the scheduling algorithm plug-in: Using containerized packaging ( Figure 5 As shown in the figure), relying on the JAR package dynamic loading mechanism technology, it supports resource isolation and hot plugging, and implements specific scheduling algorithm logic in different business scenarios, including work order parsing, scheduling task generation and issuance, and exception handling logic.

[0045] The scheduling algorithm logic varies significantly across different business scenarios (for example, logistics and road cleaning scenarios have vastly different work order attributes, leading to completely different implementation logic for work order parsing). Even within the same logistics and transportation scenario, the scheduling algorithm logic can differ significantly. For example, in factory logistics, a single unmanned vehicle can transport goods from multiple work orders. Multiple work orders might be combined to create a single dispatch task for the unmanned vehicle, ensuring optimal energy efficiency and reducing empty miles. In airport baggage transport, a single flight's luggage requires multiple unmanned vehicles to load and transport. A single work order might be split into multiple dispatch tasks, each executed by the unmanned vehicle, ensuring optimal timeliness, reducing passenger wait times for baggage claim, and improving the passenger service experience. Therefore, we cannot rigidly define the specific implementation logic of each plug-in. This application constrains its implementation framework through designs such as the "Scheduling State Machine," the plug-in's "Four Initialization Phases," and the "Operation Control Implementation Specification." The specific implementation logic is customized based on the business scenario's requirements, ensuring both robustness and complete functionality for each plug-in and the differentiation of its scheduling algorithm logic.

[0046] 2) For the parameter configuration page: According to different business scenario types, an exclusive parameter setting interface is provided. Based on the page template rendering technology, different parameter configuration pages are rendered to realize the dynamic injection of scenario-differentiated parameters (such as the path merging threshold in the logistics scenario and the brush head power in the cleaning scenario).

[0047] 3) For the new work order page: According to different business scenario types, an exclusive work order entry interface is provided. Based on the page template rendering technology, different new work order pages are rendered to realize scenario-differentiated work order entry (for example, airport baggage transportation requires entering the flight number, and logistics scenarios require binding the cargo type).

[0048] In this embodiment, the scheduling state machine is as follows: Figure 6 shown.

[0049] The scheduling system uses a state machine model to design the scheduling lifecycle, which mainly includes the following processes and states: 1) Core status flow: To be loaded → Loading → Ready → Starting → Scheduling → Stopping → Stopped → Archived, ensuring the normal scheduling lifecycle flow.

[0050] 2) Abnormal branches: loading failure, startup failure, abnormality, recovery, and stop failure. The flow of abnormal branch status supports user retries, automatic recovery mechanisms, and manual backup strategies to prevent system deadlocks and abnormality spread.

[0051] 3) Constraint rules: The states managed by each scheduling algorithm plug-in include: ready, starting, scheduling, stopping, stopped, failed to start, recovering, abnormal, and failed to stop. When implementing the scheduling algorithm logic of each plug-in, the state transition trigger conditions should be independently defined according to the actual business scenario requirements (for example, when the work order timeout rate is greater than 10%, it will trigger the abnormal state), but it must be strictly followed. Figure 6 Defined state flow direction. All automated state transitions without human intervention must be driven by preset business rules to ensure that the system operation process complies with the established state machine constraints and maintain overall scheduling stability.

[0052] In this embodiment, the dynamic loading mechanism of the plug-in program is as follows: Figure 7 As shown, the operation control implementation specification is as follows Figure 8 、 Figure 9 、 Figure 10 shown.

[0053] This embodiment designs in detail the dynamic loading mechanism and operation control implementation specification of the scheduling algorithm plug-in program, the core contents of which include: 1) Dynamic loading mechanism: Steps: Container start → Host program launch → Plug-in JAR load → Parameter injection → Component initialization.

[0054] Initialization four stages ( Figure 7 As shown in the figure: the scheduling executor (work order parsing / scheduling task generation), vehicle feedback processor (state synchronization), task dispatcher (instruction issuance), and anomaly monitor (fault detection) modules are loaded independently without interfering with each other.

[0055] Fault-tolerant design: When loading fails, manual intervention and retry are supported.

[0056] 2) Operation control implementation specifications: The event-driven architecture designs four core events: user command events (start / stop / recovery), system self-healing events (automatic recovery), state transition events (success / failure notifications), and exception trigger events (scheduling exceptions).

[0057] Double closed-loop guarantee mechanism: Forward closed loop (steady-state process): Start → Run → Monitor. After the dispatch is started, it enters the dispatching state. Real-time monitoring confirms that the dispatch is operating normally. It then switches to the normal dispatch algorithm to execute the dispatch work, and simultaneously starts the automatic monitoring mechanism to continuously track the dispatch execution status.

[0058] Fault-tolerant closed loop (exception handling): Anomaly detection → Downgraded switching → Recovery attempt -> Manual intervention (backup). When a scheduling anomaly is detected, a circuit breaker is immediately triggered, downgrading to a degraded scheduling algorithm to maintain service. Simultaneously, an automatic recovery mechanism is initiated to attempt repairs. If recovery fails, manual intervention is notified as a back-up.

[0059] Core Component Responsibilities: The Scheduler Executor encapsulates and executes the core logic of the normal and degraded scheduling algorithms. The Anomaly Monitor implements the control logic for the automatic monitoring mechanism (real-time status tracking) and the automatic recovery mechanism (fault self-healing).

[0060] The business scenario requirements corresponding to different scheduling algorithm plug-ins vary significantly, and the algorithm logic of each plug-in must be highly customized, but must be implemented in accordance with the content specifications of this chapter.

[0061] This embodiment also provides a method for dispatching unmanned vehicles based on the above-mentioned dispatching system. The following demonstrates the independence and flexibility of the system's dynamic adaptation to multi-scenario dispatching logic through differentiated configuration of the three elements of the strategy.

[0062] Scenario 1: Factory logistics and transportation (Strategy: Work order merging and energy efficiency priority). The corresponding strategy configuration is shown in Table 1.

[0063] Table 1: Scenario 1 policy configuration table Strategic Elements Configuration Instructions Scheduling algorithm plug-in logistics.jar: supports route merging (merging threshold ≤ 200 meters) and dynamic vehicle speed adjustment (20% speed reduction when empty). Parameter configuration page factory_params.html: Set "Maximum number of merged scheduling tasks = 3" and "Energy efficiency priority mode = On". New Work Order Page factory_order.html: Bind cargo type (standard parts / fragile goods), urgency level, and site coordinates. .

[0064] 1. Map and vehicle preparation Deploy the factory logistics and transportation semantic topology map M (including sites 1-3) and connect it to the autonomous driving vehicles (drivers A and B).

[0065] 2. Create a new strategy Create a factory logistics and transportation strategy T on the web front-end management page (upload the three strategy elements logistics.jar / factory_params.html / factory_order.html), and the back-end scheduling service system saves the factory logistics and transportation strategy T.

[0066] 3. Create a new schedule A new factory logistics and transportation scheduling S is created on the Web front-end management page, and the back-end scheduling service system saves, loads and runs the scheduling S.

[0067] 3.1. Select a map (Map M); 3.2. Select a vehicle (autonomous vehicle A / B / C); 3.3. Select strategy T and enter the scheduling rules and parameters on the parameter configuration page of strategy T (factory_params.html); 3.4. Load and start schedule S.

[0068] 4. Create a new work order On the web front-end management page, users submit work orders one after another on the new work order page (factory_order.html) of scheduler S.

[0069] 4.1. Work Order 1 - "Deliver cargo X from station 1 to station 3"; 4.2, Work Order 2 - "Deliver Goods Y from Station 2 to Station 4"; 4.3, Work Order 3 - "Deliver cargo Z from station 3 to station 5"; 5. Scheduling process 5.1. Initial Allocation: Unmanned Vehicle A performs dispatch task 1 (station 1 → station 3), Unmanned Vehicle B performs dispatch task 2 (station 2 → station 4), and Unmanned Vehicle C remains on standby.

[0070] 5.2. Dynamic Adjustment (Work Order Merger): Update the dispatch task 1 executed by unmanned vehicle A to (station 1 → station 3 → station 5), and unmanned vehicle C remains on standby, reducing idle mileage and improving energy efficiency.

[0071] Scenario 2: Airport baggage transportation (Strategy: work order splitting and timeliness guarantee). The corresponding strategy configuration is shown in Table 2.

[0072] Table 2: Scenario 2 policy configuration table Strategic Elements Configuration Instructions Scheduling algorithm plug-in airport.jar: supports load balancing (dynamic splitting by baggage count) and sorting station priority. Parameter configuration page airport_params.html: Set "Maximum number of bags per trip = 80", "Unmanned vehicle C is a backup vehicle", "Threshold for enabling backup vehicles = 60% load", "Sorting platform F1 / F2 normal channels, F3 backup channel, F1 weight +20%, F1 fast sorting speed". New Work Order Page airport_order.html: Enter the flight number and the number of luggage (200 pieces). .

[0073] Scheduling process: Initial allocation (work order splitting): Autonomous vehicles A / B each transport 75 pieces of luggage to F1 / F2, and autonomous vehicle C transports 50 pieces of luggage to F1 (the load of the main vehicle exceeds the threshold, and F1 has a higher priority); Dynamic adjustment (timeliness guarantee): When F1 sorting times out, the algorithm automatically switches task 3 (performed by unmanned vehicle C) to the backup sorting station F3, ensuring sorting timeliness and improving the passenger experience.

[0074] Scenario 3: Campus cleaning (Strategy: long-term scheduling by region). The corresponding strategy configuration is shown in Table 3.

[0075] Table 3: Scenario 3 policy configuration table Strategic Elements Configuration Instructions Scheduling algorithm plug-in cleaning.jar: supports periodic task scheduling (daily / weekly cycles) and regional parameter adaptation execution Parameter configuration page campus_params.html: Set the speed in the cafeteria area to 0.8 m / s and the cleaning power to 100%. The cafeteria area is heavily oily and rubbish-laden, making it difficult to clean. Set the speed in other areas to 0.8 m / s and the cleaning power to 80%. New Work Order Page campus_order.html: Select the cleaning area, set the cycle mode and time schedule (e.g. 10:00-11:00 daily, avoid meal times in the cafeteria area, avoid class times in the teaching building area). .

[0076] Scheduling process: Canteen area: Clean three times a day (10:00-11:00, 15:00-16:00, 19:00-20:00), avoiding deep cleaning during peak hours; Teaching building area: Cleaning will be done from Monday to Friday at 21:00 to avoid disrupting classes during class time.

[0077] As can be seen from the above embodiments, the system and method realize the unified scheduling and rapid reuse of multiple types of unmanned vehicles (logistics transport vehicles, road sweepers, campus inspection vehicles, etc.) in complex scenarios through the policy configuration layer and containerized dynamic loading technology.

Claims

1. A policy-driven unmanned vehicle dispatching system, characterized in that: The system adopts a three-layer decoupled architecture, including: Framework layer: Provides basic services for data management and communication, as well as a general visual human-computer interaction interface. This layer remains unchanged when new business scenarios are added. Policy layer: supports dynamic configuration and independently encapsulates the three elements of a policy based on the scenario. The three elements include a scheduling algorithm plug-in, a parameter configuration page, and a new work order page. When expanding new business scenarios, only the three elements of the policy need to be developed and uploaded through the framework layer's web front-end. In similar business scenarios, only the scheduling rule parameters need to be modified and adjusted through the policy parameter configuration page. Scheduling layer: It can be instantiated and executes specific scheduling logic based on policy instances, directing unmanned vehicles to perform scheduling tasks and supporting parallel scheduling in multiple scenarios. Its operating mechanism is as follows: each scheduling instance is bound to an independent strategy, and an event-driven architecture is used to respond to instructions to realize scheduling task dispatch and exception recovery, and the state and process are ensured to be controllable through the state machine model.

2. The policy-driven unmanned vehicle dispatching system according to claim 1 is characterized in that: The framework layer core module includes: Web front-end for maps, work orders, and vehicle management; Scheduling service system, used for data management, container management, scheduling instantiation and operation monitoring; Automatic driving system, used for unmanned vehicle positioning, control, and fault diagnosis.

3. The policy-driven unmanned vehicle dispatching system according to claim 1 is characterized in that: Among the three elements of the strategy, the scheduling algorithm plug-in uses Docker containerization for isolation and packaging, and is supported by a JAR package dynamic loading mechanism. This supports resource isolation and hot swapping, and implements work order parsing, scheduling task generation, and exception handling logic in different business scenarios. The parameter configuration page provides exclusive parameter setting interfaces according to different business scenario types. Based on page template rendering technology, different parameter configuration pages are rendered to achieve dynamic injection of scenario-differentiated parameters. The new work order page provides an exclusive work order entry interface based on different business scenario types. Based on page template rendering technology, different new work order pages are rendered to achieve scenario-differentiated work order entry.

4. The policy-driven unmanned vehicle dispatching system according to claim 3 is characterized in that: The dynamic loading mechanism of the scheduling algorithm plug-in is as follows: The steps of the dynamic loading mechanism are: container startup, host program launch, plugin JAR loading, parameter injection, and component initialization; It uses a four-stage initialization component, including a scheduling executor, a vehicle feedback processor, a task dispatcher, and an anomaly monitor. Each module is loaded independently without interfering with each other. The scheduling executor is used to execute the scheduling algorithm, the vehicle feedback processor is used to synchronize the status, the task dispatcher is used to issue scheduling tasks, and the anomaly monitor is used for fault detection. The fault-tolerant design supports manual intervention and retry when loading fails.

5. The policy-driven unmanned vehicle dispatching system according to claim 4 is characterized in that: The operation control implementation specifications of the scheduling algorithm plug-in are as follows: The event-driven architecture designs four core events. The event bus adopts an asynchronous processing mode. The core control events include user command events, system self-healing events, state transition events, and exception trigger events. User command events are used for starting, stopping, and resuming; system self-healing events are used for automatic recovery; state transition events are used for success and failure notifications; and exception trigger events are used to schedule exception triggers. The scheduling algorithm plug-in program adopts a dual closed-loop guarantee mechanism. Its forward closed-loop process is as follows: startup, operation, and monitoring. After the scheduling runs normally, the monitoring mechanism is immediately started to detect the scheduling execution status in real time; the fault-tolerant closed-loop process is as follows: anomaly detection, downgrade switching, recovery attempt, and manual intervention. When an abnormal scheduling operation is detected, the downgraded scheduling algorithm is switched and the automatic recovery mechanism is started to try to restore normal operation.

6. The policy-driven unmanned vehicle dispatching system according to claim 1 is characterized in that: The scheduling system uses a state machine model to design the scheduling lifecycle, which mainly includes the following processes and states: Core status flow: waiting to be loaded, loading, ready, starting, scheduling, stopping, stopped, archived, to ensure the normal scheduling life cycle flow; abnormal Branch: Loading failure, startup failure, exception, recovery, and stop failure. The flow of abnormal branch status supports user retries, automatic recovery mechanisms, and manual backup strategies to prevent system deadlocks and abnormality spread; Constraint rules: The scheduling algorithm plug-in can customize the state switching conditions, but is prohibited from modifying the state flow direction to ensure system stability.

7. The scheduling method of the scheduling system according to any one of claims 1 to 6, characterized in that: The steps include: 1) Map and vehicle preparation: Create a semantic topological map of the scene and deploy autonomous vehicles; 2) Create a new policy: Create a policy on the Web front-end management page, including uploading the scheduling algorithm plug-in program JAR file, the parameter configuration page HTML file, the new work order page HTML file, and the back-end scheduling service system saves the three elements of the policy; 3) Create a new schedule: Create a new schedule on the Web front-end management page, and the back-end scheduling service system saves, loads and runs the schedule; 4) New work order: On the Web front-end management page, users submit scheduled work orders one after another; 5) Scheduling process: The scheduling algorithm plug-in defines itself according to the specific business scenario to complete the scheduling task.

Images