Method for handling a fault, control system for an autonomous vehicle, electronic device

Abstract

The application provides a fault processing method, a control system of an automatic driving vehicle and an electronic device, and the method comprises the following steps: in response to receiving a fault recovery instruction, acquiring fault data; in the case that a fault type corresponding to the fault data is a white list fault, performing a first fault clearing operation to obtain a first fault clearing result, the white list fault being a fault which does not affect the formation driving performance in the case that the automatic driving mode is not degraded; in the case that the first fault clearing result shows that there is fault data which is not successfully cleared, performing a second fault clearing operation on the fault data which is not successfully cleared, and the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. Through the application, the technical problems of high labor cost, low efficiency and low safety and reliability of the fault recovery mode are solved, and the technical effects of completely unmanned operation of the following vehicle, reduction of labor cost, improvement of fault recovery efficiency and improvement of vehicle control reliability are achieved.

Description

Technical Field

[0001] This application relates to the field of autonomous driving, and in particular to fault handling methods, control systems for autonomous vehicles, and electronic equipment. Background Technology

[0002] Pacifying autonomous vehicles is an autonomous driving mode in which multiple vehicles communicate and coordinate to move in a convoy. In this mode, convoy vehicles typically include a lead vehicle and one or more follower vehicles. The lead vehicle can formulate operating strategies and transmit them to the follower vehicles through communication links to achieve unified control and coordination among the vehicles.

[0003] In autonomous vehicle platooning scenarios, the autonomous driving system of the following vehicle may malfunction due to abnormalities in modules such as perception, decision-making, execution, or communication, resulting in issues like downgrading of autonomous driving mode or limitation of critical functions. Current technologies for handling malfunctions of following vehicles generally suffer from high labor costs, low efficiency, and low safety and reliability.

[0004] However, no effective solutions have yet been proposed for the aforementioned technical problems. Summary of the Invention

[0005] The fault handling method, autonomous vehicle control system, and electronic equipment provided in this application are intended to solve one or more of the aforementioned technical problems.

[0006] In a first aspect, embodiments of this application provide a fault handling method applied to following vehicles in platooning autonomous driving, comprising: in response to receiving a fault recovery instruction, acquiring fault data; if the fault type corresponding to the fault data is a whitelist fault, performing a first fault clearing operation to obtain a first fault clearing result, wherein the whitelist fault is a fault that does not affect platooning performance when the autonomous driving mode is not downgraded; if the first fault clearing result shows that there is fault data that was not successfully cleared, performing a second fault clearing operation on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation.

[0007] Secondly, this application also provides a fault handling method applied to a lead vehicle in platooning autonomous driving, comprising: in response to obtaining a downgraded autonomous driving mode of a following vehicle, receiving a fault recovery command input by the driver of the lead vehicle on the vehicle-mounted human-machine interface; sending the fault recovery command to the following vehicle to trigger the following vehicle to execute any of the above-mentioned handling methods.

[0008] Thirdly, embodiments of this application also provide a control system for an autonomous vehicle, including at least a fault diagnosis module and a fault processing module; the fault diagnosis module is configured to acquire operating parameters through a data acquisition interface and identify fault data based on the operating parameters; the fault processing module is configured to acquire the fault data in response to receiving a fault recovery command; if the fault type corresponding to the fault data is a whitelist fault, a first fault clearing operation is performed to obtain a first fault clearing result, wherein the whitelist fault is a fault that does not affect platooning performance when the autonomous driving mode is not downgraded; if the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation.

[0009] Fourthly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method described in any of the above-mentioned embodiments.

[0010] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the preceding claims.

[0011] Sixthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the method described in any of the above-mentioned embodiments.

[0012] In this embodiment, in response to receiving a fault recovery command, fault data is acquired. If the fault type corresponding to the fault data is a whitelist fault, a first fault clearing operation is performed to obtain a first fault clearing result. The whitelist fault is one that does not affect platooning performance when the autonomous driving mode is not downgraded. If the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the uncleared fault data. The processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. In other words, this embodiment automatically performs fault clearing operations according to the whitelist faults after the following vehicle receives a fault recovery command. If there are uncleared faults, a higher-capacity fault clearing operation is further performed. This achieves fully unmanned operation of the following vehicle, reducing labor costs and improving fault recovery efficiency. Furthermore, the following vehicle performs fault recovery locally without relying on a wireless communication network, thus improving vehicle control reliability.

[0013] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0014] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0015] Figure 1 A schematic diagram of the structure of an autonomous driving system provided in an embodiment of this application is shown;

[0016] Figure 2 This illustration shows a schematic diagram of an application scenario for autonomous driving in formation, as provided in an embodiment of this application.

[0017] Figure 3 A flowchart of a fault handling method provided in an embodiment of this application is shown;

[0018] Figure 4 A structural block diagram of a fault handling device provided in an embodiment of this application is shown;

[0019] Figure 5 A flowchart of another fault handling method provided in an embodiment of this application is shown;

