Automatic driving system fault processing method, device, equipment and storage medium

CN120573128BActive Publication Date: 2026-09-08FOSS (HANGZHOU) INTELLIGENT TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510651594.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-05-20
Publication Date
2026-09-08
Estimated Expiration
2045-05-20

AI Technical Summary

Technical Problem

[0005]本发明的主要目的在于提供了一种自动驾驶系统故障处理方法、装置、设备及存储介质,旨在解决现有技术中自动驾驶系统在通信异常时,难以维持短时控车能力,导致自动驾驶系统的安全性较低的技术问题

Benefits of technology

[0039] This invention discloses a method for determining whether an autonomous driving system is faulty based on communication status information. When a fault exists in the autonomous driving system, a safety mode is triggered. Upon entering the safety mode, it is determined whether backup link perception information exists. If backup link perception information exists, vehicle control commands are generated using the backup link perception information and historical perception data, and the current vehicle status information is obtained. The vehicle control method is determined based on the current status information, and if the driver takes over the vehicle during the execution of the control commands based on the current method, the system exits the safety mode. Because this invention quickly triggers the safety mode when communication is abnormal, maintains vehicle control using backup link perception information and historical perception data, and exits the safety mode when the driver takes over the vehicle, compared to existing technologies, this invention effectively improves the robustness and safety of the autonomous driving system when communication is abnormal.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120573128B_ABST
    Figure CN120573128B_ABST
Patent Text Reader

Abstract

The application discloses an automatic driving system fault processing method, device and equipment and a storage medium. The method comprises the following steps: determining whether the automatic driving system has a fault based on communication state information; triggering a safety mode of the automatic driving system when the automatic driving system has a fault, and determining whether backup link perception information exists after entering the safety mode; generating a vehicle control instruction by using the backup link perception information and historical perception data if the backup link perception information exists, and obtaining current state information of the vehicle; determining a vehicle control mode according to the current state information, and exiting the safety mode if a driver takes over the vehicle in the process of executing the vehicle control instruction based on the vehicle control mode. Since the safety mode is triggered quickly when the communication is abnormal, the backup link perception information and the historical perception data are used to maintain vehicle control, and the safety mode is exited when the driver takes over the vehicle, the robustness and safety of the automatic driving system are effectively improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to a method, apparatus, device and storage medium for handling faults in an autonomous driving system. Background Technology

[0002] With the rapid development of autonomous driving technology, advanced driver assistance systems (ADAS) such as Highway Assist (HWA) are gradually becoming widespread in mass-produced vehicles. These systems typically rely on multi-chip or multi-core collaboration to achieve sensor data fusion, planning and control, and vehicle execution through real-time communication across chips or cores. For example, in existing technologies, previous-generation domain controllers achieved target fusion and planning and control through Ethernet communication between MCU chips and SOC chips, while new-generation domain controllers achieve collaborative perception and decision-making through multi-core division of labor within a single chip.

[0003] However, such distributed architectures face significant security challenges in complex scenarios. When cross-chip or cross-core communication is interrupted by hardware failures, software freezes, or short-term interruptions (such as a 3-second Ethernet heartbeat interruption), the system may fail to detect or respond in a timely manner. For example, in a mass-produced vehicle case, a communication interruption between the MCU and the SOC caused the fusion module to lose target information, leading the system to mistakenly determine that there was no vehicle ahead and accelerate, ultimately causing a collision. Although existing technologies trigger function degradation through diagnostic fault codes (DTCs), the delayed reporting of DTCs (e.g., reaching a 3-second threshold) means that the function may have already entered an unintended control state before degradation. Furthermore, in dynamic scenarios such as lane changes or vehicle tilting, if communication is interrupted or the module freezes, existing systems struggle to coordinate cross-lane trajectory planning and control, potentially causing the vehicle to deviate from its intended path or become uncontrollable.

[0004] Therefore, there is an urgent need for a fault handling method for autonomous driving systems that can quickly trigger a safety mode when communication is abnormal and use backup or historical data to maintain vehicle control, thereby improving the robustness and safety of autonomous driving systems. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for handling faults in an autonomous driving system, aiming to solve the technical problem in the prior art where autonomous driving systems have difficulty maintaining short-term vehicle control capabilities when communication is abnormal, resulting in low safety of the autonomous driving system.

[0006] To achieve the above objectives, the present invention provides a fault handling method for an autonomous driving system, the method comprising the following steps:

[0007] Determine if there is a fault in the autonomous driving system based on communication status information;

