Configurable and extensible fault detection method and system for autonomous driving system

Abstract

The present invention relates to the technical field of vehicles. Disclosed are a configurable and extensible fault detection method and system for an autonomous driving system, an electronic device, a storage medium, and a vehicle. The method comprises: establishing a unified node heartbeat mechanism, and collecting heartbeat information of each module of an autonomous driving system in real time; in response to the collected heartbeat information, storing and managing the heartbeat information so as to perform data query by means of a fault detection strategy; setting and executing the fault detection strategy, periodically traversing the stored heartbeat information to complete fault detection, and assigning a specified fault level to a detected fault on the basis of a fault event; and configuring and managing the fault level, performing version management on the fault level, and guiding fault handling on the basis of configuration data of the fault level. The present invention can reduce the latency of fault detection, improve the real-time performance of fault detection, and realize configurable management of fault levels.

Description

A configurable and scalable fault detection method and system for autonomous driving systems Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a configurable and expandable method, system, electronic device, storage medium, and vehicle for fault detection in an autonomous driving system. Background Technology

[0002] Currently, with the rapid development and application of autonomous driving technology, it has greatly enhanced people's experience. At the same time, the reliability and safety of autonomous driving systems are receiving increasing attention. To ensure the reliability and safety of autonomous driving systems, safety considerations need to be taken into account in the design of the system and platform, and real-time fault detection and handling are also required. As is well known, an autonomous driving system is a complex system encompassing multiple functions such as perception, localization, planning, and control. In unmanned scenarios, how to accurately and in real-time detect system faults and promptly implement safety measures is a common challenge that the autonomous driving industry must address.

[0003] The current industry-standard fault detection solution involves collecting process status information from each module and combining it with internal status information from those modules to perform a simple fault assessment. Then, a simple maximum fault level is used to determine the status of each module. Based on this, the system's status is further assessed according to the importance of each module, ultimately deriving either a safe or unsafe state. If the system is safe, autonomous driving continues; if it's unsafe, takeover is initiated. While this fault detection solution can perform basic fault detection, alerts, and handling, it suffers from inconsistent fault detection rules, high update and iteration costs, and limited supported fault handling actions. It is also inefficient in handling complex operational testing environments under unmanned conditions.

[0004] Therefore, this application provides a configurable and scalable fault detection method for autonomous driving systems to solve the above-mentioned technical problems. Summary of the Invention

[0005] The purpose of this invention is to provide a configurable and scalable fault detection method, system, electronic device, storage medium, and vehicle for autonomous driving systems, in order to solve the technical problems in the prior art, such as inconsistent fault detection rules, high update and iteration costs, relatively simple fault handling actions, and inability to efficiently cope with the complex operation and testing environment in unmanned scenarios.

[0006] To address the aforementioned technical problems, this invention provides a configurable and scalable fault detection method for an autonomous driving system, comprising:

[0007] The steps for establishing a heartbeat mechanism include establishing a unified node heartbeat mechanism and collecting heartbeat information from each module of the autonomous driving system in real time. The heartbeat information includes the timestamp, component name, and fault code of the internal fault events of each module.

[0008] The heartbeat information management steps include, in response to the collected heartbeat information, storing and managing the heartbeat information so that the fault detection strategy can perform data queries;

[0009] The fault detection steps include setting and executing the fault detection strategy, periodically traversing the stored heartbeat information, completing fault detection, and assigning a specified fault level to the detected fault based on the fault event.

[0010] The fault level management steps include configuring and managing the fault level, performing version management on the fault level, and guiding fault handling based on the configuration data of the fault level.

[0011] In some specific embodiments, the heartbeat mechanism establishment step includes establishing a unified node heartbeat mechanism and collecting heartbeat information from each module of the autonomous driving system in real time. The heartbeat information includes timestamps of fault events within each module, component names, and fault codes. Further, it includes:

[0012] A unified heartbeat cycle is set, and each module is configured to send the heartbeat information according to the heartbeat cycle.

[0013] In the heartbeat information, when the fault event exists within the module, a complete heartbeat packet including information related to the fault event is sent.

[0014] If the fault event does not exist within the module, a hollow jump packet is sent.

[0015] The heartbeat information is transmitted via a publish-subscribe communication model.

[0016] In some specific embodiments, the heartbeat information management step includes, in response to the collected heartbeat information, storing and managing the heartbeat information to enable a fault detection strategy to perform data retrieval, and further includes:

[0017] Based on a caching mechanism, the heartbeat information within a recent period is stored, wherein the caching mechanism includes a lock-free circular queue;

