Method, device, system and electronic equipment for dispatch domain isolation of autonomous vehicle

Abstract

The application discloses a dispatch domain isolation method, device and system of an autonomous vehicle and electronic equipment, and belongs to the technical field of autonomous driving. The dispatch domain isolation method of the autonomous vehicle comprises the following steps: in response to a remote assistance request of a target vehicle, obtaining a dispatch participation state of the target vehicle; in the case that the dispatch participation state indicates that the target vehicle is allowed to participate in dispatch, determining a target dispatch domain to which the target vehicle belongs, wherein each dispatch domain is configured with a vehicle set belonging to the dispatch domain and an operation seat set; based on the target dispatch domain to which the target vehicle belongs, a target operation seat is allocated from the operation seats of the target dispatch domain, so as to process the remote assistance request of the target vehicle based on the target operation seat. The dispatch domain isolation method of the autonomous vehicle avoids problems such as cross-center resource mixing and mutual interference of service quality, reduces network delay, and improves remote driving control efficiency.

Description

Technical Field

[0001] This application belongs to the field of autonomous driving technology, and in particular relates to a scheduling domain isolation method, device, system and electronic device for autonomous vehicles. Background Technology

[0002] As the scale of remote driving control services expands, operators typically deploy cloud cabin operator teams across multiple operating units, such as Operations Center A and Operations Center B, to serve autonomous vehicles in different areas. In multi-operation-center scenarios, the dispatch system needs to manage multiple operating units, multiple cloud cabin teams, and a large number of vehicle resources simultaneously. Existing multi-operation-center dispatch systems usually employ a global dispatch pool or a weakly isolated resource pool, resulting in the mixing of vehicles, cloud cabins, and work orders from different operating units. This leads to problems such as cross-center work order dispatch, increased network latency, and cloud cabin resources being preempted by other centers, resulting in low efficiency for remote driving control services. Summary of the Invention

[0003] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes a scheduling domain isolation method, apparatus, system, and electronic device for autonomous vehicles, avoiding problems such as cross-center resource sharing and mutual interference of service quality, reducing network latency, and improving the control efficiency of remote driving.

[0004] Firstly, this application provides a method for isolating the scheduling domain of an autonomous vehicle, including: In response to a remote assistance request from a target vehicle, the scheduling participation status of the target vehicle is obtained; When the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling, the target scheduling domain to which the target vehicle belongs is determined. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain, and the same vehicle and the same operating seat belong to the same scheduling domain at the same time. Based on the target dispatch domain to which the target vehicle belongs, a target operating seat is allocated from the operating seats of the target dispatch domain to process the remote assistance request of the target vehicle based on the target operating seat.

[0005] According to the scheduling domain isolation method for autonomous vehicles provided in this application, the independent control of whether a single vehicle participates in scheduling is achieved through pre-filtering of the vehicle scheduling participation status. This facilitates vehicle maintenance, testing, shutdown, and resumption of operation without affecting other vehicles or other scheduling domains. Through the unique ownership constraint of the scheduling domain, vehicles and operating positions are allocated in a closed loop within the domain, avoiding problems such as cross-center resource sharing and mutual interference of service quality, reducing network latency, and improving the control efficiency of remote driving.

[0006] An embodiment of the present application provides a scheduling domain isolation method for autonomous vehicles, wherein each scheduling domain is further configured with a scheduling queue belonging to the scheduling domain; Before allocating a target operating seat from the operating seats of the target scheduling domain based on the target vehicle's affiliation, the method further includes: Add the remote assistance request to the scheduling queue of the target scheduling domain; The allocation of target operation seats from the operation seats of the target scheduling domain includes: The remote assistance request is obtained from the scheduling queue of the target scheduling domain, and a target operating seat is allocated from the operating seats of the target scheduling domain.

[0007] One embodiment of this application provides a scheduling domain isolation method for autonomous vehicles. Adding the remote assistance request to the scheduling queue of the target scheduling domain includes: Generate a work order corresponding to the remote assistance request, and add the work order to the scheduling queue of the target scheduling domain; Retrieving the remote assistance request from the scheduling queue of the target scheduling domain includes: The work order is retrieved from the scheduling queue.

[0008] The scheduling domain isolation method for autonomous vehicles according to one embodiment of this application further includes: In response to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, the work orders that have been generated or are being executed by the target vehicle will continue to be dispatched according to the scheduling domain to which they belonged at the time of creation.

[0009] The scheduling domain isolation method for autonomous vehicles according to one embodiment of this application further includes: In response to a configuration change operation for a scheduling domain, the system verifies whether there are any incomplete work orders in the scheduling domain, operator seat, or vehicle corresponding to the configuration change operation. The configuration change operation includes at least one of the following: closing the scheduling domain, removing the operator seat from the scheduling domain, and removing the vehicle from the scheduling domain. If there are incomplete work orders, restrict or postpone the execution of the configuration change operation.

[0010] One embodiment of this application provides a scheduling domain isolation method for autonomous vehicles, wherein the identifier of the work order corresponding to the remote assistance request is stored or expressed separately from the scheduling domain information to which the work order belongs, and the scheduling domain information includes at least one of a region number, an operation center number, and a scheduling domain configuration.

[0011] The scheduling domain isolation method for autonomous vehicles according to one embodiment of this application further includes: Generate a work order corresponding to the remote assistance request; Store at least one of the following information: scheduling domain configuration, vehicle affiliation with scheduling domain, operator affiliation with scheduling domain, scheduling participation status, work order, and the scheduling domain to which the work order belongs; In response to a switchover or recovery of the scheduling system, the scheduling service is restored based on the stored information.