[0020] Figure 6 A flowchart of yet another fault handling method provided in an embodiment of this application is shown;

[0021] Figure 7 A flowchart of another fault handling method provided in an embodiment of this application is shown;

[0022] Figure 8 A structural block diagram of another fault handling device provided in an embodiment of this application is shown;

[0023] Figure 9 A structural block diagram of a control system for an autonomous vehicle provided in an embodiment of this application is shown;

[0024] Figure 10 A block diagram of an electronic device used to implement embodiments of this application is shown. Detailed Implementation

[0025] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0026] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0027] In platooned autonomous vehicles, the autonomous driving system typically includes, for example: Figure 1 The modules shown include: perception module 12, positioning module 14, communication module 16, decision-making and planning module 18, control execution module 20, safety monitoring module 22, fault diagnosis module 24, and formation management module 26. Specifically, perception module 12 collects information about the vehicle's surrounding environment, including roads, obstacles, distances between vehicles, and traffic signals; positioning module 14 determines the vehicle's absolute and relative position; communication module 16 performs vehicle-to-vehicle and vehicle-to-infrastructure communication, receives commands from the lead vehicle, and reports its own status; decision-making and planning module 18 generates driving trajectories and action plans based on perception and positioning data; control execution module 20 translates the planning results into specific operations such as steering, acceleration, and braking; safety monitoring module 22 monitors the operating parameters of each module in real time; fault diagnosis module 24 analyzes the cause of faults and determines the type of fault; and formation management module 26 maintains a safe distance and position for vehicles within the formation and coordinates the vehicles to re-enter the formation's autonomous driving mode after the fault is resolved.

[0028] However, in the event of a malfunction in a convoy, existing technologies commonly employ two main fault recovery methods: The first is manual fault recovery via a near-field grid safety operator. This method requires the safety operator to enter the malfunctioning vehicle and perform recovery operations through the vehicle's interactive or maintenance interface. While recovery can be completed in the field, it necessitates the additional deployment of safety operators, increasing operational costs. Furthermore, manual intervention suffers from slow response times and long recovery periods, particularly in scenarios like those common in Northwest China's convoy logistics operations, where fault recovery efficiency is low and can easily impact continuous convoy operation and overall safety. The second method is fault recovery via remote control. This method utilizes wireless communication networks to allow remote maintenance personnel to issue recovery commands to the malfunctioning vehicle, enabling fault handling without on-site personnel. However, this method relies on wireless communication links, and in areas with no network or weak wireless signals (such as tunnels, mountain roads, and remote areas), remote control functionality may fail, preventing the timely restoration of the vehicle's autonomous driving function and thus affecting the continuity and reliability of convoy operations.

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

[0030] The fault handling method provided in this application embodiment can be applied to scenarios where multiple autonomous vehicles (e.g., logistics trucks) adopt a platooning mode (also known as a formation driving mode). In this platooning mode, the vehicles travel in a preset platoon order, maintaining a safe distance and continuously communicating to achieve collaborative control and information sharing. Regarding platoon configuration, the vehicle at the front is the lead vehicle, which typically features Level 2 assisted driving capabilities, allowing for human driver control and reducing driver workload through limited automated driving functions, including lane keeping assist, cruise assist, and emergency braking assist. In this application scenario, the lead vehicle's driver is responsible for driving the vehicle and guiding the entire platoon forward. They also provide manual intervention capabilities in complex road environments or emergencies to ensure platoon safety and lead the platoon out of trouble in special situations. The other vehicles in the platoon besides the lead vehicle are follow vehicles, which typically feature Level 4 autonomous driving capabilities, enabling them to automatically perform following, path keeping, distance control, and obstacle avoidance operations based on communication information from the lead vehicle and the entire platoon without a driver. The following vehicles receive real-time operational status information, speed commands, route planning data, and emergency control commands from the lead vehicle via V2V (Vehicle-to-Vehicle) or V2X (Vehicle-to-Everything) links. Simultaneously, they feed back their own operational status, fault information, and environmental perception results to the lead vehicle, thereby optimizing the overall safety and efficiency of the convoy. In this convoy configuration, a fleet typically has only one driver residing in the lead vehicle, responsible for overall guidance and safety, while the remaining vehicles rely entirely on the autonomous driving system for control and operation. This configuration significantly reduces labor costs, improves long-distance transportation efficiency, and enables multi-vehicle collaborative operation while maintaining safety. For example, such as... Figure 2 The image shows the formation of autonomous vehicles.

[0031] In the above application scenarios, embodiments of this application provide a fault handling method, applied to following vehicles in platooning autonomous driving, such as... Figure 3 The diagram shown is a flowchart of a fault handling method according to an embodiment of this application. The method may include:

[0032] Step S302: In response to receiving the fault recovery command, acquire fault data.

