Unmanned intelligent driving vehicle operation task management method and system and storage medium

Abstract

The application provides an unmanned intelligent driving vehicle operation task management method and system and a storage medium, and relates to the technical field of vehicle automation scheduling control. The method comprises the following steps: in response to receiving a departure plan message sent by an external operation platform, obtaining a vehicle identifier of a target vehicle and a corresponding planned departure time; obtaining a vehicle state of the target vehicle, which is determined and updated in real time according to the current unfinished task of the target vehicle; performing a first state verification according to the vehicle state: if the vehicle state is an unusable state, a departure task is generated and an unusable alarm message is pushed to an operation terminal at the same time; if the vehicle state is an available state, only the departure task is generated; when the departure task is automatically triggered at the planned departure time, a second state verification is performed: if the vehicle state is an unusable state, the departure operation is intercepted; if the vehicle state is an available state, a departure instruction is sent to the target vehicle, thereby reducing the safety hazards of task departure.

Description

Technical Field

[0001] This application relates to the field of vehicle automated dispatch and control technology, and in particular to a method, system and storage medium for managing unmanned intelligent driving operation tasks. Background Technology

[0002] With the rapid development of autonomous driving technology, driverless ride-hailing services have gradually begun operating in specific areas. In actual operation, vehicles must strictly adhere to the daily scheduled departure and arrival procedures and park at designated stations during non-operational hours. The station management system coordinates vehicle maintenance tasks such as preparation, washing, charging, and battery swapping to ensure the reliability and safety of operations the following day. However, the dispatching and arrival of driverless vehicles at stations differs fundamentally from that of traditional manned vehicles—driverless vehicles cannot rely on driver judgment and ad-hoc decisions; their entire operation depends on precise instructions and full-process status monitoring from the back-end management system. This places higher demands on the automation level, status awareness, and anomaly handling capabilities of the dispatch management system. Simultaneously, as the fleet size continues to expand, how to efficiently, safely, and traceably manage the dispatching and arrival processes of large-scale driverless fleets has become a key technological challenge restricting the operational efficiency of driverless ride-hailing services.

[0003] In related technologies, a combination of manual dispatching and simple vehicle status management is typically used to manage the operation of autonomous vehicles. Specifically, the system maintains vehicle status fields with four values: "Available," "Operating," "Abnormal," and "Pending Preparation." These statuses are manually switched by operators via the World Wide Web (Web) or mobile devices, or automatically triggered by simple rules under specific conditions. For daily task management, operators manually create vehicle arrival, departure, and preparation tasks daily through the web-based management backend or mobile application. When the preset task time arrives, operators manually trigger task execution and issue dispatch instructions to the vehicles. When a vehicle malfunctions or requires temporary maintenance, operators similarly manually create emergency tasks and manually adjust the vehicle status to lock the vehicle. However, this management method, relying on manual coordination, results in vehicle status and task status being independent of each other. It fails to automatically determine the vehicle's true availability based on task execution, posing a safety hazard of dispatching vehicles with assigned tasks. Summary of the Invention

[0004] This application provides a method, system, and storage medium for managing unmanned intelligent vehicle operation tasks, in order to improve the problem in related technologies that the vehicle status and task status are independent of each other, which makes it impossible to automatically determine the true availability of the vehicle based on the task execution status and poses a safety hazard of dispatching vehicles with tasks.

[0005] Firstly, this application provides a method for managing the operation tasks of unmanned intelligent vehicles, applied to a site management server, including:

[0006] In response to receiving a departure plan message from an external operating platform, obtain the vehicle identifier of the target vehicle and the corresponding planned departure time;

[0007] Obtain the vehicle status of the target vehicle, which includes available and unavailable status; the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle.

[0008] Based on the vehicle status of the target vehicle, the first level of status verification is performed: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal; if the vehicle status is available, only a departure task is generated.

[0009] When the scheduled departure time is reached and the departure task is automatically triggered, a second level of status verification is performed: if the vehicle status is unavailable, the departure operation is blocked; if the vehicle status is available, a departure command is sent to the target vehicle.

[0010] In one possible embodiment, the autonomous driving operation task management method further includes: generating a vehicle collection task for the target vehicle in response to receiving a vehicle collection plan message sent by an external operation platform; wherein, when generating the vehicle collection task, a preparation task for the target vehicle is automatically generated in conjunction with it.

[0011] In one possible embodiment, the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle. This further includes: when the target vehicle is in an available state and performs a departure task to send the target vehicle off the island, switching the vehicle status from available to operational; when the target vehicle is in an operational state and completes a return task to return to the island, if there are no unfinished preparation, washing, charging, or battery swapping tasks, switching the vehicle status to available; if there are unfinished preparation, washing, charging, or battery swapping tasks, switching the vehicle status to unavailable; when the target vehicle is in an available state, if any of the following triggering conditions are detected, switching the vehicle status to unavailable, the triggering conditions include starting a return task, identifying unfinished tasks, and an abnormal operation of the currently executing task. When the target vehicle is in an unavailable state and all tasks that caused the unavailable state have been completed and the target vehicle is fault-free, the vehicle state is switched to an available state; when a preset vehicle fault signal is detected in any of the target vehicle states, including available, operational, or unavailable states, the vehicle state is switched to an abnormal state; after the vehicle fault is identified as having been eliminated, the vehicle state is restored to its original state before entering the abnormal state.

[0012] In one possible embodiment, the departure task includes a departure start node and a vehicle departure node. The departure task is executed sequentially according to the node order, specifically including: executing the departure start node: sending a departure instruction to the target vehicle so that the target vehicle starts departure according to the departure instruction; executing the vehicle departure node: confirming that the target vehicle has left the island according to the departure gate information, completing the departure task, and switching the vehicle status from available status to operational status.

[0013] In one possible embodiment, the vehicle retrieval task includes starting the return trip node, arriving at the depot node, being dispatched to a parking space node, and arriving at a parking space node. The retrieval task is executed sequentially according to the node order, specifically including:

[0014] Execute the start of the return station node: send the return station instruction and return station location information to the target vehicle, so that the target vehicle can autonomously cruise back to the station according to the return station location information;

[0015] Execute arrival at the depot node: Confirm that the target vehicle has arrived at the depot based on the entrance gate data;

[0016] Execute dispatch to parking space node: query the parking space bound to the target vehicle, send a parking space dispatch instruction to the target vehicle, so that the target vehicle can drive to the target parking space autonomously according to the parking space dispatch instruction;

[0017] Execution upon arrival at parking space: After the target vehicle completes parking, control the corresponding parking space's ground lock to lower, lock the target vehicle, and complete the vehicle return task.

[0018] In one possible embodiment, the autonomous driving operation task management method further includes: monitoring the execution status of each node; when any node fails to execute, marking the node as an abnormal state, recording the reason for the abnormality and pushing the abnormality details to the operation terminal; and providing a retry entry point for operators to trigger the node to re-execute.

[0019] In one possible embodiment, a node is marked as abnormal, the cause of the abnormality is recorded, and abnormal details are pushed to the operation terminal. A retry entry is also provided, including: displaying the node's icon or text as an abnormal identifier on the operation terminal's user interface; the abnormal details include at least the abnormal node name, a description of the cause of the abnormality, a timestamp of the abnormality occurrence, and suggested handling measures; the retry entry is a retry button, which triggers the node to re-execute in response to the operator clicking the retry button; if the retry is successful, the abnormal identifier of the node is removed, the node's normal display state is restored, and subsequent nodes continue to execute; if the retry fails, the abnormal identifier of the node is retained.

[0020] In one possible embodiment, the autonomous driving operation task management method further includes: in response to receiving an execution instruction for an emergency task, switching the vehicle state to an unavailable state to prohibit the target vehicle from performing a departure task; the emergency task includes any one of emergency vehicle return, emergency preparation, emergency car wash, emergency charging, and emergency battery swapping; after the emergency task is completed, if the target vehicle does not have any other unfinished preparation, car wash, charging, or battery swapping tasks, then switching the vehicle state to an available state.

[0021] In one possible embodiment, the autonomous driving operation task management method further includes: in response to receiving an operation instruction to forcibly switch the vehicle status from an unavailable state to an available state, triggering a secondary confirmation pop-up, the content of which indicates that the forced switch operation will close all pending tasks of the target vehicle; in response to the operator's confirmation operation in the secondary confirmation pop-up, forcibly switching the vehicle status from an unavailable state to an available state, and traversing the current list of all pending tasks of the target vehicle, uniformly adjusting the status of pending car wash tasks, charging tasks, battery swapping tasks, and maintenance tasks to abnormal termination.

[0022] In one possible embodiment, the autonomous driving operation task management method further includes: incorporating vehicle departure tasks, vehicle return tasks, and maintenance tasks into a daily task list; and acquiring periodic daily tasks created by operators in the web-based management backend or mobile terminal, instantiating the periodic daily tasks into task instances according to a preset period, and incorporating the instantiated task instances into the daily task list.

[0023] Secondly, this application provides an unmanned intelligent vehicle operation task management system, applied to a site management server, including:

[0024] The message communication module is used to respond to the departure plan message sent by the external operation platform and obtain the vehicle identifier of the target vehicle and the corresponding planned departure time.

[0025] The vehicle status management module is used to obtain the vehicle status of the target vehicle, which includes available and unavailable status. The vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle.

[0026] The task management module is used to perform the first level of status verification based on the vehicle status of the target vehicle: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal; if the vehicle status is available, only a departure task is generated.

[0027] The task execution module is used to perform a second level of status verification when the departure task is automatically triggered at the scheduled departure time: if the vehicle status is unavailable, the departure operation is blocked; if the vehicle status is available, a departure command is sent to the target vehicle.

[0028] Thirdly, this application provides a site management server, including: a processor, and a memory communicatively connected to the processor;

[0029] Memory is used to store instructions executed by the computer;

[0030] A processor for executing computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0031] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed, are used to implement the method of any one of the first aspects.

[0032] Fifthly, this application provides a computer program product, including a computer program that, when executed, implements the method of any one of the first aspects.