[0012] One embodiment of the scheduling domain isolation method for autonomous vehicles in this application includes at least one of the following processes for restoring scheduling services: Restore the enabled state of the scheduling domain; Restore the ownership relationship between vehicles and dispatch domains, as well as the ownership relationship between operating positions and dispatch domains; Restore the scheduling participation state; Restore incomplete work orders and the scheduling domain to which the incomplete work orders belong; Restore the order of pending work orders within the domain; Restore the state of security constraints associated with the scheduling domain.

[0013] The scheduling domain isolation method for autonomous vehicles according to one embodiment of this application further includes: In response to a change in the scheduling participation status of the target vehicle, the changed scheduling participation status is synchronized to the target vehicle to indicate whether the target vehicle should continue to report remote assistance requests.

[0014] An embodiment of the scheduling domain isolation method for autonomous vehicles according to this application includes allocating a target operating seat from the operating seats of the target scheduling domain to which the target vehicle belongs, comprising: If the target scheduling domain allows new requests, a target operating seat is allocated from the operating seats of the target scheduling domain.

[0015] Secondly, this application provides a scheduling domain isolation device for autonomous vehicles, comprising: The first processing module is used to respond to the remote assistance request of the target vehicle and obtain the scheduling participation status of the target vehicle. The second processing module is used to determine the target scheduling domain to which the target vehicle belongs when the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain, and the same vehicle and the same operating seat belong to the same scheduling domain at the same time. The third processing module is used to allocate a target operating seat from the operating seats of the target scheduling domain based on the target scheduling domain to which the target vehicle belongs, so as to process the remote assistance request of the target vehicle based on the target operating seat.

[0016] The autonomous vehicle scheduling domain isolation device provided in the embodiments of this application realizes independent control over whether a single vehicle participates in scheduling by filtering the vehicle scheduling participation status in advance. This facilitates vehicle maintenance, testing, shutdown and resumption of operation without affecting other vehicles and other scheduling domains. Through the unique ownership constraint of the scheduling domain, vehicles and operating positions are allocated in a closed loop within the domain, avoiding problems such as cross-center resource sharing and mutual interference of service quality, reducing network latency and improving the control efficiency of remote driving.

[0017] Thirdly, this application provides a scheduling domain isolation system for autonomous vehicles, used to perform the scheduling domain isolation method for autonomous vehicles as described in the first aspect.

[0018] Fourthly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the scheduling domain isolation method for autonomous vehicles as described in the first aspect above.

[0019] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: By filtering the vehicle's participation status before dispatching, independent control over whether a single vehicle participates in dispatching is achieved. This facilitates vehicle maintenance, testing, shutdown, and resumption of operation without affecting other vehicles or other dispatching domains. Through the unique ownership constraint of the dispatching domain, vehicles and operating positions are allocated in a closed loop within the domain, avoiding issues such as cross-center resource sharing and mutual interference in service quality. This reduces network latency and improves the control efficiency of remote driving.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of the system architecture of the scheduling domain isolation method for autonomous vehicles provided in the embodiments of this application; Figure 2 This is one of the flowcharts illustrating the scheduling domain isolation method for autonomous vehicles provided in this application embodiment; Figure 3This is a second schematic flowchart of the scheduling domain isolation method for autonomous vehicles provided in the embodiments of this application; Figure 4 This is the third flowchart illustrating the scheduling domain isolation method for autonomous vehicles provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of the dispatch domain isolation device for autonomous vehicles provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0023] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0024] The following description, in conjunction with the accompanying drawings, details the scheduling domain isolation method, scheduling domain isolation device, electronic device, and readable storage medium for autonomous vehicles provided in this application, through specific embodiments and application scenarios.

[0025] Among them, the scheduling domain isolation method for autonomous vehicles can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0026] The scheduling domain isolation method for autonomous vehicles provided in this application embodiment can be executed by an electronic device or a functional module or functional entity in an electronic device that can implement the scheduling domain isolation method for autonomous vehicles. The electronic devices mentioned in this application embodiment include, but are not limited to, mobile phones, tablets, computers, cameras and wearable devices. The scheduling domain isolation method for autonomous vehicles provided in this application embodiment will be described below using an electronic device as the execution subject.

[0027] like Figure 4 As shown, the scheduling domain isolation method for the autonomous vehicle includes steps S1, S2, and S3.

[0028] Step S1: In response to the remote assistance request of the target vehicle, obtain the dispatch participation status of the target vehicle; In this step, the target vehicle is the autonomous vehicle that initiated the remote assistance request. In a multi-vehicle concurrent scenario, each request corresponds to a specific target vehicle.

[0029] Remote assistance requests refer to requests made by autonomous vehicles to the cloud dispatch system when they encounter complex road conditions that they cannot handle on their own. These requests include types such as escaping difficulties and remote assistance requests.

[0030] The dispatch participation status is an independent business status maintained by the system for each vehicle, indicating whether the vehicle is currently allowed to enter the remote driving dispatch process. The dispatch participation status includes two values: Participating in dispatch (the vehicle is allowed to report remote assistance or distress requests and can have work orders and dispatch orders created by the dispatch system) and Not participating in dispatch (the vehicle is temporarily not entering the dispatch process, and the vehicle should stop or suppress corresponding reporting behavior). This status is an independent business configuration item.

[0031] Step S2: When the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling, determine the target scheduling domain to which the target vehicle belongs. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain. In this step, each scheduling domain represents Operations Center A, Operations Center B, Region A, Region B, or other business management scopes. For example... Figure 1 As shown, the remote driving dispatch system routes requests to the corresponding dispatch domains (dispatch domain A, dispatch domain B, ..., dispatch domain N) based on vehicle ownership. Each dispatch domain is configured with a set of vehicles belonging to that domain, a domain queue, and a set of cloud cabins. The dispatch domains are isolated from each other and do not share resources across domains. The dispatch domain is the basic boundary for resource ownership and dispatch; there is no cross-domain allocation, cross-domain preemption, or cross-domain competition between domains.