[0033] It is understood that, in this embodiment, the aforementioned fault recovery command can be triggered by the lead vehicle driver via the vehicle-to-vehicle human-machine interface (HMI). This command is then sent to the following vehicle via the vehicle-to-vehicle communication link, thereby initiating the fault data acquisition and fault clearing process. In scenarios where the vehicle-to-vehicle communication link is unavailable or other situations, the lead vehicle driver can also safely park the lead vehicle, walk to the following vehicle, and directly trigger the fault recovery command on the following vehicle's HMI, thus initiating the fault data acquisition and fault clearing process. Both of these fault recovery command triggering methods can initiate the fault recovery process of the following vehicle, and after recovery is completed, the recovery result can be reported through communication feedback or on-site confirmation to ensure the continuity and safety of platooning operations.

[0034] Optionally, in this embodiment, the fault data includes at least a Diagnostic Trouble Code (DTC). The fault code typically indicates the module to which the fault belongs, the type of fault, and the time of occurrence. For example, a perception module fault code U0401 typically indicates a camera module communication failure, a control execution module fault code U0430 typically indicates an unresponsive electronic steering system, and a communication module fault code U0422 typically indicates a data packet loss rate exceeding a threshold.

[0035] Step S304: If the fault type corresponding to the fault data is a whitelist fault, perform the first fault clearing operation to obtain the first fault clearing result. The whitelist fault is a fault that does not affect the platooning performance when the autonomous driving mode is not downgraded.

[0036] It is understood that, in this embodiment, the whitelist can be either pre-configured in the autonomous driving system or dynamically sent to the following vehicles by the lead vehicle via vehicle-to-vehicle communication. When the whitelist is in pre-configured mode, the predefined whitelist is loaded when the vehicle leaves the factory or during system initialization. When the whitelist is sent by the lead vehicle via vehicle-to-vehicle communication, the whitelist content is generated or adjusted by the lead vehicle before or during the formation mission, based on the current mission requirements, operating environment, and safety policies, and then distributed to the following vehicles via vehicle-to-vehicle communication links, thereby ensuring that the fault judgment criteria are consistent with those of all vehicles in the formation.

[0037] Optionally, in this embodiment, the aforementioned whitelist faults include, but are not limited to: controllable abnormal behavior, transient faults, redundant module faults, non-critical module faults, and non-critical interaction and display module faults. Specifically, the controllable abnormal behavior includes at least one of the following vehicle behaviors being within a controllable range: vehicle skidding, vehicle sideslip, vehicle oversteering, vehicle understeering, and vehicle rolling backwards; the transient fault includes at least one of the following: trajectory curvature exceeding a preset threshold, algorithm outputting abnormal values, and non-critical sensor data acquisition failure; the redundant module fault includes at least one of the following: redundant camera module fault, redundant radar module fault, auxiliary lidar module fault, and redundant power supply monitoring module fault; the non-critical module fault includes at least one of the following: ambient temperature sensor fault, humidity sensor fault, vehicle auxiliary lighting module fault, and non-core data recording module fault; and the non-critical interaction and display module fault includes at least one of the following: abnormal instrument panel display, unresponsive vehicle touchscreen, and auxiliary information display module fault.

[0038] Step S306: If the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation.

[0039] It is understood that, in the embodiments of this application, by introducing a second fault clearing operation with higher processing capacity into the fault recovery process, namely a two-layer fault recovery mechanism, it can be ensured that the function of the fault module can still be fully restored when the lightweight clearing method fails, thereby ensuring the continuous operation and safety performance of autonomous vehicles in platooning mode.

[0040] Through the aforementioned steps S302-S306, in response to receiving a fault recovery command, fault data is acquired. If the fault type corresponding to the fault data is a whitelist fault, a first fault clearing operation is performed to obtain a first fault clearing result. Here, the whitelist fault is a fault that does not affect platooning performance when the autonomous driving mode is not downgraded. If the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the unsuccessfully cleared fault data. The processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. In other words, this embodiment of the application, after the following vehicle receives a fault recovery command, automatically performs fault clearing operations according to the whitelist faults. If there are unsuccessful clearing operations, a higher-capacity fault clearing operation is further performed, achieving fully unmanned operation of the following vehicle, reducing labor costs, and improving fault recovery efficiency. Furthermore, the following vehicle performs fault recovery locally without relying on a wireless communication network, thus improving the reliability of vehicle control.

[0041] In one possible implementation, when the fault type corresponding to the fault data is the controllable abnormal behavior or the transient fault, the above-mentioned execution of the first fault clearing operation may include: S11, deleting the fault code corresponding to the fault data.

[0042] It is understandable that step S11 above can remove the fault code from the fault code storage area, so that the system operating state is consistent with the actual vehicle state, and avoid triggering unnecessary mode downgrades or safety restrictions due to the presence of fault codes.

[0043] Specifically, the fault code number can be used to locate its position in the fault storage unit, and a clearing operation can be performed by calling a diagnostic communication protocol (such as the Clear Diagnostic Information service of Unified Diagnostic Services (UDS)) or an internal system interface to remove the corresponding record from the fault code storage area and update the system state machine to normal operating state.

