A remote driving switching system and method based on work order generation

Abstract

The present invention provides a remote driving switching system based on work order generation, which includes: a data acquisition module, which is used to obtain road test equipment monitoring data and the vehicle's own status data, and upload them to a cloud platform; a judgment and analysis module, which is used to judge the type of remote driving switching trigger event; a road test processing module, which is used to mark medium and high-risk intersections on the cloud platform map, generate remote driving work orders and send them to the cockpit; a vehicle-side processing module, which is used to screen out fault information that affects the autonomous driving operation capability, generate remote driving work orders and send them to the cockpit; a work order confirmation module, which is used to authenticate the remote driving work order and, after confirmation by the safety officer, send the response information back to the cloud platform; and a road test monitoring module, which is used to monitor the road status in real time, record the monitoring data, and report it to the vehicle.

Description

Technical Field

[0001] The present application relates to the field of remote driving technology, and in particular to a remote driving switching system and method based on work order generation. Background Art

[0002] Remote driving technology refers to real-time communication between the control center and the vehicle, thereby achieving remote monitoring and control of the vehicle. With the popularization of 5G networks and the improvement of corresponding policies, remote control technology has gradually attracted attention. In existing technologies, when unmanned vehicles with automatic and remote driving capabilities are operating unmanned on 5G demonstration public roads, they need to exit the automatic driving mode and slow down to park before remote control can be taken over. This poses a safety hazard in some scenarios where parking is not possible (elevated roads, highways, or single-lane roads, etc.); when an unmanned vehicle switches from remote driving mode to automatic driving mode, it needs to exit the remote driving mode and wait for the automatic driving mode to take over and stabilize the driving before the remote driver can be released. Therefore, when an autonomous driving vehicle is in an abnormal state, the timing and functional boundaries of remote driving intervention are relatively vague, which affects the vehicle's operating efficiency and safety. Summary of the Invention

[0003] In view of this, the present invention provides a remote driving switching system and method based on work order generation to solve technical problems in the prior art such as vague timing and functional boundaries of remote driving intervention, low vehicle operation efficiency, and poor safety.

[0004] The present invention provides a remote driving switching system based on work order generation, the system comprising: a data acquisition module, arranged on an unmanned vehicle, for acquiring monitoring data of a road test device and the vehicle's own status data, uploading the data to a cloud platform, and actively accessing a connected cockpit based on response information, establishing a remote driving cockpit communication link, and realizing remote driving switching;

[0005] The judgment and analysis module is set on the cloud platform and is connected to the data acquisition module through the network. It is used to judge the type of remote driving switching trigger event. When the trigger event type is a road test trigger event, the road test equipment monitoring data is sent to the road test processing module. When the trigger event type is a vehicle-side trigger event, the vehicle's own status data is sent to the vehicle-side processing module. After the cockpit authentication passes the remote driving work order, the work order ID, abnormal vehicle number, abnormal content, and fault level in the work order are subcontracted and analyzed for confirmation by the remote driving safety officer, and then the response information is sent to the vehicle; the road test processing module is set on the cloud platform and is connected to the trigger judgment module. It is used to classify events into low risk, medium risk, and other risk types based on the road test equipment detection data and the preset operational impact risk level. There are three risk levels: medium risk, low risk and high risk. Medium and high risk intersections are marked on the cloud platform map, and a remote driving work order is generated and sent to the cockpit before the vehicle reaches the intersection; the vehicle-side processing module is set on the cloud platform and connected to the trigger judgment module. It is used to screen out fault information that affects the autonomous driving operation capability according to the vehicle's own status data and the preset fault level list, and generate a remote driving work order and send it to the cockpit; the work order confirmation module is set in the cockpit and is connected to the cloud platform and the vehicle through the network. It is used to authenticate the remote driving work order and send the response information back to the cloud platform after confirmation by the safety officer; the road test monitoring module is set on the road test equipment and connected to the vehicle through the network. It monitors the road status in real time, records the monitoring data, and reports it to the vehicle.

[0006] Furthermore, the cloud platform is constantly connected to the vehicle and the cockpit via TCP / IP, and the vehicle is dynamically connected to the cockpit via TCP / IP.