[0032] A vehicle set is all vehicles belonging to the same scheduling domain. A single vehicle can only belong to one scheduling domain at any given time.

[0033] The operator's seat is the remote driver's control terminal (cloud cabin), i.e., the workstation where the remote driver controls the autonomous vehicle. The same operator's seat can only belong to one dispatch domain at a time.

[0034] The target scheduling domain is the scheduling domain to which the target vehicle belongs. When a target vehicle uniquely belongs to a certain scheduling domain, that scheduling domain is the target scheduling domain.

[0035] The target operator seat is the specific seat allocated from the set of operator seats in the target scheduling domain that is actually used to handle the remote assistance request for the vehicle. Allocation is performed only within the target scheduling domain and does not involve cross-domain allocation.

[0036] Step S3: Based on the target scheduling domain to which the target vehicle belongs, allocate a target operating seat from the operating seats of the target scheduling domain to process the remote assistance request of the target vehicle based on the target operating seat.

[0037] In this step, each vehicle and operator's seat uniquely belongs to a scheduling domain, such as... Figure 3 As shown, after receiving a remote assistance or extrication request from the vehicle, the dispatch system performs the following checks in sequence: query whether the vehicle belongs to a certain dispatch domain, determine whether the dispatch domain allows accepting new requests, determine whether the vehicle is currently allowed to participate in dispatch, and determine whether there are available cloud cabin resources within the dispatch domain.

[0038] The dispatching system first obtains and determines the vehicle's dispatch participation status. If the status is "not participating in dispatch," all checks fail, the system does not create a new work order, and records the reason. If the status is "participating in dispatch," the system continues to determine the target dispatch domain to which the vehicle belongs. The dispatching system queries which dispatch domain the vehicle is assigned to. For example, if the vehicle belongs to dispatch domain A corresponding to operations center A, then that dispatch domain is the target dispatch domain. After the target dispatch domain is determined, the system selects an available operator position from the set of operator positions configured in that domain as the target operator position and assigns it to the request. The entire process adheres to the unique constraint that a vehicle and operator position belong to only one dispatch domain at any given time. When dispatching a work order, the system only selects an operator position within that dispatch domain and does not select resources across domains.

[0039] In some embodiments, the scheduling system can be deployed in two operation centers (corresponding to the first scheduling domain and the second scheduling domain, respectively). Each operation center contains an independent set of cloud cabin workstations and a vehicle pool. Specifically, each operation center has multiple cloud cabin workstations, each with an independent status identifier (such as online / idle, busy, offline, etc.) and a customer service switch to control whether the workstation accepts dispatch orders. Each operation center also has a vehicle pool, with each vehicle in the pool having an independent vehicle switch to control whether the vehicle participates in scheduling. The global layer uniformly maintains the routing table (i.e., the affiliation relationship between vehicles and operation centers) and capability profiles of each operation center, and performs cross-center matching and arbitration through the dispatch engine. However, when dispatching orders, cloud cabin workstations are selected only within the operation center to which the vehicle belongs, without cross-center allocation. In this exemplary architecture, each operation center has a central master switch to control whether the center accepts new requests. Through the above configuration, the vehicles and cloud cabin resources of different operation centers are managed in a closed loop within their respective domains. The global layer is only responsible for cross-center configuration synchronization and monitoring, and does not interfere with specific dispatch decisions within the domain, thereby achieving a domain isolation mechanism at the physical deployment level. Gray vehicles represent vehicles that are not in the pool or do not participate in scheduling. After configuration is issued by the backend management panel, they are added to the vehicle pool and scheduling is started, reflecting the independent control of the vehicle's participation status in scheduling.

[0040] During the research and development process, the inventors discovered at least three interrelated problems in the relevant technology: First, in multi-operation center scenarios, the dispatch system typically uses a globally shared resource pool, with vehicle and cloud cabin resources from different operation centers being shared among them. This can lead to requests from operation center A being assigned to the cloud cabin of operation center B, resulting in increased cross-center dispatching and network latency. Second, the system can only enable or disable dispatching capabilities from an overall perspective. When a single vehicle enters maintenance or testing mode, operators cannot independently remove it from the dispatching range without affecting other vehicles. Third, adjustments to vehicle dispatching status made by the cloud cannot be transmitted to the vehicle end. This results in the vehicle end continuing to report remote assistance requests even when the cloud wants a vehicle to temporarily not participate in dispatching, causing a backlog of invalid requests and the risk of mis-dispatching.

[0041] In this application, upon receiving a remote assistance request from the vehicle, the dispatch participation status of the target vehicle is first obtained. Processing continues only when the status indicates that the vehicle is allowed to participate in dispatch, thus achieving independent control over whether a single vehicle enters the dispatch process. For requests that allow dispatch, the unique target dispatch domain to which the vehicle belongs is determined. This dispatch domain is pre-configured with a set of vehicles and a set of operating seats belonging to that domain. The allocation of operating seats is only performed within the target dispatch domain, without cross-domain selection. The above methods work together to enable vehicle-level dispatch control, completely eliminating cross-center dispatching, while cloud-based dispatch decisions remain consistent with vehicle-side reporting behavior through a status synchronization mechanism.

[0042] According to the scheduling domain isolation method for autonomous vehicles provided in this application, the independent control of whether a single vehicle participates in scheduling is achieved through pre-filtering of the vehicle scheduling participation status. This facilitates vehicle maintenance, testing, shutdown, and resumption of operation without affecting other vehicles or other scheduling domains. Through the unique ownership constraint of the scheduling domain, vehicles and operating positions are allocated in a closed loop within the domain, avoiding problems such as cross-center resource sharing and mutual interference of service quality, reducing network latency, and improving the control efficiency of remote driving.