[0018] Establish a real-time disk recording function for the heartbeat information to ensure the security and traceability of the heartbeat information;

[0019] Provides a data query interface for the fault detection strategy within the module on the module and time dimensions.

[0020] In some specific embodiments, the fault detection step includes setting and executing the fault detection strategy, periodically traversing the stored heartbeat information to complete fault detection, and assigning a specified fault level to the detected fault based on the fault event, further including:

[0021] Based on the characteristics and requirements of the autonomous driving system, the fault detection strategy is configured accordingly, wherein the fault detection strategy includes a heartbeat timeout strategy and a heartbeat information content verification strategy.

[0022] The state of the module is determined by periodically traversing all the fault detection strategies and the strategy logic of the fault detection strategies.

[0023] Based on the determined module state, the fault detection is completed, the detected fault is assessed according to preset rules, and the assessment result is stored in the fault event cache of EventBus.

[0024] In some specific embodiments, the fault level management step, including configuring and managing the fault level, performing version management on the fault level, and guiding fault handling based on the configuration data of the fault level, further includes:

[0025] Version management is implemented for the fault levels, including displaying all current fault levels and newly added fault level versions;

[0026] Calculate the MD5 value of the fault level configuration file, and maintain the relationship between the version and the MD5 value through cloud service;

[0027] The configuration file uses a triplet approach to represent faults and rates faults from three dimensions: system impact, operational impact, and parking urgency.

[0028] In some specific embodiments, the method further includes:

[0029] When fault detection is initiated, fault level configuration data is read into the node cache and managed in the form of a hash table to facilitate fault level lookup and assignment, thereby guiding the fault handling of the autonomous driving system.

[0030] Based on the same concept, the present invention also provides a configurable and scalable fault detection system for an autonomous driving system, comprising:

[0031] The heartbeat mechanism establishment module is configured to establish a unified node heartbeat mechanism to collect heartbeat information of each module of the autonomous driving system in real time. The heartbeat information includes the timestamp, component name and fault code of the internal fault event of each module.

[0032] The heartbeat information management module is configured to store and manage the collected heartbeat information in response to the data, so that the fault detection strategy can perform data queries.

[0033] The fault detection module is configured to set and execute the fault detection strategy, periodically traverse the stored heartbeat information, complete fault detection, and assign a specified fault level to the detected fault based on the fault event.

[0034] The fault level management module is configured to configure and manage the fault levels, perform version management on the fault levels, and guide fault handling based on the configuration data of the fault levels.

[0035] Based on the same concept, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a configurable and scalable automatic driving system fault detection method.

[0036] Based on the same concept, the present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a configurable and scalable autonomous driving system fault detection method.

[0037] Based on the same concept, the present invention also provides a vehicle equipped with a configurable and expandable automatic driving system fault detection system as described above.

[0038] Compared with existing technologies, its advantages are as follows:

[0039] This invention discloses a configurable and scalable fault detection method, system, electronic device, storage medium, and vehicle for an autonomous driving system. It can reduce the latency of fault detection and improve the real-time performance of fault detection; enable configurable management of fault levels and improve the efficiency of fault detection function updates and iterations; improve the precision and accuracy of fault detection and facilitate further guidance for the implementation of fault handling actions. Attached Figure Description

[0040] Figure 1 is a flowchart illustrating some specific embodiments of the configurable and scalable fault detection method for an autonomous driving system according to the present invention.

[0041] Figure 2 is a schematic diagram of the architecture of the configurable and scalable fault detection method for autonomous driving systems of the present invention in some applications.

[0042] Figure 3 is a schematic diagram of the vehicle-cloud interaction process in some applications of the configurable and scalable fault detection method for autonomous driving systems according to the present invention.

[0043] Figure 4 is a logic block diagram of a configurable and scalable fault detection method for an autonomous driving system according to the present invention in some applications.

[0044] Figure 5 is a schematic diagram of the structure of a configurable and scalable fault detection system for an autonomous driving system according to some specific embodiments of the present invention;

[0045] Figure 6 is a schematic diagram of the structure of an electronic device according to some specific embodiments of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0048] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0049] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0050] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0051] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0052] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0053] Referring to Figure 1, a configurable and scalable fault detection method for an autonomous driving system includes:

[0054] S101, Heartbeat mechanism establishment steps, including establishing a unified node heartbeat mechanism and collecting heartbeat information of each module of the autonomous driving system in real time, wherein the heartbeat information includes the timestamp, component name and fault code of the internal fault event of each module;