[0007] Furthermore, the drive test monitoring module is further configured to, based on the road environment, record and broadcast a predetermined abnormality after determining that it occurs, thereby forming the drive test triggering event.

[0008] Furthermore, the data acquisition module is also used to diagnose the entire vehicle's intelligent system. When a system abnormality occurs, the abnormal information is monitored and uploaded to form a vehicle-side trigger event.

[0009] Furthermore, the vehicle intelligent system includes an automatic driving system, a remote driving system, a chassis control system, and a human-computer interaction system.

[0010] The present invention also provides a remote driving switching method based on work order generation, the method comprising: step 1, the vehicle obtains the monitoring data of the road test equipment and the status data of the vehicle itself, and uploads them to the cloud platform; step 2, when a road test triggering event occurs, the cloud platform divides the event into three risk levels of low risk, medium risk and high risk according to the monitoring data of the road test equipment and the preset operational impact risk level, marks the medium and high risk intersections on the cloud platform map, generates a remote driving work order before the vehicle reaches the intersection and sends it to the cockpit, and when a vehicle-side triggering event occurs, the cloud platform divides the event into three risk levels of low risk, medium risk and high risk according to ... and generates a remote driving work order before the vehicle reaches the intersection and sends it to the cockpit, and Status data, according to the preset fault level list, screens out fault information that affects the autonomous driving operation capability, generates a remote driving work order and sends it to the cockpit; Step 3, after the cockpit authenticates the remote driving work order, the cloud platform subcontracts and parses the work order ID, abnormal vehicle number, abnormal content, and fault level for confirmation by the remote driving safety officer in the cockpit; Step 4, after the safety officer confirms, the cockpit will send the response information back to the cloud platform; Step 5, the cloud platform sends the response information to the vehicle, and the vehicle actively accesses the connected cockpit based on the response information to establish a remote driving cockpit communication link.

[0011] Furthermore, the status data includes real-time vehicle chassis status data and automatic driving system diagnostic data.

[0012] Furthermore, step 2 also includes: when the cockpit is offline, busy or abnormal and cannot authenticate the remote driving work order, the cloud platform forwards the remote driving work order to other cockpits until the current cockpit authenticates the remote driving work order.

[0013] Furthermore, the system also includes: step 6, after the cockpit receives the vehicle access information, it verifies the access information; step 7, after the verification is successful, the cockpit displays the video information and chassis status information in the interface, establishes a remote control channel, enters the remote supervision state and waits for the safety officer to perform remote driving scheduling.

[0014] Furthermore, the system further includes: step 8, after the safety officer completes the takeover, the cockpit starts the automatic driving system, exits the remote driving state, reports to the cloud platform, and ends the remote driving work order task;

[0015] Step 9: After receiving the end signal from the cockpit, the cloud platform sets the work status to end, closes the interactive information flow of this work order, and waits for the next work order to be triggered.

[0016] The present invention provides a remote driving switching system and method based on work order generation. This technical solution dynamically connects the cloud platform, vehicle, and cockpit to ensure that the remote driving system can take over promptly and effectively in the event of an autonomous driving anomaly. This solves the problem of how to use the remote driving system to promptly rescue and take over abnormal vehicles when vehicles with automatic and remote driving capabilities are operating unmanned on public roads. This technical solution clarifies the timing and functional boundaries of intervention in unmanned operations, and implements an operational process that focuses on autonomous driving and uses remote driving for anomaly handling. This allows unmanned vehicles to reduce onboard manpower while also ensuring operational efficiency and safety. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a schematic diagram of a remote driving switching system based on work order generation provided by the present invention;

[0018] Figure 2 This is a schematic diagram of a remote driving switching method based on work order generation provided by the present invention;

[0019] Figure 3 This is the work order information content provided by the present invention. DETAILED DESCRIPTION

[0020] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0021] Device Item Example:

[0022] The present invention provides a remote driving switching system based on work order generation, such as Figure 1 As shown, the system includes a data acquisition module, a judgment and analysis module, a road test processing module, a vehicle-side processing module, a work order confirmation module and a road test detection module.