[0043] In some embodiments, each scheduling domain is further configured with a scheduling queue belonging to the scheduling domain; Before allocating a target operating seat from the operating seats in the target scheduling domain based on the target vehicle's affiliation, the method further includes: Add the remote assistance request to the scheduling queue of the target scheduling domain; Allocate target operation seats from the operation seats of the target scheduling domain, including: Retrieve remote assistance requests from the scheduling queue of the target scheduling domain and allocate target operation seats from the operation seats of the target scheduling domain.

[0044] In this embodiment, the scheduling queue is an independent queue maintained within each scheduling domain, used to store pending remote assistance requests or work orders. For example... Figure 1 As shown, each scheduling domain (scheduling domain A, B, ..., N) is configured with its own domain queues (domain queues A, B, ..., N). Queues in different scheduling domains are isolated from each other and operate independently. Queues in different domains do not share operation slot resources and do not preempt resources in their own domain due to an increase in the number of requests or changes in request priorities in other domains.

[0045] After determining the target dispatch domain corresponding to the target vehicle, the remote assistance request can be placed in the dispatch queue of the target dispatch domain. Once added to the queue, the remote assistance request for the target vehicle waits in line for processing and is not immediately assigned a work position. After being retrieved from the dispatch queue, the request enters the dispatching process and can be assigned an operating work position.

[0046] like Figure 1 and Figure 3 As shown, each scheduling domain has an independent scheduling queue. Before allocating operation seats, the system first adds remote assistance requests to the target scheduling domain's scheduling queue; when allocating operation seats, the request is retrieved from the scheduling queue, and then an available operation seat is selected from within that scheduling domain. Enqueueing and dequeueing form a complete queue scheduling closed loop, ensuring the sequential processing of requests. Within a single scheduling domain, the system can organize queues according to business urgency, task type, creation order, or other operational strategies. This queue strategy only takes effect within the domain and does not affect the service quality of other scheduling domains.

[0047] According to the scheduling domain isolation method for autonomous vehicles provided in the embodiments of this application, by maintaining an independent scheduling queue in each scheduling domain, the queues between different domains do not share operation seat resources and do not preempt resources in this domain due to an increase in the number of requests or changes in request priority in other domains; within a single scheduling domain, queues can be organized according to the urgency of business, task type, and creation order, and this queue strategy only takes effect within this domain and does not affect the service quality of other scheduling domains.

[0048] In some embodiments, adding a remote assistance request to the scheduling queue of the target scheduling domain may include: Generate a work order corresponding to the remote assistance request and add the work order to the scheduling queue of the target scheduling domain; Retrieve remote assistance requests from the scheduling queue of the target scheduling domain, including: Retrieve work orders from the scheduling queue.

[0049] In this embodiment, a work order is a scheduling task record created by the scheduling system for each vehicle-side remote assistance request. The work order contains information such as vehicle identifier, request time, task type, and task status, and serves as the carrier for the request to flow in the queue and for its entire lifecycle management.

[0050] After a request passes verification, the scheduling system creates a work order instance corresponding to that request. Once the work order is generated, it is bound to the scheduling domain for business operations.

[0051] After a work order is retrieved from the scheduling queue, it enters the work order allocation stage.

[0052] like Figure 3 As shown, after all verification items of the vehicle-side remote assistance request pass, the dispatch system creates a work order and binds the work order to the target dispatch domain, thus forming a business binding between the work order and the dispatch domain. Once created, the work order is added to the dispatch queue of the target dispatch domain. When dispatching a work order, the system retrieves the work order from the dispatch queue and then allocates a target operation seat from the operation seats within that dispatch domain.

[0053] According to the scheduling domain isolation method for autonomous vehicles provided in the embodiments of this application, by abstracting vehicle-side requests into a work order as a scheduling task record, the entire lifecycle of a request from receipt to dispatch is traceable and manageable; the business binding between the work order and the scheduling domain ensures the implementation of the domain isolation mechanism at the task level.

[0054] In some embodiments, it may further include: In response to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, the work orders that have been generated or are being executed by the target vehicle will continue to be dispatched according to the scheduling domain to which they belonged at the time of creation.

[0055] In this embodiment, switching to non-participation in scheduling refers to the action taken by operators or automated strategies to actively change the scheduling participation status of a vehicle from participating in scheduling to non-participation in scheduling. This switch may occur in scenarios such as when a vehicle needs maintenance, testing, or temporary outage.

[0056] A generated or executing work order refers to a work order that has been created for the vehicle but has not yet been completed before the switching action occurs, including work orders in the queue, allocation, or execution stages.

[0057] The work order's dispatch path remains unchanged regardless of subsequent changes in vehicle dispatch status; subsequent dispatching and resource allocation continue within the dispatch domain bound at the time of work order creation. The domain affiliation at creation is saved as a business snapshot of the work order.

[0058] like Figure 2 As shown, after an operations staff member or automated strategy initiates a change in vehicle dispatch status, the cloud dispatch side's execution permissions, ownership, and active task impact verification are affected. When a vehicle's dispatch participation status changes from "participating in dispatch" to "not participating in dispatch," the system does not directly cancel any work orders already generated or being executed for that vehicle. These work orders continue to be dispatched according to the dispatch domain bound at the time of creation. The change in vehicle dispatch status only affects newly reported requests and the creation of new work orders after the change. This avoids operations staff accidentally affecting ongoing remote driving tasks by adjusting vehicle dispatch status, ensuring vehicle safety and task continuity.

[0059] In some embodiments, it may further include: In response to a configuration change operation for a scheduling domain, the system verifies whether there are any incomplete work orders in the scheduling domain, operator seat, or vehicle corresponding to the configuration change operation. The configuration change operation includes at least one of the following: closing the scheduling domain, removing the operator seat from the scheduling domain, and removing the vehicle from the scheduling domain. If there are incomplete work orders, restrict or postpone the execution of configuration change operations.