[0008] When a fault occurs in the autonomous driving system, the safety mode of the autonomous driving system is triggered, and after entering the safety mode, it is determined whether backup link perception information exists.

[0009] If backup link awareness information exists, the backup link awareness information and historical awareness data are used to generate vehicle control commands and obtain the vehicle's current status information.

[0010] The vehicle control mode is determined based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, the safe mode is exited.

[0011] Optionally, the step of determining whether the autonomous driving system has a fault based on communication status information includes:

[0012] Acquire communication status information, which is the update status information of perception fusion information and heartbeat packet information;

[0013] Based on the update status information, determine whether the perception fusion information has not been updated continuously until the first preset frame or whether the heartbeat packet information has not been updated continuously until the second preset frame, and obtain the determination result;

[0014] The determination of whether the autonomous driving system is faulty is based on the judgment result.

[0015] Optionally, after the step of determining whether the autonomous driving system has a fault based on the determination result, the method further includes:

[0016] If the judgment result is that the perception fusion information has not been updated for a first preset frame or the heartbeat packet information has not been updated for a second preset frame, then the autonomous driving system is faulty.

[0017] Optionally, after the step of triggering the safety mode of the autonomous driving system when a fault occurs, and determining whether backup link perception information exists after entering the safety mode, the method further includes:

[0018] If there is no backup link sensing information, the vehicle control command is generated using historical sensing data, and the current status information of the vehicle is obtained.

[0019] The steps include determining the vehicle control mode based on the current status information and, during the execution of the vehicle control command based on the vehicle control mode, exiting the safety mode if the driver takes over the vehicle.

[0020] Optionally, the step of triggering a safety mode of the autonomous driving system when a fault occurs, and determining whether backup link awareness information exists after entering the safety mode, includes:

[0021] When a malfunction occurs in the autonomous driving system, the safety mode of the autonomous driving system is triggered;

[0022] After the autonomous driving system enters the safety mode, it issues the flag corresponding to the safety mode.

[0023] Historical sensing data is acquired, and it is determined whether backup link sensing information exists. The historical sensing data is sensor data from a preset time period before the fault occurred.

[0024] Optionally, the step of determining the vehicle control mode based on the current state information, and exiting the safety mode if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, includes:

[0025] The vehicle control method is determined based on the current status information, and the vehicle control method includes the vehicle control method in this lane and the vehicle control method across lanes;

[0026] When the vehicle control mode is the lane-specific vehicle control mode, a vehicle control duration threshold is determined based on the current environmental information and the current state information, and the driver is reminded by generating a vehicle takeover prompt message through the autonomous driving system.

[0027] During the execution of the vehicle control command based on the lane-specific vehicle control method, if the vehicle control duration does not exceed the vehicle control duration threshold and the driver receives the vehicle takeover prompt and takes over the vehicle, the safety mode is exited.

[0028] Optionally, after the step of determining the vehicle control mode based on the current state information, the method further includes:

[0029] When the vehicle control mode is a cross-lane vehicle control mode, determine whether the autonomous driving system can generate a trajectory for the vehicle to return to its own lane during the lane change process;

[0030] If the autonomous driving system cannot generate a trajectory for the vehicle to return to its lane during the lane change process, it controls the vehicle to change lanes to the target lane based on the cross-lane vehicle control method, and generates a vehicle takeover prompt message through the autonomous driving system to remind the driver.

[0031] During the execution of the vehicle control command based on the cross-lane vehicle control method, if the driver receives the vehicle takeover prompt information and takes over the vehicle, the driver exits the safety mode.

[0032] Furthermore, to achieve the above objectives, the present invention also proposes an automatic driving system fault handling device, the device comprising:

[0033] The fault diagnosis module is used to determine whether there is a fault in the autonomous driving system based on communication status information.

[0034] The safety trigger module is used to trigger the safety mode of the autonomous driving system when a fault occurs in the autonomous driving system, and to determine whether backup link perception information exists after entering the safety mode.

[0035] The information acquisition module is used to generate vehicle control commands using the backup link perception information and historical perception data if backup link perception information exists, and to acquire the current status information of the vehicle.

[0036] The vehicle control module is used to determine the vehicle control mode based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, the module exits the safety mode.

[0037] Furthermore, to achieve the above objectives, the present invention also proposes an autonomous driving system fault handling device, the device comprising: a memory, a processor, and an autonomous driving system fault handling program stored in the memory and executable on the processor, the autonomous driving system fault handling program being configured to implement the steps of the autonomous driving system fault handling method described above.