[0055] Understandably, heartbeat information includes the following three core fields:

[0056] Timestamp: Records the exact time when a fault event occurred within the module, in the format of year, month, day, hour, minute, second, and millisecond, ensuring time accuracy to the millisecond level.

[0057] Component Name: Identifies the specific component or module name where the fault occurred, in string format, such as "radar sensor" or "navigation computing unit", to facilitate quick location of the problem source.

[0058] Fault Code: According to the preset fault coding system, a unique identifier is assigned to each possible fault, which is represented by hexadecimal or decimal numbers, such as "0x0001" which means "sensor data abnormal".

[0059] Within each key module of the autonomous driving system, a heartbeat information acquisition module is embedded. This module is responsible for monitoring the module's operating status in real time. Once an internal fault event is detected (such as abnormal sensor data, overload of the computing unit, etc.), it immediately generates heartbeat information according to the above specifications.

[0060] For example, in the "radar sensor" module, if a data transmission interruption is detected, the heartbeat information acquisition module captures the current timestamp (e.g., "2023-04-01 14:30:05.234"), determines the component name as "radar sensor", and queries the corresponding fault code "0x0002" (assuming it is "data transmission failure"). Then, it encapsulates this information into a heartbeat information packet.

[0061] An internal communication protocol (such as CAN bus, Ethernet, etc.) is used to transmit the heartbeat information of each module to the central monitoring unit in real time. The central monitoring unit is designed with a heartbeat information receiving module, which is responsible for receiving and parsing the heartbeat information from each module.

[0062] In some applications, the heartbeat mechanism establishment steps include establishing a unified node heartbeat mechanism, collecting heartbeat information from each module of the autonomous driving system in real time, and the heartbeat information including the timestamp of the fault event within each module, the component name, and the fault code. A unified heartbeat period is set, and each module is configured to send heartbeat information according to the heartbeat period. In the heartbeat information, if there is a fault event within the module, a complete heartbeat packet including the fault event information is sent; if there is no fault event within the module, an empty heartbeat packet is sent. The heartbeat information is transmitted through a publish-subscribe communication mode.

[0063] Understandably, a uniform heartbeat cycle should be set based on the operating characteristics and monitoring requirements of the autonomous driving system. For example, the heartbeat cycle could be set to 5 seconds.

[0064] Each system module is configured with heartbeat sending logic to send heartbeat information according to a set heartbeat cycle. The content of the heartbeat information varies depending on whether a fault event occurs within the module.

[0065] When a fault event occurs within the module:

[0066] Heartbeat packet content includes heartbeat header information (such as timestamp, module ID, etc.) and fault event-related information (such as fault timestamp, component name, fault code, fault description, etc.).

[0067] Sending logic: When a fault event is detected inside the module, a complete heartbeat packet is generated based on the fault information and sent when the next heartbeat cycle arrives.

[0068] For example, suppose the "camera module" detects an "image transmission interruption" fault at a certain moment, and the generated heartbeat packet contains the following information:

[0069] Timestamp: 2023-05-10 12:00:00.000;

[0070] Module ID: Camera_01;

[0071] Fault timestamp: 2023-05-10 12:00:00.000;

[0072] Component Name: Image Transmission Unit;

[0073] Fault code: 0x0010;

[0074] Fault description: Image Transmission Interrupted;

[0075] When there are no fault events within the module:

[0076] Heartbeat packet content: It only contains heartbeat header information, which is an empty heartbeat packet or a heartbeat confirmation packet.

[0077] Sending logic: In each heartbeat cycle, if no fault event is detected inside the module, a heartbeat packet containing only basic header information is sent as an existence confirmation.

[0078] Heartbeat information is transmitted using a publish-subscribe communication model. The central monitoring unit acts as a subscriber, subscribing to heartbeat information from each module; while each module acts as a publisher, publishing heartbeat information to the central monitoring unit according to the heartbeat cycle. Each module publishes heartbeat information to the system's message queue or topic according to the set heartbeat cycle. The central monitoring unit continuously listens to these message queues or topics. When it receives heartbeat information, it parses and processes it, including confirming that the module is currently in normal operation and updating the module's online status information for empty heartbeat packets. For complete heartbeat packets, it parses the fault event information in the complete heartbeat packet, performs fault analysis based on the fault code and fault description, and triggers corresponding alarms or handling mechanisms.

[0079] S102, heartbeat information management step, including in response to the collected heartbeat information, storing and managing the heartbeat information so that the fault detection strategy can perform data query;