[0060] In this embodiment, the configuration change operation is a management operation for the scheduling domain, which may specifically include: closing the scheduling domain, removing the operator seat (cloud cabin) from the scheduling domain, and removing the vehicle from the scheduling domain.

[0061] If the operation is to close the scheduling domain, then the domain is verified; if the operation is to remove the operator's seat, then the seat is verified; if the operation is to remove the vehicle, then the vehicle is verified.

[0062] Incomplete work orders are those that are in the queue, being assigned, being executed, or have not yet been archived.

[0063] When there are active work orders, the operation should be prevented from being executed immediately, or the operation should be postponed until all related work orders are completed.

[0064] In actual implementation, when operators initiate configuration change operations such as closing a dispatch domain, removing an operator's seat from a dispatch domain, or removing a vehicle from a dispatch domain, the system first checks whether there are any incomplete work orders for the corresponding dispatch domain, operator's seat, or vehicle. If there are incomplete work orders, the execution of the configuration change operation is restricted or postponed. Configuration changes are only allowed to proceed after there are no affected active work orders, or after the system has completed task convergence and resource release. This mechanism prevents configuration changes from directly interrupting ongoing remote driving tasks, reducing the impact of configuration errors on vehicle safety.

[0065] In some embodiments, it may further include: In response to a change in the dispatch participation status of the target vehicle, the changed dispatch participation status is synchronized to the target vehicle to indicate whether the target vehicle should continue to report remote assistance requests.

[0066] In this embodiment, a change refers to a switch in the vehicle's scheduling participation status between participating in scheduling and not participating in scheduling. This change is triggered manually by operators or by automated strategies.

[0067] The cloud (dispatch system) can send the changed dispatch status to the target vehicle via vehicle-to-cloud communication.

[0068] After receiving the synchronization status, the vehicle determines whether to continue sending remote assistance or get-out-of-trouble requests to the cloud based on the status.

[0069] like Figure 2 As shown, after an operations staff member or automated strategy initiates a vehicle dispatch status change, the cloud dispatch side performs verification of execution permissions, ownership, and active task impact. Upon successful verification, the cloud-based vehicle dispatch status takes effect first, and the cloud synchronizes the dispatch decision to the vehicle. The vehicle adjusts its remote assistance reporting behavior based on the synchronization information. If the status is "participating in dispatch," the vehicle reports the request normally; if the status is "not participating in dispatch," the vehicle stops or suppresses reporting. The vehicle provides feedback on the synchronization result for observability, retry, or manual review. To ensure timely operational response, dispatch status changes adopt a cloud-first, asynchronous feedback approach; that is, cloud status changes do not depend on vehicle-side synchronization feedback to take effect; vehicle-side feedback is only used for observability, auditing, and troubleshooting. In case of abnormal feedback, the cloud status is not directly rolled back; instead, it is handled according to a compensation strategy (such as alarms, retry, or manual review).

[0070] According to the scheduling domain isolation method for autonomous vehicles provided in the embodiments of this application, the cloud scheduling status and the vehicle-side reporting behavior form a synchronization mechanism, reducing the accumulation of invalid requests caused by the cloud not scheduling but the vehicle-side continuously reporting; the cloud status taking effect first ensures timely response to operational operations, and the vehicle-side feedback is used for observability and problem investigation without blocking operational operations.

[0071] In some embodiments, allocating a target operating seat from the operating seats of the target scheduling domain based on the target vehicle's belonging target scheduling domain may include: If the target scheduling domain allows new requests, allocate a target operation seat from the operation seats of the target scheduling domain.

[0072] In this embodiment, new requests are allowed to be received when the service switch of the scheduling domain itself is in the "on" state. This switch is an independent configuration item of the scheduling domain, which determines whether the scheduling domain accepts new remote assistance requests and creates new work orders.

[0073] like Figure 3 As shown, after determining the target scheduling domain to which the target vehicle belongs, and before assigning an operation seat, the scheduling system first checks whether the scheduling domain allows accepting new requests. If the target scheduling domain allows accepting new requests, then the system continues to assign the target operation seat from the operation seats of that domain. If not, then no new work order is created and the reason is recorded. This can form a two-layer filtering with the vehicle scheduling participation status verification. The first layer is to query the vehicle's assigned scheduling domain and determine whether the domain allows accepting new requests; the second layer is to determine whether the vehicle is allowed to participate in scheduling and whether there are available cloud cabin resources within the domain.

[0074] Operators can temporarily stop new request access to a scheduling domain by turning off the accept new request switch without affecting the continued execution of existing work orders, which facilitates maintenance, upgrades or load adjustment by the operations center.

[0075] In some embodiments, the identifier of the work order corresponding to the remote assistance request is stored or expressed separately from the scheduling domain information to which the work order belongs. The scheduling domain information includes at least one of the following: regional number, operation center number, and scheduling domain configuration.

[0076] In this embodiment, the work order is identified by a unique identifier assigned to each work order by the scheduling system, which is used to uniquely identify the work order in the entire system.

[0077] The work order identifier and scheduling domain information are stored separately at the data storage level. The work order identifier is stored as an independent field, and the scheduling domain information is stored as another independent field. The two are independent of each other and do not depend on each other.

[0078] The work order identifier and scheduling domain information are transmitted independently in scenarios such as internal system communication, log recording, and API interfaces. The scheduling domain information is not encoded or embedded in the work order identifier string.

[0079] The scheduling domain information is data related to the identity and configuration of the scheduling domain, specifically including at least one of the following: regional ID (e.g., East China Region, North China Region), operation center ID (e.g., Operation Center A, Operation Center B), and scheduling domain configuration (e.g., scheduling domain name, identifier, activation status, etc.).