[0044] Optionally, when the fault type corresponding to the fault data is the redundant module fault, the non-critical module fault, or the non-critical interaction and display module fault, the above-mentioned second fault clearing operation for the fault data that was not successfully cleared may include: S21, restarting the service process associated with the fault data that was not successfully cleared.

[0045] Specifically, based on the module identifier in the fault code, the corresponding software service process can be located. Then, the task scheduling interface or operating system process management function can be called through the process management module to stop and restart the service process. During the restart process, the internal process cache is cleared, occupied resources are released, and necessary runtime configurations are reloaded to eliminate the fault state caused by the process abnormality.

[0046] For example, suppose that in the event of a redundant radar module failure, after performing the first fault clearing operation (e.g., deleting the fault code), the safety monitoring module 22 reports that the radar module is still in a faulty state and the fault data has not been successfully cleared. At this point, a second fault clearing operation can be triggered to restart the radar data processing service process associated with the fault data. Specifically, the process management module can be called, and through the process management interface provided by the operating system, a stop signal (e.g., SIGTERM) can be sent to the service process. The process waits for the cache and communication resources it occupies to be released, and then the startup script of the radar data processing module is loaded to restart the process. After restarting, the radar data processing service process will re-establish the communication link with the radar sensor and initialize the necessary parameters. The safety monitoring module 22 then detects that the radar module has resumed normal operation, and the fault has been cleared.

[0047] In some cases, the above-mentioned soft reboot method cannot completely solve the fault. Optionally, the embodiments of this application also propose: S22, in response to the result of the reboot showing that there is fault data that was not successfully cleared, power is cut off to the target module associated with the fault data that was not successfully cleared and power is restored after a preset delay to restart the target module.

[0048] Understandably, when the soft reboot results in uncleared fault data, the power management module or hardware reset interface can be invoked to disconnect the power supply to the target module. After a preset delay (e.g., 500 milliseconds to 3 seconds to ensure complete release of hardware registers and caches) during the power-off state, power is restored to the target module to trigger the reinitialization of the hardware and its drivers. This hard reboot process can clear residual anomalies at the hardware and driver layers, thereby restoring the target module to its normal operating state.

[0049] For example, if a following vehicle in a platoon-driven autonomous driving system detects an anomaly in the in-vehicle touchscreen graphics rendering module within the non-critical interaction and display modules, and after deleting the fault code and performing a soft reboot, the safety monitoring module 22 finds that the touchscreen still cannot respond to user input, and the fault state remains unresolved. In this case, the power management module can be invoked to cut off the touchscreen's power supply. After maintaining the power-off state for one second, power is restored, the touchscreen hardware restarts and loads the display driver, the rendering module resumes normal operation, the fault state is cleared, and the system state machine is updated to normal operation.

[0050] Understandably, step S22 above, when a soft reboot fails, performs a hardware-level module power-off reboot or operating system reboot. This thoroughly clears the software runtime environment and resource lock-up state, and reinitializes the faulty module and its related processes. This hard reboot method can simultaneously clear residual anomalies in hardware registers and deep software faults triggered by the hardware layer (such as process freezes, driver response anomalies, system kernel freezes, etc.), thereby significantly improving the success rate of fault recovery. This strategy can cover deep fault scenarios, including hardware faults and hardware-induced software faults, increasing the recovery coverage of such faults to over 90%, reducing the risk of autonomous driving mode downgrades or vehicle platooning interruptions due to residual faults, and ensuring system stability and platooning continuity.

[0051] Extensive experimental data testing shows that, through the above steps S11 and S21~S22, the embodiments of this application can reduce the fault recovery time from the original minutes to a maximum of 30 seconds, as exemplified in Table 1 below:

[0052] Table 1

[0053]

[0054] In one possible implementation, before performing the first fault clearing operation, the method may further include: S31, performing a safety condition verification operation, wherein the safety condition includes the following vehicle being in at least one of the following states: stopped, the distance between the vehicle in front and the distance between the vehicle behind meets a preset safety threshold, or the vehicle behind is stationary.

[0055] Understandably, the aforementioned braking state can be achieved by the vehicle's autonomous driving system detecting that the current vehicle speed is zero and that the brake actuator remains locked, ensuring the vehicle comes to a complete stop. The aforementioned front and rear vehicle distances meeting preset safety thresholds can be achieved by acquiring data on the distances to the vehicles in front and behind via forward-facing radar, rear-facing radar, or vehicle-to-vehicle communication, and determining that both are greater than the system's preset safe distance (e.g., both front and rear vehicle distances ≥ 20 meters), and that any changes in distance are within a safe range. The aforementioned stationary rear vehicle can be determined in platooning scenarios by the communication module 16 or the perception module 12, which determines that the vehicle immediately following behind is stationary, preventing rear-end collisions during the clearing process.

