Intelligent driving-based fault management system and method, vehicle, and storage medium

Abstract

Disclosed in the present application are an intelligent driving-based fault management system and method, a vehicle and a storage medium. The system comprises: a fault detection module, a fault management module and a fault processing module. The fault detection module is configured to: when a fault status code corresponding to a detected fault changes, send fault information corresponding to the fault to the fault management module. The fault management module is configured to: determine a fault processing result of the fault on the basis of the fault information, and send the fault processing result to the fault processing module. The fault processing module is configured to: manage a corresponding function of an intelligent driving vehicle on the basis of the fault processing result. Only when the fault status code corresponding to the detected fault changes, the present system sends the fault information to the fault management module, which enables the fault management module and the fault processing module to manage the fault, thereby reducing resource consumption and improving the real-time performance of fault processing.

Description

Fault management system, method, vehicle and storage medium based on intelligent driving

[0001] This application claims priority to Chinese Patent Application No. 202411489851.7, filed with the Chinese Patent Office on October 24, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of autonomous driving technology, and in particular to a fault management system, method, vehicle, and storage medium based on intelligent driving. Background Technology

[0003] The intelligent driving domain controller based on the autonomous driving system has a fault management module. After a system failure occurs, the fault management module will quickly identify the fault and execute preset safety response measures to prevent dangerous situations caused by system or equipment failures, thereby ensuring driver safety and ensuring that the functional safety requirements of the autonomous driving system are met.

[0004] In existing fault management systems, when the acquisition module detects a vehicle fault, it reports the fault to the management module. However, the relevant methods consume unnecessary resources when reporting faults, and the real-time performance of fault processing is not high. Summary of the Invention

[0005] This application provides a fault management system, method, vehicle, and storage medium based on intelligent driving to solve the problems of resource waste and low real-time performance in handling faults that occur in intelligent driving in related technologies.

[0006] According to one aspect of this application, a fault management system based on intelligent driving is provided. The system includes: a fault detection module, a fault management module, and a fault processing module, wherein the fault management module is connected to the fault detection module and the fault processing module respectively.

[0007] The fault detection module is used to send the fault information corresponding to the fault to the fault management module when the fault status code corresponding to the detected fault changes.

[0008] The fault management module is used to determine the fault handling result based on the fault information and send the fault handling result to the fault handling module.

[0009] The fault handling module is used to manage the corresponding functions of the intelligent driving vehicle based on the fault handling results.

[0010] According to another aspect of this application, a fault management method based on intelligent driving is provided, the method being implemented by the fault management system based on intelligent driving described in any embodiment of this application, the method comprising:

[0011] When the fault status code corresponding to a detected fault changes, the fault detection module sends the fault information corresponding to the fault to the fault management module.

[0012] The fault management module determines the fault handling result based on the fault information and sends the fault handling result to the fault handling module.

[0013] The fault handling module manages the corresponding functions of the intelligent driving vehicle based on the fault handling results.

[0014] According to another aspect of this application, a vehicle is provided, the vehicle comprising: at least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the fault management method based on intelligent driving as described in any embodiment of this application.

[0017] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the fault management method based on intelligent driving as described in any embodiment of this application.

[0018] This application discloses a fault management system, method, vehicle, and storage medium based on intelligent driving. The system includes a fault detection module, a fault management module, and a fault processing module. The fault detection module sends fault information corresponding to a detected fault to the fault management module when the fault status code changes. The fault management module determines the fault processing result based on the fault information and sends the fault processing result to the fault processing module. The fault processing module manages the corresponding functions of the intelligent driving vehicle based on the fault processing result. By only sending fault information to the fault management module when the fault status code corresponding to a detected fault changes, this system enables both the fault management module and the fault processing module to manage faults, reducing resource consumption and improving the real-time performance of fault processing. This solves the problems of resource waste and low real-time performance in handling faults in intelligent driving in related technologies.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 is a schematic diagram of the architecture of a fault management system provided by related technologies;

[0022] Figure 2 is a schematic diagram of the structure of a fault management system based on intelligent driving provided in Embodiment 1 of this application;

[0023] Figure 3 is a schematic diagram of the structure of a fault management system based on intelligent driving provided in Embodiment 2 of this application;

[0024] Figure 4 is a schematic diagram of a fault management system based on intelligent driving provided in an embodiment of this application;

[0025] Figure 5 is a state machine diagram of a fault response provided in an embodiment of this application;

[0026] Figure 6 is a schematic diagram of a fault recovery process provided in an embodiment of this application;

[0027] Figure 7 is a schematic diagram of fault data storage provided in an embodiment of this application;

[0028] Figure 8 is a schematic diagram of a fault data format provided in an embodiment of this application;

[0029] Figure 9 is a schematic diagram of a fault information reporting method provided in an embodiment of this application;

[0030] Figure 10 is a schematic diagram of another fault information reporting method provided in an embodiment of this application;

[0031] Figure 11 is a schematic diagram of a fault storage module storing fault information according to an embodiment of this application;

[0032] Figure 12 is a flowchart illustrating a fault management method based on intelligent driving provided in Embodiment 3 of this application;