[0033] The autonomous driving operation task management method, system, and storage medium provided in this application, in response to receiving a departure plan message sent by an external operation platform, obtains the vehicle identifier of the target vehicle and the corresponding planned departure time; obtains the vehicle status of the target vehicle, including available and unavailable status; wherein, the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle; according to the vehicle status of the target vehicle, a first level of status verification is performed: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal; if the vehicle status is available, only a departure task is generated; when the departure task is automatically triggered at the planned departure time, a second level of status verification is performed: if the vehicle status is unavailable, the departure operation is intercepted; if the vehicle status is available, a departure command is sent to the target vehicle.

[0034] In this process, by establishing a deep linkage mechanism between vehicle status and task status, the vehicle status is determined and updated in real time based on the current incomplete tasks of the target vehicle. This allows the vehicle status to automatically and accurately reflect the task execution status, effectively reducing the risk of inconsistencies between manually set status and the actual task status, thereby reducing the probability of status misjudgment. Simultaneously, by performing status checks before generating and executing departure tasks, and issuing alarms or blocking departure operations when a vehicle is in an unavailable state, dual control before and after departure is achieved. This "early warning + interception" dual verification mechanism effectively prevents unavailable vehicles from being dispatched, fundamentally reducing the safety hazards of dispatching vehicles with tasks, and significantly improving the automation level of intelligent vehicle dispatch management, the accuracy of departure determination, and the safety and reliability of the operation process. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0036] Figure 1 A flowchart illustrating an exemplary embodiment of this application for managing the operation tasks of an unmanned intelligent vehicle;

[0037] Figure 2 A schematic diagram of a vehicle status update process provided for an exemplary embodiment of this application;

[0038] Figure 3 A schematic diagram of a daily task list provided in an embodiment of this application;

[0039] Figure 4 A schematic diagram of the structure of an autonomous intelligent vehicle operation task management system provided as an exemplary embodiment of this application;

[0040] Figure 5 A schematic diagram of the structure of a site management server provided for an exemplary embodiment of this application.

[0041] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0042] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0043] The terms "first," "second," etc., used in this application's specification and some aspects are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0044] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0045] First, let me explain the terms used in this application:

[0046] Vehicle Identification Number (VIN): Consists of 17 characters and is a unique identifier for a vehicle;

[0047] Ground lock: refers to an electronically controlled locking device installed on a parking space to prevent unauthorized vehicles from occupying the parking space;

[0048] Message Queuing Telemetry Transport (MQTT) is a lightweight message transmission protocol based on a publish / subscribe model, suitable for IoT scenarios.

[0049] Advanced Message Queuing Protocol (AMQP) is an advanced message queuing protocol that supports reliable message delivery and complex routing.

[0050] gRPC (Google Remote Procedure Call) is a high-performance, open-source remote procedure call framework.

[0051] WebSocket: refers to a protocol that enables full-duplex communication over a single TCP connection, suitable for real-time data push scenarios.

[0052] Remote Procedure Call (RPC) is a technique that allows a program to call a function or method located on a remote server.

[0053] In related technologies, when using a combination of manual scheduling and simple vehicle status management for the operation and management of autonomous vehicles, several problems arise. First, because vehicle status is independent of specific task statuses such as vehicle return, departure, preparation, washing, charging, and battery swapping, vehicle status is manually switched by operators rather than automatically determined based on task completion. The current task execution status cannot be judged by whether the vehicle is available; for example, if a vehicle has an incomplete charging task, its status may still show as available, making it impossible for operators to intuitively and accurately determine the vehicle's true availability. Second, the vehicle return and departure process heavily relies on manual intervention. Daily departure and return tasks require operators to manually create and trigger execution, which is cumbersome and prone to delays due to human error, resulting in low operational efficiency and difficulty in supporting automated scheduling of large-scale fleets. Furthermore, the lack of an effective status verification mechanism before departure means that the system may still allow a vehicle to depart even if it has incomplete preparation, washing, charging, or battery swapping tasks, posing a safety hazard of dispatching vehicles with faults or tasks.

[0054] To address the aforementioned technical challenges, this application provides an unmanned intelligent vehicle operation task management solution. By responding to departure plan messages sent by an external operation platform, it automatically generates departure tasks for target vehicles, achieving automatic task generation. Through a deep linkage mechanism between vehicle and task status, it determines and updates the vehicle status as available or unavailable in real time based on whether the target vehicle currently has any unfinished tasks such as vehicle collection, preparation, washing, charging, or battery swapping. This ensures that the vehicle status accurately reflects the actual execution of tasks. Furthermore, a dual status verification mechanism is implemented. A first verification is performed before generating a departure task; if the vehicle status is unavailable, an alarm message is pushed to the operation terminal. A second verification is performed before executing the departure task; if the vehicle status is unavailable, the departure operation is directly intercepted. This dual protection of "early warning + interception" ensures that unavailable vehicles cannot be dispatched, fundamentally reducing the safety risks of dispatching vehicles with assigned tasks. This significantly improves the automation level of intelligent vehicle collection and dispatch management, the accuracy of departure determination, and the safety and reliability of the operation process.

[0055] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0056] Figure 1 A flowchart illustrating an exemplary embodiment of this application shows a method for managing the operation tasks of an unmanned intelligent vehicle. Figure 1 As shown, the autonomous driving operation task management method includes the following steps:

[0057] S101. In response to receiving a departure plan message from an external operating platform, obtain the vehicle identifier of the target vehicle and the corresponding planned departure time.

[0058] The depot management server, as the implementing entity of this application, can be deployed in the depot operation backend or cloud computing environment, and establish data communication connections with external operation platforms, operation terminals, and target vehicles. The external operation platform, according to preset operation rules, sends a departure plan message to the depot management server at a specified time before the start of operation each day. The departure plan message carries at least a vehicle identifier, such as the vehicle VIN code, and a planned departure time. The vehicle identifier is used to locate the target vehicle, and the planned departure time is used to determine the trigger time for subsequent departure tasks. Correspondingly, upon receiving the departure plan message, the depot management server parses and verifies the message. If the verification passes, it obtains the vehicle identifier of the target vehicle and the corresponding planned departure time, and generates the corresponding departure task accordingly. When the external operation platform sends a modified departure plan message, the depot management server can locate the existing plan record based on the vehicle identifier and update the planned departure time to the latest value.

[0059] It should be noted that the above-mentioned message communication methods are not the only implementation. In actual deployment, the internal modules of the site management server can use an internal message bus or RPC in a microservice architecture to achieve message passing; message sending and receiving between the site management server and the external operation platform can be implemented using MQTT, AMQP, or Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) interfaces; in addition, for communication with the external operation platform, besides using MQTT or HTTP / HTTPS interfaces, real-time communication protocols such as gRPC and WebSocket can also be selected according to the network environment to meet the low-latency communication requirements in different scenarios.

[0060] Based on the above implementation, the departure plan message is not merely saved as a static notification, but directly drives the depot management server to establish a departure plan context for the target vehicle. This ensures that subsequent vehicle status acquisition, task generation, and departure control are all executed around the same vehicle identifier and the same planned departure time, thus forming a closed-loop operation management link for each vehicle. As the analysis above shows, this step, by receiving departure plan messages from external operation platforms, extracting vehicle identifiers and planned departure times, and generating corresponding departure tasks, transforms the previously manually created departure tasks into task objects automatically created by the depot management server. This provides subsequent control processes with clearly defined vehicle objects and definite trigger times, which is a prerequisite for the automatic management of unmanned intelligent vehicle operation tasks.

[0061] S102. Obtain the vehicle status of the target vehicle, which includes available status and unavailable status; the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle.

[0062] Accordingly, when a target vehicle has unfinished tasks, the vehicle status is determined to be unavailable; when all tasks are completed or closed, the vehicle status is determined to be available. Unfinished tasks include at least one of the following: vehicle collection task, maintenance task, car wash task, charging task, and battery swapping task.

[0063] The vehicle status reflects whether the target vehicle currently meets the departure conditions. In this application, a static field with manual marking is not used; instead, the station management server determines this in real-time based on the task status in the task system. An available status indicates that the target vehicle has no unfinished tasks preventing departure, while an unavailable status indicates that the target vehicle has at least one unfinished and unclosed task. Unfinished tasks include at least one of the following: vehicle return task, maintenance task, car wash task, charging task, and battery swapping task. Specifically, the vehicle return task indicates whether the vehicle's return process from the previous operating cycle has ended; the maintenance task indicates whether the vehicle's inspection, cleaning, and material recovery process after returning to the station has been completed; the car wash task indicates whether the vehicle cleaning process has ended; the charging task indicates whether the vehicle recharging process has ended; and the battery swapping task indicates whether the battery replacement process has ended. In practice, the station management server retrieves the associated tasks of the target vehicle based on the vehicle identifier obtained in S101, filters records whose task type belongs to the above task set and whose task status is neither completed nor closed, and uses the filtering results as the current status of unfinished tasks. For example, task status may include states such as pending, executing, suspended, completed, and closed, where pending, executing, and suspended are all identified as incomplete states; completed and closed are identified as states that do not constitute a departure obstacle. Correspondingly, after obtaining information about incomplete tasks, the depot management server executes status judgment logic: when there are incomplete tasks, the vehicle status of the target vehicle is determined to be unavailable; when all tasks have been completed or closed, the vehicle status of the target vehicle is determined to be available. In one possible embodiment, the depot management server may recalculate the vehicle status of the target vehicle when the task status changes; in another possible embodiment, the depot management server may perform an incomplete task scan on target vehicles that have received departure plans at preset time intervals. Based on the above analysis, this step establishes a real-time mapping relationship between the vehicle status and the current unfinished tasks, enabling the vehicle status to accurately reflect whether the target vehicle is still undergoing any of the processes of receiving, preparing, washing, charging, or swapping batteries before departure. This allows subsequent departure-related judgments to rely directly on the task execution results rather than human experience, thus constituting a key processing link in solving the problem of the disconnect between vehicle status and actual tasks.

[0064] S103. Based on the vehicle status of the target vehicle, perform the first level of status verification: if the vehicle status is unavailable, generate a departure task and push an unavailable alarm message to the operation terminal; if the vehicle status is available, generate only a departure task.

