A configurable scalable autonomous driving system fault detection method and system

Abstract

The application relates to the technical field of vehicles and discloses a configurable and expandable automatic driving system fault detection method and system, an electronic device, a storage medium and a vehicle, which comprise establishing a unified node heartbeat mechanism to collect heartbeat information of each module of an automatic driving system in real time; in response to the collected heartbeat information, the heartbeat information is stored and managed to enable a fault detection strategy to perform data query; the fault detection strategy is set and executed to periodically traverse the stored heartbeat information, complete fault detection, and assign a specified fault level to the detected fault based on a fault event; the fault level is configured and managed, the fault level is managed in terms of version, and fault disposal is guided based on configuration data of the fault level. The application can reduce the delay time of fault detection, improve the real-time performance of fault detection, and realize configurable management of fault levels.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, in particular to a configuration extensible automatic driving system fault detection method, system, electronic device, storage medium and vehicle. BACKGROUND

[0002] At present, with the rapid development and application of automatic driving technology, automatic driving technology brings great experience improvement to people. At the same time, the reliability and safety of the automatic driving system itself are also paid more and more attention. To ensure the reliability and safety of the automatic driving system, on the one hand, safety-related considerations need to be made in the design of the automatic driving system and platform, and on the other hand, real-time fault detection and fault disposal of the automatic driving system are also needed. As we all know, the automatic driving system is a complex system including perception, positioning, planning and control and other functions. In the unmanned scene, how to detect the system fault of the system in real time and accurately, and timely perform safety disposal actions, is a common problem to be solved in the automatic driving industry.

[0003] The fault detection scheme commonly adopted in the industry at present is to collect the process state information of each module, combine the internal state information sent by the module, make a simple fault judgment on the state information, and then perform a simple maximum value operation on the fault level to judge the state of each module. On this basis, the state of the system is judged according to the importance of the module itself, and finally the system is derived into two states of safety or non-safety. If it is a safe state, the automatic driving continues, and if it is a non-safety state, the takeover processing is performed. Although this fault detection scheme can complete the basic functions of fault detection, fault reminder and fault disposal, it also has the problems of non-uniform fault detection rules, large update iteration cost and single fault disposal action. It cannot efficiently cope with the complex operation test environment in the unmanned scene.

[0004] Therefore, the present application provides a configuration extensible automatic driving system fault detection method to solve the above technical problems. SUMMARY

[0005] The purpose of the present application is to provide a configuration extensible automatic driving system fault detection method, system, electronic device, storage medium and vehicle, which solves the technical problems of non-uniform fault detection rules, large update iteration cost, single fault disposal action, and inability to efficiently cope with the complex operation test environment in the unmanned scene in the prior art.

[0006] In order to solve the above technical problems, the present application provides a configuration extensible automatic driving system fault detection method, comprising:

[0007] The heartbeat mechanism establishment step includes 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 a timestamp, a component name, and a fault code of each internal fault event of the module.

[0008] The heartbeat information management step includes storing and managing the collected heartbeat information to enable the fault detection strategy to perform data queries.

[0009] The fault detection step includes 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 step includes configuring and managing the fault level, version managing the fault level, and guiding fault disposal based on the configuration data of the fault level.

[0011] In some embodiments, the heartbeat mechanism establishment step includes 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 a timestamp, a component name, and a fault code of each internal fault event of the module, and further includes:

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

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

[0014] When the module does not have the fault event, an empty heartbeat packet is sent.

[0015] The heartbeat information is transmitted through a publish-subscribe communication mode.

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

[0017] Based on a cache mechanism, the heartbeat information in the recent period is stored, wherein the cache mechanism includes a lock-free ring queue.

[0018] A real-time disk landing function of the heartbeat information is established to ensure the safety and traceability of the heartbeat information.

[0019] A data query interface of the fault detection strategy in the module and time dimension is provided.

[0020] In some embodiments, the fault detection step includes 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, further including:

[0021] The fault detection strategy is configured according to the characteristics and needs of the autonomous driving system, wherein the fault detection strategy includes a heartbeat timeout strategy and a heartbeat information content verification strategy;

[0022] Periodically traverse all the fault detection strategies, and determine the state of the module according to the strategy logic of the fault detection strategy;