[0056] For example, in platooning autonomous driving mode, if the following vehicle detects a sensor failure in a non-critical module, such as an interruption of the backup link of the communication module, corresponding to fault code U0420, it will trigger the execution of the first fault clearing operation. Before execution, the safety conditions are verified, such as the current vehicle speed being 0, the braking system being locked, the vehicle being in a completely stopped state, the forward radar measuring a distance of 25 meters from the vehicle in front, the rear radar measuring a distance of 22 meters from the vehicle behind, and the vehicle behind being in a stopped state and not dynamically approaching the vehicle. If all safety conditions are met, fault code U0420 is cleared.

[0057] By following step S31 above, after confirming that the safety conditions are met, the fault clearing action is then performed to ensure that the fault recovery process in formation mode does not affect driving safety and formation stability.

[0058] Optionally, in the embodiments of this application, the above method may further include: S41, recording an event log, wherein the event log includes at least the fault type and the fault clearing method corresponding to the fault type.

[0059] Understandably, the aforementioned event logs are typically stored in the vehicle system's log database or non-volatile storage media. Recording event logs through step S41 facilitates subsequent fault cause analysis, recovery strategy effectiveness evaluation, and system optimization by maintenance personnel or system analysis tools during the maintenance phase.

[0060] In order to ensure that the vehicle can maintain the adaptability of the fault handling strategy under different operating conditions and environments, avoid interruption of continuous platooning due to unnecessary mode downgrade, and improve the overall operating efficiency and safety of the system, the above processing method may optionally include: S51, updating the whitelist.

[0061] Optionally, in this embodiment, S51 may include: S511, obtaining the fault recovery success rate and security event statistics results corresponding to the candidate fault type; S512, adding the candidate fault type to the whitelist when the fault recovery success rate meets the preset conditions and it is determined that no security event has occurred based on the security event statistics results.

[0062] It is understood that the aforementioned fault recovery success rate is usually for a specific fault type, representing the proportion of successful recovery attempts after performing fault clearing operations within a preset statistical period, out of the total number of attempts. The aforementioned security event statistics are typically the number of security events related to that fault type that occurred within the same statistical period. In this embodiment, the condition for triggering a whitelist update can be that the aforementioned preset condition—a recovery success rate greater than or equal to a first threshold (e.g., 90%)—and that the number of security events occurring within the statistical period is zero.

[0063] For example, in platooning autonomous driving mode, runtime testing and data collection are performed on candidate fault types whose inclusion in the whitelist is not yet determined. When these fault types are detected by the fault judgment module 24 during operation, an appropriate fault clearing method is selected (a first fault clearing operation, such as deleting fault codes; or a second fault clearing operation, such as soft resetting related service processes), and recovery results and safety status information are continuously recorded during platooning. After the preset statistical period ends (e.g., 30 days), all recovery records for the candidate fault type are read from the event log, the number of successful recoverys and the number of safety events are counted, and the recovery success rate is calculated. For example, for the redundant camera communication anomaly fault type, a total of 10 faults occurred within this period, all of which were successfully recovered through soft reset (recovery success rate 100%), and the safety monitoring module 22 confirmed that the vehicle did not trigger any safety events during these 10 fault occurrences (safety event count 0). Based on the preset inclusion conditions (recovery success rate ≥ 90% and safety event count = 0), the system determines that the candidate fault type meets the whitelist inclusion requirements, and thus officially adds it to the whitelist.

[0064] Through the above steps S511~S512, the fault determination strategy can be dynamically optimized, enabling vehicles to avoid downgrading or limiting the function of fault triggering modes that do not affect safety and performance as much as possible in platooning automatic driving mode, thereby improving operational efficiency and the targeted nature of fault recovery, and maintaining the continuity and safety of platooning.

[0065] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a fault handling device, applied to following vehicles in platooning autonomous driving. For example... Figure 4 The diagram shown is a structural block diagram of a fault handling apparatus according to an embodiment of this application. The apparatus may include:

[0066] The acquisition module 42 is used to acquire fault data in response to receiving a fault recovery command;

[0067] The first clearing module 44 is used to perform a first fault clearing operation and obtain a first fault clearing result when the fault type corresponding to the fault data is a whitelist fault. The whitelist fault is a fault that does not affect the platooning performance when the autonomous driving mode is not downgraded.

[0068] The second clearing module 46 is used to perform a second fault clearing operation on the fault data that was not successfully cleared when the first fault clearing result shows that there is fault data that was not successfully cleared. The processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation.

[0069] pass Figure 4 The device shown, in response to receiving a fault recovery command, acquires fault data; if the fault type corresponding to the fault data is a whitelist fault, it performs a first fault clearing operation to obtain a first fault clearing result, wherein the whitelist fault is a fault that does not affect platooning performance when the autonomous driving mode does not degrade; if the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. In other words, this embodiment of the application, after the following vehicle receives a fault recovery command, automatically performs fault clearing operations according to the whitelist faults, and further performs a higher-capacity fault clearing operation when there are unsuccessful clearings, achieving the technical effect of fully unmanned operation of the following vehicle, reducing labor costs and improving fault recovery efficiency. Moreover, the following vehicle performs fault recovery locally without relying on a wireless communication network, achieving the technical effect of improving vehicle control reliability.