[0038] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing an autonomous driving system fault handling program, wherein when the autonomous driving system fault handling program is executed by a processor, it implements the steps of the autonomous driving system fault handling method described above.

[0039] This invention discloses a method for determining whether an autonomous driving system is faulty based on communication status information. When a fault exists in the autonomous driving system, a safety mode is triggered. Upon entering the safety mode, it is determined whether backup link perception information exists. If backup link perception information exists, vehicle control commands are generated using the backup link perception information and historical perception data, and the current vehicle status information is obtained. The vehicle control method is determined based on the current status information, and if the driver takes over the vehicle during the execution of the control commands based on the current method, the system exits the safety mode. Because this invention quickly triggers the safety mode when communication is abnormal, maintains vehicle control using backup link perception information and historical perception data, and exits the safety mode when the driver takes over the vehicle, compared to existing technologies, this invention effectively improves the robustness and safety of the autonomous driving system when communication is abnormal. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating the first embodiment of the fault handling method for an autonomous driving system according to the present invention.

[0041] Figure 2 This diagram illustrates the internal links of the previous generation domain controller and the new generation domain controller.

[0042] Figure 3 This is a schematic diagram illustrating the specific workflow of the fault handling system of the autonomous driving system of the present invention;

[0043] Figure 4 This is a flowchart illustrating the second embodiment of the fault handling method for an autonomous driving system of the present invention;

[0044] Figure 5 This is a schematic diagram of the safety response mechanism of the autonomous driving system of the present invention in the event of communication interruption or system crash;

[0045] Figure 6 This is a flowchart illustrating the third embodiment of the fault handling method for an autonomous driving system of the present invention;

[0046] Figure 7 This is a structural block diagram of the first embodiment of the fault handling device for the autonomous driving system of the present invention;

[0047] Figure 8 This is a schematic diagram of the structure of an autonomous driving system fault handling device in the hardware operating environment involved in the embodiments of the present invention.

[0048] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0050] This invention provides a method for handling faults in an autonomous driving system, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the fault handling method for the autonomous driving system of the present invention.

[0051] In this embodiment, the automatic driving system fault handling method includes steps S10 to S40:

[0052] Step S10: Determine whether there is a fault in the autonomous driving system based on the communication status information.

[0053] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in vehicle control. The computer server device can be located in the vehicle, and can be a server, computer, in-vehicle mobile device, or an electronic device capable of performing the above functions, such as an autonomous driving system fault handling device. The following uses an autonomous driving system fault handling device as an example to illustrate this embodiment and the subsequent embodiments.

[0054] It should be explained that the aforementioned communication status information can be cross-chip or cross-core communication status information, and can be the update status information of perception fusion information and heartbeat packet information. The perception fusion information can be the fusion information of multiple sensors, and the heartbeat packet information can be a custom data packet used to maintain connection and monitor status in the network communication of the autonomous driving system.

[0055] refer to Figure 2 , Figure 2 This diagram illustrates the internal links of the previous generation and the new generation domain controller. In the previous generation domain controller, the SOC chip fused front and side radar information (environmental information detected by radar sensors in front of and to the sides of the vehicle) with forward-looking information from the vision processing chip (visual information in front of the vehicle), a process known as Sensor Data Fusion (SDF). The MCU chip then handled Sensor Fusion (SF), path planning, and control, as well as arbitration between different systems. Heartbeat packets were used for system health monitoring, and DTCs (Diagnostic Trouble Codes) were used for fault diagnosis and reporting. In short, the previous generation domain controller completed target fusion and planning control through Ethernet communication between the MCU chip and the SOC chip. In the new generation domain controller, visual information is first acquired. Then, the first core performs target fusion (SDF + SF + driving planning), handling target fusion, sensor fusion, and driving path planning. The second core then performs SF + partial L2 planning + control + arbitration, handling sensor fusion, partial L2 autonomous driving planning and control, and system arbitration. In short, the new generation domain controller achieves collaborative perception and decision-making through multi-core division of labor. Therefore, when cross-chip or cross-core communication is interrupted by hardware failure, software freeze, or short-term interruption (such as a 3-second interruption of Ethernet heartbeat), the autonomous driving system may not be able to detect or respond in a timely manner.

[0056] In practical implementation, communication status information across chips or cores can be monitored. When the communication status information (i.e., the update status information of perception fusion information and heartbeat packet information) is used to determine whether there is a fault in the autonomous driving system, it can also monitor communication status information across chips or cores and combine the communication status information with DTC (Diagnostic Trouble Code) information to determine whether there is a fault in the autonomous driving system.