[0033] Figure 13 is a structural schematic diagram of the vehicle according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. It should be understood that the various steps described in the method implementation of the present application can be performed in different orders and / or in parallel. Furthermore, the method implementation may include additional steps and / or omit the steps shown. The scope of the present application is not limited in this respect.

[0035] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, any variations of the terms "comprising" and "having," etc., are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0038] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0039] Existing fault management systems mainly consist of a fault monitoring group (monitor), a fault collection group (collector), and a fault handling group (handler). However, they suffer from drawbacks such as unnecessary resource consumption, neglect of fault recovery status, low real-time performance, and risk of data loss. As shown in Figure 1, the fault detection module (Fault Monitor 1 to Fault Monitor n) can include a temperature monitoring module, an analog-to-digital converter (ADC) voltage monitoring module, etc. All faults detected by the fault detection module are mapped to the corresponding fault identifier (error ID) in the fault list. When a fault occurs, it is sent to the functional safety fault management module (Safety Manager) in the form of an error ID. If the fault does not occur or recovers, no error ID is sent to the Safety Manager. However, because error IDs are continuously sent for faults in a persistent state, it leads to unnecessary resource consumption; moreover, each project has a corresponding fault list, resulting in high costs for updating, maintaining, and version management.

[0040] Safety Manager can collect error IDs transmitted by fault detection modules, determine the fault status of each module, and perform subsequent processing according to the Action if it is a newly occurred fault; otherwise, it does not process the existing fault. Faults can be logged. However, this method does not consider fault recovery and has low real-time performance. Fault status determination is entirely handled by Safety Manager, which slows down the response time as the number of front-end detection modules and faults increases. The probability of data loss in the logs is high, hindering post-incident analysis. The Fault Handler module can degrade or terminate functionality based on received fault information. This module is typically handled by the upper-layer application, but existing methods do not consider function recovery, making recovery inflexible.

[0041] To address the aforementioned issues, this application proposes a fault management system based on intelligent driving, as detailed below:

[0042] Example 1

[0043] Figure 2 is a schematic diagram of a fault management system based on intelligent driving provided in Embodiment 1 of this application. The system is applicable to the management of vehicle faults in intelligent driving scenarios. The system can execute fault management methods based on intelligent driving and is generally integrated into the vehicle. In this embodiment, the vehicle includes, but is not limited to, vehicles with intelligent driving functions such as large vehicles, medium-sized vehicles and small vehicles.

[0044] As shown in Figure 2, the fault management system based on intelligent driving provided in Embodiment 1 of this application includes: a fault detection module 10, a fault management module 20 and a fault processing module 30, wherein the fault management module 20 is connected to the fault detection module 10 and the fault processing module 30 respectively.

[0045] The fault detection module 10 is used to send the fault information corresponding to the fault to the fault management module 20 when the fault status code corresponding to the detected fault changes.

[0046] The fault management module 20 is used to determine the fault handling result based on the fault information and send the fault handling result to the fault handling module 30.

[0047] The fault handling module 30 is used to manage the corresponding functions of the intelligent driving vehicle based on the fault handling results.

[0048] The fault detection module 10 can be a module in the vehicle used to detect faults, such as a temperature monitoring module or an ADC voltage monitoring module. The fault can be a malfunction occurring in a module within the vehicle. The fault status code is an identifier indicating the state of the fault and can be used to determine whether a fault has occurred. The fault information can be related to the fault, including fault identifiers and fault status codes. The fault management module 20 is a module that analyzes all faults and determines the vehicle's response measures. The fault handling result indicates how to handle the fault. The fault handling module 30 is a module that processes the fault. The intelligent driving vehicle can be a vehicle equipped with intelligent driving functions. The fault handling module 30 can be implemented by an upper-layer application.

[0049] In this embodiment, the number of fault detection modules 10 can be one or more. After detecting a fault, one or more fault detection modules 10 can determine whether the fault status code corresponding to the fault has changed. When it changes, it indicates that the fault status has changed, from not occurring to occurring, or from occurring to recovering. At this time, the fault information corresponding to the fault can be sent to the fault management module 20. After receiving the fault information, the fault management module 20 can analyze the fault information, determine the fault handling result for the fault, and send the fault handling result to the fault handling module 30. The fault handling module 30 can then manage the corresponding functions of the intelligent driving vehicle according to the fault handling result, thereby ensuring the safe state of intelligent driving. For example, it ensures that when a critical fault is detected, the domain controller can place the system in a known safe state, such as decelerating and stopping, maintaining the lane, or safely pulling over.

[0050] This application provides a fault management system based on intelligent driving, comprising: a fault detection module, a fault management module, and a fault processing module. The fault detection module sends fault information corresponding to a detected fault to the fault management module when the fault status code changes. The fault management module determines the fault processing result based on the fault information and sends the result to the fault processing module. The fault processing module manages the corresponding functions of the intelligent driving vehicle based on the fault processing result. This system reduces resource consumption by only sending fault information to the fault management module when the fault status code changes, enabling both the fault management and fault processing modules to manage faults. Decoupling the fault management module eliminates the need for complex judgment logic to determine the fault status, improving the real-time performance of fault processing and solving the problems of resource waste and low real-time performance in handling faults in intelligent driving technologies.