[0080] When generating work order identifiers, the system does not use the region number, operation center number, or scheduling domain configuration as a uniqueness dependency. Work order identifiers are generated by a globally unified identifier generation mechanism and are stored or represented separately from scheduling domain information. Scheduling domains, region codes, and operation center codes can serve as business snapshots at the time of work order creation for subsequent scheduling, querying, auditing, and recovery, but this information does not participate in the core constraints of work order identifier uniqueness. Therefore, even if different scheduling domains use the same or similar region configurations, it will not affect the uniqueness and traceability of the work order identifier. The decoupling of work order identifiers from region information avoids identifier conflicts or migration difficulties caused by changes in configurations across different operation centers, making it more suitable for multi-center expansion.

[0081] By storing or representing work order identifiers separately from scheduling domain information, the uniqueness and traceability of work order identifiers will not be affected even if different scheduling domains use the same or similar regional configurations. When a scheduling domain configuration changes (such as renaming an operations center, merging or migrating regions), only the scheduling domain information field needs to be modified; the work order identifier itself does not need to be changed. This avoids identifier conflicts and migration difficulties, making it more suitable for multi-center expansion.

[0082] In some embodiments, it also includes: Generate a work order corresponding to the remote assistance request; Store at least one of the following information: dispatch domain configuration, vehicle affiliation with dispatch domain, operator affiliation with dispatch domain, dispatch participation status, work order, and the dispatch domain to which the work order belongs; In response to a switchover or recovery of the scheduling system, the scheduling service is restored based on the stored information.

[0083] In this embodiment, critical scheduling status data can be written to non-volatile storage media (such as databases, disks, etc.) so that the data remains available after system restart or failure.

[0084] The scheduling domain is configured with various configuration parameters, including the scheduling domain's enabled status and whether to accept new requests as a service switch.

[0085] The relationship between vehicles and scheduling domains is a mapping relationship of which scheduling domain each vehicle currently belongs to.

[0086] The relationship between operating positions and scheduling domains is a mapping relationship of which scheduling domain each operating position (cloud cabin) currently belongs to.

[0087] The dispatch participation status is an independent business status for each vehicle, indicating whether it is allowed to enter the remote driving dispatch process.

[0088] The scheduling domain to which a work order belongs is the scheduling domain that the work order was bound to when it was created.

[0089] The dispatch service refers to the remote assistance request dispatch function based on dispatch domain isolation, including core dispatch capabilities such as receiving vehicle-side requests, verifying vehicle status, routing to the corresponding dispatch domain, and allocating operation seats.

[0090] Key states such as dispatch domain configuration, vehicle dispatch status, vehicle affiliation with dispatch domain, operator affiliation with dispatch domain, queue status within the domain, and domain snapshot at the time of work order creation are persistently saved. Runtime memory is used only as a dispatch acceleration cache and is not the sole source of state.

[0091] In some embodiments, restoring the scheduling service includes at least one of the following processes: Restore the scheduling domain to its enabled state; Restore the ownership relationship between vehicles and dispatch domains, as well as the ownership relationship between operating positions and dispatch domains; Restore scheduling participation status; Restore incomplete work orders and the scheduling domain to which they belong; Restore the order of pending work orders within the domain; Restore the state of security constraints associated with the scheduling domain.

[0092] In this embodiment, when the scheduling system undergoes a primary / backup switchover or fault recovery, the new scheduling node can recover from the persistent state by: restoring the enabled state of each scheduling domain, determining which scheduling domains are enabled and which are disabled; restoring the ownership relationship between all vehicles and operator positions and scheduling domains, ensuring that the resource ownership mapping is consistent with before the fault; restoring the scheduling participation status of each vehicle, determining whether each vehicle is allowed to participate in scheduling; restoring incomplete work orders and their respective scheduling domains, enabling these work orders to continue to be dispatched within the correct scheduling domains; restoring the order of pending work orders in each domain, ensuring that the processing priority and order of work orders remain unchanged; and restoring the security constraint state related to the scheduling domains, ensuring that the restored scheduling service continues to operate within the security boundary. After all the recovery is completed, the new scheduling node continues to process existing work orders and new requests according to the domain isolation rules.

[0093] In this application, after the critical scheduling state is persisted, the new scheduling node can restore the domain configuration, vehicle status and intra-domain queues, ensuring scheduling continuity after the switchover and avoiding resource boundary loss, queue loss or duplicate order dispatch after high availability switchover.

[0094] In actual implementation, in a multi-operation center resource isolation scheduling scenario, the system is configured with multiple scheduling domains, each managing its own vehicles, operator seats, and scheduling queues. After a vehicle initiates a remote assistance request, the cloud-based dispatching side first determines the scheduling domain to which the vehicle belongs. The work order enters the queue of the corresponding scheduling domain, and only available operator seats within that domain are selected during work order dispatch. Requests and operator seat resources from other scheduling domains do not participate in the work order dispatch competition. Each scheduling domain independently completes its own work order dispatch, without competing for resources.

[0095] In a vehicle maintenance scheduling scenario, when a vehicle enters maintenance or testing mode, operations personnel switch it to not participate in scheduling. The cloud-based scheduling side updates the vehicle's scheduling status and notifies the vehicle to stop or suppress related reporting. Subsequent new remote assistance requests for this vehicle will not create new work orders. If there were already active work orders before the switch, those work orders will continue to be processed according to the rules at the time of creation. After vehicle maintenance is completed, it is switched back to participate in scheduling, and normal reporting and dispatching resume.

[0096] In a scenario where domain isolation scheduling is restored after a high-availability switchover, if the primary node of the scheduling system fails, the backup node takes over the scheduling service. The new scheduling node restores the scheduling domain configuration, vehicle and operator assignments, vehicle scheduling status, and incomplete work orders from the persistent state, and restores the domain's pending queue based on the domain snapshot at the time the work order was created. After restoration, the scheduling system continues to process existing work orders and new vehicle-side requests according to the domain isolation rules.