[0057] Step S20: When there is a fault in the autonomous driving system, the safety mode of the autonomous driving system is triggered, and after entering the safety mode, it is determined whether there is backup link perception information.

[0058] It should be understood that the safety mode of an autonomous driving system is a comprehensive system designed to ensure that the vehicle can operate safely and reliably without human intervention.

[0059] It should be explained that backup link perception information refers to the perception data obtained by the autonomous driving system when the main communication link or main sensor link fails (such as communication interruption or sensor failure). This data is used to maintain the system's perception capability when the main link fails, ensuring the continuity and safety of vehicle control.

[0060] In a specific implementation, when a fault occurs in the autonomous driving system, the safety mode of the autonomous driving system is triggered; after the autonomous driving system enters the safety mode, a flag corresponding to the safety mode is issued; historical perception data is acquired, and it is determined whether there is backup link perception information. The historical perception data is sensor data from a preset time period before the fault occurred.

[0061] Step S30: If backup link sensing information exists, use the backup link sensing information and historical sensing data to generate vehicle control commands and obtain the current status information of the vehicle.

[0062] It should be understood that if there is no backup link sensing information, then historical sensing data is used to generate vehicle control and obtain the vehicle's current status information.

[0063] Understandably, vehicle control commands refer to vehicle control commands generated by the autonomous driving system based on perception data, planning algorithms, and the current vehicle status, used to control the vehicle's acceleration, deceleration, steering, and other behaviors.

[0064] It should be noted that the vehicle's current status information may include the vehicle's lane position, driving direction, and target trajectory.

[0065] Step S40: Determine the vehicle control mode based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, exit the safety mode.

[0066] It should be noted that vehicle control methods can include lane-specific control and cross-lane control. These two control methods have different control logics and objectives in safety mode to ensure safety in different scenarios.

[0067] It should be explained that positive acceleration requests are not allowed under this lane control mode; if a deceleration request is made when using backup link perception information to control the vehicle, the deceleration request will be executed; this lane control mode has a maximum control duration, which is determined by the lane length, vehicle speed, specific scenario, etc.; during this lane control process, the system needs to immediately remind the driver to take over the vehicle; if the driver takes over the vehicle during this lane control process, the safety mode will exit.

[0068] In cross-lane vehicle control mode, positive acceleration requests are not allowed; if a deceleration request is made using backup link sensing information, the deceleration request will be executed; during lane change, if the system can plan a trajectory to return to the current lane, the vehicle will return to the current lane; during lane change, if the system cannot plan a trajectory to the current lane, the vehicle will continue to change lanes to the target lane; the system needs to immediately remind the driver to take over the vehicle; during cross-lane vehicle control, if the driver takes over the vehicle, the safety mode will exit.

[0069] For example, refer to Figure 3 , Figure 3 The diagram illustrates the specific workflow of the autonomous driving system fault handling of this invention. First, it determines whether a safety mode has been triggered. If the safety mode is not triggered, the system operates normally. If the safety mode is triggered, it determines whether backup link perception information (i.e., backup link perception data) exists. If backup link perception information exists, the system uses the backup link perception information and historical perception data to control the vehicle and determines whether the vehicle is in a lane-changing state. If the vehicle is in a lane-changing state, a cross-lane control method is selected; if the vehicle is not in a lane-changing state, a lane-based control method is selected. Then, after the driver takes over the vehicle, the system exits the safety mode (i.e., function exit). If backup link perception information does not exist, the system uses historical perception data to control the vehicle and determines whether the vehicle is in a lane-changing state. If the vehicle is in a lane-changing state, a cross-lane control method is selected; if the vehicle is not in a lane-changing state, a lane-based control method is selected. Then, after the driver takes over the vehicle, the system exits the safety mode (i.e., function exit).

[0070] This embodiment discloses a method for determining whether an autonomous driving system is faulty based on communication status information. When a fault exists in the autonomous driving system, a safety mode is triggered. Upon entering the safety mode, it is determined whether backup link perception information exists. If backup link perception information exists, vehicle control commands are generated using the backup link perception information and historical perception data, and the current vehicle status information is obtained. The vehicle control method is determined based on the current status information, and if the driver takes over the vehicle during the execution of the control commands based on the current method, the system exits the safety mode. Because this embodiment quickly triggers the safety mode when communication is abnormal, maintains vehicle control using backup link perception information and historical perception data, and exits the safety mode when the driver takes over the vehicle, compared to existing technologies, this embodiment effectively improves the robustness and safety of the autonomous driving system when communication is abnormal.