[0080] In some applications, the heartbeat information management steps include: responding to the collected heartbeat information, storing and managing the heartbeat information so that the fault detection strategy can query the data; storing the heartbeat information within a recent period based on a caching mechanism, which includes a lock-free circular queue; establishing a real-time disk write function for heartbeat information to ensure the security and traceability of the heartbeat information; and providing data query interfaces for the internal fault detection strategy of the module at both the module and time dimensions.

[0081] Understandably, a lock-free circular queue is used as the primary data structure for caching in order to quickly respond to the collection and processing of heartbeat information. This queue can safely store heartbeat information within a recent period in a multi-threaded environment, avoiding the overhead of data contention and lock waiting.

[0082] Parameter settings: Set the capacity of the lockless circular queue to N heartbeat packets, for example, N=1000. The queue can cache the most recent 1000 heartbeat packets (assuming a heartbeat cycle of 5 seconds, then it is about 5000 seconds, or about 83 minutes of historical data).

[0083] Heartbeat information enqueueing and dequeueing: Whenever new heartbeat information is collected, it is encapsulated into a heartbeat packet and an attempt is made to add it to the circular queue without locking. If the queue is full, the oldest heartbeat packet is automatically overwritten according to the first-in-first-out principle.

[0084] To ensure the security and long-term traceability of heartbeat information, a real-time disk write function is designed. This function periodically or asynchronously writes the cached heartbeat information to persistent storage media (such as hard disks or SSDs).

[0085] Disk write frequency: Set to perform a disk write operation once every M heartbeat cycles. For example, M=100 means that a disk write is performed once every 500 seconds (100 5-second cycles), which balances data security and system write overhead.

[0086] To support the flexibility and efficiency of fault detection strategies, a data query interface is provided, allowing for refined queries based on module and time dimensions.

[0087] Module-level query: Allows users to specify a module ID or module name to query the heartbeat information of that module within a specified time period. For example, query all heartbeat information for the "Radar Module" in the past hour.

[0088] Time-based query: Supports querying by time range. Users can specify a start time and an end time to retrieve heartbeat information for all modules or a specific module within that time period. For example, query all heartbeat information from "2023-05-10 10:00:00" to "2023-05-10 12:00:00".

[0089] Interface Implementation: Design a RESTful API or internal service interface to provide the above query functionality. The interface receives query parameters (such as module ID, time range, etc.) and returns a list of heartbeat information that meets the conditions. The list contains detailed information about the heartbeat packets, such as timestamps, module IDs, and fault events.

[0090] For example, if the "LiDAR module" experiences a "data transmission interruption" fault at 11:30:00 on May 10, 2023, this fault is captured as a heartbeat message. This heartbeat message is first added to a lock-free circular queue. If the queue is not full, it is stored directly; if it is full, the oldest heartbeat packet is overwritten. Subsequently, in the next disk write cycle (assuming the disk write time has not yet arrived), this heartbeat message will be written to persistent storage along with other heartbeat messages that meet the disk write conditions. When the fault detection strategy needs to analyze this fault, it can use the data query interface, specifying the module ID as "LiDAR module" and the time range as a period before and after "11:30:00 on May 10, 2023," to obtain a list of heartbeat messages containing this fault event. The fault detection strategy can then perform further analysis and processing based on this information.

[0091] S103, execute the fault detection step, including setting and executing the fault detection strategy, periodically traversing the stored heartbeat information, completing fault detection, and assigning a specified fault level to the detected fault based on the fault event.

[0092] In some applications, the fault detection steps include setting and executing fault detection strategies, periodically traversing the stored heartbeat information, completing fault detection, and assigning a specified fault level to the detected fault based on the fault event. Based on the characteristics and requirements of the autonomous driving system, the fault detection strategies are configured accordingly, including heartbeat timeout strategies and heartbeat information content verification strategies. All fault detection strategies are periodically traversed, and the module status is judged according to the strategy logic of the fault detection strategies. Based on the judged module status, fault detection is completed, the fault level of the detected fault is evaluated according to preset rules, and the evaluation results are stored in the fault event cache of EventBus.

[0093] Understandably, based on the characteristics and requirements of autonomous driving systems, two main types of fault detection strategies are set: heartbeat timeout strategy and heartbeat information content verification strategy.

[0094] Heartbeat timeout policy: Set a reasonable heartbeat timeout threshold, such as 3 heartbeat cycles (assuming each cycle is 5 seconds, then the timeout threshold is 15 seconds). If a module fails to send heartbeat information within 3 consecutive heartbeat cycles, it is considered that the module has experienced a heartbeat timeout failure.