[0023] The data acquisition module, installed on the unmanned vehicle, is used to acquire monitoring data from the road test equipment and the vehicle's own status data, and upload it to the cloud platform. Simultaneously, based on the response information, it proactively accesses the connected cockpit to establish a remote driving in-cabin communication link. The vehicle referred to here typically refers to a Level 4 (L4 autonomous driving, which achieves full autonomous driving within a specified speed without driver intervention) vehicle equipped with both automatic and remote control systems. It possesses 5G and V2X interoperability and ensures real-time data exchange with the cloud platform upon power-up. Data uploaded to the cloud platform includes real-time chassis status data and autonomous driving system diagnostic data, while commands issued to the vehicle from the cloud platform include remote dispatch commands and operational route instructions. The vehicle's interaction with the road test equipment primarily involves obtaining real-time functional and operational status of the road ahead, including information such as traffic light change signals, road congestion signals, and traffic accident change signals. The vehicle is also used to diagnose the vehicle's intelligent system. When a system anomaly occurs, the anomaly information is monitored and uploaded, generating a vehicle-side trigger event. The vehicle's intelligent system includes the autonomous driving system, remote driving system, chassis control system, and human-computer interaction system.

[0024] The judgment and analysis module is set on the cloud platform and connected to the data acquisition module through the network. It is used to judge the type of remote driving switching trigger event. When the trigger event type is a road test trigger event, the road test equipment monitoring data is sent to the road test processing module. When the trigger event type is a vehicle-side trigger event, the vehicle's own status data is sent to the vehicle-side processing module. After the cockpit authentication passes the remote driving work order, the work order ID, abnormal vehicle number, abnormal content, and fault level in the work order are subcontracted and analyzed for confirmation by the remote driving safety officer, and then the response information is sent to the vehicle. The road test processing module, located on the cloud platform and connected to the trigger judgment module, is used to classify events into three risk levels: low risk, medium risk, and high risk, based on the detection data of the road test equipment and according to the preset operational impact risk level. Medium and high-risk intersections are marked on the cloud platform map, and a remote driving work order is generated and sent to the cockpit before the vehicle reaches the intersection. The vehicle-side processing module, located on the cloud platform and connected to the trigger judgment module, is used to screen out fault information that affects the autonomous driving operation capability based on the vehicle's own status data and a preset fault level list, and generate a remote driving work order and send it to the cockpit. The cloud platform can manage, monitor, and dispatch batch device information for vehicles, cockpits, remote driver accounts, etc., and can register, monitor, and allocate information such as vehicles, cockpits, and remote driver accounts. It can also parse and display the status data of vehicles, cockpits, and other equipment in real time, and allocate the binding relationship between vehicles and cockpits based on device background requests, pre-configuration, algorithm scheduling, etc., to maximize the operational efficiency of unmanned vehicles. The dispatch algorithm comprehensively evaluates V2X data reported by vehicles and vehicle self-diagnostic data to identify vehicles that may or have been affected. It then generates work orders based on the severity of the impact, such as those requiring manual assistance or manual warnings, and assigns them to available cockpits. The cloud platform maintains a TCP / IP connection with the vehicles and cockpits.

[0025] The work order confirmation module, located in the cockpit, is connected to the cloud platform and the vehicle via the network. It authenticates remote driving work orders and, after confirmation by the safety officer, transmits the response information back to the cloud platform. The cockpit, with its own independent IP address, acts as a client, communicating with the cloud platform and reporting its status data and control requests. It also serves as a remote driving server, waiting for a vehicle to connect and exchange data for control, video, and display links. The vehicle and cockpit are dynamically connected via TCP / IP.

[0026] The road test monitoring module is installed on the road test equipment and connected to the vehicle via the network. It monitors the road status in real time, records the monitoring data, and reports it to the vehicle. The road test equipment has batch deployment, perception capabilities, and V2X communication capabilities. It can perceive and judge traffic targets and traffic environment information, and package and broadcast data. Therefore, the road test equipment is also used to record and broadcast the occurrence of specified anomalies based on the road environment, forming the road test trigger event. The specified anomalies here refer to the fact that since the road test equipment has standard traffic event monitoring capabilities, it can obtain, monitor, and send event scenario information structure data in accordance with the requirements of GB / T29100-2012; at the same time, it supports the monitoring of events such as traffic disasters, traffic weather, road conditions, road construction, etc., and supports vehicle-side equipment to obtain road information in advance.