[0023] Based on the determined module state, complete the fault detection, evaluate the fault level of the detected fault according to the preset rule, and store the evaluation result in the fault event cache of the EventBus.

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

[0025] Version managing the fault level includes displaying all current versions of the fault level and adding new versions of the fault level;

[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 triple tuple to represent faults and rate faults from three dimensions: system impact, operational impact, and parking urgency.

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

[0029] When starting fault detection, read the fault level configuration data into the node cache, manage it in the form of a hash table, and perform fault level lookup and assignment to guide fault handling of the autonomous driving system.

[0030] Based on the same concept, the present application also provides a configuration-based scalable autonomous driving system fault detection system, including:

[0031] The heartbeat mechanism establishment module is configured to establish a unified node heartbeat mechanism and collect 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 each internal fault event of the module;

[0032] The heartbeat information management module is configured to store and manage the heartbeat information in response to the collected heartbeat information, so as to enable the fault detection strategy to query data.

[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 a fault event.

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

[0035] Based on the same concept, the present application also provides an electronic device comprising 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, which, when executed by the processor, causes the processor to execute the steps of the configurable and expandable fault detection method for an autonomous driving system.

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

[0037] Based on the same concept, the present application also provides a vehicle provided with the configurable and expandable fault detection system for an autonomous driving system as described above.

[0038] Compared with the prior art, the present application has the following advantages:

[0039] The present application discloses a configurable and expandable fault detection method and system for an autonomous driving system, an electronic device, a storage medium and a vehicle, which can reduce the delay time of fault detection, improve the real-time performance of fault detection, realize configurable management of fault levels, improve the update iteration efficiency of fault detection function, improve the precision and accuracy of fault detection, and facilitate the implementation of fault disposal actions. BRIEF DESCRIPTION OF DRAWINGS

[0040] Figure 1 is a flowchart of the configurable and expandable fault detection method for an autonomous driving system in some embodiments of the present application;

[0041] Figure 2 is an architecture diagram of the configurable and expandable fault detection method for an autonomous driving system in some applications of the present application;

[0042] Figure 3 is a vehicle cloud interaction process schematic diagram of a configurable expandable automatic driving system fault detection method in some applications of the present application;

[0043] Figure 4 is a logic block diagram of a configurable expandable automatic driving system fault detection method in some applications of the present application;

[0044] Figure 5 is a structural schematic diagram of a configurable expandable automatic driving system fault detection system in some specific embodiments of the present application;

[0045] Figure 6 is a structural schematic diagram of an electronic device in some specific embodiments of the present application. DETAILED DESCRIPTION

[0046] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0047] The terms used in the embodiments of the present application are only for the purpose of describing the specific embodiments, and are not intended to limit the present application. The singular forms "a", "an" and "the" used in the embodiments of the present application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. "Multiple" generally includes at least two.

[0048] It should be understood that the term "and / or" used herein is only to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this paper generally represents that the front and rear associated objects are a "or" relationship.

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

[0050] Depending on the context, the word "if" as used herein can be interpreted to mean "when" or "while" or "in response to determining" or "in response to detecting." Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" can be interpreted to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]."

[0051] It is also to be noted that the terms "comprising", "including", and any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises a... " does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0052] It is particularly noted that symbols and / or numbers present in the description, if not marked in the description of the figures, are not figure references.

[0053] Reference Figure 1 A configuration scalable autonomous driving system fault detection method, comprising:

[0054] S101, a heartbeat mechanism establishment step, comprising 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 comprises a timestamp, a component name and a fault code of each internal fault event of the module;

[0055] It can be understood that the heartbeat information contains the following three core fields:

[0056] Timestamp: records the exact time of occurrence of the internal fault event of the module, in the format of year-month-day-hour-minute-second-millisecond, ensuring time accuracy to the millisecond level.

[0057] Component name: identifies the specific component or module name where the fault occurs, in the form of a string, such as "radar sensor", "navigation calculation unit", etc., to facilitate quick positioning of the problem source.

[0058] Fault code: according to a pre-set fault coding system, a unique identifier is assigned to each possible fault, represented by hexadecimal or decimal numbers, such as "0x0001" representing "sensor data anomaly".

[0059] Inside each key module of the autonomous driving system, a heartbeat information collection module is embedded. This module is responsible for real-time monitoring of module running status. Once an internal fault event is detected (such as sensor data anomaly, calculation unit overload, etc.), heartbeat information is immediately generated according to the above-mentioned specifications.

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

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

[0062] In some applications, the heartbeat mechanism establishment step includes establishing a unified node heartbeat mechanism, collecting heartbeat information of each module of the autonomous driving system in real time, the heartbeat information including the timestamp, component name and fault code of the internal fault event of each module, setting a unified heartbeat period, configuring each module to send heartbeat information according to the heartbeat period; when there is a fault event inside the module, a complete heartbeat package including the fault event related information is sent; when there is no fault event inside the module, an empty heartbeat package is sent; the heartbeat information is transmitted through the publish / subscribe communication mode.

[0063] It can be understood that a unified heartbeat period is set according to the running characteristics and monitoring requirements of the autonomous driving system. For example, the heartbeat period is set to 5 seconds.

[0064] In each system module, the heartbeat sending logic is configured to enable it to send heartbeat information according to the set heartbeat period. The content of the heartbeat information is different according to whether there is a fault event inside the module.

[0065] When there is a fault event inside the module:

[0066] Heartbeat package content: including heartbeat header information (such as timestamp, module ID, etc.), 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 package is generated according to the fault information and sent at the next heartbeat period.

[0068] For example, assuming that the "camera module" detects a "image transmission interruption" fault at a certain moment, 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 is no fault event inside the module:

[0076] Heartbeat packet content: only contains heartbeat header information, i.e. an empty heartbeat packet or called heartbeat confirmation packet.

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

[0078] The communication mode of publishing and subscribing is adopted for the transmission of heartbeat information. 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 period. Each module publishes heartbeat information to the message queue or topic of the system according to the set heartbeat period. The central monitoring unit continuously listens to these message queues or topics, and when it receives heartbeat information, it parses and processes it, including, for empty heartbeat packets, confirming that the module is currently in normal operation and updating the online state information of the module. Complete heartbeat packet processing, parsing the fault event information in the complete heartbeat packet, analyzing the fault according to the fault code and fault description, triggering the corresponding alarm or processing mechanism.

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

[0080] In some applications, the heartbeat information management step includes storing and managing the heartbeat information in response to the collected heartbeat information, so that the fault detection strategy can query the data based on a cache mechanism, storing the heartbeat information in the recent period, the cache mechanism includes a lock-free ring queue; Establishing a real-time disk landing function of heartbeat information to ensure the safety and traceability of heartbeat information; Providing a data query interface for the module internal fault detection strategy in the module and time dimensions.

[0081] It can be understood that, in order to quickly respond to the collection and processing of heartbeat information, a lock-free ring queue is used as the main data structure of the cache. This queue can safely store heartbeat information in the recent period in a multi-threaded environment, avoiding the overhead of data competition and lock waiting.

[0082] Parameter setting: Set the capacity of the lock-free ring queue to N heartbeat packets, for example, N = 1000, the queue can cache the last 1000 heartbeat packets (assuming the heartbeat period is 5 seconds, about 5000 seconds, about 83 minutes of historical data).

[0083] Heartbeat information enqueue and dequeue: Whenever new heartbeat information is collected, it is encapsulated into a heartbeat packet and attempts to join the ring queue without locks. If the queue is full, the oldest heartbeat packet is automatically overwritten according to the first-in, first-out principle.

[0084] To ensure the safety and long-term traceability of heartbeat information, a real-time disk landing function is designed. This function regularly or asynchronously writes the heartbeat information in the cache to a persistent storage medium (such as a hard disk or SSD).

[0085] Disk landing frequency: Set to perform a disk landing operation every M heartbeat period, for example, M = 100, that is, perform a disk landing every 500 seconds (100 5-second periods), balancing data safety and system write overhead.

[0086] To support the flexibility and efficiency of the fault detection strategy, a data query interface is provided to allow fine-grained queries based on module and time dimensions.

[0087] Module dimension query: Allows users to specify module ID or module name to query the heartbeat information of the module in the specified time period. For example, query all heartbeat information of the "radar module" in the past hour.

[0088] Time dimension query: Supports querying by time range, users can specify start time and end time to get heartbeat information of all modules or heartbeat information of specific modules in 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 function. The interface receives query parameters such as module ID, time range, etc., and returns a list of heartbeat information that meets the conditions, including detailed content of the heartbeat packet such as timestamp, module ID, fault event, etc.

[0090] For example, a "laser radar module" has a "data transmission interruption" failure at "2023-05-10 11:30:00", which is captured as heartbeat information. This heartbeat information is first added to the lock-free ring queue. If the queue is not full at this time, it is directly stored; if it is full, the oldest heartbeat packet is overwritten. Subsequently, in the next disk writing period (assuming that the disk writing time point has not been reached), the heartbeat information will be written to the persistent storage along with other heartbeat information that meets the disk writing conditions. When the fault detection strategy needs to analyze the fault, the module ID can be specified as "laser radar module" and the time range can be specified as a period of time before and after "2023-05-10 11:30:00" to obtain a list of heartbeat information containing the fault event. The fault detection strategy can further analyze and process based on these information.

[0091] S103, performing a 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 step includes 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. Based on the characteristics and needs of the autonomous driving system, the fault detection strategy is configured accordingly. The fault detection strategy includes a heartbeat timeout strategy and a heartbeat information content verification strategy. All fault detection strategies are periodically traversed according to the strategy logic of the fault detection strategy to determine the state of the module. Based on the determined module state, the fault detection is completed, the detected fault is evaluated according to the pre-set rules, and the evaluation result is stored in the fault event cache of the EventBus.

[0093] It can be understood that, according to the characteristics and needs of the autonomous driving system, two main fault detection strategies are set: heartbeat timeout strategy and heartbeat information content verification strategy.

[0094] Heartbeat timeout strategy: set a reasonable heartbeat timeout threshold, for example, 3 heartbeat periods (assuming each period is 5 seconds, the timeout threshold is 15 seconds). If a module does not send heartbeat information for 3 consecutive heartbeat periods, it is considered to have a heartbeat timeout failure.

[0095] Heartbeat information content verification strategy: define the verification rules of heartbeat information content, such as checking whether the timestamp in the heartbeat packet is continuous, whether the fault code is valid, etc. If the heartbeat information content does not meet the expectations, it is considered that the content verification fails, indicating that there is an exception inside the module.

[0096] Performing fault detection:

[0097] Periodic traversal of heartbeat information: set the detection period (such as once every minute), and in this period, traverse the stored heartbeat information. In the traversal process, the configured fault detection strategies are applied in turn.

[0098] Strategy logic judgment module state: for each module, according to its heartbeat information, respectively apply the heartbeat timeout strategy and the heartbeat information content verification strategy. If any strategy judges that the module state is abnormal (such as timeout or content verification failure), mark the module as a fault state.

[0099] Fault detection and level assessment:

[0100] Complete fault detection: after the traversal is completed, the information of all modules marked as fault state is summarized.

[0101] Fault level assessment: according to the preset rules, the detected faults are assessed in levels. For example, set three fault levels: level one (serious fault, such as key sensor failure), level two (medium fault, such as non-key component anomaly), and level three (minor fault, such as temporary communication interruption). The assessment rules can be based on a comprehensive consideration of factors such as fault type, impact range, recovery time, etc.

[0102] For example, if the "radar sensor" module has a heartbeat timeout and has not recovered for multiple consecutive periods, it is assessed as a level one fault; if the "audio playback system" module has a content verification failure, but does not affect the safe driving of the vehicle, it is assessed as a level three fault.

[0103] Store fault events:

[0104] EventBus fault event cache: encapsulate the assessed fault events and their related information (such as fault level, occurrence time, module ID, etc.) into event objects and publish them to the fault event cache of EventBus. EventBus, as an efficient event publishing / subscription mechanism, can ensure that fault events are timely and accurately delivered to related processing systems or components.

[0105] S104, fault level management step, including configuring and managing the fault level, version managing the fault level, and guiding fault disposal based on the configuration data of the fault level.

[0106] In some applications, the fault level management step includes configuring and managing fault levels, version managing fault levels, and guiding fault handling based on fault level configuration data. Version managing fault levels includes displaying all current versions of fault levels and adding new fault level versions; calculating the md5 value of the fault level configuration file and maintaining the relationship between the version and the md5 value through cloud services; and configuring the file in a triple tuple manner to represent faults and rate faults from three dimensions of system impact, operational impact, and parking urgency.

[0107] It can be understood that the fault level is configured and managed according to the actual situation and business needs of the automatic driving system. The fault level is used to guide the fault handling work.

[0108] Fault level definition: define different levels of faults, such as level 1 (serious fault), level 2 (moderate fault), level 3 (minor fault), etc., each level corresponds to different system impact, operational impact and parking urgency.

[0109] Configuration file format: use triple tuple to represent faults, each fault entry contains three key information: system impact (System Impact), operational impact (Operational Impact) and parking urgency (Parking Urgency). These three dimensions together determine the level of the fault.

[0110] For example, fault entry 1: {System Impact: "high", Operational Impact: "medium", Parking Urgency: "high"}, rated as level 1 fault.

[0111] Fault entry 2: {System Impact: "medium", Operational Impact: "low", Parking Urgency: "low"}, rated as level 3 fault.

[0112] In order to support flexible adjustment and optimization of fault levels, version management strategy is implemented.

[0113] Version display: provide a user interface or API interface to display all current versions of fault level configurations. Users can view detailed information of each version, including version number, creation time, modification content, etc.

[0114] New version: allow users or system administrators to add fault level versions. When adding a new version, upload the new configuration file and fill in the version description.

[0115] In order to ensure the consistency and security of the configuration file, md5 value is used for version control.

[0116] MD5 value calculation: Whenever a new fault level configuration file is uploaded, automatically calculate the MD5 value of the file. The MD5 value is a unique hash value used to verify the integrity of the file content.

[0117] Cloud service maintenance: Store each version of the configuration file and its corresponding MD5 value in the cloud service. The cloud service provides a mapping relationship between the version and the MD5 value to verify the correctness of the configuration file when needed.

[0118] Fault level configuration data is not only used for fault assessment and classification, but also used to guide subsequent fault handling work.

[0119] Fault assessment: When a fault is detected, according to the specific information of the fault (such as error code, fault phenomenon, etc.), combined with the fault level configuration data, the level of the fault is assessed.

[0120] Handling suggestions: According to the assessment results, provide corresponding fault handling suggestions. For example, for a first-level fault, suggest stopping immediately and contacting technical support; for a third-level fault, only record in the log and continue running.

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

[0122] It can be understood that, in order to improve data access efficiency, the loaded fault level configuration data is stored in the cache of the system node. The fault level configuration data is organized in the form of a hash table in the node cache. The hash table stores data in the form of key-value pairs, where the key can be a unique identifier of the fault (such as fault code, module ID, etc.), and the value is the corresponding fault level configuration information (including system impact degree, operation impact degree, parking urgency degree, etc.). During fault detection, when a fault is detected, the corresponding fault level configuration is quickly found in the hash table through the unique identifier of the fault (such as 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 assignment result of the fault level, the autonomous driving system can more accurately judge the severity of the fault and formulate a fault handling strategy accordingly.

[0123] The following embodiments of the application will be described in conjunction with Figures 2 to 4 the configuration of the expandable autonomous driving system fault detection method in some applications:

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

[0125] As shown in Figure 2 , a heartbeat mechanism for each module of the autonomous driving system is established to collect the state information of each module in real time. Based on the publish-subscribe communication mode, each module is required to send heartbeat information to the fault detection module according to a unified heartbeat period (e.g., 50 ms). The heartbeat information can carry information such as the timestamp of the internal fault event of the module, the component name, and the fault code. If there is a certain fault event inside the module, the above event-related information is published through the heartbeat. If there is no fault event inside the module, only an empty information packet is sent.

[0126] The fault detection module sorts the collected heartbeat information of each module according to the timestamp and stores it in the cache (for example, a lock-free ring queue can be used to store the node heartbeat information in the last 20 minutes), which is used for data query in the module and time dimensions by the internal fault detection strategy and supports real-time data landing.

[0127] The fault detection module designs and adds fault detection strategies according to the actual situation (for example, a module heartbeat timeout strategy, i.e., whether the number of heartbeat packets of the module in the last period of time in the heartbeat cache meets the timeout threshold number, if less than the timeout threshold, it is judged that the heartbeat is timed out and the module is abnormal, otherwise the heartbeat is normal). The fault detection module periodically traverses all fault detection strategies to complete fault detection.

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

[0129] In order to better guide the fault disposal of each module downstream, the correspondence between the specified fault level and the disposal method is realized, and when evaluating the level of the fault, it is evaluated according to three dimensions: system impact degree, operation impact degree, and parking urgency degree. The system impact degree refers to the impact on the main system control module, the backup system control module, and the auxiliary module. The operation impact degree refers to the impact on the completion of this order. The parking urgency degree refers to whether parking is required at present and the parking level requirement.

[0130] The functional safety personnel complete the fault level assessment after the fault, and access the fault management tool through the browser to manage the fault level. The main function of the configuration tool is the version management function of the fault level. All current versions of the fault level are displayed through the page, and new versions of the fault level can be added. When the fault level configuration is completed, the tool will generate a fault level configuration file, and use the MD5 tool to calculate the md5 value of the fault configuration file. The cloud service maintains the relationship between the version and the md5 value. The functional safety personnel confirms the configuration.

[0131] As shown in Figure 4 Each fault is rated from three different dimensions: system impact, safety and operation impact, and parking urgency. The final fault level is obtained. Each fault on the vehicle is rated in three dimensions, and the fault level is finally configured in the fault level configuration file. The fault detection module reads the fault level configuration data into the node cache when the node starts, and manages it in the form of a hash table. It is convenient for efficient fault level lookup and assignment on the vehicle.

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

[0133] 1. The functional safety personnel assesses the fault level of a certain fault and needs to adjust (or add or delete a fault). Access the fault management service through the browser and make the corresponding fault configuration to obtain the version number and md5 value of the fault set.

[0134] 2. The fault management service generates a fault level configuration file and stores it in the disk with the md5 value as the file name. At the same time, a fault configuration file version information is added in the database, including the file name, path, and version number, for subsequent query and use;

[0135] 3. The functional safety personnel configure the md5 value of the above fault set version to the code of the fault management module. After completing the code compilation, the fault detection module is burned and written on the automatic driving platform.

[0136] 4. After starting the fault detection module, the fault detection module reads the fault level configuration file on the vehicle end, calculates the md5 value of the configuration file, and compares it with the md5 value in the code to find that they are inconsistent. Then, through the http protocol, the fault management service requests the fault level configuration file corresponding to the md5 value configured in the code.

[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 end fault detection module through http.

[0138] 6、The vehicle end detection module stores and reads the configuration file, and puts the fault level information into a hash table to store the fault name as a key and the fault level as a value;

[0139] 7、If a module at the vehicle end crashes, the heartbeat timeout strategy of the fault detection module detects heartbeat timeout, and the fault level query hash table is queried for the fault level of the fault;

[0140] 8、After the fault level is superimposed, the fault level of the system is calculated and returned.

[0141] This embodiment realizes real-time fault detection of each module at the vehicle end through a unified fault level superposition scheme, completes fault level configuration in combination with the fault level version management tool of the cloud end, then realizes efficient management of the fault level through vehicle-cloud interaction and version verification, and finally realizes an efficient fault detection scheme.

[0142] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present application are not limited by the order of the described actions, because according to the embodiments of the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of the present application.

[0143] As shown in Figure 5 The present application also provides a configuration-extended automatic driving system fault detection system, which comprises:

[0144] A heartbeat mechanism establishment module 201 is configured to establish a unified node heartbeat mechanism and collect heartbeat information of each module of the automatic driving system in real time, wherein the heartbeat information comprises a timestamp, a component name and a fault code of each internal fault event of the module;

[0145] A 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 performs data query;

[0146] An execution 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] A fault level management module 204 is configured to configure and manage the fault level, perform version management on the fault level, and guide fault disposal based on the configuration data of the fault level.

[0148] It is worth noting that, although only some basic function modules are disclosed in the embodiments of the present application, it does not mean that the composition of the system is limited to the above basic function modules, on the contrary, the meaning expressed in the embodiments is: on the basis of the above basic function modules, those skilled in the art can add one or more function modules to form infinite embodiments or technical solutions in combination with the prior art, that is, the system is open rather than closed, and the protection scope of the present application claim cannot be limited to the disclosed basic function modules because the embodiments only disclose individual basic function modules. At the same time, in order to facilitate description, the above device is described as various units and modules. Of course, the functions of each unit and module can be implemented in the same software and / or hardware when implementing the present application.

[0149] As shown in Figure 6 The present application also provides an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the configuration-based expandable automatic driving system fault detection method.

[0150] Figure 6 is a structural schematic diagram of an electronic device provided by the embodiments of the present application. As shown in the structure of Figure 6 The electronic device provided in the embodiments of the present application includes one or more processors 710 and storage devices 720; the processor 710 in the electronic device can be one or more, Figure 6 In the foregoing, the processor 710 is taken as an example; the storage device 720 is used for storing 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 configuration-based expandable automatic driving system fault detection method according to any one of the embodiments of the present application.

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

[0152] The processor 710, the storage device 720, the input device 730 and the output device 740 in the electronic device can be connected through a bus or other means, Figure 6 In the foregoing, the connection through the bus is taken as an example.

[0153] The storage 720 in the electronic device can be used to store one or more programs as a computer readable storage medium, which can be a software program, a computer executable program and a module, such as the program instructions / modules corresponding to the configured expandable automatic driving system fault detection method provided in the embodiments of the present application. The processor 710 executes the software program, instructions and modules stored in the storage 720, thereby performing various function applications and data processing of the electronic device, i.e. implementing the configured expandable automatic driving system fault detection method in the above method embodiments.

[0154] The storage 720 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required by a function; the data storage area can store data created according to the use of the electronic device, etc. In addition, the storage 720 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state memory device. In some examples, the storage 720 can further include a memory remotely arranged with respect to the processor 710, which can be connected to the device through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

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

[0156] The present application also provides a computer readable storage medium storing a computer program executable by an electronic device, which causes the electronic device to perform the steps of the configured expandable automatic driving system fault detection method when the computer program is running on the electronic device.

[0157] In particular, the computer storage medium of the embodiments of the present application can adopt 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. The computer readable storage medium may, for example, be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples (non-exhaustive list) of the computer readable storage medium include: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present 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, device or apparatus.

[0158] The present application also provides a vehicle provided with the configured 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 application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A configurable scalable automated driving system fault detection method, characterized in that, The method comprises the following steps: Heartbeat mechanism establishment step, 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 comprises a timestamp, a component name and a fault code of each internal fault event of the module; Heartbeat information management step, including storing and managing the heartbeat information in response to the collected heartbeat information to enable the fault detection strategy to query data; 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; Fault level management step, including configuring and managing the fault level, version managing the fault level, and guiding fault disposal based on the configuration data of the fault level, specifically including: The functional safety personnel assesses the level of a certain fault that needs to be adjusted, accesses the fault management service through a browser, and makes corresponding fault configuration to obtain the version number and md5 value of the fault set; at this time, the fault management service generates a fault level configuration file and stores it in the disk with the md5 value as the file name, and adds a fault configuration file version information in the database, including the file name, path and version number, for subsequent query and use; the functional safety personnel configures the md5 value of the above fault set version to the code of the fault management module, and completes code compilation; after the fault detection module is burned and written on the autonomous driving platform; after starting the fault detection module, the fault detection module reads the fault level configuration file of the vehicle end, calculates the md5 value of the configuration file, and compares it with the md5 value in the code to find that they are inconsistent; then, the fault detection module requests the fault level configuration file corresponding to the md5 value configured in the code through the http protocol; the fault management service finds the configuration file of the specified version by querying the md5 value, and sends it to the vehicle end fault detection module through http; the vehicle end detection module stores and reads the configuration file, and stores the fault level information in a hash table with the fault name as the key and the fault level as the value; if a certain module of the vehicle end crashes, the heartbeat timeout strategy of the fault detection module detects heartbeat timeout, and queries the fault level of the fault in the fault level query hash table; after fault level superposition, the fault level of the system is calculated and returned; Each fault is represented in the form of a triple: {node name, component name, fault code}; Each fault is rated from three different dimensions: system self-impact, safety and operation impact, and parking urgency, to obtain the fault level of the fault; Each fault on the vehicle is rated in three dimensions, and the fault level is configured in the fault level configuration file; the fault detection module reads the fault level configuration data into the node cache when the node starts, and manages it in the form of a hash table, so as to facilitate efficient fault level lookup and assignment on the vehicle.

2. The configurable extensible automated driving system fault detection method of claim 1, wherein, The heartbeat mechanism establishment step comprises establishing a unified node heartbeat mechanism and collecting heartbeat information of each module of the automatic driving system in real time, wherein the heartbeat information comprises a timestamp, a component name and a fault code of each internal fault event of the module, and further comprises: A uniform heartbeat period is set, and each module is configured to send the heartbeat information according to the heartbeat period; When the internal fault event exists in the module, a complete heartbeat packet including the information related to the fault event is sent; When the internal fault event does not exist in the module, an empty heartbeat packet is sent; The heartbeat information is transmitted through a publish-subscribe communication mode.

3. The configurable extensible automated driving system fault detection method of claim 1, wherein, The heartbeat information management step comprises storing and managing the heartbeat information in response to the collected heartbeat information, so that the fault detection strategy performs data query, and further comprises: Based on a cache mechanism, the heartbeat information in the recent period of time is stored, wherein the cache mechanism comprises a lock-free ring queue; A real-time disk landing function of the heartbeat information is established to ensure the safety and traceability of the heartbeat information; A data query interface of the fault detection strategy in the module and time dimension is provided.

4. The configurable extensible automated driving system fault detection method of claim 1, wherein, The fault detection step comprises 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, and further comprises: Based on the characteristics and needs of the automatic driving system, the fault detection strategy is configured accordingly, wherein the fault detection strategy comprises a heartbeat timeout strategy and a heartbeat information content verification strategy; Periodically traverse all the fault detection strategies, and determine the state of the module according to the strategy logic of the fault detection strategy; Based on the determined state of the module, the fault detection is completed, the fault level of the detected fault is evaluated according to the preset rule, and the evaluation result is stored in the fault event cache of EventBus.

5. A configurable scalable autonomous driving system fault detection system, characterized in that, Comprise: The heartbeat mechanism establishment module is configured to establish a unified node heartbeat mechanism and collect heartbeat information of each module of the automatic driving system in real time, wherein the heartbeat information comprises a timestamp, a component name and a fault code of each internal fault event of the module; The heartbeat information management module is configured to store and manage the heartbeat information in response to the collected heartbeat information, so that the fault detection strategy performs data query; 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 level, perform version management on the fault level, and guide fault disposal based on the configuration data of the fault level, specifically comprising: The functional safety personnel assesses the level of a certain fault, accesses the fault management service through a browser, and makes a corresponding fault configuration to obtain the version number and md5 value of the fault set; at this time, the fault management service generates a fault level configuration file and stores it in the disk with the md5 value as the file name, and adds a fault configuration file version information in the database, including the file name, path and version number, for subsequent query and use; the functional safety personnel configures the md5 value of the above fault set version to the code of the fault management module, and after completing the code compilation, the fault detection module is burned and written on the automatic driving platform; after starting the fault detection module, the fault detection module reads the fault level configuration file of the vehicle end, calculates the md5 value of the configuration file, and compares it with the md5 value in the code to find that they are inconsistent, then requests the fault level configuration file corresponding to the md5 value configured in the code through the http protocol; the fault management service finds the configuration file of the specified version by querying the md5 value, and sends it to the vehicle end fault detection module through http; the vehicle end detection module stores and reads the configuration file, and puts the fault level information into a hash table to store it with the fault name as the key and the fault level as the value; if a certain module of the vehicle end crashes, the heartbeat timeout strategy of the fault detection module detects the heartbeat timeout, and queries the fault level of the fault in the fault level query hash table; after fault level superposition, the fault level of the system is calculated and returned; Each fault is represented in the form of a triple: {node name, component name, fault code}; Each fault is rated from three different dimensions: system self-impact, safety and operation impact, and parking urgency, to obtain the fault level of the fault; Each fault on the vehicle is rated in three dimensions, and the fault level is configured in the fault level configuration file. The fault detection module reads the fault level configuration data into the node cache when the node starts, and manages it in the form of a hash table, facilitating efficient fault level lookup and assignment on the vehicle.

6. An electronic device, comprising: Comprise: 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, when the computer program is executed by the processor, the processor executes the steps of the method of any one of claims 1 to 4.

7. A computer readable storage medium characterized in that, It stores a computer program executable by an electronic device, when the computer program runs on the electronic device, the electronic device executes the steps of the method of any one of claims 1 to 4.

8. A vehicle characterized by comprising: The vehicle is provided with the configuration expandable automatic driving system fault detection system of claim 5.

Images