[0095] Heartbeat message content verification strategy: Define verification rules for heartbeat message content, such as checking whether the timestamps in the heartbeat packet are continuous and whether the fault codes are valid. If the heartbeat message content does not meet expectations, it is considered a content verification failure, indicating that there is an anomaly within the module.

[0096] Perform fault detection:

[0097] Periodic traversal of heartbeat information: Set a detection period (e.g., once per minute), and within this period, traverse the stored heartbeat information. During the traversal, apply the configured fault detection strategies sequentially.

[0098] The strategy logic determines the module status: For each module, based on its heartbeat information, a heartbeat timeout strategy and a heartbeat information content verification strategy are applied respectively. If either strategy determines that the module status is abnormal (such as timeout or content verification failure), the module is marked as faulty.

[0099] Fault detection and severity assessment:

[0100] Fault detection complete: After the traversal is complete, summarize the information of all modules marked as faulty.

[0101] Fault Level Assessment: Detected faults are assessed according to preset rules. For example, three fault levels can be set: Level 1 (critical fault, such as failure of a critical sensor), Level 2 (moderate fault, such as abnormality of a non-critical component), and Level 3 (minor fault, such as temporary communication interruption). The assessment rules can be based on a comprehensive consideration of factors such as fault type, scope of impact, and recovery time.

[0102] For example, if the "radar sensor" module experiences a heartbeat timeout and fails to recover for several consecutive cycles, it is classified as a Level 1 fault; if the "audio playback system" module experiences a content verification failure but does not affect the safe operation of the vehicle, it is classified as a Level 3 fault.

[0103] Storage failure events:

[0104] EventBus fault event cache: Evaluated fault events and their related information (such as fault level, occurrence time, module ID, etc.) are encapsulated into event objects and published to the EventBus fault event cache. As an efficient event publish / subscribe mechanism, EventBus ensures that fault events are delivered to the relevant processing systems or components in a timely and accurate manner.

[0105] S104, Fault Level Management Steps, including configuring and managing the fault levels, performing version management on the fault levels, and guiding fault handling based on the configuration data of the fault levels.

[0106] In some applications, fault level management steps include configuring and managing fault levels, version management of fault levels, and guiding fault handling based on fault level configuration data. Fault level version management includes displaying all current fault level versions and newly added fault level versions; calculating the MD5 value of the fault level configuration file and maintaining the relationship between version and MD5 value through cloud services; the configuration file uses triples to represent faults and rates faults from three dimensions: system impact, operational impact, and parking urgency.

[0107] Understandably, fault levels are configured and managed based on the actual situation of the autonomous driving system and business needs. Fault levels are used to guide fault handling.

[0108] Fault Level Definition: Define different levels of faults, such as Level 1 (serious fault), Level 2 (moderate fault), and Level 3 (minor fault), etc. Each level corresponds to different system impact, operational impact, and shutdown urgency.

[0109] Configuration file format: Faults are represented using a triplet approach. Each fault entry contains three key pieces of information: System Impact, Operational Impact, and Parking Urgency. These three dimensions together determine the fault level.

[0110] For example, fault item 1: {System Impact: "High", Operational Impact: "Medium", Parking Urgency: "High"} is rated as a Level 1 fault.

[0111] Fault item 2: {System Impact: "Medium", Operational Impact: "Low", Parking Urgency: "Low"}, is rated as a level three fault.

[0112] To support flexible adjustments and optimizations at the fault level, a version management strategy is implemented.

[0113] Version Display: Provides a user interface or API to display the fault level configurations for all current versions. Users can view detailed information for each version, including version number, creation time, and modifications.

[0114] Add a new version: Allows users or system administrators to add fault level versions. When adding a new version, a new configuration file must be uploaded, and a version description must be filled in.

[0115] To ensure the consistency and security of configuration files, MD5 values ​​are used for version control.

[0116] MD5 Value Calculation: Whenever a new fault level configuration file is uploaded, its MD5 value is automatically calculated. An MD5 value is a unique hash value used to verify the integrity of the file content.

[0117] Cloud service maintenance: The configuration file for each version and its corresponding MD5 value are stored in the cloud service. The cloud service provides a mapping between versions and MD5 values ​​to verify the correctness of the configuration file when needed.

[0118] Fault level configuration data is used not only to assess and classify faults, but also to guide subsequent fault handling.