[0027] The present invention provides a remote driving switching system based on work order generation, which dynamically connects the four systems of vehicle, road, cloud, and cabin. It mainly solves the problem of how to use road test equipment and vehicle self-diagnosis capabilities when vehicles with automatic and remote driving capabilities are operating unmanned on 5G demonstration public roads, and promptly use the remote driving system to rescue and get out of trouble for problems and situations that may or have affected the operation of autonomous driving vehicles, restore the vehicle's operating capabilities, and ensure that the remote driving system can take over in a timely and effective manner when normal autonomous driving operations are obstructed, thereby ensuring the efficiency of unmanned operations.

[0028] Method Example:

[0029] The present invention provides a remote driving switching method based on work order generation, such as Figure 2 As shown, the method includes the following steps.

[0030] Step 1: The vehicle obtains monitoring data from the road test equipment and its own status data and uploads them to the cloud platform;

[0031] Since the vehicle itself has fault diagnosis and network communication capabilities, it can report its own fault information in the form of fault codes to the cloud platform in real time.

[0032] Step 2: When a road test trigger event occurs, the cloud platform classifies the event into three risk levels: low, medium, and high, based on the detection data from the road test equipment and the preset operational impact risk level. Medium and high-risk intersections are marked on the cloud platform map, and a remote driving work order is generated and sent to the cockpit before the vehicle reaches the intersection. When a vehicle-side trigger event occurs, the cloud platform screens out fault information that affects the autonomous driving operation capability based on the preset fault level list, generates a remote driving work order, and sends it to the cockpit.

[0033] Since the cloud platform usually manages multiple vehicles and cockpits at the same time, when the cloud platform sends a remote driving work order to the preset default supervision cockpit, it may encounter that the cockpit is not idle, that is, the cockpit cannot provide remote driving services. Therefore, the cloud platform needs to first determine whether the current cockpit is idle. The judgment method is whether the cloud platform can receive the remote driving work order authentication or response information fed back by the cockpit within the specified time. Therefore, step 2 also includes: when the cockpit is offline, busy or abnormal and cannot authenticate the remote driving work order, the cloud platform forwards the remote driving work order to other cockpits until the current cockpit authenticates the remote driving work order.

[0034] Remote driving work orders are divided into two forms: passive work orders and active work orders, such as Figure 3 As shown. Active driving work orders are a means for remote driving safety officers to proactively adjust the vehicle's status and remotely take over based on the vehicle's actual operating conditions. In actual operations, if there are non-fault scenarios requiring interruption of autonomous driving, such as changes in the operating route or temporary changes in the vehicle's mission, the remote driving safety officer can proactively select the corresponding vehicle number, forcibly interrupt autonomous driving, smoothly switch to remote driving, and remotely control the vehicle according to the actual mission schedule. After completing this task, you can use the "Actively Report Work Order" option in the cockpit interface to select information such as the takeover time, end time, reason for takeover, and vehicle being taken over, and then package it and report it to the reporting platform. After receiving the information stream proactively reported by the cockpit, the platform parses the information and converts it into a work order dataset, stores it in the database, archives the work order information, and completes the generation of this proactive work order. Since active work orders are mainly selected manually, they are not included in this step. The vehicle's C-V2X communication capabilities, 5G network communication capabilities, and self-diagnosis capabilities are used to integrate the acquired abnormal event information and report it to the platform. The work order is then generated based on the platform's scheduling algorithm. The remote driving work order generated in this step is a passive work order.

[0035] In addition, the cloud platform can manually filter out fault information that affects the autonomous driving operation capability from the data information uploaded in step 1. According to preset rules, a new work order data set with work order number, vehicle number, fault content, generation time, fault level, etc. is generated and stored in the server.

[0036] Step 3: After the remote driving work order is authenticated in the cockpit, the cloud platform will analyze the work order ID, abnormal vehicle number, abnormal content, and fault level for confirmation by the remote driving safety officer in the cockpit.

[0037] Once the cockpit is authenticated and displayed as online, the received information set is parsed and parsed. Information such as the work order ID, the vehicle number of the abnormality, the abnormality details, and the fault level are displayed in the cockpit interface as a remote takeover work order, awaiting confirmation from the remote driver. The remote takeover work order has two options: accept or reject. The remote driver responds based on the actual situation and reports the response. If the work order is rejected, the reason for the rejection must be noted.