[0071] refer to Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the fault handling method for the autonomous driving system of the present invention.

[0072] Based on the first embodiment described above, in this embodiment, step S10 includes steps S101 to S103:

[0073] Step S101: Obtain communication status information, which is the update status information of perception fusion information and heartbeat packet information.

[0074] Step S102: Determine whether the perception fusion information has not been updated continuously until the first preset frame or the heartbeat packet information has not been updated continuously until the second preset frame based on the update status information, and obtain the determination result.

[0075] Step S103: Determine whether the autonomous driving system has a fault based on the judgment result.

[0076] In a specific implementation, if the judgment result is that the perception fusion information has not been updated for a first preset frame or the heartbeat packet information has not been updated for a second preset frame, it indicates that the autonomous driving system has a fault.

[0077] For example, refer to Figure 5 , Figure 5 This diagram illustrates the safety response mechanism of the autonomous driving system of the present invention in the event of communication interruption or system hangup. In the diagram, time T1 represents the actual occurrence of the communication interruption or module hangup. At this time, the system may detect that the fused data (i.e., perception fused data) is not updated or the heartbeat packet (i.e., heartbeat packet information) is interrupted. If the fused data does not update for n1 frames (i.e., the first preset frame) or the transmission control heartbeat packet does not update for n2 frames (i.e., the second preset frame), the safety mode triggering condition is met, and the system enters safety mode. Before time T1 (i.e., before the safety mode flag is issued), the system records perception data (i.e., historical perception data, such as lane lines, target vehicle position, etc.) for a period of time to maintain vehicle control capability in safety mode. Time T2 is the moment when the system triggers safety mode after detecting the communication interruption or module hangup. At this time, the system determines whether to enter safety mode based on preset conditions (such as n1 frames of fused data not updating or n2 frames of heartbeat packet not updating). The exit time of safety mode can be dynamically determined according to specific operating conditions (such as lane length, vehicle speed, driver takeover status, etc.). When the driver takes over the vehicle or communication is restored, the system exits safety mode, and vehicle control commands become invalid. In safety mode, the system will not accelerate; it uses backup link sensing data or some valid sensor data for vehicle control; it uses historical sensing information for vehicle control; the exit time depends on the specific operating conditions.

[0078] It should be understood that the first and second preset frames mentioned above can be custom-set, and this embodiment does not impose any restrictions on them.

[0079] This embodiment discloses the acquisition of communication status information, which includes update status information of perception fusion information and heartbeat packet information. Based on the update status information, it determines whether the perception fusion information has not been updated for a first preset frame or whether the heartbeat packet information has not been updated for a second preset frame, obtaining a determination result. Based on the determination result, it determines whether the autonomous driving system has a fault. Since this invention determines whether the autonomous driving system has a fault by judging whether the perception fusion information has not been updated for a first preset frame or whether the heartbeat packet information has not been updated for a second preset frame, compared to existing technologies, this invention can quickly determine the system fault when communication is abnormal, thereby quickly triggering a safety mode and further improving the safety of the autonomous driving system.

[0080] refer to Figure 6 , Figure 6 This is a flowchart illustrating the third embodiment of the fault handling method for the autonomous driving system of the present invention.

[0081] Based on the above embodiments, in this embodiment, step S40 includes steps S401 to S403:

[0082] Step S401: Determine the vehicle control mode based on the current status information. The vehicle control mode includes the vehicle control mode in this lane and the vehicle control mode across lanes.

[0083] In practice, the current vehicle status can be determined based on the current status information, whether it is a lane keeping state or a lane changing state. If the current vehicle status is a lane keeping state, then the vehicle is controlled in the same lane, that is, the vehicle control method is the same as the lane control method. If the current vehicle status is a lane changing state, then the vehicle control method is determined based on the lane changing sub-state.

[0084] It should be noted that the lane change sub-states include Stage 0, Stage 1, and Stage 2. Stage 0 is the lane change waiting state; Stage 1 is the state where the vehicle begins to change lanes but does not have the right-of-way in the target lane and can safely and comfortably plan its return trajectory to the original lane; Stage 2 is the state where the vehicle already has the right-of-way in the target lane or is no longer able to safely and comfortably return to the original lane.