[0119] Fault assessment: When a fault is detected, the level of the fault is assessed based on the specific information of the fault (such as error code, fault symptoms, etc.) and the fault level configuration data.

[0120] Handling Recommendations: Based on the assessment results, provide corresponding troubleshooting recommendations. For example, for a Level 1 fault, it is recommended to immediately shut down the system and contact technical support; for a Level 3 fault, simply log the fault and continue operation.

[0121] In some of these applications, fault level configuration data is read into the node cache when fault detection is initiated and managed in the form of a hash table to facilitate fault level lookup and assignment, thereby guiding the fault handling of the autonomous driving system.

[0122] Understandably, to improve data access efficiency, the loaded fault level configuration data is stored in the system node cache. This fault level configuration data is organized in the node cache using a hash table. The hash table stores data in key-value pairs, where the key can be a unique identifier for the fault (such as a fault code, module ID, etc.), and the value is the corresponding fault level configuration information (including system impact, operational impact, parking urgency, etc.). During fault detection, when a fault is detected, the corresponding fault level configuration is quickly looked up in the hash table using the fault's unique identifier (such as a fault code). After finding the corresponding fault level configuration, the fault is rated according to the configuration information, and the rating result is assigned to the fault object or related processing logic. Based on the fault level assignment result, the autonomous driving system can more accurately determine the severity of the fault and formulate a fault handling strategy accordingly.

[0123] The following, with reference to Figures 2 to 4, illustrates embodiments of the configurable and scalable automatic driving system fault detection method of the present invention in some applications:

[0124] In this embodiment, a unified node heartbeat mechanism is established to perform real-time and accurate fault detection for each module. By establishing a configurable fault level judgment mechanism, the flexibility of fault level setting can be increased. A set of fault superposition calculation rules is proposed to superimpose and calculate multiple faults and derive the fault level of the entire system to further guide fault handling.

[0125] As shown in Figure 2, a heartbeat mechanism is established for each module of the autonomous driving system to collect real-time status information of each module. Based on a publish-subscribe communication model, each module is required to send heartbeat information to the fault detection module at a unified heartbeat period (e.g., 50ms). This heartbeat information can carry information such as the timestamp of the fault event within the module, the component name, and the fault code. If a fault event exists within the module, the relevant information is published via the heartbeat. If no fault event occurs within the module, only an empty information packet is sent.

[0126] The fault detection module collects heartbeat information from each module, organizes it according to timestamps, and stores it in a cache (for example, a lock-free circular queue can be used to store node heartbeat information within the last 20 minutes). This allows the module's internal fault detection strategy to query data at both the module and time dimensions and supports real-time data persistence to disk.

[0127] The fault detection module designs and adds fault detection strategies based on actual conditions (e.g., a module heartbeat timeout strategy, which calculates whether the number of heartbeat packets from the module in the recent period meets the timeout threshold in the heartbeat cache; if it is less than the timeout threshold, the heartbeat is judged as timeout and the module is abnormal; otherwise, the heartbeat is normal). The fault detection module periodically iterates through all fault detection strategies to complete fault detection.

[0128] As shown in Figure 3, by completing the fault level assessment of all faults in advance, the detected fault events are assigned a specified fault level and stored in the fault event cache of EventBus.

[0129] To better guide downstream modules in handling faults and establish a correspondence between specified fault levels and handling methods, fault levels are assessed according to three dimensions: system impact, operational impact, and parking urgency. System impact refers to the assessment of the impact on the main system's vehicle control module, the backup system's vehicle control module, and auxiliary modules. Operational impact refers to the assessment of the impact on the completion of this order. Parking urgency refers to whether parking is currently necessary and the required parking level.

[0130] After functional safety personnel complete the fault level assessment, they manage the fault levels by accessing a fault management tool via a browser. The primary function of this configuration tool is version management of fault levels. It displays all current fault level versions in a web-based interface and allows adding new fault level versions. Once the fault level configuration is complete, the tool generates a fault level configuration file and calculates the MD5 value of that version's fault configuration file using an MD5 tool. A cloud service maintains the relationship between versions and MD5 values. Functional safety personnel then confirm the configuration.

[0131] As shown in Figure 4, each fault is represented using a triple: {node name, component name, fault code}. Each fault is rated based on three dimensions: system impact, safety and operational impact, and urgency of stopping, ultimately resulting in a fault level. Each fault on the vehicle is evaluated across these three dimensions, and the fault level is configured in a fault level configuration file. When a node starts, the fault detection module reads the fault level configuration data into the node cache and manages it using a hash table. This facilitates efficient fault level lookup and assignment on the vehicle.