[0038] Step 4: After the safety officer confirms, the cockpit will send the response information back to the cloud platform;

[0039] After the safety officer confirms the response, the cockpit sends the response back to the cloud platform. If the response is accepted, the cloud platform sends the cockpit ID, IP address, and port number to the abnormal vehicle. The vehicle then actively connects to the target cockpit server based on the cockpit information, formally establishing a remote driving cockpit communication link. If the response is rejected, the platform retrieves other cockpit information and issues a work order dataset until the work order information is executed.

[0040] Step 5: The cloud platform sends the response information to the vehicle, and the vehicle actively accesses the connected cockpit based on the response information to establish a remote driving cockpit communication link.

[0041] Step 6: After receiving the vehicle access information, the cockpit verifies the access information;

[0042] Step 7: After successful verification, the cockpit will display the video information and chassis status information on the interface, establish a remote control channel, and enter the remote supervision state to wait for the safety officer to conduct remote driving dispatch.

[0043] Step 8: After the safety officer takes over, the cockpit starts the autonomous driving system, exits the remote driving state, reports to the cloud platform, and ends the remote driving work order task;

[0044] Step 9: After receiving the end signal from the cockpit, the cloud platform sets the work status to end, closes the interactive information flow of this work order, and waits for the next work order to be triggered.

[0045] After the safety officer officially takes over the vehicle, he or she will determine the remote control action based on the vehicle's surrounding environment and fault information. If the control is completed, the autonomous driving system will be started through the remote cockpit. After it is determined that it is working normally, the remote supervision state will be exited and the platform will be reported to complete the work order task. Upon receiving the end signal, the platform will set the work status to "end" and close the interactive information flow of this work order, waiting for the next work order to be triggered.

[0046] As can be seen from the above steps, the passive work order generation process goes through six stages: triggering, transmission, judgment, scheduling, execution, and termination. The triggering stage consists of two parts: road triggering and vehicle triggering, which are referred to as road test triggering events and vehicle-side triggering events above. The transmission stage is categorized into two types depending on the triggering component: I (Infrastructure) 2V (Vehicle) 2C (Cloud) and V2C. When triggered on the road, the abnormal event is broadcast via PC5 communication. The vehicle-side OBU receives the data and forwards it to the platform's communication data architecture for transmission to the cloud platform. When triggered on the vehicle, fault data from subsystems such as the automatic control, remote control, and chassis is packaged by the diagnostic system and forwarded to the cloud platform. The scheduling stage involves the platform scheduling cockpits based on resource priority. The cloud platform pre-registers cockpit, vehicle, and other equipment, and presets a default supervisory cockpit ID for each vehicle. Once the cockpit and vehicle complete login authentication and engage in continuous data communication, the platform prioritizes issuing vehicle abnormality work orders to the default cockpit. If the corresponding cockpit status is abnormal, such as offline, busy, or faulty, or if the work order is rejected, the platform proactively searches for other available and functioning cockpits and reissues the work order scheduling information until the work order is properly processed. Remote takeover work orders have two options: accept or reject. The remote safety officer responds based on the actual situation and reports the response. If the work order is rejected, the reason for rejection must be noted. After the safety officer confirms the response, the cockpit transmits the response back to the cloud platform. If the response is accepted, the platform sends the cockpit ID, IP address, and port array to the abnormal vehicle. The vehicle, based on the cockpit information, proactively connects to the target cockpit server, formally establishing a remote driving cockpit communication link. If the response is rejected, the platform retrieves other cockpit information and issues the work order dataset until the work order is processed. After the cockpit receives the vehicle connection information and successfully verifies the information, it displays the video and chassis status information on the interface, establishes a remote control channel, and enters the remote monitoring state, awaiting the safety officer's remote control takeover. The execution phase involves the remote cockpit driver performing specific actions on the unmanned vehicle based on the work order. For medium-risk work orders, the cockpit driver only monitors the vehicle's operating status in real time based on the vehicle bound to the work order without remote control. If the vehicle's automatic driving system operates normally and there are no obvious abnormalities in the vehicle speed, driving direction, etc., the driver will monitor the vehicle through the intersection or wait for the fault to disappear before exiting the monitoring state and ending the work order. If it is received from a high-risk work order, and the vehicle is obviously in an abnormal state after supervision or the road ahead will significantly affect the operation, remote control will be actively carried out, and the remote driver will steer the vehicle through the intersection. If it passes, the automatic driving system function will be restarted and restored to normal, and the operation will continue. If serious abnormalities persist, the remote control will directly take over the vehicle and exit the operation and return it to the maintenance station. The ending link is a closed-loop operation of the entire scheduling process. The cloud platform closes the work order process by receiving the work order end signal to form a work order record.After completing a single work order, the cockpit driver reports the completion of the work order to the platform using the "End" button. Upon receiving this signal, the platform completes the work order, creating a complete record of the process, including trigger time, trigger conditions, cockpit ID, execution time, executing user, and end time. This record is stored in the database for future reference. Active work orders allow remote drivers to proactively adjust the vehicle's status and remotely take over based on actual vehicle operations. In actual operations, if a non-fault situation arises, such as a route change or a temporary change in vehicle mission, but autonomous driving requires interruption, the remote driver can proactively select the corresponding vehicle ID, forcibly interrupt autonomous driving, and smoothly switch to remote driving, where they can remotely control the vehicle according to the actual task schedule. After completing the task, the driver can use the "Active Work Order" option in the cockpit interface to select the takeover time, end time, reason for takeover, and vehicle, and then submit the report to the platform. After receiving the information flow actively reported by the cockpit, the platform parses the information and converts it into a work order data set, stores it in the database, archives the work order information, and completes the generation of this active work order.