[0085] In the specific implementation, when the vehicle is in Stage 0, the lane change is canceled and the vehicle is controlled according to the lane-specific control method; when the vehicle is in Stage 1, the lane change is canceled, and the vehicle first travels along the trajectory back to the center of its own lane (i.e., the vehicle is controlled according to the cross-lane control method), and then the vehicle is controlled according to the lane-specific control method; when the vehicle is in Stage 2, it continues to complete the lane change according to the lane change trajectory (i.e., the vehicle is controlled according to the cross-lane control method), and after the lane change ends and it reaches the target lane, the vehicle is controlled according to the lane-specific control method.

[0086] It should be understood that when a vehicle is in stage 1, it will continuously plan a return path. If a comfortable trajectory to return to the original lane can be planned while satisfying the requirements of lateral acceleration comfort, the planning is considered successful. If the planned return path encroaches on the target lane of the lane change, it is considered to have the right-of-way of the target lane, that is, the vehicle is in stage 2.

[0087] Step S402: When the vehicle control mode is the lane-specific vehicle control mode, a vehicle control duration threshold is determined based on the current environment information and the current state information, and the driver is reminded by generating a vehicle takeover prompt message through the autonomous driving system.

[0088] Step S403: During the execution of the vehicle control command based on the lane-specific vehicle control method, if the vehicle control duration does not exceed the vehicle control duration threshold and the driver receives the vehicle takeover prompt and takes over the vehicle, exit the safety mode.

[0089] It should be noted that the above-mentioned vehicle control duration threshold can be determined based on factors such as lane length, vehicle speed, and the current specific scenario. The current environmental information can include lane length and the current specific scenario.

[0090] In a specific implementation, after step S401, steps S404 to S406 are also included:

[0091] Step S404: When the vehicle control mode is cross-lane vehicle control mode, determine whether the autonomous driving system can generate a trajectory for the vehicle to return to its own lane during the lane change process.

[0092] Step S405: If the autonomous driving system cannot generate a trajectory for the vehicle to return to its lane during the lane change process, it controls the vehicle to change lanes to the target lane based on the cross-lane vehicle control method, and generates a vehicle takeover prompt message through the autonomous driving system to remind the driver.

[0093] It should be noted that if the autonomous driving system can generate the trajectory of the vehicle returning to its lane during the lane change process, the vehicle can control the vehicle to return to its lane based on the cross-lane vehicle control method.

[0094] Step S406: During the execution of the vehicle control command based on the cross-lane vehicle control method, if the driver receives the vehicle takeover prompt information and takes over the vehicle, exit the safety mode.

[0095] This embodiment discloses a method for determining a vehicle control mode based on the current state information. The vehicle control mode includes lane-based control and cross-lane control. When the vehicle control mode is lane-based, a control duration threshold is determined based on the current environment information and the current state information. The autonomous driving system generates a vehicle takeover prompt to alert the driver. During the execution of the vehicle control command based on the lane-based control mode, if the control duration does not exceed the control duration threshold and the driver receives the vehicle takeover prompt and takes over the vehicle, the safe mode is exited. Because this embodiment determines the vehicle control mode based on the current state information, and when the control mode is lane-based, it determines the control duration threshold based on the current environment information and the current state information. If the control duration does not exceed the control duration threshold and the driver receives the vehicle takeover prompt and takes over the vehicle, the safe mode is exited. Compared to existing technologies, this embodiment dynamically adjusts the vehicle control command by distinguishing the vehicle's current state, ensuring safe driving even in fault states such as communication interruption or module jamming.

[0096] Furthermore, this embodiment of the invention also proposes a storage medium storing an autonomous driving system fault handling program, which, when executed by a processor, implements the steps of the autonomous driving system fault handling method described above.

[0097] Reference Figure 7 , Figure 7 This is a structural block diagram of the first embodiment of the fault handling device for the autonomous driving system of the present invention.

[0098] like Figure 7 As shown, the fault handling device for an autonomous driving system proposed in this embodiment of the invention includes: a fault judgment module 701, a safety triggering module 702, an information acquisition module 703, and a vehicle control module 704.

[0099] The fault determination module 701 is used to determine whether there is a fault in the autonomous driving system based on communication status information.

[0100] The safety trigger module 702 is used to trigger the safety mode of the autonomous driving system when there is a fault in the autonomous driving system, and after entering the safety mode, to determine whether there is backup link perception information.

[0101] The information acquisition module 703 is used to generate vehicle control commands using the backup link perception information and historical perception data if backup link perception information exists, and to acquire the current status information of the vehicle.

[0102] The vehicle control module 704 is used to determine the vehicle control mode based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, the safe mode is exited.