[0065] The first level of status verification occurs after the departure plan message is received and the vehicle status is acquired. Its goal is to confirm, while establishing the departure task, whether the target vehicle meets the departure conditions. The departure task is an operational task created by the depot management server for the target vehicle, used to control the target vehicle to enter the departure process at the corresponding planned departure time. The operation terminal receives alarms and task information from the depot management server. Unavailable alarm messages are used to inform operations personnel that the target vehicle still has incomplete tasks and the current departure conditions are not met. Specifically, the depot management server constructs departure task records based on vehicle identification, planned departure time, and current vehicle status. When S102 determines the vehicle status to be available, the depot management server generates a departure task and does not send an unavailability alarm message. When S102 determines the vehicle status to be unavailable, the depot management server still generates a corresponding departure task to ensure that the plan is still retained by the system and enters the subsequent departure processing link. At the same time, it generates an unavailability alarm message based on the incomplete tasks and pushes it to the operation terminal. The unavailability alarm message can include the target vehicle's vehicle identifier and parking space number, for example, the content format of the unavailability alarm message is "Vehicle VIN code: XXXXXXXXXXXXXXXX, Parking space number: XXXXXX, X tasks are incomplete, vehicle status is unavailable and cannot depart, please handle in time", so that the operation personnel can perform subsequent actions based on the alarm content. Based on the above analysis, it can be seen that the first level of status verification does not abandon the generation of departure tasks because the vehicle is currently unavailable, but outputs an unavailability alarm to the operation terminal while retaining the planned tasks, so that the plan information, task information and status risk information are processed in a coordinated manner at the same time, thereby realizing the pre-departure reminder and automatic task creation processing.

[0066] S104. When the departure task is automatically triggered at the scheduled departure time, a second level of status verification is performed: if the vehicle status is unavailable, the departure operation is intercepted; if the vehicle status is available, a departure command is sent to the target vehicle.

[0067] The second level of status verification is automatically executed by the depot management server when the scheduled departure time arrives. It is used to reconfirm the real-time status of the target vehicle before the actual departure action occurs, thereby handling possible status changes between the first level of status verification and the actual departure. The departure operation refers to the control action that causes the target vehicle to leave the depot and enter the operating route as planned. The departure instruction refers to the executable control command sent by the depot management server to the target vehicle. After receiving the command, the target vehicle enters the preset departure process. In practice, when a departure task is automatically triggered, the depot management server retrieves the latest vehicle status at that point in time based on the vehicle identifier. If the second retrieved vehicle status is unavailable, the depot management server marks the departure task as a departure interception and terminates the process of sending the departure command to the target vehicle. Simultaneously, it records the reason for the interception in the task execution log. The reason for the interception is generated based on the current incomplete task status and can be the same as the reason during the first level of status verification, or it can reflect the incomplete task status that occurred after the first level of status verification. Additionally, a departure failure reason message can be pushed to the operation terminal. The content format of the departure failure reason message is "Vehicle VIN: XXXXXXXXXXXXXXXX, Parking Space Number: XXXXXX, Current Vehicle Status (Unavailable / Abnormal), Departure Failed, Please Handle Promptly." Conversely, if the second retrieved vehicle status is available, the depot management server marks the departure task as allowed to depart and sends a departure command to the target vehicle. The departure command includes at least the target vehicle identifier and a departure execution command. Correspondingly, after receiving the departure command, the target vehicle reports the reception result, and the depot management server saves the command issuance time, response status, and task execution status, forming a complete departure execution record. In one possible embodiment, the second state verification occurs before the departure command is issued to ensure that the verification result corresponds to the actual control action. Based on the above analysis, this step extends the confirmation of departure conditions from the time of task generation to the time of task execution by performing state verification again at the planned departure time. This allows the system to identify target vehicles that have not completed the tasks of vehicle collection, preparation, washing, charging, or battery swapping before departure and directly intercept the departure operation for such vehicles. For target vehicles whose status meets the departure conditions, the departure command is automatically sent, thus forming a dual state verification mechanism that connects the two stages.

[0068] The unmanned intelligent vehicle operation task management method provided in this application establishes a deep linkage mechanism between vehicle status and task status. Specifically, it determines and updates the vehicle status in real time based on the current incomplete tasks of the target vehicle. When there are incomplete tasks, the vehicle is automatically determined to be in an unavailable state; when all tasks are completed or closed, the vehicle is automatically determined to be in an available state. This allows the vehicle status to automatically and accurately reflect the task execution status, effectively reducing the risk of inconsistencies between manually set status and the actual task status, thereby reducing the probability of status misjudgment. Simultaneously, by performing status verification before generating and executing a departure task, and issuing alarms or intercepting departure operations when the vehicle is in an unavailable state, dual control before and after departure is achieved. This "early warning + interception" dual verification mechanism effectively prevents unavailable vehicles from being dispatched, fundamentally reducing the safety hazards of dispatching vehicles with tasks, and significantly improving the automation level of intelligent vehicle dispatch management, the accuracy of departure determination, and the safety and reliability of the operation process.

[0069] In some embodiments, the autonomous driving operation task management method further includes: in response to receiving a vehicle collection plan message sent by an external operation platform, generating a vehicle collection task for the target vehicle; wherein, when generating the vehicle collection task, a preparation task for the target vehicle is automatically generated in conjunction with it.

[0070] In this embodiment, the external operating platform sends a vehicle collection plan message to the depot management server at a specified time before the end of the day's operation, according to preset operating rules. The vehicle collection plan message includes at least vehicle identification, such as the vehicle VIN code, and the planned collection time.

[0071] It should be noted that the triggering methods for the aforementioned departure and return tasks are not the only implementation. In actual deployment, in addition to automatic timed triggering, the intelligent dispatch engine can dynamically calculate the optimal triggering time by combining dynamic factors such as real-time vehicle location, road congestion, and weather conditions, achieving more refined dispatch control. For example, when the target vehicle's current location is far from the depot or real-time traffic conditions show road congestion leading to the depot, the intelligent dispatch engine can appropriately advance the return task to ensure the vehicle returns to the island within the planned time; when real-time traffic conditions show clear roads, the return task can be appropriately delayed to improve vehicle operating efficiency. The same applies to the triggering of departure tasks. When weather conditions are severe (such as rain, snow, or heavy fog) or road congestion is serious, the intelligent dispatch engine can delay the triggering of departure tasks, executing departures only after the weather improves or roads become clear, thus ensuring both operational safety and operational efficiency.

[0072] Correspondingly, after receiving the vehicle return plan message, the station management server first parses the vehicle identifier and planned return time to determine the target vehicle. The server then creates a return task for the target vehicle in the task management module, with the task record containing at least the vehicle identifier, planned return time, task status, and task source information. Simultaneously, the server synchronously generates a preparation task corresponding to the return task based on preset association rules, establishing a task association field between the preparation task and the return task, allowing them to be managed within the same task chain. This association field can be implemented using task number mapping or parent-child task binding, enabling the preparation task to automatically enter a pending execution state when the return task is triggered or completed. The planned start time for the preparation task can be set by default to either after the return task is completed or before the start of operations the following day.

[0073] In its implementation, the depot management server can write vehicle return tasks and maintenance tasks into the same task queue, and the execution result of the vehicle return task serves as the activation condition for the maintenance task. When the target vehicle returns to the depot according to the vehicle return task, the server automatically switches the maintenance task status based on the task association relationship and pushes the maintenance task to the operation terminal or depot operation terminal so that subsequent operators or automated equipment can perform the corresponding maintenance work. In practical applications, this task association method can also be adjusted according to business configuration to parallel recording, serial triggering, or automatic deriving of child tasks after the parent task is completed; this application does not limit this.

[0074] By adopting the above method, the vehicle return plan message can directly drive the generation of return tasks, and the maintenance task will be created and bound together accordingly, thus enabling the maintenance work after the vehicle returns to the depot to be continuously connected with the vehicle return management. Since the return task and the maintenance task are automatically generated by the server, the consistency of the task chain is maintained, which reduces the occurrence of task omissions and manual duplication, thereby making the management of returning vehicles on the depot side more consistent.

[0075] In some embodiments, determining and updating the vehicle status in real time based on the current unfinished tasks of the target vehicle further includes: when the target vehicle is in an available state and performs a departure task to send the target vehicle off the island, switching the vehicle status from an available state to an operational state; when the target vehicle is in an operational state and completes a return task to the island, if there are no unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, switching the vehicle status to an available state; if there are unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, switching the vehicle status to an unavailable state; when the target vehicle is in an available state, if... If any of the following trigger conditions are detected, the vehicle status will be switched to an unavailable state: the start of a vehicle recovery task, the detection of an incomplete task, or an abnormal operation of a currently executing task. When the target vehicle is in an unavailable state and all tasks that caused the unavailable state have been completed and the target vehicle is fault-free, the vehicle status will be switched to an available state. When a preset vehicle fault signal is detected in any of the target vehicle's states (available, operational, or unavailable), the vehicle status will be switched to an abnormal state. After the vehicle fault has been identified and resolved, the vehicle status will be restored to its original state before entering the abnormal state.

[0076] In practical implementation, the station management server can maintain a vehicle maintenance status database. This database establishes status, task, and fault fields for each target vehicle. It also receives completion receipts for dispatch, return, preparation, washing, charging, and battery swapping tasks through a task management module. For example, Figure 2 This is a schematic diagram illustrating the vehicle status update process provided for an exemplary embodiment of this application. Figure 2 As shown, when the target vehicle is in an available state and performs a departure task to send the target vehicle off the island, the server updates the status field to "operating". When the target vehicle is in an operating state and completes the return task to return to the island, the server reads the task field to see if there are still any unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks. If there are no such unfinished tasks, the server updates the status field to "available". If there are such unfinished tasks, the server updates the status field to "unavailable". When the target vehicle is in an available state, if it detects the start of a return task, identifies an unfinished task (including at least one of preparation tasks, car wash tasks, charging tasks, and battery swapping tasks), or if the currently executing task is running abnormally, the server updates the status to "unavailable". When all the tasks that caused the unavailable status are completed and the fault field is empty, the system returns to an available state.