[0047] The present invention builds a multi-vehicle to multi-cabin unmanned driving operation system, giving the remote driving system time to prepare for takeover in advance, clarifying the intervention timing and functional boundaries of the remote driving system, and realizing an operation process that is mainly based on automatic driving and uses remote driving for operation warning and exception handling. This allows unmanned vehicles to reduce manpower investment on the vehicle while also ensuring operational efficiency and safety.

[0048] In summary, the embodiments of the present invention provide a remote driving switching system and method based on work order generation. By monitoring the status through multiple data such as road test feedback and vehicle diagnosis, the remote cockpit and unmanned vehicle scheduling control is completed based on the cloud platform, forming a vehicle scheduling trigger medium in the form of a work order. The remote driving system uses the work order information as an intervention signal in daily operations, clarifies the specific reasons for takeover and the content of takeover, and provides the remote driving safety officer with clear takeover prompts. At the same time, the remote takeover work order is used as the working boundary of the automatic driving system and the remote driving system. Before the work order is triggered, daily vehicle operations are mainly carried out based on automatic driving; after the work order is triggered, the main body of operational responsibility is transferred to the remote driving system and needs to be handled by the remote safety officer, avoiding the situation of unclear responsibilities and unclear boundaries caused by human judgment. In addition, the remote driving safety officer's ability to take over proactively is retained. In non-standard scenarios and temporary needs, the safety officer can also proactively interrupt the automatic driving system to meet temporary needs through remote control, retaining the ability of human judgment to be superior to machine judgment.

[0049] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A remote driving switching system based on work order generation, characterized in that: The system comprises: The data acquisition module is installed on the unmanned vehicle and is used to obtain monitoring data from the road test equipment and the vehicle's own status data, and upload it to the cloud platform. At the same time, it actively accesses the connected cockpit based on the response information, establishes a remote driving cockpit communication link, and realizes remote driving switching; The judgment and analysis module is set up on the cloud platform and connected to the data acquisition module through the network. It is used to determine the type of remote driving switching trigger event. If the trigger event type is a road test trigger event, the road test equipment monitoring data is sent to the road test processing module. If the trigger event type is a vehicle-side trigger event, the vehicle's own status data is sent to the vehicle-side processing module. After the cockpit authenticates the remote driving work order, the work order ID, abnormal vehicle number, abnormal content, and fault level in the work order are subcontracted and analyzed for confirmation by the remote driving safety officer, and then the response information is sent to the vehicle; The drive test processing module, located on the cloud platform and connected to the trigger judgment module, is used to classify events into three risk levels: low, medium, and high, based on the detection data of the drive test equipment and the preset operational impact risk level. Medium and high-risk intersections are marked on the cloud platform map, and a remote driving work order is generated and sent to the cockpit before the vehicle reaches the intersection. The vehicle-side processing module, installed on the cloud platform and connected to the trigger judgment module, is used to filter out fault information that affects autonomous driving operations based on the vehicle's own status data and a preset fault level list, and then generate a remote driving work order and send it to the cockpit; The work order confirmation module is installed in the cockpit and connected to the cloud platform and the vehicle through the network. It is used to authenticate the remote driving work order and transmit the response information back to the cloud platform after the safety officer confirms it. The road test monitoring module is installed on the road test equipment and connected to the vehicle through the network. It monitors the road status in real time, records the monitoring data, and reports it to the vehicle.