[0051] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0052] In one embodiment, the fault information includes a fault identifier and a fault status code corresponding to the fault. The fault management module 20 is specifically used to: find the corresponding fault response operation from the fault list according to the fault identifier; and determine the fault handling result of the fault according to the fault level corresponding to the fault response operation and the fault status code. The fault level includes a normal fault level, a system-on-a-chip fault level, and a domain controller fault level.

[0053] In this context, the fault identifier can be a unique identifier for the fault. The fault list can be a list used to store information corresponding to each type of fault. The fault response action can be the action to be taken when a specific fault is detected, such as error reporting, logging, or system reset. The fault level can be a classification of faults of different severity levels. In this embodiment, the fault levels can include ordinary fault levels, system-on-chip (SoC) fault levels, and domain controller fault levels. Ordinary fault levels are minor faults that do not affect or only affect the normal operation of some functions. System-on-chip (SoC) fault levels are faults that occur at the SoC level and cause the SoC to restart. Domain controller fault levels are severe faults that occur in the system and cause the domain controller to restart.

[0054] In this embodiment, the fault information may include a fault identifier and a fault status code. After receiving the fault information, the fault management module 20 can find the corresponding fault response operation from the fault list based on the fault identifier in the fault information. Based on the fault response operation, it can determine how to handle the fault. For example, the fault handling result can be obtained based on the fault level and fault status code corresponding to the fault response operation. In this embodiment, the fault management module only needs the fault information and the fault list to determine the corresponding fault handling result, eliminating the need for complex judgments and thus improving the fault handling speed.

[0055] In one embodiment, the fault list includes at least the following fields: fault type, fault name, fault identifier, debouncing, recovery identifier, fault response operation, and applicable items.

[0056] The fault type can be defined based on the module where the fault occurred. For example, the fault type could include Temperature Monitor (TMON) for System on Chip (SOC), represented by SOC_TMON, or voltage monitoring via ADC, represented by ADC_VMON. The fault name can be a descriptive name for the specific fault; for example, when the SOC reaches a high temperature, the fault name could be "SOC_TMON_ALERT_ERROR". The fault identifier can be a unique 32-bit hexadecimal fault code that identifies each error.

[0057] The debouncing function indicates whether debouncing should be performed when a fault is detected, as well as the duration or number of debouncing attempts. For example, in ADC monitoring with a 10ms sampling period, debouncing can be configured to require a voltage anomaly to be detected 10 times consecutively before a corresponding fault is reported. The recovery flag indicates whether the corresponding fault can recover automatically. For example, if there is a heartbeat loss fault between the Microcontroller Unit (MCU) and the System-on-Chips (SOC), a 5-second delay is required before the system restarts. Even if a heartbeat is detected again before the restart, the fault recovery will not be reported. The applicable items indicate the applicable systems for different vehicle models. Due to differences in modules across vehicle models, faults in the fault list may not be applicable to all vehicles. Therefore, the applicable items indicate which vehicles the fault applies to.

[0058] In this embodiment, the fault list can define at least the following fields: fault type, fault name, fault identifier, debouncing, recovery identifier, fault response operation, and applicable projects. The fault type field allows for quick identification of the nature of the error; the fault name allows for quick identification and searching of specific errors; and the fault identifier facilitates programmatic referencing and handling of specific errors. Setting a debouncing identifier for a fault reduces the frequency of error reports, preventing a flood of error reports due to temporary issues. The applicable project field allows all projects to share the same fault list, facilitating the platformization of the fault list and enabling the extension of project-specific fault information onto the basic fault list.

[0059] In one embodiment, the fault management module 20 is specifically configured to: when the fault status code is a fault occurrence code, determine the function to be exited based on the fault level corresponding to the fault response operation, and exit the function to be exited as the fault handling result of the fault; when the fault status code is a fault recovery code, determine the function to be recovered based on the fault level corresponding to the fault response operation, and recover the function to be recovered as the fault handling result of the fault.

[0060] Among them, the functions to be exited can be functions related to the fault that need to be exited. The functions to be restored can be functions related to the fault that need to be restored.

[0061] In this embodiment, the fault management module 20 can determine the status of the fault status code. When the fault status code is a fault occurrence code, it indicates that a fault has just occurred. At this time, it is necessary to determine the function to be exited based on the fault level corresponding to the fault response operation. When the fault status code is a fault recovery code, it indicates that the fault has been recovered, and the corresponding function can be restored. For example, when the fault level is a normal fault level, the function corresponding to the fault can be directly designated as the function to be exited or restored; when the fault level is a system-level chip fault level, regardless of the fault, it is necessary to restart or restore all functions of the system-level chip, and the system-level chip is directly designated as the function to be exited or restored; when the fault level is a domain controller fault level, regardless of the fault, it is necessary to restart or restore all functions in the system, and the domain controller is directly designated as the function to be exited or restored.

[0062] The fault management module in this embodiment also takes into account the fault recovery status. It can determine whether the fault has been recovered based on the fault status code, which makes it easier for upper-layer applications to flexibly recover the fault according to the fault status, taking into account both functional safety and user experience.