[0097] The scheduling domain isolation method for autonomous vehicles provided in this application can be executed by a scheduling domain isolation device for autonomous vehicles. This application uses the execution of the scheduling domain isolation method for autonomous vehicles by a scheduling domain isolation device as an example to illustrate the scheduling domain isolation device for autonomous vehicles provided in this application.

[0098] This application also provides a scheduling domain isolation device for autonomous vehicles.

[0099] like Figure 5 As shown, the dispatch domain isolation device for the autonomous vehicle includes: a first processing module 510, a second processing module 520, and a third processing module 530.

[0100] The first processing module 510 is used to respond to the remote assistance request of the target vehicle and obtain the scheduling participation status of the target vehicle. The second processing module 520 is used to determine the target scheduling domain to which the target vehicle belongs when the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain, and the same vehicle and the same operating seat belong to the same scheduling domain at the same time. The third processing module 530 is used to allocate a target operating seat from the operating seats of the target scheduling domain based on the target scheduling domain to which the target vehicle belongs, so as to process the remote assistance request of the target vehicle based on the target operating seat.

[0101] The autonomous vehicle scheduling domain isolation device provided in the embodiments of this application realizes independent control over whether a single vehicle participates in scheduling by filtering the vehicle scheduling participation status in advance. This facilitates vehicle maintenance, testing, shutdown and resumption of operation without affecting other vehicles and other scheduling domains. Through the unique ownership constraint of the scheduling domain, vehicles and operating positions are allocated in a closed loop within the domain, avoiding problems such as cross-center resource sharing and mutual interference of service quality, reducing network latency and improving the control efficiency of remote driving.

[0102] In some embodiments, each scheduling domain is further configured with a scheduling queue belonging to the scheduling domain; the scheduling domain isolation device for the autonomous vehicle may further include a fourth processing module, used to add the remote assistance request to the scheduling queue of the target scheduling domain before allocating a target operating seat from the operating seats of the target scheduling domain based on the target scheduling domain to which the target vehicle belongs. The third processing module 530 can also be used for: Retrieve remote assistance requests from the scheduling queue of the target scheduling domain and allocate target operation seats from the operation seats of the target scheduling domain.

[0103] In some embodiments, the fourth processing module can also be used for: Generate a work order corresponding to the remote assistance request and add the work order to the scheduling queue of the target scheduling domain; The third processing module 530 can also be used for: Retrieve work orders from the scheduling queue.

[0104] In some embodiments, the dispatch domain isolation device for the autonomous vehicle may further include a fifth processing module, for: In response to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, the work orders that have been generated or are being executed by the target vehicle will continue to be dispatched according to the scheduling domain to which they belonged at the time of creation.

[0105] In some embodiments, the dispatch domain isolation device for the autonomous vehicle may further include a sixth processing module for: In response to a configuration change operation for a scheduling domain, the system verifies whether there are any incomplete work orders in the scheduling domain, operator seat, or vehicle corresponding to the configuration change operation. The configuration change operation includes at least one of the following: closing the scheduling domain, removing the operator seat from the scheduling domain, and removing the vehicle from the scheduling domain. If there are incomplete work orders, restrict or postpone the execution of configuration change operations.

[0106] In some embodiments, the dispatch domain isolation device for the autonomous vehicle may further include a seventh processing module, which is used to separate the identifier of the work order corresponding to the remote assistance request from the dispatch domain information to which the work order belongs, and to store or express them separately. The dispatch domain information includes at least one of the following: regional number, operation center number, and dispatch domain configuration.

[0107] In some embodiments, the dispatch domain isolation device for the autonomous vehicle may further include an eighth processing module, for: Generate a work order corresponding to the remote assistance request; Store at least one of the following information: dispatch domain configuration, vehicle affiliation with dispatch domain, operator affiliation with dispatch domain, dispatch participation status, work order, and the dispatch domain to which the work order belongs; In response to a switchover or recovery of the scheduling system, the scheduling service is restored based on the stored information.

[0108] In some embodiments, the eighth processing module can also be used for: Restore the scheduling domain to its enabled state; Restore the ownership relationship between vehicles and dispatch domains, as well as the ownership relationship between operating positions and dispatch domains; Restore scheduling participation status; Restore incomplete work orders and the scheduling domain to which they belong; Restore the order of pending work orders within the domain; Restore the state of security constraints associated with the scheduling domain.

[0109] In some embodiments, the dispatch domain isolation device for the autonomous vehicle may further include a ninth processing module, for: In response to a change in the dispatch participation status of the target vehicle, the changed dispatch participation status is synchronized to the target vehicle to indicate whether the target vehicle should continue to report remote assistance requests.

[0110] In some embodiments, the third processing module 530 can also be used for: If the target scheduling domain allows new requests, allocate a target operation seat from the operation seats of the target scheduling domain.

[0111] The dispatch domain isolation device for autonomous vehicles in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the specific implementation.

[0112] The dispatch domain isolation device for autonomous vehicles in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit it.

[0113] The dispatch domain isolation device for autonomous vehicles provided in this application embodiment can achieve Figures 1 to 4 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0114] In some embodiments, this application also provides a scheduling domain isolation system for autonomous vehicles, which is used to execute the various processes of the above-described scheduling domain isolation method embodiments for autonomous vehicles and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0115] In some embodiments, such as Figure 6 As shown, this application embodiment also provides an electronic device 600, including a processor 601, a memory 602, and a computer program stored in the memory 602 and executable on the processor 601. When the program is executed by the processor 601, it implements the various processes of the above-described autonomous vehicle scheduling domain isolation method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0116] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0117] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described autonomous vehicle scheduling domain isolation method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0118] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0119] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for isolating the scheduling domain of an autonomous vehicle.