2. The remote driving switching system based on work order generation according to claim 1, characterized in that: The cloud platform is always connected to the vehicle and the cockpit via TCP / IP, while the vehicle and the cockpit are dynamically connected via TCP / IP.

3. The remote driving switching system based on work order generation according to claim 1, characterized in that: The drive test monitoring module is further configured to record and broadcast a predetermined abnormality upon determining the occurrence of the abnormality based on the road environment, thereby forming the drive test triggering event.

4. The remote driving switching system based on work order generation according to claim 1, characterized in that: The data acquisition module is also used to diagnose the entire vehicle's intelligent system. When a system abnormality occurs, the abnormal information is monitored and uploaded to form a vehicle-side trigger event.

5. A remote driving switching system based on work order generation according to claim 4, characterized in that: The vehicle intelligent system includes an automatic driving system, a remote driving system, a chassis control system, and a human-computer interaction system.

6. A method using the remote driving switching system based on work order generation according to claims 1-5, characterized in that: The method comprises: Step 1: The vehicle obtains monitoring data from the road test equipment and its own status data and uploads them to the cloud platform; Step 2: When a road test trigger event occurs, the cloud platform classifies the event into three risk levels: low, medium, and high, based on the detection data of the road test equipment and the preset operational impact risk level. Medium and high-risk intersections are marked on the cloud platform map, and a remote driving work order is generated and sent to the cockpit before the vehicle reaches the intersection. When a vehicle-side trigger event occurs, the cloud platform screens out fault information that affects the autonomous driving operation capability based on the vehicle's own status data and the preset fault level list, and generates a remote driving work order and sends it to the cockpit; Step 3: After the remote driving work order is authenticated in the cockpit, the cloud platform will analyze the work order ID, abnormal vehicle number, abnormal content, and fault level for confirmation by the remote driving safety officer in the cockpit. Step 4: After the safety officer confirms, the cockpit will send the response information back to the cloud platform; In step 5, the cloud platform sends the response information to the vehicle, and the vehicle actively accesses the connected cockpit based on the response information to establish a remote driving cockpit communication link so that the vehicle can switch to remote driving.

7. The remote driving switching method based on work order generation according to claim 6, characterized in that: The status data includes real-time vehicle chassis status data and automatic driving system diagnostic data.

8. The remote driving switching method based on work order generation according to claim 6, characterized in that: The step 2 also includes: when the cockpit is offline, busy or abnormal and cannot authenticate the remote driving work order, the cloud platform forwards the remote driving work order to other cockpits until the current cockpit authenticates the remote driving work order.

9. The remote driving switching method based on work order generation according to claim 6, characterized in that: The system further comprises: Step 6: After receiving the vehicle access information, the cockpit verifies the access information; Step 7: After successful verification, the cockpit will display the video information and chassis status information on the interface, establish a remote control channel, and enter the remote supervision state to wait for the safety officer to conduct remote driving dispatch.

10. The remote driving switching method based on work order generation according to claim 9, characterized in that: The system further comprises: Step 8: After the safety officer takes over, the cockpit starts the autonomous driving system, exits the remote driving state, reports to the cloud platform, and ends the remote driving work order task; Step 9: After receiving the end signal from the cockpit, the cloud platform sets the work status to end, closes the interactive information flow of this work order, and waits for the next work order to be triggered.

Images