[0070] In one possible implementation, the aforementioned whitelist faults include at least: controllable abnormal behavior, transient faults, redundant module faults, non-critical module faults, and non-critical interaction and display module faults.

[0071] Optionally, the aforementioned controllable abnormal behaviors include at least one of the following vehicle behaviors being within a controllable range: vehicle skidding, vehicle sideslipping, vehicle oversteering, vehicle understeering, and vehicle rolling backwards; the instantaneous fault includes at least one of the following: trajectory curvature exceeding a preset threshold, algorithm outputting abnormal values, and failure to acquire data from non-critical sensors; the redundant module fault includes at least one of the following: redundant camera module fault, redundant radar module fault, auxiliary lidar module fault, and redundant power supply monitoring module fault; the non-critical module fault includes at least one of the following: ambient temperature sensor fault, humidity sensor fault, vehicle auxiliary lighting module fault, and non-core data recording module fault; the non-critical interaction and display module fault includes at least one of the following: abnormal instrument panel display, unresponsive vehicle touchscreen, and auxiliary information display module fault.

[0072] Optionally, the first clearing module 44 is further configured to delete the fault code corresponding to the fault data when the fault type corresponding to the fault data is the controllable abnormal behavior or the transient fault.

[0073] Optionally, the second clearing module 46 is further configured to restart the service process associated with the uncleared fault data when the fault type corresponding to the fault data is the redundant module fault, the non-critical module fault, or the non-critical interaction and display module fault.

[0074] Optionally, the second clearing module 46 is further configured to, if the restart result shows that there is fault data that was not successfully cleared, power off the target module associated with the fault data that was not successfully cleared and power it back on after a preset delay, so as to restart the target module.

[0075] Optionally, the above device further includes: a verification module, used to perform a safety condition verification operation before performing the first fault clearing operation, wherein the safety conditions include at least the following conditions: the following vehicle is in a stopped state, the distance between the front vehicle and the rear vehicle meets a preset safety threshold, and the following vehicle is stationary.

[0076] Optionally, the above device further includes: a recording module for recording an event log, wherein the event log includes at least the fault type and the fault clearing method corresponding to the fault type.

[0077] Optionally, the above device further includes an update module for updating the whitelist. Specifically, the update module is used to obtain the fault recovery success rate and security event statistics corresponding to the candidate fault type; if the fault recovery success rate meets a preset condition and it is determined based on the security event statistics that no security event has occurred, the candidate fault type is added to the whitelist.

[0078] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0079] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a fault handling method, applied to the lead vehicle in platooning autonomous driving. For example... Figure 5 The diagram shows a flowchart of a self-fault handling method according to an embodiment of this application. The method may include:

[0080] S502, in response to obtaining the downgraded state of the following vehicle's autonomous driving mode, receives the fault recovery command input by the driver of the lead vehicle on the in-vehicle human-machine interface;

[0081] S504, send the fault recovery command to the following vehicle to trigger the fault handling method of the following vehicle.

[0082] Through steps S502-S504 above, in response to obtaining the downgraded autonomous driving mode status of the following vehicle, the system receives the fault recovery command input by the driver of the lead vehicle through the in-vehicle human-machine interface; and sends the fault recovery command to the following vehicle to trigger the fault handling method of the following vehicle. That is to say, the lead vehicle has sole control over its operating authority; all fault recovery commands can only be triggered by the lead vehicle driver. A second confirmation before operation avoids misoperation, adapting to the lead vehicle driver's advantage of overall state control in platooning scenarios. Furthermore, after receiving the fault recovery command, the following vehicle automatically performs fault clearing operations according to the whitelist of faults. If some faults are not cleared successfully, a higher-capacity fault clearing operation is further performed, achieving fully unmanned operation of the following vehicle, reducing labor costs and improving fault recovery efficiency. Moreover, the following vehicle performs fault recovery locally without relying on the wireless communication network, achieving the technical effect of improving vehicle control reliability.

[0083] The embodiments of this application will be illustrated below with specific examples.

[0084] Example 1

[0085] This example provides a method for handling faults, such as... Figure 6 As shown, it includes:

[0086] S602, the lead vehicle receives downgraded parking status information from the following vehicles via V2V communication;

[0087] S604, the lead vehicle driver clicks the "Recover" button on the HMI interface, triggering a fault recovery command to be sent to the following vehicles;

[0088] S606, following the vehicle receiving the fault recovery command, performs safety condition verification (e.g., confirming the vehicle is stopped, the distance between vehicles in front and behind meets the safety threshold, and the following vehicle is stationary). After the conditions are met, the first fault clearing operation is performed: locate the fault code corresponding to the fault data, call the UDS protocol (0x14 Clear Diagnostic Information) to delete the fault code, and update the state machine to normal operation.