[0132] The following describes this embodiment in conjunction with an application scenario:

[0133] 1. Functional safety personnel assess whether the fault level of a certain fault needs to be adjusted (or add or delete a fault). They access the fault management service through a browser, make the corresponding fault configuration, and obtain the version number and MD5 value of the fault set.

[0134] 2. At this point, the fault management service generates a fault level configuration file and stores it on the disk with the MD5 value as the filename. At the same time, it adds version information of the fault configuration file to the database, including the filename, path, and version number, for subsequent querying.

[0135] 3. Functional safety personnel configure the MD5 value of the above fault set version into the code of the fault management module. After the code is compiled, the fault detection module is flashed on the autonomous driving platform.

[0136] 4. After the fault detection module is started, it reads the fault level configuration file on the vehicle and calculates the MD5 value of the configuration file. If it finds that the MD5 value is inconsistent with the MD5 value in the code, it requests the fault level configuration file corresponding to the MD5 value configured in the code from the fault management service via the HTTP protocol.

[0137] 5. The fault management service finds the configuration file of the specified version by querying the MD5 value and sends it to the vehicle-side fault detection module via HTTP.

[0138] 6. The vehicle-side detection module stores and reads the configuration file, and puts the fault level information into a hash table, storing it with the fault name as the key and the fault level as the value;

[0139] 7. If a module on the vehicle crashes, the heartbeat timeout policy of the fault detection module detects the heartbeat timeout and queries the fault level lookup hash table for the fault level.

[0140] 8. Calculate the system's fault level by superimposing the fault levels, and return the result.

[0141] This embodiment uses a unified fault level overlay scheme to perform real-time fault detection on various modules of the vehicle. It combines a cloud-based fault level version management tool to complete the fault level configuration, and then achieves efficient fault level management through vehicle-cloud interaction and version verification, ultimately realizing an efficient fault detection solution.

[0142] For the purpose of simplicity, the method steps disclosed in the above embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0143] As shown in Figure 5, the present invention also provides a configurable and scalable fault detection system for an autonomous driving system, comprising:

[0144] The heartbeat mechanism establishment module 201 is configured to establish a unified node heartbeat mechanism to collect heartbeat information of each module of the autonomous driving system in real time. The heartbeat information includes the timestamp, component name and fault code of the internal fault event of each module.

[0145] The heartbeat information management module 202 is configured to store and manage the heartbeat information in response to the collected heartbeat information, so that the fault detection strategy can perform data query;

[0146] The fault detection module 203 is configured to set and execute the fault detection strategy, periodically traverse the stored heartbeat information, complete fault detection, and assign a specified fault level to the detected fault based on the fault event.

[0147] The fault level management module 204 is configured to configure and manage the fault levels, perform version management on the fault levels, and guide fault handling based on the configuration data of the fault levels.

[0148] It is worth noting that although only some basic functional modules are disclosed in the embodiments of this invention, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be considered as the scope of protection of the claims of this invention being limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0149] As shown in Figure 6, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a configurable and scalable automatic driving system fault detection method.

[0150] Figure 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. As shown in Figure 6, the electronic device provided in this embodiment of the present invention includes: one or more processors 710 and a storage device 720; the processors 710 in the electronic device may be one or more, and Figure 6 takes one processor 710 as an example; the storage device 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement the configurable and scalable autonomous driving system fault detection method as described in any one embodiment of the present invention.

[0151] The electronic device may also include an input device 730 and an output device 740.

[0152] The processor 710, storage device 720, input device 730 and output device 740 in this electronic device can be connected by a bus or other means. Figure 6 shows an example of connection via a bus.

[0153] The storage device 720 in this electronic device serves as a computer-readable storage medium, capable of storing one or more programs. These programs can be software programs, computer-executable programs, or modules, such as the program instructions / modules corresponding to the configurable and extensible autonomous driving system fault detection method provided in this embodiment of the invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the storage device 720, thereby implementing the configurable and extensible autonomous driving system fault detection method described in the above method embodiment.

[0154] Storage device 720 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, storage device 720 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, storage device 720 may further include memory remotely located relative to processor 710, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0155] Input device 730 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 740 may include display devices such as a display screen.

[0156] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a configurable and scalable autonomous driving system fault detection method.