[0077] Furthermore, when a vehicle fault signal is detected in any of the target vehicle's states—available, operational, or unavailable—the vehicle state is switched to an abnormal state. This vehicle fault signal can be output by the onboard controller, chassis control unit, battery management unit, or communication monitoring unit. Upon receiving this signal, the server sets the target vehicle to an abnormal state and records the original state identifier before entering the abnormal state. After the vehicle fault signal is cleared, the server restores the vehicle state to its original state before entering the abnormal state based on the recorded original state identifier.

[0078] Still referencing Figure 2 Vehicle status is categorized into four mutually exclusive states: available, operational, abnormal, and unavailable. In practical applications, a state machine pattern can also be used: each state transition rule is defined as a state transition table, and the state machine engine drives state changes uniformly. Specifically, upon receiving events such as vehicle departure, vehicle return to the island, task completion, or vehicle malfunction, the state machine engine queries the state transition table and transitions the vehicle status to the corresponding next state. This pattern centrally manages state change logic; each business module only needs to deliver events, eliminating the need for decentralized maintenance of transition conditions. This makes state management more standardized, helps reduce the risk of state inconsistency, and facilitates the subsequent expansion of new states or transition rules.

[0079] In this embodiment of the application, by adopting the above-mentioned state linkage mechanism, the vehicle state can be kept consistent with the departure, return and maintenance tasks, and can be independently switched to an abnormal state when a fault occurs, so that the scheduling results are updated synchronously with the actual availability of the vehicle.

[0080] Considering that in related technologies, when problems such as communication failures, abnormal vehicle positioning, and parking space conflicts occur during the execution of vehicle departure or arrival tasks, existing systems lack effective anomaly identification and retry mechanisms, making it difficult for island staff to quickly locate abnormal nodes and resume task execution. Therefore, in some embodiments, the departure task includes a departure start node and a vehicle departure node, and the departure task is executed sequentially according to the node order, specifically including: executing the departure start node: sending a departure command to the target vehicle, causing the target vehicle to start departure according to the departure command; executing the vehicle departure node: confirming that the target vehicle has left the island based on the departure gate information, completing the departure task, and switching the vehicle status from available to operational status.

[0081] For example, when executing the start departure node, the depot management server establishes a departure control session based on the target vehicle identifier corresponding to the departure task and sends a departure command to the target vehicle so that the vehicle can start driving when the departure conditions are met. After the target vehicle completes its start and drives towards the depot exit, the depot management server continuously receives departure gate information uploaded by the departure gate. When the departure gate information indicates that the target vehicle has passed through the exit, it can be confirmed that the vehicle has left the island, and the departure task is terminated accordingly. After the departure task is completed, the vehicle status changes from available to operational, indicating that the target vehicle has entered the daily operation process and can continue to receive operational scheduling commands.

[0082] By dividing the departure task into two sequentially executed nodes—the start departure node and the vehicle departure node—departure control and departure confirmation are executed at different nodes, ensuring consistency in timing between departure actions and state transitions. Specifically, at the start departure node, the depot management server issues a departure command to the target vehicle, triggering the vehicle to start and leave the depot. At the vehicle departure node, the depot management server confirms the target vehicle has left the island based on the departure gate information, completing the departure task and switching the vehicle status from available to operational. This node-based execution method synchronizes vehicle status with actual departure behavior, allowing the depot management server to record the operational status of target vehicles more accurately and providing a consistent state basis for subsequent scheduling and task management.

[0083] Based on the above embodiments, the vehicle retrieval task further includes a start return node, an arrival at the depot node, a dispatch to a parking space node, and an arrival at a parking space node. The vehicle retrieval task is executed sequentially according to the node order, specifically including:

[0084] Execute the start of the return station node: send the return station instruction and return station location information to the target vehicle, so that the target vehicle can autonomously cruise back to the station according to the return station location information;

[0085] Execute arrival at the depot node: Confirm that the target vehicle has arrived at the depot based on the entrance gate data;

[0086] Execute dispatch to parking space node: query the parking space bound to the target vehicle, send a parking space dispatch instruction to the target vehicle, so that the target vehicle can drive to the target parking space autonomously according to the parking space dispatch instruction;

[0087] Execution upon arrival at parking space: After the target vehicle completes parking, control the corresponding parking space's ground lock to lower, lock the target vehicle, and complete the vehicle return task.

[0088] In practical applications, return-to-station instructions and parking space scheduling instructions can be sent to the target vehicle via the onboard communication module. The communication module can adopt a cellular network communication unit or a parking lot dedicated network communication unit to ensure the continuity and reachability of instruction issuance. Entrance gate data can be provided by the gate controller, image recognition terminal, or ground sensor unit. The ground lock can be controlled by a motor drive mechanism for lifting and lowering, and the current locking status is transmitted back to the server via a lock position feedback signal.

[0089] The vehicle return task includes the start return node, arrival at the depot node, dispatch to a parking space node, and arrival at a parking space node, executed sequentially according to the node order. For example, when executing the start return node, the depot management server automatically triggers the return task at the end of the vehicle's operating time. It sends a return command and return point location information to the target vehicle via the message communication module. The return point location information includes at least the latitude and longitude coordinates of the depot entrance and a recommended driving route. The target vehicle autonomously cruises back to the depot according to the recommended route. When executing the arrival at the depot node, after the target vehicle reaches the depot entrance area, the depot management server confirms the vehicle's arrival based on the entrance gate data. This entrance gate data includes the vehicle arrival signal reported by the gate controller, license plate recognition results collected by the signal and image recognition terminal, or vehicle arrival signals triggered by the ground sensor unit. When executing the dispatch to a parking space node, the depot management server queries the parking space bound to the target vehicle and generates the optimal route based on the depot map and real-time parking space occupancy status. The parking space dispatch instruction includes the target parking space number, route planning data, and obstacle avoidance instructions. The target vehicle autonomously drives to the target parking space according to the parking space dispatch instruction. Upon arrival at the parking space node, the target vehicle completes the precise parking operation according to the parking space dispatch instruction. Subsequently, the station management server controls the corresponding parking space's ground lock to descend and confirms the ground lock has descended through the lock position feedback signal, thus locking the vehicle. At this point, the vehicle return task is completed, and the vehicle status changes from operating status to unavailable status (if there is a maintenance task associated with it, the unavailable status remains).

[0090] It's important to note that in actual deployment, parking space scheduling isn't limited to simply allocating spaces based on the target vehicle's current location and the distribution of available spaces. Further considerations can be given to factors such as vehicle type, charging needs, and maintenance plans. Multi-objective optimization algorithms can be employed to allocate optimal parking spaces to vehicles, thereby improving the rationality and operational efficiency of parking space scheduling. For example, when the target vehicle is a new energy vehicle requiring charging, the scheduling algorithm can prioritize parking spaces equipped with charging piles, allowing the vehicle to charge simultaneously while parked. When the system detects that a target vehicle is approaching its maintenance cycle or has an pending maintenance plan, the scheduling algorithm can prioritize allocating spaces near the preparation or maintenance area to shorten the transfer distance for subsequent maintenance operations. When multiple vehicles return to the station simultaneously, the scheduling algorithm can comprehensively calculate the suitability score of each parking space based on the vehicle's charging urgency, maintenance priority, and current location, allocating the parking space with the best overall score to each vehicle, thus avoiding congestion caused by multiple vehicles waiting for the same type of parking space. By introducing multi-objective optimization algorithms for parking space scheduling, the allocation of parking spaces in the vehicle return task is no longer limited to matching a single available parking space, but comprehensively considers multiple factors such as vehicle attributes and operation plans, thereby achieving refined allocation of parking space resources and improving the overall operational efficiency of the depot.

[0091] The vehicle retrieval task links the return to the station, arrival at the station, parking, and locking of the vehicle into a continuous closed loop. The station management server confirms the arrival status based on the data from the entrance gate, generates a parking scheduling instruction based on the bound parking space, and triggers the ground lock to lock after parking is completed, so that the target vehicle is in a verifiable, schedulable, and fixed control state throughout the entire retrieval process.

[0092] In this embodiment of the application, by dividing the vehicle return task into multiple nodes to be executed sequentially, the return, positioning and locking of vehicles are all uniformly controlled by the server. The completion status of vehicle return is jointly confirmed by the entrance gate data and the status of the ground lock, which ensures that the vehicle return process has high execution consistency and status traceability.

[0093] In some embodiments, the autonomous driving operation task management method further includes: monitoring the execution status of each node; when any node fails to execute, marking the node as an abnormal state, recording the reason for the abnormality and pushing the abnormality details to the operation terminal; and providing a retry entry point for operators to trigger the node to re-execute.

[0094] In practical implementation, after generating departure or return tasks, the station management server establishes corresponding status records for each node and refreshes the status fields when a node starts, is executing, completes, or fails. The server can obtain the execution results of nodes through the task scheduling module, vehicle control interface, gate feedback interface, and parking space control interface, and compare the results with preset success conditions. When the comparison result shows that a node has not returned a successful response as scheduled, has not completed the task after a timeout, or has returned a failure code, the server determines that the node has failed and updates the node's status field to an abnormal state, while also writing an exception reason field. The exception reason field may include communication timeout, vehicle not responding, gate not recognizing, parking space scheduling failure, ground lock control failure, or interface error code. The exception details are assembled by the server according to the exception node name, exception reason, exception occurrence time, and suggested handling measures, and then pushed to the operation terminal. After receiving the anomaly details, the operation terminal can display the anomaly identifier and retry entry in the task interface. After verifying the anomaly information, the operation personnel can trigger this entry, and the server will resend the execution request to the corresponding node. After the retry is successful, the node will be restored to the normal state. If the retry still fails, the node will remain in the anomaly state and the latest anomaly reason will be updated.

[0095] Under this mechanism, the server continuously monitors each stage of the daily departure and arrival tasks, and manages the status, cause, displayed information, and retry actions of failed nodes in a coordinated manner. This ensures that anomalies are promptly identified, accurately recorded, and quickly reported back to the operations terminal. By allowing operations personnel to directly initiate re-execution of failed nodes, the server can repair individual anomalies without rolling back the entire task, thereby improving the continuity and efficiency of task execution.