[0089] After the fault code was cleared, the S608's autonomous driving mode was restored to the original platoon level. It started again following the vehicles and rejoined the platoon, and sent a status message indicating that the recovery was complete to the lead vehicle.

[0090] Example 2

[0091] This example provides a method for handling faults, such as... Figure 7 As shown, it includes:

[0092] S702, the lead vehicle receives downgraded parking status information from the following vehicles via V2V communication;

[0093] S704, the lead vehicle driver clicks the "Recover" button on the HMI interface, triggering a fault recovery command to be sent to the following vehicles;

[0094] S706, after receiving the fault recovery command, the following vehicle performs safety condition verification (e.g., confirming parking, safe distance, and the following vehicle is stationary). Once the conditions are met, the first fault clearing operation is performed first. If the result of the first fault clearing operation shows that the redundant module fault was not successfully cleared, the second fault clearing operation is performed: when the fault type corresponding to the fault data is the redundant module fault, the non-critical module fault, or the non-critical interaction and display module fault, the service process associated with the uncleared fault data is restarted. In response to the restart result showing the existence of uncleared fault data, the target module associated with the uncleared fault data is powered off and then powered back on after a preset delay to restart the target module.

[0095] After the fault was recovered, the S708 updated its state machine, restored its autonomous driving mode to the original platoon level, restarted following the vehicles and rejoined the platoon, and sent a recovery status message to the lead vehicle.

[0096] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a fault handling device, applied to the lead vehicle in platooning autonomous driving. For example... Figure 8 The diagram shown is a structural block diagram of a fault handling apparatus according to an embodiment of this application. The apparatus may include:

[0097] The receiving module 82 is used to receive the fault recovery command input by the driver of the lead vehicle on the in-vehicle human-machine interface in response to the acquisition of the downgraded state of the following vehicle's autonomous driving mode.

[0098] Trigger module 84 is used to send the fault recovery command to the following vehicle to trigger the fault handling method of the following vehicle.

[0099] pass Figure 8 The device shown, in response to acquiring a downgraded autonomous driving mode status of the following vehicle, receives a fault recovery command input by the driver of the lead vehicle through the in-vehicle human-machine interface; it then sends the fault recovery command to the following vehicle to trigger the following vehicle's fault handling method. That is, the lead vehicle has sole control over its operating authority; all fault recovery commands can only be triggered by the lead vehicle driver. A second confirmation before operation avoids misoperation, adapting to the lead vehicle driver's advantage of overall state control in platooning scenarios. Furthermore, after receiving the fault recovery command, the following vehicle automatically performs fault clearing operations according to a whitelist of faults. If some faults are not cleared successfully, a higher-capacity fault clearing operation is performed, achieving fully unmanned operation of the following vehicle, reducing labor costs and improving fault recovery efficiency. Moreover, the following vehicle performs fault recovery locally without relying on a wireless communication network, thus improving vehicle control reliability.

[0100] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0101] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a control system for an autonomous vehicle, such as... Figure 9 The diagram shown is a block diagram of the control system structure of an autonomous vehicle according to an embodiment of this application. The system includes at least: a fault diagnosis module 92 and a fault processing module 94.

[0102] The aforementioned fault diagnosis module 92 is configured to acquire operating parameters through a data acquisition interface and identify fault data based on these operating parameters.

[0103] The aforementioned fault handling module 94 is configured to, in response to receiving a fault recovery command, acquire the fault data; if the fault type corresponding to the fault data is a whitelist fault, perform a first fault clearing operation to obtain a first fault clearing result, wherein the whitelist fault is a fault that does not affect the platooning performance when the autonomous driving mode is not downgraded; if the first fault clearing result shows that there is fault data that was not successfully cleared, perform a second fault clearing operation on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation.

[0104] pass Figure 9 The system shown automatically performs fault clearing operations according to the whitelist of faults after the following vehicle receives a fault recovery command. If the fault clearing is unsuccessful, it further performs fault clearing operations with higher processing capabilities, thus achieving fully unmanned operation of the following vehicle, reducing labor costs and improving fault recovery efficiency. Moreover, the following vehicle performs fault recovery locally without relying on the wireless communication network, thus improving the reliability of vehicle control.

[0105] Figure 10 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 10 As shown, the electronic device includes a memory 1001 and a processor 1002. The memory 1001 stores a computer program that can run on the processor 1002. When the processor 1002 executes the computer program, it implements the method described in the above embodiments. The number of memories 1001 and processors 1002 can be one or more.

[0106] The electronic device also includes:

[0107] Communication interface 1003 is used to communicate with external devices and perform data exchange and transmission.

[0108] If the memory 1001, processor 1002, and communication interface 1003 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0109] Optionally, in a specific implementation, if the memory 1001, processor 1002, and communication interface 1003 are integrated on a single chip, then the memory 1001, processor 1002, and communication interface 1003 can communicate with each other through an internal interface.

[0110] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0111] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0112] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0113] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0114] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0115] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0116] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0117] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0118] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0119] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0120] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0122] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all 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.