[0157] Specifically, the computer storage medium in this embodiment of the invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be—but is not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0158] The present invention also provides a vehicle equipped with a configurable and expandable automatic driving system fault detection system as described above.

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A configurable and scalable fault detection method for an autonomous driving system, characterized in that, include: The steps for establishing a heartbeat mechanism include establishing a unified node heartbeat mechanism and collecting heartbeat information from each module of the autonomous driving system in real time. The heartbeat information includes the timestamp, component name, and fault code of the internal fault events of each module. The heartbeat information management steps include, in response to the collected heartbeat information, storing and managing the heartbeat information so that the fault detection strategy can perform data queries; The fault detection steps include setting and executing the fault detection strategy, periodically traversing the stored heartbeat information, completing fault detection, and assigning a specified fault level to the detected fault based on the fault event. The fault level management steps include configuring and managing the fault level, performing version management on the fault level, and guiding fault handling based on the configuration data of the fault level.

2. The configurable and scalable fault detection method for an autonomous driving system according to claim 1, characterized in that, The heartbeat mechanism establishment steps include establishing a unified node heartbeat mechanism and collecting heartbeat information from each module of the autonomous driving system in real time. The heartbeat information includes the timestamp of fault events within each module, component name, and fault code. Further, it includes: A unified heartbeat cycle is set, and each module is configured to send the heartbeat information according to the heartbeat cycle. In the heartbeat information, when the fault event exists within the module, a complete heartbeat packet including information related to the fault event is sent. If the fault event does not exist within the module, a hollow jump packet is sent. The heartbeat information is transmitted via a publish-subscribe communication model.

3. The configurable and scalable fault detection method for an autonomous driving system according to claim 1, characterized in that, The heartbeat information management step includes, in response to the collected heartbeat information, storing and managing the heartbeat information to enable a fault detection strategy to perform data retrieval, and further includes: Based on a caching mechanism, the heartbeat information within a recent period is stored, wherein the caching mechanism includes a lock-free circular queue; Establish a real-time disk recording function for the heartbeat information to ensure the security and traceability of the heartbeat information; Provides a data query interface for the fault detection strategy within the module on the module and time dimensions.

4. The configurable and scalable fault detection method for an autonomous driving system according to claim 1, characterized in that, The fault detection step includes setting and executing the fault detection strategy, periodically traversing the stored heartbeat information to complete fault detection, and assigning a specified fault level to the detected fault based on the fault event, further including: Based on the characteristics and requirements of the autonomous driving system, the fault detection strategy is configured accordingly, wherein the fault detection strategy includes a heartbeat timeout strategy and a heartbeat information content verification strategy. The state of the module is determined by periodically traversing all the fault detection strategies and the strategy logic of the fault detection strategies. Based on the determined module state, the fault detection is completed, the detected fault is assessed according to preset rules, and the assessment result is stored in the fault event cache of EventBus.

5. The configurable and scalable fault detection method for an autonomous driving system according to claim 1, characterized in that, The fault level management steps include configuring and managing the fault levels, performing version management on the fault levels, and guiding fault handling based on the configuration data of the fault levels, further including: Version management is implemented for the fault levels, including displaying all current fault levels and newly added fault level versions; Calculate the MD5 value of the fault level configuration file, and maintain the relationship between the version and the MD5 value through cloud service; The configuration file uses a triplet approach to represent faults and rates faults from three dimensions: system impact, operational impact, and parking urgency.

6. The configurable and scalable fault detection method for an autonomous driving system according to claim 5, characterized in that, The method further includes: When fault detection is initiated, fault level configuration data is read into the node cache and managed in the form of a hash table to facilitate fault level lookup and assignment, thereby guiding the fault handling of the autonomous driving system.

7. A configurable and scalable fault detection system for an autonomous driving system, characterized in that, include: The heartbeat mechanism establishment module is configured to establish a unified node heartbeat mechanism to collect heartbeat information of each module of the autonomous driving system in real time. The heartbeat information includes the timestamp, component name and fault code of the internal fault event of each module. The heartbeat information management module is configured to store and manage the collected heartbeat information in response to the data, so that the fault detection strategy can perform data queries. The fault detection module is configured to set and execute the fault detection strategy, periodically traverse the stored heartbeat information, complete fault detection, and assign a specified fault level to the detected fault based on the fault event. The fault level management module is configured to configure and manage the fault levels, perform version management on the fault levels, and guide fault handling based on the configuration data of the fault levels.

8. An electronic device, characterized in that, include: The system includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; the memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the method according to any one of claims 1 to 6.

10. A vehicle, characterized in that, The vehicle is equipped with a configurable and expandable automatic driving system fault detection system as described in claim 7.

Images