[0096] In some embodiments, nodes are marked as abnormal, the cause of the abnormality is recorded, and abnormal details are pushed to the operation terminal. A retry entry is also provided, including: displaying the node's icon or text as an abnormal identifier on the operation terminal's user interface; the abnormal details include at least the abnormal node name, a description of the cause of the abnormality, a timestamp of the abnormality occurrence, and suggested handling measures; the retry entry is a retry button, which triggers the node to re-execute in response to the operator clicking the retry button; if the retry is successful, the abnormal identifier of the node is removed, the node's normal display state is restored, and subsequent nodes continue to execute; if the retry fails, the abnormal identifier of the node is retained.

[0097] In actual operation, the station management server monitors the execution results of each node in the arrival and departure tasks in real time through the exception handling module. Upon detecting any node failure, the server determines the node has failed based on the execution result feedback, updates the node's status to an abnormal state, and simultaneously generates an exception record. The cause of the exception and the time of occurrence are recorded in the system log database. Simultaneously, exception details, including the abnormal node name, a description of the cause, a timestamp of the exception, and suggested handling measures, are sent to the operations terminal. Upon receiving the exception details, the operations terminal updates the exception indicator in the corresponding node's display area, for example, by highlighting the node's icon or text in red to visually alert operations personnel that the node is abnormal. A retry button is also added in the same area as the entry point for the retry function. When operations personnel click this button, the server initiates a re-execution request to the node's control logic, re-invoking the task processing interface or control command corresponding to that node. After the server performs a retry operation, it determines whether the node has successfully re-executed. If the node returns a successful result after re-execution, the server removes the abnormal flag of the node, restores its display to the normal state, and continues to drive the execution of subsequent nodes. If a failure result is returned, the abnormal flag remains unchanged, and the server waits for further processing by operations personnel, such as manual on-site intervention or contacting technical support personnel.

[0098] It should be noted that the above-mentioned anomaly identification methods are not the only implementation. In actual deployment, in addition to highlighting the icons or text of abnormal nodes in red, other methods such as icon flashing, pop-up prompts, and audible alarms can be selected to identify abnormal nodes, or a combination of these methods can be used, depending on the equipment capabilities of the operating terminals and the needs of the operational scenario, to enhance the visibility of anomaly alerts. For example, for operating terminals deployed on large monitoring screens at sites, icon flashing combined with pop-up prompts can be used to quickly locate abnormal nodes in the global view; for mobile terminals carried by operators, audible alarms combined with red highlighting can be used to ensure that abnormal nodes are detected and handled promptly; for central control room terminals that monitor multiple sites simultaneously, icon flashing combined with pop-up prompts and audible alarms can be used to ensure that abnormal information is detected promptly on different terminal devices. By using the above-mentioned multiple anomaly identification methods or combinations of multiple methods, operators can quickly perceive the occurrence of anomalies and accurately locate abnormal nodes, effectively shortening the time for anomaly detection and response.

[0099] This approach links the display of abnormal states and information with retry triggers. The exception handling module monitors the execution results of each execution node in real time and sequentially performs the full-process processing provided by the node marking, exception identification, reason recording, details push, and retry entry when execution fails. The operation terminal can directly display the specific information of the abnormal node and complete the retry operation. The server controls the node display status and subsequent node connection based on the retry results, and records the entire exception handling process to the system log database, thereby ensuring that the exception handling process remains continuous, consistent, and traceable.

[0100] In this embodiment, by marking the failure, recording the cause, pushing details, and providing a retry entry when an execution node fails, the system synchronously presents the location information of the abnormal node, the time of occurrence, and the handling suggestions. It clarifies the interface state changes when the retry is successful and unsuccessful, ensuring that the node can directly connect to the execution of subsequent nodes after it recovers.

[0101] In some embodiments, the autonomous driving operation task management method further includes: in response to receiving an execution instruction for an emergency task, switching the vehicle state to an unavailable state to prohibit the target vehicle from performing a departure task; the emergency task includes any one of emergency vehicle return, emergency preparation, emergency car wash, emergency charging, and emergency battery swapping; after the emergency task is completed, if the target vehicle does not have any other unfinished preparation, car wash, charging, or battery swapping tasks, then switching the vehicle state to an available state.

[0102] In practical implementation, the server can bind and manage emergency tasks with the task queues of target vehicles. Upon receiving the execution instruction for an emergency task, the server switches the target vehicle's status to an unavailable state and locks the vehicle's departure permission. This allows the departure scheduling module to directly read the unavailable status and intercept the departure instruction during departure verification, thus preventing the target vehicle from executing the departure task. Emergency tasks are one-time tasks created by operators through the web-based management backend or mobile terminals, including any one of emergency vehicle return, emergency preparation, emergency car wash, emergency charging, and emergency battery swapping. After an emergency task is completed, the server further queries whether the target vehicle still has any unfinished preparation, car wash, charging, or battery swapping tasks. If the query result is empty, a status recovery instruction is sent to the status management module to restore the vehicle's status to an available state; if any unfinished task remains, the unavailable state is maintained. This control can be implemented by the software logic of the depot management server. Relevant task records can be stored in the task database, and the status switching results are synchronously updated to the vehicle status table for real-time reading by the departure verification module.

[0103] In this implementation, once an emergency task is triggered, vehicle dispatch authority is immediately suspended, and the vehicle status is simultaneously switched to an unavailable state. This prevents the vehicle from being scheduled for routine dispatch tasks by the dispatch task execution module before the emergency task is completed. After the emergency task is finished, the remaining unfinished maintenance tasks determine whether the vehicle status should be restored to available status. This ensures that the vehicle status is consistent with the on-site emergency response task and establishes a direct linkage between dispatch control and emergency maintenance control. Since status restoration depends on the actual existence of unfinished tasks, the vehicle only regains dispatch eligibility after all maintenance tasks have been cleared.

[0104] In this embodiment, the vehicle status is directly switched to an unavailable state in response to the execution command of an emergency task. During the emergency task, the target vehicle is prohibited from performing dispatch tasks. After the emergency task is completed, the decision to restore the vehicle to an available state is based on whether there are still other unfinished preparation, washing, charging, or battery swapping tasks. This makes the vehicle status switching path in emergency maintenance scenarios clear and requires no manual intervention. The vehicle only automatically regains its dispatch eligibility after all maintenance tasks are completed. This method allows the target vehicle to promptly exit dispatch scheduling in emergency scenarios and automatically regains availability after all maintenance tasks are cleared. This effectively reduces the safety risk of vehicles being mistakenly dispatched during emergency maintenance. Furthermore, the absence of manual intervention in the status switching process reduces safety hazards caused by delays or oversights in manual operation, further improving the accuracy of vehicle status management.

[0105] Based on the above embodiments, the autonomous intelligent driving operation task management method further includes: in response to receiving an operation instruction to forcibly switch the vehicle status from an unavailable state to an available state, triggering a secondary confirmation pop-up, the content of which indicates that the forced switching operation will close all pending tasks of the target vehicle; in response to the operator's confirmation operation in the secondary confirmation pop-up, forcibly switching the vehicle status from an unavailable state to an available state, and traversing the current list of all pending tasks of the target vehicle, uniformly adjusting the status of pending tasks such as car washing, charging, battery swapping, and maintenance to abnormal termination.

[0106] After the operator clicks "confirm," the server updates the target vehicle's status to "available" and queries the current list of tasks to be executed based on the target vehicle's identifier. This task list is maintained in real-time by a task management table, which records the task type, task status, associated vehicle identifier, and creation time for each task. While traversing this list, the server writes the execution status of each car wash, charging, battery swapping, and maintenance task, uniformly changing it from "pending execution," "in execution," or "awaiting confirmation" to "abnormal termination," and simultaneously records the reason for the forced shutdown, the operation timestamp, and the operator's identifier. The abnormal termination status indicates that the task was abnormally closed due to a forced status switch, and the scheduling module will not issue execution control commands to that task again based on this information.

[0107] In this implementation, the secondary confirmation pop-up and task cleanup logic are controlled by the same transaction. The server performs batch writing of task status after completing the vehicle status update, or performs status verification and persistence simultaneously before transaction commit to ensure consistency between vehicle status and task status. If no corresponding task type is found during the traversal of the task list, the writing process for that task type is skipped and the remaining task types are processed. The secondary confirmation pop-up can be in the form of a masked prompt window, with its content area displaying the scope of the closed effect, and the confirmation button and cancel button corresponding to continue execution and abort forced switching, respectively.

[0108] After adopting the above method, operators can access the vehicle management page via a mobile application and issue an operation command to forcibly switch the vehicle status from unavailable to available. The server first triggers a secondary confirmation pop-up, indicating that the operation will close all pending tasks for the target vehicle. After the operator confirms, the server forcibly switches the vehicle status from unavailable to available and simultaneously clears the target vehicle's pending car wash, charging, battery swapping, and maintenance tasks, marking them as abnormally terminated and removing them from the pending task list. This ensures that the status switch result is consistent with the task management result, reducing the chance of subsequent scheduling mis-triggering of failed tasks. The secondary confirmation pop-up allows operators to clearly understand the scope of closure before performing the forced switch, reducing the probability of misoperation and making the task closure process traceable.

[0109] In this embodiment, a secondary confirmation pop-up is first triggered in response to a forced switching command issued by the operator. This ensures that the operator is fully aware that the operation will close all pending tasks on the target vehicle before performing the forced switch, effectively reducing the risk of tasks being abnormally closed due to misoperation. After the operator confirms, the server automatically switches the vehicle status from unavailable to available and simultaneously iterates through the current list of all pending tasks, uniformly adjusting the status of pending tasks such as car wash, charging, battery swapping, and maintenance to abnormal termination. This keeps the vehicle status switching result synchronized with the task management result, reducing the problem of failed tasks remaining in the pending queue after the status switch, which could lead to subsequent scheduling errors. Simultaneously, the abnormal termination status indicates that the task was abnormally closed due to the forced switch, providing a verifiable operation record for subsequent task tracing and anomaly analysis, making the forced switching process traceable. Through this mechanism, manual forced switching operations can automatically update the vehicle and task statuses while ensuring operational controllability, effectively improving the consistency of status management in scenarios requiring manual intervention.