[0063] In one embodiment, the fault handling module 30 is specifically used to: perform function exit or function recovery on the corresponding functions of the intelligent driving vehicle according to the fault handling result; wherein, the fault handling result includes: function exit and function recovery of specified partial functions, system-on-a-chip, or domain controllers.

[0064] Specifically, designated functions correspond to the functions associated with a fault at the ordinary fault level. The system-on-a-chip (SoC) can be a single chip integrating multiple system functions, and the domain controller can be an Autonomous Driving Control Unit (ADCU). A domain controller can consist of an MCU, a System-on-a-Chip (SoC), and some peripherals. The MCU can be a microcontroller unit in the control system, responsible for handling various control logic.

[0065] In this embodiment, the fault handling module 30 can disable or restore corresponding functions in the intelligent driving vehicle based on the fault handling result. The fault handling result may include the disabling or restoration of specified functions, system-on-a-chip (SoC), or domain controllers. The specified functions, SoCs, or domain controllers correspond to the ordinary fault level, the SoC fault level, and the domain controller fault level, respectively. This embodiment, through the fault handling module, can restore / disable functions based on the fault handling result, thereby improving the flexibility of function restoration.

[0066] Example 2

[0067] Figure 3 is a schematic diagram of a fault management system based on intelligent driving provided in Embodiment 2 of this application. Embodiment 2 is an optimization based on the above embodiments. For details not covered in this embodiment, please refer to Embodiment 1.

[0068] As shown in Figure 3, the fault management system based on intelligent driving provided in Embodiment 2 of this application further includes: a power management module 40; the fault management module 20 is also used to send a power-down request to the power management module 40 when it is determined that the fault handling result includes the function exit of the system chip or domain controller; the power management module 40 is used to restart the system chip or domain controller according to the power-down request.

[0069] The power-down request can be a request to power down the module. The power management module 40 can be a module responsible for performing operations such as system restart based on the request.

[0070] In this embodiment, the fault management system may further include a power management module 40, which may be connected to the fault management module 20. When the fault management module 20 determines that the fault handling result is the function exit of the system chip or the function exit of the domain controller, it may send a power-down request to the power management module 40. The power management module 40 may determine whether to restart the system chip or the domain controller based on the power-down request.

[0071] Embodiment 2 of this application provides a fault management system based on intelligent driving. It specifies a fault management module and further includes a power-down request sent to the power management module when the fault handling result determines that the system-on-a-chip or domain controller has exited its function. The power management module is used to restart the system-on-a-chip or domain controller according to the power-down request. This system, by having the power management module restart the system-on-a-chip or domain controller according to the power-down request, can prevent safety issues caused by faults.

[0072] In one embodiment, the power management module 40 is specifically used to: upon receiving a power-down request, wait for a preset time interval, and then restart the system-on-a-chip or domain controller according to the power-down request.

[0073] The preset time interval can be set according to the actual situation.

[0074] In this embodiment, when the power management module 40 receives a power-down request, it can wait for a preset time interval before restarting the system-on-a-chip or domain controller according to the power-down request, thereby providing a time buffer for the safe shutdown and data protection of the system.

[0075] In one embodiment, the system further includes: a fault storage module; a fault management module 20, which, upon receiving the fault information, stores the fault index corresponding to the fault identifier of the fault in the random access memory of the fault storage module; a power management module 40, which, upon receiving the power-down request, sends a storage request to the fault storage module; and the fault storage module, upon receiving the storage request, stores the data in the random access memory in a local non-volatile memory.

[0076] The fault storage module stores information related to vehicle faults. The fault index corresponds to the index value of a fault identifier; different fault identifiers have different fault indices. The storage request is a request to store fault information.

[0077] In this embodiment, after receiving the fault information, the fault management module 20 can temporarily store the fault index corresponding to the fault identifier in the random access memory. After receiving the power-down request, the power management module 40 sends a storage request to the fault storage module. After receiving the storage request, the fault storage module can store the data in the random access memory to the local non-volatile memory (NVM) to ensure that the fault information is not lost after the system chip or domain controller is powered down.

[0078] In one embodiment, the fault storage module is specifically configured to: upon receiving the storage request, write the data in the random access memory into a first storage error block in a local non-volatile memory; perform an OR operation between the data in the first storage error block and the data in the second storage error block, and write the data in the first storage error block that is different from the data in the second storage error block into the second storage error block; and clear the data in the random access memory; wherein the first storage error block is used to store fault data that occurred after the last system-on-a-chip restart, and the second storage error block is used to store fault data that occurred during the vehicle's lifespan.

[0079] The non-volatile memory may include two distinct fault storage blocks. The first fault storage block stores fault data that occurred after the last system-on-a-chip (SoC) reboot, while the second fault storage block stores fault data that occurred throughout the vehicle's lifespan. The fault data may include fault information such as fault indices.