[0103] The safety trigger module 702 is further configured to generate a vehicle control command using historical sensing data if no backup link sensing information exists, and obtain the current status information of the vehicle; execute the step of determining the vehicle control mode based on the current status information, and exiting the safety mode if the driver takes over the vehicle during the process of executing the vehicle control command based on the vehicle control mode.

[0104] The safety trigger module 702 is also used to trigger the safety mode of the autonomous driving system when there is a fault in the autonomous driving system; after the autonomous driving system enters the safety mode, it issues a flag corresponding to the safety mode; acquires historical perception data and determines whether there is backup link perception information, wherein the historical perception data is sensor data from a preset time period before the fault occurred.

[0105] This device embodiment discloses a method for determining whether an autonomous driving system is faulty based on communication status information. When a fault exists in the autonomous driving system, a safety mode is triggered. Upon entering the safety mode, it is determined whether backup link perception information exists. If backup link perception information exists, vehicle control commands are generated using the backup link perception information and historical perception data, and the current vehicle status information is obtained. The vehicle control method is determined based on the current status information, and if the driver takes over the vehicle during the execution of the control commands based on the control method, the safety mode is exited. Because this device embodiment quickly triggers the safety mode when communication is abnormal, maintains vehicle control using backup link perception information and historical perception data, and exits the safety mode when the driver takes over the vehicle, compared to existing technologies, this device embodiment effectively improves the robustness and safety of the autonomous driving system when communication is abnormal.

[0106] Based on the first embodiment of the automatic driving system fault handling device of the present invention, a second embodiment of the automatic driving system fault handling device of the present invention is proposed.

[0107] In this embodiment, the fault judgment module 701 is further configured to acquire communication status information, which is the update status information of perception fusion information and heartbeat packet information; determine whether the perception fusion information has not been updated continuously to a first preset frame or whether the heartbeat packet information has not been updated continuously to a second preset frame based on the update status information, and obtain a judgment result; and determine whether the autonomous driving system has a fault based on the judgment result.

[0108] The fault judgment module 701 is further configured to indicate that the autonomous driving system has a fault if the judgment result is that the perception fusion information has not been updated for a first preset frame or the heartbeat packet information has not been updated for a second preset frame.

[0109] Other embodiments or specific implementations of the fault handling device for the autonomous driving system of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0110] This application provides an autonomous driving system fault handling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the autonomous driving system fault handling method in the above embodiment 1.

[0111] The following is for reference. Figure 8 The diagram illustrates a structural schematic suitable for implementing an autonomous driving system fault handling device according to embodiments of this application. The autonomous driving system fault handling device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The illustrated autonomous driving system fault handling device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0112] like Figure 8As shown, the autonomous driving system fault handling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the autonomous driving system fault handling device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the autonomous driving system fault handling device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows an autonomous driving system fault handling device with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0113] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0114] The autonomous driving system fault handling device provided in this application, employing the autonomous driving system fault handling method in the above embodiments, can solve the technical problem in the prior art where the autonomous driving system is unable to maintain short-term vehicle control capability when communication is abnormal, resulting in low safety of the autonomous driving system. Compared with the prior art, the beneficial effects of the autonomous driving system fault handling device provided in this application are the same as those of the autonomous driving system fault handling method provided in the above embodiments, and other technical features in this autonomous driving system fault handling device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0115] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0116] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0117] 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 system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0118] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0119] 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 the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0120] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. An automatic driving system failure handling method characterized by, The method includes: Determine if there is a fault in the autonomous driving system based on communication status information; When a fault occurs in the autonomous driving system, the safety mode of the autonomous driving system is triggered, and after entering the safety mode, it is determined whether backup link perception information exists. If backup link awareness information exists, the backup link awareness information and historical awareness data are used to generate vehicle control commands and obtain the vehicle's current status information. The vehicle control method is determined based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control method, the safety mode is exited. The step of determining whether the autonomous driving system has a fault based on communication status information includes: Acquire communication status information, which is the update status information of perception fusion information and heartbeat packet information; Based on the update status information, determine whether the perception fusion information has not been updated continuously until the first preset frame or whether the heartbeat packet information has not been updated continuously until the second preset frame, and obtain the determination result; Based on the judgment result, determine whether the autonomous driving system has a malfunction; After the step of triggering the safety mode of the autonomous driving system when a fault occurs, and determining whether backup link perception information exists after entering the safety mode, the method further includes: If there is no backup link sensing information, the vehicle control command is generated using historical sensing data, and the current status information of the vehicle is obtained. The steps include determining the vehicle control mode based on the current status information and, during the execution of the vehicle control command based on the vehicle control mode, exiting the safety mode if the driver takes over the vehicle.