[0110] In some embodiments, the autonomous driving operation task management method further includes: incorporating vehicle departure tasks, vehicle return tasks, and preparation tasks into a daily task list; and obtaining periodic daily tasks created by operators in the web-based management backend or mobile terminal, instantiating the periodic daily tasks into task instances according to a preset period, and incorporating the instantiated task instances into the daily task list.

[0111] For example, operators can input the name, applicable vehicle, execution cycle, and effective time period of periodic daily tasks through a web-based management backend or mobile terminal. After receiving the data, the server automatically generates specific task instances for the corresponding dates according to the preset cycle, and writes the execution time, associated vehicle, and task status of the instance into the daily task list. This preset cycle can correspond to daily, weekly, or other periodic rules. Based on this, the server generates a one-time execution task when the cycle arrives and updates its status after the task is completed.

[0112] During operation, the server integrates the daily departure tasks (corresponding to departure messages sent by the external operations platform at a specified time before the start of daily operations according to preset operational rules via message queue or HTTP interface), the daily return tasks (corresponding to return messages sent by the external operations platform at a specified time before the end of daily operations according to preset operational rules), and the maintenance tasks automatically generated when generating daily return tasks, into a unified daily task list. Then, it performs periodic parsing and instantiation of periodic daily tasks created by operations personnel, forming directly scheduleable task instances and including them in the same list. The departure and return messages must at least contain the vehicle VIN code and the corresponding planned time; the planned start time for maintenance tasks can be set by default to after the return task is completed or before the start of operations the following day. In addition, periodic daily tasks include weekly deep cleaning tasks and monthly system self-check tasks created by operations personnel on a fixed date in the web-based management backend or on mobile terminals. Through the above processing mechanism, four types of task sources—external operation platform vehicle dispatch messages, external operation platform vehicle receipt messages, associated preparation tasks, and periodic daily tasks—are all maintained in a unified task view, which allows the server to perform status association, task retrieval, and subsequent execution control.

[0113] After the above four types of tasks are uniformly incorporated into the daily task list, they will be displayed on the operations staff's mobile devices according to task dimensions. For example, Figure 3 This is a schematic diagram of a daily task list provided in an embodiment of this application. For example... Figure 3As shown, the mobile terminal display for operators includes two main function entry points: "Daily Tasks" and "Emergency Tasks." The top of the interface also displays a statistical overview of vehicle status, including the distribution of vehicles in four status categories: "Pending Preparation," "Available," "In Operation," and "Abnormal." The task list area displays each vehicle's currently pending tasks in the form of task cards. Each task card includes at least a vehicle identifier, the current vehicle status, and the available operation entry point. Through this display method, operators can intuitively view the task status of each vehicle and quickly execute task operations, effectively improving the monitoring efficiency and ease of handling daily tasks.

[0114] After adopting the above processing method, the creation, collection, and scheduling of daily tasks are all handled uniformly by the server. Four types of task sources—external operation platform vehicle dispatch messages, external operation platform vehicle receipt messages, associated maintenance tasks, and periodic daily tasks—are all uniformly included in the same daily task list. Periodic tasks can be automatically converted into specific task instances and added to the same task set according to a preset cycle. By managing these four types of tasks in a unified list, the task management approach is kept consistent, task records are more complete, and task omissions or duplications caused by fragmented management of tasks from multiple sources are reduced. Simultaneously, a unified display is provided on the mobile terminals of operations personnel at the task level. Operations personnel can view the details, execution progress, and historical records of all pending tasks on a single interface, eliminating the need to switch between different functional modules and effectively reducing the complexity of task monitoring. Furthermore, the unified task list provides a consistent data foundation for subsequent linkage processing with vehicle status, facilitating the status management module to automatically determine vehicle availability based on task completion status.

[0115] To facilitate understanding, the technical solution of this application will be further described below through a specific embodiment.

[0116] For example, the technical solution in this application is applied to the operation and management of intelligent driving ride-hailing vehicles in urban commuting scenarios. Assuming there are 100 unmanned intelligent vehicles at the depot, they need to depart on time during the morning peak hours (07:30-09:00), deliver passengers to their destinations, and return to the depot between 19:30-21:00 at the end of the evening peak hours to complete tasks such as charging, washing, and maintenance, before being put back into operation the next day. Since the fleet size is several hundred vehicles, the depot management server uses an automated system to achieve dynamic linkage between vehicle status and tasks, automatic task generation and execution, anomaly handling, and manual intervention management. Taking vehicle VIN12345678901234567 as an example, the external operating platform is the city commuter dispatch platform. At 07:00 daily, the platform pushes a departure plan message for vehicle VIN12345678901234567 with a planned departure time of 07:30 to the system. After receiving this departure plan message, the station management server parses the target vehicle's vehicle identifier and corresponding planned departure time, and queries the target vehicle's current task pool for incomplete tasks. Incomplete tasks include at least one of the following: daily vehicle collection task, maintenance task, car wash task, charging task, and battery swapping task. The server determines the vehicle's status in real time based on the incomplete tasks. If there are incomplete tasks, the vehicle is considered unavailable; if all tasks are completed or closed, the vehicle is considered available. Simultaneously, the daily departure task, daily vehicle collection task, and maintenance task are all included in the daily task list. The server also retrieves the periodic daily tasks created by operators in the web-based management backend or mobile terminal, instantiates them into specific task instances according to a preset cycle, and then adds them to the daily task list.

[0117] After determining the vehicle status, the depot management server performs the first level of status verification. If the vehicle status is unavailable, a daily departure task is generated and an unavailable alarm message is pushed to the operation terminal. If the vehicle status is available, a daily departure task is generated but the alarm message is not pushed. In the urban commuting example, if vehicle VIN12345678901234567 still has an incomplete charging task after being taken down yesterday, the server determines the vehicle to be unavailable during the daily departure task generation and verification phase at 07:30 and immediately pushes an alarm message "One task is incomplete, unable to depart". After the external operation platform sends the vehicle return plan message, the depot management server generates the daily return task for the target vehicle and automatically generates the target vehicle's preparation task when generating the daily return task. In this example, the preparation task is a charging task, and vehicle VIN12345678901234567 needs to complete the charging task after being taken down at 19:30. Once the target vehicle is in an available state and completes its daily departure task, the vehicle status changes from available to operational. Once the target vehicle is in an operational state and completes its daily return task, if there are no unfinished maintenance, car wash, charging, or battery swapping tasks, the vehicle status changes back to available. If there are unfinished maintenance, car wash, charging, or battery swapping tasks, the vehicle status changes back to unavailable.

[0118] When a target vehicle is in an available state, if any of the following trigger conditions are detected: the start of the daily vehicle collection task, the identification of an incomplete task, or an abnormal operation of the currently executing task, the vehicle state switches to an unavailable state. If the target vehicle is in an unavailable state and all tasks that caused the unavailable state have been completed and the target vehicle is fault-free, the vehicle state switches to an available state. In this urban commuting scenario, after the operations personnel handle the charging task for vehicle VIN12345678901234567, the vehicle state returns to an available state. If a preset vehicle fault signal is detected in any of the target vehicle states—available, operational, or unavailable—the vehicle state switches to an abnormal state. After the fault is identified and resolved, the vehicle returns to its original state before entering the abnormal state. Upon receiving an emergency task execution instruction, the server switches the vehicle status to an unavailable state, prohibiting the target vehicle from performing the departure task. Emergency tasks include any one of emergency vehicle return, emergency preparation, emergency car wash, emergency charging, and emergency battery swapping. After the emergency task is completed, if the target vehicle does not have any other unfinished preparation, car wash, charging, or battery swapping tasks, the vehicle status is switched to an available state.

[0119] When the scheduled departure time arrives, the depot management server automatically triggers the daily departure task and performs a second status check by reading the real-time vehicle status of the target vehicle. In this example, at 07:30, the server automatically triggers the daily departure task for vehicle VIN12345678901234567 and first checks whether the vehicle status is available. If the vehicle status is unavailable, the departure operation is blocked; if the vehicle status is available, a departure command is sent to the target vehicle. For cases where charging tasks were not completed after the previous day's vehicle collection, the server blocks the departure operation during the 07:30 check and pushes an alarm message stating "One task is incomplete, departure is not possible." After the operations staff completes the charging task, the server checks again, passes the check, and sends a departure command to the vehicle. The daily departure task includes a departure start node and a vehicle departure node. When the departure start node is executed, the server issues a departure instruction to the target vehicle, causing the target vehicle to start departure according to the departure instruction. At the vehicle departure node, the server confirms that the target vehicle has left the island based on the departure gate information. In this urban commuting scenario, the departure gate data confirms that vehicle VIN12345678901234567 has left the island. After confirming departure, the daily departure task is completed, and the vehicle status is switched from available to operational status so that it can be put into operation between 07:30 and 09:00 and transport passengers to their destinations.

[0120] The daily vehicle return task includes the start return node, arrival at the depot node, dispatch to a parking space node, and arrival at a parking space node, which are executed sequentially. In this example, vehicle VIN12345678901234567 needs to return on time at 19:30, and the evening peak period ends from 19:30 to 21:00. After the planned return time of 19:30 is reached, the start return node is executed. The depot management server sends a return command and return point location information to vehicle VIN12345678901234567, enabling the target vehicle to autonomously cruise back to the depot according to the return point location information. The vehicle's driving trajectory is monitored through the onboard terminal, and the vehicle travels to the depot entrance along the recommended route. When the arrival at the depot node is executed, the server confirms that the target vehicle has arrived at the depot based on the entrance gate data. When the vehicle is dispatched to a parking space node, the server queries the parking space bound to the target vehicle. Under normal circumstances, parking space number A12 can be found, and a parking space dispatch command is sent to the target vehicle, causing the target vehicle to autonomously drive to the target parking space according to the dispatch command. Upon arrival at the parking space node, after the target vehicle completes parking, the server controls the corresponding parking space's ground lock to lower and lock the target vehicle, completing the daily vehicle return task. If vehicle VIN12345678901234567 completes the daily vehicle return task while in operation and has no unfinished preparation, washing, charging, or battery swapping tasks after returning to the island, the vehicle status switches to available status. In this example, the vehicle needs to complete the charging task after being returned at 19:30, so the vehicle status is updated from in operation to unavailable after the vehicle return task is completed.