[0080] In this embodiment, the fault storage module can write data from the random access memory (RAM) to a first fault block in the local non-volatile memory (NVM), and through an OR operation, write data that is not present in the second fault block but exists in the first fault block to the second fault block, and then clear the data in the RAM. This embodiment, by storing fault data in NVM, enables more precise problem localization and reduces the risk of data loss. Furthermore, by not immediately storing fault data to the NVM after a fault occurs, it reduces the number of NVM erase / write cycles and extends the lifespan of the NVM storage.

[0081] Based on the technical solutions of the above embodiments, this application provides several specific implementation methods.

[0082] As a specific implementation of this embodiment, Figure 4 is a schematic diagram of the structure of a fault management system based on intelligent driving provided in this application embodiment. As shown in Figure 4, the system architecture mainly consists of a fault monitoring group (monitor), a fault collection group (collector), a fault handling group (Handler), and a fault storage group (storage). All faults of the fault module are mapped to the corresponding error ID in the Faultlist. When a fault occurs, the fault detection module sends the error ID and status to the fault management module (Safety Manager). A status of 0 indicates fault recovery, and 1 indicates a fault occurrence. Fault information is only sent to the Safety Manager when the fault status code changes. This reduces unnecessary resource consumption. The fault management module receives the error ID and status. If the status is 1, it performs the corresponding processing action according to the fault response action; if it is 0, it processes the fault as recovery and stores the fault information in RAM according to the index. Before the SOC and MCU are powered down, it requests storage in the NVM.

[0083] The fault detection system in this embodiment defines a common fault list, Faultlist, which includes fields such as fault type, fault name, fault ID, debounce, recovery, fault response action, and applicable project. This allows the system to distinguish whether a fault applies to a specific project, providing a structured platform for fault classification, recording, and processing. It also facilitates global management of fault information for all projects and reduces maintenance costs.

[0084] For example, Table 1 is a schematic diagram of a fault list, which shows 3 faults.

[0085] Table 1 Fault List

[0086] SOC_TMON_ALERT_ERROR is a temperature monitoring-related fault for the SOC, indicating that the SOC temperature has exceeded a preset warning threshold and an alarm is issued. The debouncing time is 1 second, meaning that if the fault detection module detects that the temperature returns to normal within 1 second, it will not report the fault to the Safety Manager. If the temperature is still abnormal after 1 second, it will send 0xA0000101status:1 to the Safety Manager. The Safety Manager will then trigger the corresponding operation based on action 0x01, namely, reporting the errorid and status to the fault handling module for functional degradation. If the fault detection module detects fault recovery, it will send 0xA0000101status:0 to the Safety Manager, and the Safety Manager will report 0xA0000101status:0 to the fault handling module for functional restoration.

[0087] SOC_TMON_SHDN_ERROR is a temperature monitoring-related fault for the SOC, indicating that the SOC temperature has reached a dangerous level. It signals that the SOC will be shut down to prevent chip damage. The debouncing time is 1 second, meaning that if the fault detection module detects that the temperature returns to normal within 1 second, it will not report the fault to the Safety Manager. If the temperature is still abnormal after 1 second, it will send 0xA0000102status:1 to the Safety Manager. The Safety Manager will then trigger the corresponding operation based on action 0x02, namely, reporting SOC status 1 to the fault handling module for functional degradation and sending a power-down request to the power management module to shut down the SOC. After the SOC restarts, if the fault detection module detects that the temperature has returned to normal, it will send 0xA0000102status:0 to the Safety Manager. The Safety Manager will then report SOC status 0 to the fault handling module for functional restoration.

[0088] MCU_TMON_SHDN_ERROR is a temperature monitoring-related fault for the MCU, indicating that the MCU temperature has reached a dangerous level. It signals that the ADCU domain controller (i.e., the domain controller) is about to shut down to prevent chip damage. The debouncing time is 1 second, meaning that if the fault detection module detects that the temperature returns to normal within 1 second, it will not report the fault to the Safety Manager. If the temperature is still abnormal after 1 second, it will send 0xA0000201status:1 to the Safety Manager. The Safety Manager, based on action 0x03, triggers the corresponding operation, namely reporting MCU status:1 to the fault handling module for function degradation and sending a power-down request to the power management module to shut down the domain controller. Because the domain controller system is reinitialized, all faults default to a fault-free state, and functions can be enabled normally.

[0089] Figure 5 is a state machine diagram of a fault response provided in an embodiment of this application. As shown in Figure 5, this embodiment designs different levels of functional degradation (Degrade1, Degrade2, Degrade3). Figure 5 describes the transition logic of the system under different fault conditions. The system can gradually reduce functions according to the severity of the fault, instead of directly entering a completely shut-down state. This hierarchical processing can improve the stability of the system and the user experience. F1, F2, and F3 represent the ordinary fault level, the system-on-a-chip fault level, and the domain controller fault level, respectively. The fault response operation corresponding to F1 can be 0x01, the fault response operations corresponding to F2 can be 0x02 and 0x05, and the fault response operation corresponding to F3 can be 0x03.

[0090] The following is a description of each state and transition in the state machine diagram:

[0091] For example, the transition from the Normal state to the Degrade 1 state is triggered by the activation of an F1 fault. The transition from Normal or Degrade 1 to Degrade 2 is triggered by the activation of an F2 fault. The transition from Normal or Degrade 1 to Degrade 3 is triggered by the activation of an F3 fault. The Degrade 2 state triggers a SOC reset (i.e., SOC shutdown). The Degrade 3 state triggers a domain controller reset (i.e., ADCU restart). The Initialization mode (Init1) indicates that the domain controller is in initialization mode, which may be due to a reset caused by a power-on (key on) or a warm start. During this stage, the ADCU output is disabled, and the system is shut down.

[0092] The state machine diagram in this embodiment provides a clear view of how the system responds and transitions its state in the face of different fault conditions, ensuring the stability and security of the system. The fault management system can not only determine the fault level (F1, F2, F3) but also identify the fault recovery state, thus enabling more flexible responses to faults rather than simply taking action when a fault occurs. Upper-layer applications can perform fault degradation and recovery based on the fault state, making the functional degradation strategy more flexible while simultaneously considering functional safety and user experience.

[0093] This embodiment uses different strategies for different actions. Table 2 shows the classification of fault response operations in this embodiment.

[0094] Table 2 Classification of Fault Response Operations

[0095] The FSP (Fault Signaling Protocol) is a pin on the MCU used to notify the external control chip of its fault status. Forced power-down simplifies the power-down process, while a safe power-down process performs a chip self-test. This embodiment defines different response measures based on the severity of the fault (F1, F2, F3 levels), and the upper-layer application decides whether to exit or degrade the function based on the actual impact. This hierarchical processing method improves the system's flexibility and adaptability, minimizing the impact of faults. By defining fault status codes, fault information is standardized, allowing the upper-layer application to quickly degrade or restore functionality based on the fault status codes.

[0096] For example, Figure 6 is a schematic diagram of a fault recovery process provided in an embodiment of this application. As shown in Figure 6, if an F1 level fault (action 0x01) occurs: the fault management module notifies the fault handling module, and the fault handling module performs function exit / function degradation according to the actual impact scope; when the fault is recovered, the fault handling module restores the relevant functions. For example, if a fault identified by fault code 0xA000101 occurs, the fault detection module n sends 0xA000101status 1 to the fault management module. The fault management module notifies the fault handling module according to the action (0x01) of this fault, and the fault handling module will exit the functions affected by the 0xA000101 fault. When the fault detection module n detects that the fault has been recovered, it sends 0xA000101status 0 to the fault management module. The fault management module notifies the fault handling module according to the action (0x01) of this fault, and the fault handling module will restore the functions affected by the 0xA000101 fault and return to the active state.

[0097] If an F2-level fault occurs (action 0x02 / 0x05), the fault management module sends SOC status 1, indicating that the SOC has experienced a serious fault and is preparing to shut down. The fault handling module then exits the functionality. After the SOC restarts, it continues to detect faults. When the fault is resolved, the fault management module sends SOC status 0 to the fault handling module to restore the relevant functions. For example, if a fault identified by fault code 0xA000102 occurs, fault detection module 1 sends 0xA000102status 1 to the fault management module. Based on the fault's action (0x02), the fault management module sends SOC status 1 to the fault handling module and simultaneously requests the power management module to shut down the SOC after a 500ms delay. Upon receiving this notification, the fault handling module executes the exit of the relevant intelligent driving functions. Before the SOC is powered down, the system stores the first storage error block (Error_Block_Cur) and the second storage error block (Error_Block_His) through NVM. After the SOC restarts, if 0xA000102 has been resolved, the fault management module will then notify the fault handling module, which will restore the previously exited intelligent driving functions.

[0098] If an F3-level fault (action 0x03) occurs, the fault management module sends MCU status 1, indicating that the ADCU system has experienced a serious fault and is preparing to shut down. The fault handling module then exits its functions. After the MCU restarts, it continues to detect faults, and all functions are enabled by default. For example, if a fault identified by fault code 0xA000201 occurs, the fault detection module sends 0xA000201 status 1 to the fault management module. Based on the fault's action (0x03), the fault management module sends MCU status 1 to the fault handling module and simultaneously requests the power management module to shut down the MCU (domain controller) after a 300ms delay. Upon receiving this notification, the fault handling module exits the relevant intelligent driving functions. Before the MCU is powered down, the system stores the error block via NVM. After the MCU restarts, all faults default to the initial state, and all functions are enabled by default.

[0099] Figure 7 is a schematic diagram of fault data storage provided in an embodiment of this application. As shown in Figure 7, the NVM of this embodiment includes two 256-byte storage blocks, Error_Block_Cur and Error_Block_His, which store the fault data of the most recent SOC restart and all historical fault data, respectively. Before the MCU is powered off and the SOC is powered off, the fault data can be stored according to the fault index transmitted by the fault management module.

[0100] Figure 8 is a schematic diagram of a fault data format provided in an embodiment of this application. As shown in Figure 8, the fault data format stored in NVM may include a 4-byte timestamp, a 1-byte version number, and the remaining bytes store fault information. The timestamp records the latest time of storing the current fault data, the version number is the version number of the current fault list, and each fault in the fault information corresponds to a fault index value, stored sequentially starting from byte 5, with one bit representing one fault. The fault indices corresponding to faults in different versions of the fault list may be different. Therefore, this embodiment also records the version number. If the fault index is changed, the fault list version needs to be updated.