[0120] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0121] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described autonomous vehicle scheduling domain isolation method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0122] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0123] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0125] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0126] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0127] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A scheduling domain isolation method for autonomous vehicles, characterized in that, include: In response to a remote assistance request from a target vehicle, the scheduling participation status of the target vehicle is obtained; When the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling, the target scheduling domain to which the target vehicle belongs is determined. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain, and the same vehicle and the same operating seat belong to the same scheduling domain at the same time. Based on the target dispatch domain to which the target vehicle belongs, a target operating seat is allocated from the operating seats of the target dispatch domain to process the remote assistance request of the target vehicle based on the target operating seat; Before allocating a target operating seat from the operating seats of the target scheduling domain based on the target vehicle's affiliation, the method further includes: generating a work order corresponding to the remote assistance request, wherein the work order is bound to the target scheduling domain; In response to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, the work orders that the target vehicle has generated or is currently executing will continue to be dispatched according to the scheduling domain to which they belonged at the time of creation. The operating position is the remote driver's operating terminal.

2. The scheduling domain isolation method for autonomous vehicles according to claim 1, characterized in that, Each of the aforementioned scheduling domains is also configured with a scheduling queue belonging to that scheduling domain; Before allocating a target operating seat from the operating seats of the target scheduling domain based on the target vehicle's affiliation, the method further includes: Add the remote assistance request to the scheduling queue of the target scheduling domain; The allocation of target operation seats from the operation seats of the target scheduling domain includes: The remote assistance request is obtained from the scheduling queue of the target scheduling domain, and a target operation seat is allocated from the operation seats of the target scheduling domain.

3. The scheduling domain isolation method for autonomous vehicles according to claim 2, characterized in that, Adding the remote assistance request to the scheduling queue of the target scheduling domain includes: Generate a work order corresponding to the remote assistance request, and add the work order to the scheduling queue of the target scheduling domain; Retrieving the remote assistance request from the scheduling queue of the target scheduling domain includes: The work order is retrieved from the scheduling queue.

4. The scheduling domain isolation method for autonomous vehicles according to claim 3, characterized in that, Also includes: In response to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, the work orders that have been generated or are being executed by the target vehicle will continue to be dispatched according to the scheduling domain to which they belonged at the time of creation.

5. The scheduling domain isolation method for autonomous vehicles according to claim 3, characterized in that, Also includes: In response to a configuration change operation for a scheduling domain, the system verifies whether there are any incomplete work orders in the scheduling domain, operator seat, or vehicle corresponding to the configuration change operation. The configuration change operation includes at least one of the following: closing the scheduling domain, removing the operator seat from the scheduling domain, and removing the vehicle from the scheduling domain. If there are incomplete work orders, restrict or postpone the execution of the configuration change operation.

6. The scheduling domain isolation method for autonomous vehicles according to any one of claims 1-5, characterized in that, The identifier of the work order corresponding to the remote assistance request is stored or expressed separately from the scheduling domain information to which the work order belongs. The scheduling domain information includes at least one of the following: regional number, operation center number, and scheduling domain configuration.

7. The scheduling domain isolation method for autonomous vehicles according to any one of claims 1-5, characterized in that, Also includes: Generate a work order corresponding to the remote assistance request; Store at least one of the following information: scheduling domain configuration, vehicle affiliation with scheduling domain, operator affiliation with scheduling domain, scheduling participation status, work order, and the scheduling domain to which the work order belongs; In response to a switchover or recovery of the scheduling system, the scheduling service is restored based on the stored information.

8. The scheduling domain isolation method for autonomous vehicles according to claim 7, characterized in that, The recovery scheduling service includes at least one of the following processes: Restore the enabled state of the scheduling domain; Restore the ownership relationship between vehicles and dispatch domains, as well as the ownership relationship between operating positions and dispatch domains; Restore the scheduling participation state; Restore incomplete work orders and the scheduling domain to which the incomplete work orders belong; Restore the order of pending work orders within the domain; Restore the state of security constraints associated with the scheduling domain.

9. The scheduling domain isolation method for autonomous vehicles according to any one of claims 1-5, characterized in that, Also includes: In response to a change in the scheduling participation status of the target vehicle, the changed scheduling participation status is synchronized to the target vehicle to indicate whether the target vehicle should continue to report remote assistance requests.

10. The scheduling domain isolation method for autonomous vehicles according to any one of claims 1-5, characterized in that, The step of allocating a target operating seat from the operating seats of the target scheduling domain based on the target vehicle's affiliation includes: If the target scheduling domain allows new requests, a target operating seat is allocated from the operating seats of the target scheduling domain.

11. A scheduling domain isolation device for an autonomous vehicle, characterized in that, include: The first processing module is used to respond to the remote assistance request of the target vehicle and obtain the scheduling participation status of the target vehicle. The second processing module is used to determine the target scheduling domain to which the target vehicle belongs when the scheduling participation status indicates that the target vehicle is allowed to participate in the scheduling. Each scheduling domain is configured with a set of vehicles and a set of operating seats belonging to the scheduling domain, and the same vehicle and the same operating seat belong to the same scheduling domain at the same time. The third processing module is used to allocate a target operating seat from the operating seats of the target scheduling domain based on the target scheduling domain to which the target vehicle belongs, so as to process the remote assistance request of the target vehicle based on the target operating seat. The fourth processing module is used to allocate a target operation seat from the operation seats of the target dispatch domain based on the target vehicle's affiliation, generate a work order corresponding to the remote assistance request, and bind the work order to the target dispatch domain. The fifth processing module is used to respond to the target vehicle's scheduling participation status switching from participating in scheduling to not participating in scheduling, and the work orders that the target vehicle has generated or is currently executing continue to be dispatched according to the scheduling domain to which they belonged at the time of creation; The operating position is the remote driver's operating terminal.

12. A scheduling domain isolation system for autonomous vehicles, characterized in that, Used to perform the scheduling domain isolation method for autonomous vehicles as described in any one of claims 1-10.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the scheduling domain isolation method for autonomous vehicles as described in any one of claims 1-10.

Images