[0121] The server continuously monitors the execution status of each node during execution. When any node fails, it marks the node as abnormal, records the cause of the failure, pushes the failure details to the operations terminal, and displays the node icon or text as an abnormal identifier on the operations terminal user interface. The failure details include at least the abnormal node name, a description of the cause of the failure, a timestamp of the failure occurrence, and suggested handling measures. A retry button is also provided on the interface. In this example, vehicle VIN12345678901234567 failed to park at 19:30 because the parking space at the depot was occupied, specifically parking space A12. The "Dispatch to Parking Space" node failed to execute. The system marked the "Dispatch to Parking Space" node as abnormal, recorded the cause of the failure as "Parking Space Occupied," and pushed a "Parking Space Occupied, Retry Recommended" prompt to the operations personnel. This prompt constitutes the suggested handling measures in the failure details. The operations terminal user interface displays the node icon or text of the abnormal node as an abnormal identifier, shows the abnormal node name, a description of the cause of the failure, a timestamp of the failure occurrence, and suggested handling measures, and provides a retry button. In response to the operator manually clicking the retry button, the trigger node is re-executed. The system reassigns available parking spaces, such as parking space B5, and sends a new parking space reassignment instruction to the vehicle. After the vehicle successfully completes parking, the node continues execution at the parking space. The server controls the ground lock corresponding to parking space B5 to lower and lock the target vehicle. If the retry is successful, the error flag is canceled and the normal display status is restored, and subsequent nodes continue to be executed; if the retry fails, the error flag is retained.

[0122] When an operator initiates a command to forcibly switch a vehicle's status from unavailable to available, the station management server first triggers a secondary confirmation pop-up. The pop-up indicates that the forced switch will close all pending tasks for the target vehicle. In this example, if an operator mistakenly switches the status of vehicle VIN12345678901234567 from unavailable to available via a mobile terminal, the system will display a secondary confirmation prompt: "This operation will close all pending tasks for the vehicle. Confirm?". After receiving confirmation from the operator in the secondary confirmation pop-up, the server switches the vehicle's status from unavailable to available and iterates through the target vehicle's current list of all pending tasks, uniformly adjusting the status of pending car wash, charging, battery swapping, and maintenance tasks to "abnormally terminated." In this example, the system automatically closes the vehicle's current charging task, and the charging task status is adjusted to "abnormally closed."

[0123] In summary, this application has at least the following advantages:

[0124] I. Through deep integration of vehicle status and task status, precise real-time control of vehicle operation status is achieved. Specifically, the vehicle status is automatically determined and updated by the system based on the current status of incomplete tasks, reducing the risk of inconsistencies between manually set status and actual task status. This ensures that the vehicle status can accurately reflect the true execution of tasks in real time, effectively reducing the probability of status misjudgment and providing a reliable status foundation for operation scheduling.

[0125] Second, by automatically generating and executing tasks based on messages from an external operations platform, manual intervention is significantly reduced. Specifically, both departure and arrival tasks are automatically generated by the system based on operations plan messages and are automatically triggered for execution when the planned time arrives. This eliminates the need for operations personnel to manually create and trigger tasks, making the dispatching and arrival scheduling of large-scale fleets efficient and reliable, and effectively reducing labor costs and the probability of operational errors.

[0126] Third, by performing a first-level status check before generating a departure task and a second-level status check when the task is triggered at the scheduled departure time, the vehicle status is checked at both the task generation and execution stages. This allows for the timely interception of departure operations that do not meet the conditions and the proactive push of alarm messages to the operation terminal. Through this dual-status check mechanism, the safety risks of dispatching vehicles with assigned tasks are effectively reduced, thereby effectively improving operational safety.

[0127] Fourth, by dividing the vehicle arrival and departure tasks into multiple sequentially executed nodes, each node independently monitors its execution status. When any node fails, the system marks it as abnormal and identifies the anomaly, records the cause of the anomaly, and pushes the anomaly details to the operations terminal. Operations personnel can trigger the node to re-execute with a single click through the retry entry. This multi-level node anomaly handling mechanism enables the rapid location and recovery of abnormal nodes, significantly shortening the anomaly handling time and enhancing the system's robustness.

[0128] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0129] Figure 4 This is a schematic diagram of the structure of an autonomous driving operation task management system provided as an exemplary embodiment of this application. The autonomous driving operation task management system provided in this embodiment is applied to a site management server. Figure 4 As shown, the unmanned intelligent vehicle operation task management system 40 includes a message communication module 41, a vehicle status management module 42, a task management module 43, and a task execution module 44, wherein:

[0130] The message communication module 41 is used to respond to the departure plan message sent by the external operation platform and obtain the vehicle identifier of the target vehicle and the corresponding planned departure time.

[0131] The vehicle status management module 42 is used to obtain the vehicle status of the target vehicle, which includes an available status and an unavailable status; the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle.

[0132] The task management module 43 is used to perform the first level of status verification based on the vehicle status of the target vehicle: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal at the same time; if the vehicle status is available, only a departure task is generated.

[0133] The task execution module 44 is used to perform a second level of status verification when the departure task is automatically triggered at the scheduled departure time: if the vehicle status is unavailable, the departure operation is intercepted; if the vehicle status is available, a departure command is sent to the target vehicle.

[0134] In one possible implementation, the message communication module 41 can be specifically used to: generate a vehicle collection task for the target vehicle in response to receiving a vehicle collection plan message sent by an external operating platform; wherein, when generating the vehicle collection task, a preparation task for the target vehicle is automatically generated in conjunction with it.

[0135] In one possible embodiment, the vehicle status management module 42 can be specifically used to: switch the vehicle status from available to operational status when the target vehicle is in an available state and the departure task is performed to make the target vehicle leave the island; when the target vehicle is in an operational state and the return task is completed and the vehicle returns to the island, if there are no unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, then switch the vehicle status to available status; if there are unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, then switch the vehicle status to unavailable status; when the target vehicle is in an available state, if any of the following triggering conditions are detected, then switch the vehicle status to unavailable status, the triggering conditions include starting the return task, identifying the existence of unfinished tasks, and the current task running abnormally. When the target vehicle is in an unavailable state and all tasks that caused the unavailable state have been completed and the target vehicle is fault-free, the vehicle state is switched to an available state; when a preset vehicle fault signal is detected in any of the target vehicle states, including available, operational, or unavailable states, the vehicle state is switched to an abnormal state; after the vehicle fault is identified as having been eliminated, the vehicle state is restored to its original state before entering the abnormal state.

[0136] In one possible embodiment, the departure task includes a departure start node and a vehicle departure from the depot node, and the task execution module 44 can be specifically used for:

[0137] Execute the start departure node: send a departure command to the target vehicle, so that the target vehicle starts departure according to the departure command; Execute the vehicle departure node: confirm that the target vehicle has left the island according to the departure gate information, complete the departure task, and switch the vehicle status from available status to operational status.

[0138] In one possible embodiment, the vehicle return task includes starting the return node, arriving at the depot node, being dispatched to a parking space node, and arriving at the parking space node. The task execution module 44 can also be used for:

[0139] Execute the start of the return station node: send the return station instruction and return station location information to the target vehicle, so that the target vehicle can autonomously cruise back to the station according to the return station location information;

[0140] Execute arrival at the depot node: Confirm that the target vehicle has arrived at the depot based on the entrance gate data;

[0141] Execute dispatch to parking space node: query the parking space bound to the target vehicle, send a parking space dispatch instruction to the target vehicle, so that the target vehicle can drive to the target parking space autonomously according to the parking space dispatch instruction;

[0142] Execution upon arrival at parking space: After the target vehicle completes parking, control the corresponding parking space's ground lock to lower, lock the target vehicle, and complete the vehicle return task.

[0143] In one possible embodiment, the vehicle status management module 42 can also be used to: monitor the execution status of each node, mark the node as abnormal when any node fails to execute, record the reason for the abnormality and push the abnormality details to the operation terminal, and provide a retry entry point for operators to trigger the node to re-execute.

[0144] In one possible embodiment, the vehicle status management module 42 can also be used to: display the node's icon or text as an anomaly identifier on the user interface of the operation terminal; the anomaly details include at least the anomaly node name, an anomaly cause description, an anomaly occurrence timestamp, and suggested handling measures; the retry entry is a retry button, which triggers the node to re-execute in response to the operator clicking the retry button; if the retry is successful, the node's anomaly identifier is canceled, the node's normal display state is restored, and subsequent nodes continue to execute; if the retry fails, the node's anomaly identifier is retained.

[0145] In one possible embodiment, the vehicle status management module 42 can also be used to: switch the vehicle status to an unavailable state in response to receiving an execution instruction for an emergency task, so as to prohibit the target vehicle from performing the departure task; the emergency task includes any one of emergency vehicle return, emergency preparation, emergency car wash, emergency charging and emergency battery swapping; after the emergency task is completed, if the target vehicle does not have any other unfinished preparation task, car wash task, charging task or battery swapping task, then switch the vehicle status to an available state.

[0146] In one possible embodiment, the vehicle status management module 42 can also be used to: in response to receiving an operation instruction to forcibly switch the vehicle status from an unavailable state to an available state, trigger a secondary confirmation pop-up, the content of which indicates that the forced switch operation will close all pending tasks of the target vehicle; in response to the confirmation operation of the operator in the secondary confirmation pop-up, forcibly switch the vehicle status from an unavailable state to an available state, and traverse the current list of all pending tasks of the target vehicle, and uniformly adjust the status of the pending car wash task, charging task, battery swapping task and maintenance task to abnormal termination.

[0147] In one possible embodiment, the vehicle status management module 42 can also be used to: uniformly include departure tasks, return tasks and preparation tasks into the daily task list; and to obtain the periodic daily tasks established by the operators in the web-based management backend or mobile terminal, instantiate the periodic daily tasks into task instances according to a preset period, and include the instantiated task instances into the daily task list.