[0101] This embodiment uses NVM to store the faults that occur, providing important data for subsequent fault analysis and system optimization. Furthermore, each stored fault index maps to 1 bit, saving space and improving storage efficiency compared to storing fault names and fault identifiers.

[0102] Figure 9 is a schematic diagram of one method of reporting fault information provided in an embodiment of this application, and Figure 10 is a schematic diagram of another method of reporting fault information provided in an embodiment of this application. As shown in Figures 9 and 10, this embodiment only reports faults when the state of the fault changes.

[0103] Figure 11 is a schematic diagram of a fault storage module storing fault information provided in an embodiment of this application. As shown in Figure 11, cur00-cur15 correspond to Error_Block_Cur in non-volatile memory, and bak00-bak15 correspond to Error_Block_His in non-volatile memory.

[0104] Example 3

[0105] Figure 12 is a flowchart illustrating a fault management method based on intelligent driving according to Embodiment 3 of this application. This method is applicable to managing vehicle faults in intelligent driving scenarios. The method can be implemented by a fault management system based on intelligent driving and is generally integrated into the vehicle. For details not covered in this embodiment, please refer to the above embodiments.

[0106] As shown in Figure 12, the fault management method based on intelligent driving provided in Embodiment 3 of this application includes the following steps:

[0107] S310. When the fault status code corresponding to the detected fault changes, the fault information corresponding to the fault is sent to the fault management module through the fault detection module.

[0108] The fault can be a module malfunction within the vehicle. The fault status code is an identifier indicating the state of the fault and can be used to determine whether a fault has occurred. Fault information includes relevant information about the fault, such as the fault identifier and fault status code.

[0109] In this embodiment, the fault detection module can detect faults in the vehicle, and when it is determined that the fault status code corresponding to the fault has changed, the fault information corresponding to the fault can be sent to the fault management module.

[0110] S320. The fault management module determines the fault handling result based on the fault information and sends the fault handling result to the fault handling module.

[0111] In this embodiment, the fault information can be analyzed by the fault management module to obtain the fault handling result, and the fault handling result can be sent to the fault handling module.

[0112] S330. The fault handling module manages the corresponding functions of the intelligent driving vehicle based on the fault handling results.

[0113] In this embodiment, the fault handling module can take corresponding measures based on the fault handling results to manage the corresponding functions of the intelligent driving vehicle.

[0114] This embodiment provides a fault management method based on intelligent driving, comprising: when a fault detection module detects a change in the fault status code corresponding to a fault, sending fault information corresponding to the fault to a fault management module; the fault management module determining a fault handling result based on the fault information and sending the fault handling result to a fault handling module; and the fault handling module managing the corresponding functions of the intelligent driving vehicle based on the fault handling result. By sending fault information to the fault management module only when the fault status code corresponding to the detected fault changes, the fault management module and the fault handling module can manage faults, reducing resource consumption and improving the real-time performance of fault handling. This solves the problems of resource waste and low real-time performance in handling faults occurring in intelligent driving in related technologies.

[0115] Furthermore, the fault information includes a fault identifier and a fault status code corresponding to the fault. The step of determining the fault handling result of the fault through the fault management module based on the fault information includes: finding the corresponding fault response operation from the fault list based on the fault identifier; and determining the fault handling result of the fault based on the fault level corresponding to the fault response operation and the fault status code. The fault level includes a normal fault level, a system-on-a-chip fault level, and a domain controller fault level.

[0116] Furthermore, determining the fault handling result based on the fault level corresponding to the fault response operation and the fault status code includes: when the fault status code is a fault occurrence code, determining the function to be exited based on the fault level corresponding to the fault response operation, and taking the exit of the function to be exited as the fault handling result; when the fault status code is a fault recovery code, determining the function to be recovered based on the fault level corresponding to the fault response operation, and taking the recovery of the function to be recovered as the fault handling result.

[0117] Furthermore, the fault list includes at least the following fields: fault type, fault name, fault identifier, debouncing, recovery identifier, fault response operation, and applicable items.

[0118] Furthermore, the management of the corresponding functions of the intelligent driving vehicle by the fault handling module based on the fault handling result includes: deactivating or restoring the corresponding functions of the intelligent driving vehicle based on the fault handling result; wherein, the fault handling result includes: deactivating or restoring the functions of specified parts of the vehicle, system-on-a-chip, or domain controller.

[0119] Furthermore, the method also includes: when the fault handling result is determined by the fault management module to include the exit of the function of the system chip or domain controller, a power-down request is sent to the power management module; and the power management module restarts the system chip or domain controller according to the power-down request.

[0120] Furthermore, the step of restarting the system-on-a-chip or domain controller according to the power-down request via the power management module includes: upon receiving the power-down request, waiting for a preset time interval, and then restarting the system-on-a-chip or domain controller according to the power-down request.