Claims

1. A method for handling faults, characterized in that, Following vehicles used in platooning autonomous driving include: In response to receiving a fault recovery command, acquire fault data; If the fault type corresponding to the fault data is a whitelist fault, a first fault clearing operation is performed to obtain a first fault clearing result. The whitelist fault is a fault that does not affect the platooning performance when the autonomous driving mode is not downgraded. If the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the fault data that was not successfully cleared, wherein the processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. The whitelist faults include at least: controllable abnormal behavior, transient faults, redundant module faults, non-critical module faults, and non-critical interaction and display module faults. When the fault type corresponding to the fault data is the controllable abnormal behavior or the transient fault, the first fault clearing operation includes: deleting the fault code corresponding to the fault data; When the fault type corresponding to the fault data is the redundant module fault, the non-critical module fault, or the non-critical interaction and display module fault, the second fault clearing operation for the fault data that was not successfully cleared includes: restarting the service process associated with the fault data that was not successfully cleared. The method further includes: in response to the result of the restart showing that there is fault data that was not successfully cleared, powering off the target module associated with the fault data that was not successfully cleared and then powering it back on after a preset delay to restart the target module.

2. The processing method according to claim 1, characterized in that, The controllable abnormal behavior includes at least one of the following vehicle behaviors being within a controllable range: vehicle skidding, vehicle sideslipping, vehicle oversteering, vehicle understeering, and vehicle rolling away. The instantaneous fault includes at least one of the following: the trajectory curvature exceeds a preset threshold, the algorithm outputs an abnormal value, or the non-critical sensor data acquisition fails. The redundant module failure includes at least one of the following: redundant camera module failure, redundant radar module failure, auxiliary lidar module failure, and redundant power supply monitoring module failure. The non-critical module failures include at least one of the following: ambient temperature sensor failure, humidity sensor failure, vehicle auxiliary lighting module failure, and non-core data recording module failure. The non-critical interaction and display module failures include at least one of the following: abnormal instrument panel display, unresponsive in-vehicle touch screen, or failure of auxiliary information display module.

3. The processing method according to claim 1, characterized in that, Before performing the first fault clearing operation, the procedure also includes: Perform a safety condition verification operation, wherein the safety conditions include at least the following conditions: the following vehicle is in a stopped state, the distance between the vehicle in front and the distance between the following vehicle meets a preset safety threshold, and the following vehicle is stationary.

4. The processing method according to claim 1, characterized in that, Also includes: Record an event log, wherein the event log includes at least the fault type and the fault clearing method corresponding to the fault type.

5. The processing method according to claim 1, characterized in that, Also includes: Update the whitelist.

6. The processing method according to claim 5, characterized in that, Updating the whitelist includes: Obtain the failure recovery success rate and security event statistics corresponding to the candidate failure types; If the failure recovery success rate meets the preset conditions and it is determined that no security event has occurred based on the security event statistics, the candidate failure type will be added to the whitelist.

7. A method for handling faults, characterized in that, Lead vehicles used in platooning autonomous driving include: In response to the acquisition of the downgraded state of the following vehicle autonomous driving mode, the system receives the fault recovery command input by the driver of the lead vehicle on the in-vehicle human-machine interface. Send the fault recovery command to the following vehicle to trigger the following vehicle to execute the processing method according to any one of claims 1 to 6.

8. A control system for an autonomous vehicle, characterized in that, It should include at least a fault diagnosis module and a fault handling module; The fault diagnosis module is configured to acquire operating parameters through a data acquisition interface and identify fault data based on the operating parameters. The fault handling module is configured to acquire the fault data in response to receiving a fault recovery command; If the fault type corresponding to the fault data is a whitelist fault, a first fault clearing operation is performed to obtain a first fault clearing result. The whitelist fault is a fault that does not affect the platooning performance when the autonomous driving mode is not downgraded. If the first fault clearing result shows that there is fault data that was not successfully cleared, a second fault clearing operation is performed on the fault data that was not successfully cleared. The processing capacity of the second fault clearing operation is higher than that of the first fault clearing operation. The whitelist faults include at least: controllable abnormal behavior, transient faults, redundant module faults, non-critical module faults, and non-critical interaction and display module faults. When the fault type corresponding to the fault data is the controllable abnormal behavior or the transient fault, the first fault clearing operation includes: deleting the fault code corresponding to the fault data; When the fault type corresponding to the fault data is the redundant module fault, the non-critical module fault, or the non-critical interaction and display module fault, the second fault clearing operation for the fault data that was not successfully cleared includes: restarting the service process associated with the fault data that was not successfully cleared. The fault handling module is further configured to: in response to the result of the restart showing that there is fault data that was not successfully cleared, to perform a power outage on the target module associated with the fault data that was not successfully cleared and then restore power after a preset delay, so as to restart the target module.

9. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

11. A computer program product, characterized in that, Includes computer instructions, wherein when executed by a processor, the computer instructions implement the method described in any one of claims 1-7.

Images