[0148] The unmanned intelligent vehicle operation task management system provided in this application embodiment can execute the technical solution shown in the above embodiment of the unmanned intelligent vehicle operation task management method. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0149] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0150] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0151] It should be noted that the above system embodiments are merely illustrative, and the system of this application can also be implemented in other ways; and it should be understood that the division of the various modules of the above system is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can all be implemented in software through processing element calls; they can all be implemented in hardware; or some modules can be implemented by processing element calls to software, and some modules can be implemented in hardware. For example, the vehicle status management module can be a separately established processing element, or it can be integrated into a chip in the above system. Alternatively, it can be stored as program code in the memory of the above system, and its functions can be called and executed by a processing element of the above system. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through hardware integrated logic circuits in the processor element or software instructions.

[0152] For example, these modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). As another example, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a System-On-a-Chip (SOC).

[0153] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Video Discs, DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0154] Figure 5 A schematic diagram of the structure of a site management server provided for an exemplary embodiment of this application. (See diagram below.) Figure 5 As shown, the site management server 50 in this embodiment includes:

[0155] At least one processor 51; and a memory 52 communicatively connected to the at least one processor;

[0156] The memory 52 stores instructions that can be executed by at least one processor 51 to cause the site management server to perform the method as described in any of the above embodiments.

[0157] Alternatively, the memory 52 can be either standalone or integrated with the processor 51.

[0158] The memory 52 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0159] The processor 51 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Specifically, when implementing the method for managing unmanned intelligent vehicle operation tasks described in the foregoing method embodiments, the site management server may be an electronic device with processing capabilities, such as a server.

[0160] Optionally, the site management server may also include a communication interface 53. In specific implementations, if the communication interface 53, memory 52, and processor 51 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0161] Optionally, in a specific implementation, if the communication interface 53, memory 52 and processor 51 are integrated on a single chip, then the communication interface 53, memory 52 and processor 51 can communicate through an internal interface.

[0162] The message communication module receives departure plans and extracts vehicle identifiers and planned departure times, synchronizing plans from external operating platforms to the depot, ensuring a unified data source for departure task creation. The vehicle status management module associates vehicle status with incomplete tasks in real time, avoiding status distortion caused by relying solely on manual marking. The task management module performs the first level of status verification during task generation, pushing alerts to unavailable vehicles while generating daily departure tasks, allowing operations personnel to intervene and handle anomalies in advance. The task execution module performs a second level of status verification during planned departure, accurately determining whether departure is permitted even after task status changes. This prevents vehicles from being mistakenly dispatched before completion of tasks such as vehicle collection, preparation, washing, charging, or battery swapping, thus improving depot scheduling automation, operational efficiency, and departure safety.

[0163] The implementation principle and technical effects of the site management server provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0164] This application also provides a computer program product, including a computer program, which, when executed, implements the method steps as described in the above method embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0165] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed, they are used to implement the method steps as described in the above method embodiments. The specific implementation methods and technical effects are similar and will not be repeated here.

[0166] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0167] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in a system for managing autonomous vehicle operations.

[0168] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interface, or indirect coupling or communication connection between systems or units, and may be electrical, mechanical, or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0171] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0172] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0173] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for managing the operation tasks of unmanned intelligent vehicles, characterized in that, Applications to site management servers include: In response to receiving a departure plan message from an external operating platform, obtain the vehicle identifier of the target vehicle and the corresponding planned departure time; The vehicle status of the target vehicle is obtained, including an available status and an unavailable status; wherein, the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle. Based on the vehicle status of the target vehicle, the first level of status verification is performed: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal; if the vehicle status is available, only the departure task is generated. When the departure task is automatically triggered at the scheduled departure time, a second level of status verification is performed: if the vehicle status is unavailable, the departure operation is blocked; if the vehicle status is available, a departure command is sent to the target vehicle.

2. The unmanned intelligent driving operation task management method according to claim 1, characterized in that, Also includes: In response to receiving a vehicle collection plan message from the external operating platform, a vehicle collection task for the target vehicle is generated; wherein, when generating the vehicle collection task, a preparation task for the target vehicle is automatically generated in conjunction with it.

3. The unmanned intelligent driving operation task management method according to claim 2, characterized in that, Based on the unfinished tasks of the target vehicle, the system further includes real-time determination and updating of the vehicle status, and includes: When the target vehicle is in the available state and the departure task is performed to make the target vehicle leave the island, the vehicle status is switched from the available state to the operational state. When the target vehicle is in the operational state and returns to the island after completing the vehicle collection task, if there are no unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, the vehicle status is switched to the available state; if there are unfinished preparation tasks, car wash tasks, charging tasks, or battery swapping tasks, the vehicle status is switched to the unavailable state. When the target vehicle is in the available state, if any of the following triggering conditions are detected, the vehicle state will be switched to the unavailable state. The triggering conditions include starting the vehicle collection task, identifying an incomplete task, and an abnormal operation of the currently executing task. When the target vehicle is in the unavailable state and all tasks that caused the unavailable state have been completed and the target vehicle is fault-free, the vehicle state is switched to the available state. When the target vehicle detects a preset vehicle fault signal in any of the available, operational, or unavailable states, the vehicle state is switched to an abnormal state; after the vehicle fault is identified as having been resolved, the vehicle state is restored to its original state before entering the abnormal state.

4. The unmanned intelligent driving operation task management method according to claim 3, characterized in that, The departure task includes a departure start node and a vehicle departure from the depot node. The departure task is executed sequentially according to the node order, specifically including: Execute the start departure node: send a departure command to the target vehicle, causing the target vehicle to start departure according to the departure command; Execute the vehicle departure node: confirm that the target vehicle has left the island based on the departure gate information, complete the departure task, and switch the vehicle status from the available status to the operational status.

5. The unmanned intelligent driving operation task management method according to claim 3, characterized in that, The vehicle return task includes the start return node, arrival at the depot node, dispatch to a parking space node, and arrival at a parking space node. The vehicle return task is executed sequentially according to the node order, specifically including: Execute the start return node: send a return command and return station location information to the target vehicle, so that the target vehicle can autonomously cruise back to the station according to the return station location information; Execute the arrival at the depot node: confirm that the target vehicle has arrived at the depot based on the entrance gate data; Execute the scheduling to the parking space node: query the parking space bound to the target vehicle, send a parking space scheduling instruction to the target vehicle, so that the target vehicle can drive to the target parking space autonomously according to the parking space scheduling instruction; Execute the arrival at the parking space node: After the target vehicle completes parking, control the ground lock of the corresponding parking space to lower, lock the target vehicle, and complete the vehicle return task.

6. The unmanned intelligent vehicle operation task management method according to claim 4 or 5, characterized in that, Also includes: Monitor the execution status of each node. When any node fails to execute, mark the node as abnormal, record the reason for the abnormality, and push the abnormality details to the operation terminal. At the same time, provide a retry entry point so that the operation personnel can trigger the node to re-execute.

7. The unmanned intelligent driving operation task management method according to claim 6, characterized in that, The process of marking the node as abnormal, recording the cause of the abnormality, pushing the abnormality details to the operation terminal, and providing a retry entry point includes: The node's icon or text is displayed as an anomaly identifier on the user interface of the operating terminal; the anomaly details include at least the anomaly node name, a description of the cause of the anomaly, a timestamp of the anomaly occurrence, and suggested handling measures; The retry entry is a retry button, which responds to the operator clicking the retry button and triggers the node to re-execute; If the retry is successful, the error flag of the node is canceled, the normal display state of the node is restored, and subsequent nodes continue to be executed. If the retry fails, the node's error flag is retained.

8. The unmanned intelligent vehicle operation task management method according to any one of claims 1 to 5, characterized in that, Also includes: In response to receiving an emergency task execution command, the vehicle status is switched to an unavailable state to prevent the target vehicle from performing the departure task; The emergency tasks include any one of the following: emergency vehicle recovery, emergency preparation, emergency car washing, emergency charging, and emergency battery swapping; Once the emergency task is completed, if the target vehicle has no other unfinished preparation, washing, charging, or battery swapping tasks, the vehicle status will be switched to an available state.

9. The unmanned intelligent vehicle operation task management method according to any one of claims 1 to 5, characterized in that, Also includes: In response to receiving an operation command to forcibly switch the vehicle status from an unavailable state to an available state, a secondary confirmation pop-up is triggered. The content of the secondary confirmation pop-up indicates that the forced switch operation will close all pending tasks of the target vehicle. In response to the confirmation operation of the operator in the secondary confirmation pop-up, the vehicle status is forcibly switched from unavailable to available, and the current list of all pending tasks of the target vehicle is traversed, and the status of pending car wash, charging, battery swapping and maintenance tasks is uniformly adjusted to abnormal termination.

10. The unmanned intelligent vehicle operation task management method according to any one of claims 1 to 5, characterized in that, Also includes: The dispatch, return, and preparation tasks are all included in the daily task list. as well as, The system retrieves periodic daily tasks created by operators in the web-based management backend or on mobile devices, instantiates these periodic daily tasks into task instances according to a preset cycle, and includes the instantiated task instances in the daily task list.

11. A management system for unmanned intelligent driving operations, characterized in that, Applications to site management servers include: The message communication module is used to respond to the departure plan message sent by the external operation platform and obtain the vehicle identifier of the target vehicle and the corresponding planned departure time. The vehicle status management module is used to obtain the vehicle status of the target vehicle, which includes an available status and an unavailable status; wherein, the vehicle status is determined and updated in real time based on the current unfinished tasks of the target vehicle. The task management module is used to perform a first-level status check based on the vehicle status of the target vehicle: if the vehicle status is unavailable, a departure task is generated and an unavailable alarm message is pushed to the operation terminal; if the vehicle status is available, only the departure task is generated. The task execution module is used to perform a second state check when the departure task is automatically triggered at the scheduled departure time: if the vehicle status is unavailable, the departure operation is blocked; if the vehicle status is available, a departure command is sent to the target vehicle.

12. A site management server, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory is used to store computer-executed instructions; The processor is configured to execute the computer execution instructions to implement the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed, are used to implement the method as described in any one of claims 1 to 10.

Images