[0121] Furthermore, the method also includes: after receiving the fault information through the fault management module, storing the fault index corresponding to the fault identifier of the fault into the random access memory of the fault storage module; when the power management module receives the power-down request, sending a storage request to the fault storage module; and when the fault storage module receives the storage request, storing the data in the random access memory into local non-volatile memory.

[0122] Furthermore, the step of storing the data in the random access memory to local non-volatile memory includes: writing the data in the random access memory into a first storage error block in the local non-volatile memory; performing an OR operation on the data in the first storage error block and the data in a second storage error block, and writing the data in the first storage error block that is different from the data in the second storage error block into the second storage error block; and clearing the data in the random access memory; wherein the first storage error block is used to store fault data that occurred after the last system-on-a-chip restart, and the second storage error block is used to store fault data that occurred during the vehicle's lifespan.

[0123] Example 4

[0124] Figure 13 shows a schematic diagram of the structure of a vehicle 10 that can be used to implement an embodiment of this application. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of this application described and / or claimed herein.

[0125] As shown in Figure 13, the vehicle 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer programs stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the vehicle 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0126] Multiple components in vehicle 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows vehicle 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0127] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as fault management methods based on intelligent driving.

[0128] In some embodiments, the intelligent driving-based fault management method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on vehicle 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the intelligent driving-based fault management method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the intelligent driving-based fault management method by any other suitable means (e.g., by means of firmware).

[0129] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0130] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0131] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0132] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0133] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0134] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0135] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0136] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A fault management system based on intelligent driving, the system comprising: The system includes a fault detection module, a fault management module, and a fault handling module, wherein the fault management module is connected to both the fault detection module and the fault handling module. The fault detection module is used to send the fault information corresponding to the fault to the fault management module when the fault status code corresponding to the detected fault changes. The fault management module is used to determine the fault handling result based on the fault information and send the fault handling result to the fault handling module. The fault handling module is used to manage the corresponding functions of the intelligent driving vehicle based on the fault handling results.

2. The system according to claim 1, wherein, The fault information includes the fault identifier and fault status code corresponding to the fault. The fault management module is specifically used for: The corresponding fault response operation is retrieved from the fault list based on the fault identifier; The fault handling result is determined based on the fault level corresponding to the fault response operation and the fault status code. The fault levels include ordinary fault levels, system-on-a-chip fault levels, and domain controller fault levels.

3. The system according to claim 2, wherein, The fault management module is specifically used for: When the fault status code is a fault occurrence code, the function to be exited is determined according to the fault level corresponding to the fault response operation, and exiting the function to be exited is taken as the fault handling result of the fault. When the fault status code is a fault recovery code, the function to be recovered is determined according to the fault level corresponding to the fault response operation, and the recovery of the function to be recovered is taken as the fault handling result of the fault.

4. The system according to claim 2, wherein, The fault list shall include at least the following fields: Fault type, fault name, fault identifier, debouncing, recovery identifier, fault response operation, and applicable items.

5. The system according to claim 1, wherein, The fault handling module is specifically used for: Based on the fault handling results, the corresponding functions of the intelligent driving vehicle are either deactivated or restored. The fault handling results include: the exit and recovery of functions of specified parts, system-on-a-chip, or domain controllers.

6. The system according to claim 1, further comprising: Power management module; The fault management module is also used to send a power-down request to the power management module when it is determined that the fault handling result includes the exit of the function of the system chip or domain controller; The power management module is used to restart the system-on-a-chip or domain controller according to the power-down request.

7. The system according to claim 6, wherein, The power management module is specifically used for: Upon receiving a power-down request, wait for a preset time interval and then restart the system-on-a-chip or domain controller according to the power-down request.

8. The system according to claim 6, further comprising: Fault storage module; The fault management module is also used to store the fault index corresponding to the fault identifier of the fault into the random access memory of the fault storage module after receiving the fault information. The power management module is also used to send a storage request to the fault storage module when it receives the power-down request; The fault storage module is used to store the data in the random access memory to local non-volatile memory when the storage request is received.

9. The system according to claim 8, wherein, The fault storage module is specifically used for: Upon receiving the storage request, the data in the random access memory is written into the first storage error block in the local non-volatile memory; Perform an OR operation between the data in the first storage error block and the data in the second storage error block, and write the data in the first storage error block that is different from the data in the second storage error block into the second storage error block; Clear the data in the random access memory; The first storage error block is used to store fault data that occurred after the last system-on-a-chip restart, and the second storage error block is used to store fault data that occurred during the vehicle's lifespan.

10. A fault management method based on intelligent driving, the method being implemented by a fault management system based on intelligent driving as described in any one of claims 1-9, the method comprising: When the fault status code corresponding to a detected fault changes, the fault detection module sends the fault information corresponding to the fault to the fault management module. The fault management module determines the fault handling result based on the fault information and sends the fault handling result to the fault handling module. The fault handling module manages the corresponding functions of the intelligent driving vehicle based on the fault handling results.

11. A vehicle, the vehicle comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the fault management method based on intelligent driving as described in claim 10.

12. A computer-readable storage medium storing computer instructions for causing a processor to execute and implement the fault management method based on intelligent driving as described in claim 10.

Images