2. The method for handling faults in an autonomous driving system as described in claim 1, characterized in that, After the step of determining whether the autonomous driving system has a fault based on the judgment result, the method further includes: If the judgment result is that the perception fusion information has not been updated for a first preset frame or the heartbeat packet information has not been updated for a second preset frame, then the autonomous driving system is faulty.

3. The method for handling faults in an autonomous driving system as described in claim 1, characterized in that, The step of triggering a safety mode of the autonomous driving system when a fault occurs, and determining whether backup link awareness information exists after entering the safety mode, includes: When a malfunction occurs in the autonomous driving system, the safety mode of the autonomous driving system is triggered; After the autonomous driving system enters the safety mode, it issues the flag corresponding to the safety mode. Historical sensing data is acquired, and it is determined whether backup link sensing information exists. The historical sensing data is sensor data from a preset time period before the fault occurred.

4. The method for handling faults in an autonomous driving system as described in claim 1, characterized in that, The step of determining the vehicle control mode based on the current state information, and exiting the safety mode if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, includes: The vehicle control method is determined based on the current status information, and the vehicle control method includes the vehicle control method in this lane and the vehicle control method across lanes; When the vehicle control mode is the lane-specific vehicle control mode, a vehicle control duration threshold is determined based on the current environmental information and the current state information, and the driver is reminded by generating a vehicle takeover prompt message through the autonomous driving system. During the execution of the vehicle control command based on the lane-specific vehicle control method, if the vehicle control duration does not exceed the vehicle control duration threshold and the driver receives the vehicle takeover prompt and takes over the vehicle, the safety mode is exited.

5. The method for handling faults in an autonomous driving system as described in claim 4, characterized in that, After the step of determining the vehicle control method based on the current state information, the method further includes: When the vehicle control mode is a cross-lane vehicle control mode, determine whether the autonomous driving system can generate a trajectory for the vehicle to return to its own lane during the lane change process; If the autonomous driving system cannot generate a trajectory for the vehicle to return to its lane during the lane change process, it controls the vehicle to change lanes to the target lane based on the cross-lane vehicle control method, and generates a vehicle takeover prompt message through the autonomous driving system to remind the driver. During the execution of the vehicle control command based on the cross-lane vehicle control method, if the driver receives the vehicle takeover prompt information and takes over the vehicle, the driver exits the safety mode.

6. A fault handling device for an autonomous driving system, characterized in that, The device includes: The fault diagnosis module is used to determine whether there is a fault in the autonomous driving system based on communication status information. The safety trigger module is used to trigger the safety mode of the autonomous driving system when a fault occurs in the autonomous driving system, and to determine whether backup link perception information exists after entering the safety mode. The information acquisition module is used to generate vehicle control commands using the backup link perception information and historical perception data if backup link perception information exists, and to acquire the current status information of the vehicle. The vehicle control module is used to determine the vehicle control mode based on the current status information, and if the driver takes over the vehicle during the execution of the vehicle control command based on the vehicle control mode, the module exits the safety mode. The fault judgment module is further configured to acquire communication status information, which is the update status information of perception fusion information and heartbeat packet information; determine whether the perception fusion information has not been updated continuously to a first preset frame or whether the heartbeat packet information has not been updated continuously to a second preset frame based on the update status information, and obtain a judgment result; and determine whether the autonomous driving system has a fault based on the judgment result. The safety triggering module is further configured to generate vehicle control commands using historical sensing data if no backup link sensing information exists, and to obtain the current status information of the vehicle; execute the steps of determining the vehicle control mode based on the current status information, and exiting the safety mode if the driver takes over the vehicle during the process of executing the vehicle control command based on the vehicle control mode.

7. A fault handling device for an autonomous driving system, characterized in that, The device includes: a memory, a processor, and an autonomous driving system fault handling program stored in the memory and executable on the processor, the autonomous driving system fault handling program being configured to implement the steps of the autonomous driving system fault handling method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores an autonomous driving system fault handling program, which, when executed by a processor, implements the steps of the autonomous driving system fault handling method as described in any one of claims 1 to 5.

Citation Information

Patent Citations

  • Vehicle control method and device based on automatic driving, equipment and medium

    CN109606385A

  • Automatic driving perception redundancy control method and device, equipment and storage medium

    CN117842076A