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

Abstract

The invention discloses a fault management system and method based on intelligent driving, 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 used for sending fault information corresponding to a fault to the fault management module when a fault state code corresponding to the detected fault changes; the fault management module is used for determining a fault processing result of the fault according to the fault information and sending the fault processing result to the fault processing module; and the fault processing module is used for managing corresponding functions of the intelligent driving vehicle according to the fault processing result. According to the system, the fault information is sent to the fault management module only when the fault state code corresponding to the detected fault is changed, so that the fault management module and the fault processing module manage the fault, resource consumption can be reduced, and the real-time performance of fault processing is improved.

Description

Technical Field

[0001] Embodiments of the present invention relate 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 Art

[0002] 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.

[0003] In the existing fault management system, when the acquisition module detects that a vehicle fault occurs, it will report the fault to the management module. However, the existing method consumes unnecessary resources when reporting the fault, and the real-time performance of the fault handling is not high. Summary of the invention

[0004] The present invention 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 when handling faults occurring in intelligent driving in the prior art.

[0005] According to one aspect of the present invention, there is provided a fault management system based on intelligent driving, the system comprising: a fault detection module, a fault management module and a fault processing module, the fault management module being connected to the fault detection module and the fault processing module respectively;

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

[0007] The fault management module is used to determine the fault handling result of the fault according to the fault information, and send the fault handling result to the fault handling module;

[0008] The fault processing module is used to manage the corresponding functions of the intelligent driving vehicle according to the fault processing result.

[0009] According to another aspect of the present invention, a fault management method based on intelligent driving is provided. The method is implemented by the fault management system based on intelligent driving according to any embodiment of the present invention, and the method includes:

[0010] 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 by the fault detection module;

[0011] Determine, by the fault management module, a fault handling result of the fault according to the fault information, and send the fault handling result to the fault handling module;

[0012] The fault handling module manages the corresponding functions of the intelligent driving vehicle according to the fault handling results.

[0013] According to another aspect of the present invention, there is provided a vehicle, the vehicle comprising: at least one processor; and

[0014] a memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the fault management method based on intelligent driving described in any embodiment of the present invention.

[0016] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the fault management method based on intelligent driving described in any embodiment of the present invention when executed.

[0017] The fault management system, method, vehicle and storage medium based on intelligent driving of the embodiment of the present invention, the system includes: a fault detection module, a fault management module and a fault processing 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 processing result of the fault according to the fault information, and send the fault processing result to the fault processing module; the fault processing module is used to manage the corresponding function of the intelligent driving vehicle according to the fault processing result. The system sends fault information to the fault management module only when the fault status code corresponding to the detected fault changes, so that the fault management module and the fault processing module manage the fault, which can reduce resource consumption and improve the real-time performance of fault processing, and solves the problems of resource waste and low real-time performance when processing faults occurring in intelligent driving in the prior art.

[0018] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0020] Figure 1 A schematic diagram of the architecture of a fault management system provided by the prior art;

[0021] Figure 2 A schematic diagram of the structure of a fault management system based on intelligent driving provided in the first embodiment of the present invention;

[0022] Figure 3 A schematic diagram of the structure of a fault management system based on intelligent driving provided in the second embodiment of the present invention;

[0023] Figure 4 A schematic diagram of the structure of a fault management system based on intelligent driving provided by an embodiment of the present invention;

[0024] Figure 5 A state machine diagram of a fault response provided by an embodiment of the present invention;

[0025] Figure 6 A schematic diagram of a fault recovery process provided by an embodiment of the present invention;

[0026] Figure 7 A schematic diagram of storing fault data provided by an embodiment of the present invention;

[0027] Figure 8 A schematic diagram of a data format of fault data provided by an embodiment of the present invention;

[0028] Fig. 9 A schematic diagram of reporting fault information provided by an embodiment of the present invention;

[0029] Fig.10 A schematic diagram of another method for reporting fault information provided by an embodiment of the present invention;

[0030] Fig.11 A schematic diagram of a fault storage module storing fault information provided by an embodiment of the present invention;

[0031] Fig.12 A flowchart of a fault management method based on intelligent driving provided in Embodiment 3 of the present invention;

[0032] Fig.13 Schematic diagram of the structure of a vehicle according to an embodiment of the present invention. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiment of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiment of the present invention. Obviously, the described embodiment is only an embodiment of a part of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work should belong to the scope of protection of the present invention. It should be understood that the various steps recorded in the method implementation of the present invention can be performed in different orders and / or in parallel. In addition, the method implementation may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0034] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part 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". The relevant definitions of other terms will be given in the following description.

[0035] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, any variations of the terms "including" and "having" are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0036] It should be noted that the modifications of "one" and "plurality" mentioned in the present invention are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0037] The names of the messages or information exchanged between multiple devices in the embodiments of the present invention are only used for illustrative purposes, and are not used to limit the scope of these messages or information.

[0038] The existing fault management system mainly includes the fault monitoring group (monitor), the fault collection group (collector) and the fault handling group (handler), but it has defects such as unnecessary resource consumption, neglect of fault recovery, low real-time performance and data loss risk. Figure 1 As shown, the fault detection module (Fault Monitor 1 to Fault Monitor n) may include a temperature monitoring module, an analog-to-digital converter (ADC), a voltage monitoring module, etc. All faults detected by the fault detection module will be mapped to the corresponding fault identifier (error id) in the fault list (Faultlist). When a fault occurs, the fault 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 is recovered, the error id is not sent to the Safety Manager. However, since the error id will be sent for the faults in the ongoing state, it leads to unnecessary resource consumption; and each project has a corresponding Faultlist, and the cost of update maintenance and version management is high.

[0039] Safety Manager can collect the error ID transmitted by the fault detection module, determine the fault status transmitted by each module, and if it is a new fault, perform subsequent processing according to the Action. If it is an ongoing fault, no processing is performed; the fault that occurred can be printed and recorded in the log. However, this method does not consider the situation of fault recovery, and the real-time performance is not high. The judgment of the fault status is made by the Safety Manager. As the number of front-end detection modules and the number of faults increase, the response speed to the fault will slow down. The probability of data loss in the printed log is high, which is not convenient for analyzing the cause of the problem after the problem occurs. The fault handling module (Fault Handler) can perform functional downgrade / function exit according to the received fault information. Generally, the upper-level application is responsible for this module, but the existing method does not consider the situation of functional recovery, and the functional recovery is not flexible.

[0040] In view of the above problems, the present invention proposes a fault management system based on intelligent driving, which is as follows:

[0041] Embodiment 1

[0042] Figure 2A structural schematic diagram of a fault management system based on intelligent driving provided in Embodiment 1 of the present invention. The system can be applied to the management of vehicle faults in intelligent driving scenarios. The system can execute a fault management method based on intelligent driving and is generally integrated on a vehicle. In this embodiment, the vehicle includes but is not limited to large vehicles, medium-sized vehicles, small vehicles and other vehicles with intelligent driving functions.

[0043] like Figure 2 As shown, a fault management system based on intelligent driving provided by the first embodiment of the present invention 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;

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

[0045] The fault management module 20 is used to determine the fault processing result of the fault according to the fault information, and send the fault processing result to the fault processing module 30;

[0046] The fault processing module 30 is used to manage the corresponding functions of the intelligent driving vehicle according to the fault processing result.

[0047] Among them, the fault detection module 10 can be a module in the vehicle for detecting faults, for example, the fault detection module can be a detection module such as a temperature monitoring module, an ADC voltage monitoring module, etc. The fault can be a fault that occurs in a module in the vehicle. The fault status code can be an identifier indicating the state of the fault, which can be used to determine whether the fault occurs. The fault information can be related information of the fault, and the fault information can include a fault identifier and a fault status code, etc. The fault management module 20 can be a module that analyzes all faults and determines the vehicle's response measures to the fault. The fault handling result can be a result indicating how to deal with the fault. The fault handling module 30 can be a module for handling the fault. The intelligent driving vehicle can be a vehicle with intelligent driving functions. The fault handling module 30 can be implemented by an upper-layer application.

[0048] 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 the fault status code changes, it indicates that the fault status has changed, and the fault 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 manage the corresponding functions of the intelligent driving vehicle according to the fault handling result, so as to ensure the safe state of the intelligent driving. For example, it is ensured that when a critical fault is detected, the domain controller can put the system into a known safe state, such as decelerating to stop, keeping the lane, or safely pulling over.

[0049] A fault management system based on intelligent driving provided in the first embodiment of the present invention comprises: a fault detection module, a fault management module and a fault processing 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 processing result of the fault according to the fault information, and send the fault processing result to the fault processing module; the fault processing module is used to manage the corresponding function of the intelligent driving vehicle according to the fault processing result. The system sends fault information to the fault management module only when the fault status code corresponding to the detected fault changes, so that the fault management module and the fault processing module manage the fault, which can reduce resource consumption; the fault management module is decoupled, and the fault management module does not need to perform complex judgment logic to judge the state of the fault, which can improve the real-time performance of fault processing, and solve the problems of resource waste and low real-time performance when processing faults occurring in intelligent driving in the prior art.

[0050] Based on the above embodiment, a variant embodiment of the above embodiment is proposed. It should be noted that in order to make the description concise, only the differences from the above embodiment are described in the variant embodiment.

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

[0052] Among them, the fault identifier can be a unique identifier of the fault. The fault list can be a list for storing information corresponding to each fault. The fault response operation can be an error that should be taken when a specific fault is detected, for example, error reporting, logging, system reset and other responses. The fault level can be the level of faults of different severity. In this embodiment, the fault level can include a common fault level, a system-level chip fault level and a domain controller fault level. The common fault level can be a relatively minor fault that does not affect or affects the normal operation of part of the function. The system-level chip fault level can be a fault that occurs on the system-level chip side and causes the system-level chip to restart. The domain controller fault level can be a serious fault that occurs in the system and causes the domain controller to restart.

[0053] In this embodiment, the fault information may include a fault identifier and a fault status code of the fault. After receiving the fault information, the fault management module 20 may find the corresponding fault response operation of the fault from the fault list according to the fault identifier in the fault information, and may determine how to handle the fault according to the fault response operation, such as obtaining the fault handling result according to the fault level and the fault status code corresponding to the fault response operation. The fault management module of this embodiment only needs to determine the fault handling result corresponding to the fault according to the fault information and the fault list, without making any complicated judgments, thereby improving the fault handling speed.

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

[0055] Among them, the fault type can be the type of fault, and the fault type can be defined according to the module where the fault occurs. For example, the fault type can include temperature monitoring (TMON) of the system-level chip (System on Chip, SOC), represented by SOC_TMON, and voltage monitoring through ADC can also be represented by ADC_VMON. The fault name can be a descriptive name of a specific fault. For example, when the SOC reaches a higher temperature, the fault name can be "SOC_TMON_ALERT_ERROR". The fault identifier can be a 32-bit hexadecimal fault code that uniquely identifies each error.

[0056] Among them, debouncing can be used to indicate whether to debouncing when a fault is detected, as well as the time or number of debouncing. For example, when monitoring with ADC, sampling is performed with a sampling period of 10ms. By setting debouncing, it can be required to detect voltage abnormalities for 10 consecutive times before reporting the corresponding fault. The recovery flag can be used to indicate whether the corresponding fault can recover by itself. For example, if the heartbeat loss failure between the microcontroller unit (MCU) and the SOC occurs, the system needs to be restarted after a delay of 5s. During the period from the detection of the heartbeat failure to the restart, even if the heartbeat is detected again, the fault recovery will not be reported. Applicable items can be used to indicate the items to which the fault applies. The items refer to the systems corresponding to different models. Due to the differences in modules of different models, the faults in the fault list may not be applicable to all vehicles. Therefore, the applicable items can be used to indicate which vehicles the fault applies to.

[0057] In this embodiment, at least the following fields may be defined in the fault list: fault type, fault name, fault identifier, debounce, recovery identifier, fault response operation, and applicable project. By defining the fault type field, the nature of the error can be quickly identified, the fault name can be quickly identified and searched for a specific error, and the fault identifier can facilitate programmatic reference and processing of a specific error. By setting a debounce identifier for the fault, the frequency of error reports can be reduced and the flood of error reports caused by temporary problems can be avoided. By using the applicable project field, all projects can share the same fault list, which helps to platform the fault list and expand project-specific fault information on the basic fault list.

[0058] In one embodiment, the fault management module 20 is specifically used for: when the fault status code is a fault occurrence code, determining the function to be exited according to the fault level corresponding to the fault response operation, and using the exit from the function to be exited as the fault processing result of the fault; when the fault status code is a fault recovery code, determining the function to be restored according to the fault level corresponding to the fault response operation, and using the restoration of the function to be restored as the fault processing result of the fault.

[0059] The function to be exited may be a function related to the fault and needs to be exited, and the function to be restored may be a function related to the fault and needs to be restored.

[0060] In this embodiment, the fault management module 20 can determine the state of the fault status code. When the fault status code is a fault occurrence code, it means that the fault has just occurred. At this time, it is necessary to determine the function to be exited according to the fault level corresponding to the fault response operation of the fault. When the fault status code is a fault recovery code, it means that the fault has been recovered, and the corresponding function can be restored at this time. For example, when the fault level is a normal fault level, the function corresponding to the fault can be directly used as a function to be exited or restored; when the fault level is a system-level chip fault level, no matter what the fault is, all functions of the system-level chip need to be restarted or restored. At this time, the system-level chip is directly used as a function to be exited or restored; when the fault level is a domain controller fault level, no matter what the fault is, all functions in the system need to be restarted or restored. At this time, the domain controller is directly used as a function to be exited or restored.

[0061] The fault management module of this embodiment also takes into account the fault recovery situation and can determine whether the fault is recovered based on the fault status code, so that the upper-layer application can flexibly recover the fault according to the fault situation, taking into account both functional safety and user experience.

[0062] In one embodiment, the fault handling module 30 is specifically used to: exit or restore the corresponding function of the intelligent driving vehicle according to the fault handling result; wherein the fault handling result includes: exit and restore the function of a specified part of the function, system-level chip or domain controller.

[0063] The designated part of functions may correspond to the function corresponding to the fault when the fault level is a normal fault level. The system-level chip may be a single chip integrating multiple system functions, and the domain controller may be an autonomous driving domain controller (ADCU), which may be composed of an MCU, a SOC and some peripherals. The MCU may be a microcontroller unit in the control system, responsible for processing various control logics.

[0064] In this embodiment, the fault handling module 30 can perform function exit or function recovery on the corresponding function in the intelligent driving vehicle according to the fault handling result. The fault handling result may include function exit and function recovery of a specified part of the function, system-level chip or domain controller. The specified part of the function, system-level chip or domain controller corresponds to the common fault level, system-level chip fault level and domain controller fault level of the fault level respectively. In this embodiment, through the fault handling module, function recovery / function exit can be performed according to the fault handling result, which can improve the flexibility of function recovery.

[0065] Embodiment 2

[0066] Figure 3This is a schematic diagram of a fault management system based on intelligent driving provided by Embodiment 2 of the present invention. Embodiment 2 is optimized on the basis of the above embodiments. For details not yet provided in this embodiment, please refer to Embodiment 1.

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

[0068] The power-off request may be a request for instructing to power off the module. The power management module 40 may be a module responsible for executing operations such as system restart according to the request.

[0069] 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 functional exit of the system-level chip or the functional exit of the domain controller, the fault management module 20 may send a power-off request to the power management module 40. The power management module 40 may determine whether to restart the system-level chip or the domain controller based on the power-off request.

[0070] A fault management system based on intelligent driving provided in the second embodiment of the present invention specifies a fault management module, and is also used to send a power-off request to the power management module when it is determined that the fault handling result includes the function exit of the system-level chip or domain controller; the power management module is used to restart the system-level chip or domain controller according to the power-off request. The system restarts the system-level chip or domain controller according to the power-off request through the power management module, which can prevent safety problems caused by faults.

[0071] In one embodiment, the power management module 40 is specifically configured to: upon receiving a power-off request, restart the system-on-chip or the domain controller according to the power-off request after waiting for a preset time interval.

[0072] The preset time interval can be set according to actual conditions.

[0073] In this embodiment, when receiving a power-off request, the power management module 40 may wait for a preset time interval and then restart the system-level chip or domain controller according to the power-off request, thereby providing a time buffer for safe shutdown and data protection of the system.

[0074] In one embodiment, the system also includes: a fault storage module; a fault management module 20, which is also used to store the fault index corresponding to the fault identifier of the fault in the random access memory of the fault storage module after receiving the fault information; a power management module 40, which is also used to send a storage request to the fault storage module when receiving the power-off request; the fault storage module is used to store the data in the random access memory to the local non-volatile memory when receiving the storage request.

[0075] The fault storage module may be a module for storing relevant information of a fault occurring in the vehicle. The fault index may be an index value corresponding to a fault identifier, and different fault identifiers may correspond to different fault indexes. The storage request may be a request for storing fault information.

[0076] In this embodiment, after receiving the fault information, the fault management module 20 can also temporarily store the fault index corresponding to the fault identifier of the fault in the random access memory. After receiving the power-off 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-level chip or domain controller is powered off.

[0077] In one embodiment, the fault storage module is specifically used to: when receiving the storage request, write the data in the random access memory into the first storage error block in the local non-volatile memory; perform an OR operation on 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; wherein, the first storage error block is used to store fault data that occurs after the last system-level chip restart of the vehicle, and the second storage error block is used to store fault data that occurs during the life of the vehicle.

[0078] The non-volatile memory may include two different storage error blocks, the first storage error block may be used to store fault data that occurred after the last system-level chip restart, and the second storage error block may be used to store fault data that occurred during the entire life of the vehicle. The fault data may include information such as the fault index of the fault.

[0079] In this embodiment, the fault storage module can write the data in the random access memory into the first storage error block in the local non-volatile memory, and write the data that does not exist in the second storage error block but exists in the first storage error block into the second storage error block through an OR operation, and clear the data in the random access memory. This embodiment can locate the problem more accurately and reduce the risk of data loss by storing the fault data in the non-volatile memory; and when storing the fault data, it is not stored in the NVM immediately after the fault occurs, which can reduce the number of times the NVM is erased and written, and extend the service life of the NVM storage.

[0080] The embodiments of the present invention provide several specific implementation methods based on the technical solutions of the above embodiments.

[0081] As a specific implementation method of this embodiment, Figure 4 A schematic diagram of a fault management system based on intelligent driving provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, the system architecture is mainly composed of a fault monitoring group (monitor), a fault collection group (collector), a fault handling group (Handler), and a fault storage group (storage). Among them, all faults of the fault module will be 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). Status 0 represents fault recovery, and 1 represents fault occurrence. Only when the fault status code changes will the fault information be sent to the Safety Manager. This can reduce unnecessary resource consumption. The fault management module receives the error id and status. If the status is 1, the corresponding processing action is performed according to the fault response operation (Action) of the fault. If it is 0, it is processed according to the fault recovery process, and the fault information is stored in RAM according to the index. Before the SOC is powered off and before the MCU is powered off, the request is stored in the NVM.

[0082] The fault detection system of this embodiment defines a common fault list Faultlist, defines fields such as fault type (Error Type), fault name (Error Name), fault identifier (Error ID), debounce (Debounce), recovery identifier (Recovery), fault response operation (Action) and applicable project (For Project XXX), etc., which can distinguish whether the fault is applicable to a certain project, and provides a structured platform for fault classification, recording and processing, which facilitates the global management of fault information of all projects and reduces maintenance costs.

[0083] For example, Table 1 is a schematic diagram of a fault list, in which three faults are shown.

[0084] Table 1 Fault list

[0085]

[0086] Among them, SOC_TMON_ALERT_ERROR is a fault related to the temperature monitoring of the SOC, which means that the temperature of the SOC exceeds the preset warning threshold and an alarm is issued. The debounce time is 1 second, which means 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 triggers the corresponding operation according to action 0x01, that is, reporting errorid and status to the fault handling module for functional degradation. If the fault detection module monitors the fault recovery, it will send 0xA0000101status: 0 to the Safety Manager, and the Safety Manager reports 0xA0000101status: 0 to the fault handling module for functional recovery.

[0087] SOC_TMON_SHDN_ERROR is a fault related to SOC temperature monitoring, which means that the temperature of the SOC has reached a dangerous level, prompting the SOC to shut down to prevent chip damage. The debounce time is 1 second, which means 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 triggers the corresponding operation according to action 0x02, that is, reporting SOC status 1 to the fault handling module for functional degradation, and sending a power-off request to shut down the SOC to the power management module. After the SOC restarts, if the fault detection module monitors that the temperature returns to normal, it will send 0xA0000102status: 0 to the Safety Manager, and the Safety Manager reports SOC status 0 to the fault handling module for functional recovery.

[0088] MCU_TMON_SHDN_ERROR is a fault related to the temperature monitoring of the MCU. It means that the temperature of the MCU has reached a dangerous level, prompting the ADCU domain control system (i.e., the domain controller) to shut down to prevent chip damage. The debounce time is 1 second, which means 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 triggers the corresponding operation according to action 0x03, that is, reporting MCU status: 1 to the fault handling module for functional degradation, and sending a power-off request to the power management module to shut down the domain controller. Since the domain control system is reinitialized, all faults default to a non-fault state, and the function can be enabled normally.

[0089] Figure 5 A state machine diagram of a fault response provided by an embodiment of the present invention, such as Figure 5 As shown, this embodiment designs different levels of functional degradation (Degrade1, Degrade2, Degrade3). Figure 5 Describes the conversion logic of the system under different fault conditions. The system can gradually reduce functions according to the severity of the fault, rather than directly entering a completely shut down state. This hierarchical processing can improve the stability of the system and user experience. Among them, F1, F2, and F3 are common fault levels, system-level chip fault levels, and domain controller fault levels, respectively. The fault response operation corresponding to F1 can be 0x01, the fault response operation 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 the states and transitions in the state machine diagram:

[0091] For example, the transition from the Normal state to the Degraded 1 state is triggered by the activation of the F1 fault. The transition from Normal or Degrade1 to Degraded 2 (Degrade2) is triggered by the activation of the F2 fault. The transition from Normal or Degrade1 to Degraded 3 (Degrade3) is triggered by the activation of the F3 fault. The Degrade2 state triggers a SOC reset (i.e., the SOC is off). The Degrade3 state triggers a domain control system reset (i.e., an ADCU restart). Among them, the initialization mode (Init1) indicates that the domain control system is in initialization mode, which may be a reset caused by power-on (Keyon) or a hot start. At this stage, the output of the ADCU is disabled and the system is shut down.

[0092] The state machine diagram of this embodiment provides a clear view to show how the system responds and transforms its state when facing different fault conditions to ensure the stability and safety of the system. The fault management system can not only determine the fault level (F1, F2, F3), but also identify the recovery state of the fault, so that it can respond to the fault more flexibly, instead of just taking action when the fault occurs. The upper-layer application can perform fault downgrade and recovery according to the state of the error, making the function downgrade strategy more flexible while taking into account functional safety and user experience.

[0093] In this embodiment, different strategies are corresponding to different ACTIONs. Table 2 is a classification of fault response operations in this embodiment.

[0094] Table 2 Classification of fault response operations

[0095]

[0096] Among them, FSP (Fault Signaling Protocol) is a pin on the MCU, which is used to notify the peripheral control chip of its own fault status. Forced power-off simplifies the power-off process, and the safe power-off process will perform chip self-check. This embodiment defines different response measures according to the severity of the fault (F1, F2, F3 levels), and the upper-level application decides whether to exit the function or downgrade the function according to the actual impact scope. This hierarchical processing method improves the flexibility and adaptability of the system and minimizes the impact of faults. By defining the fault status code status of the fault and standardizing the fault information, the upper-level application can quickly downgrade and restore the function according to the fault status code.

[0097] For example, Figure 6 A schematic diagram of a fault recovery process provided by an embodiment of the present invention is shown in FIG. Figure 6 As shown in the figure, if a fault of level F1 (action 0x01) occurs: the fault management module notifies the fault handling module, and the fault handling module exits / downgrades the function according to the actual impact range; when the fault is restored, 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, and the fault management module notifies the fault handling module according to the action (0x01) of this fault, and the fault handling module exits the function affected by the fault 0xA000101. When the fault detection module n detects that the fault is restored, it sends 0xA000101status 0 to the fault management module, and the fault management module notifies the fault handling module according to the action (0x01) of this fault, and the fault handling module restores the function affected by the fault 0xA000101 and returns to the activatable state.

[0098] If a fault of level F2 (action 0x02 / 0x05) occurs, the fault management module sends SOC status 1, indicating that the SOC has a serious fault and is ready to shut down, and the fault handling module exits the function; when the SOC restarts, it continues to detect faults, and when the fault is restored, the fault management module sends SOC status 0 to the fault handling module to restore related functions. For example, if a fault identified by fault code 0xA000102 occurs, the fault detection module 1 sends 0xA000102status 1 to the fault management module. The fault management module sends SOC status 1 to the fault handling module according to the action (0x02) of this fault, and requests the power management module to shut down the SOC after a delay of 500ms. After receiving this notification, the fault handling module executes the exit of the relevant intelligent driving function. Before the SOC is powered off, the system will store 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 restored, the fault management module will then notify the fault handling module, which will restore the relevant intelligent driving functions that were previously exited.

[0099] If a fault of level F3 (action 0x03) occurs, the fault management module sends MCU status 1, indicating that the ADCU system has a serious fault and is ready to shut down, and the fault handling module exits the function; when 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 0xA000201status 1 to the fault management module. The fault management module sends MCUstatus 1 to the fault handling module according to the action (0x03) of this fault, and requests the power management module to shut down the MCU (domain controller) after a delay of 300ms. After receiving this notification, the fault handling module executes the exit of the relevant intelligent driving function. Before the MCU is powered off, the system will store the error block through NVM. After the MCU restarts, all faults default to the initial state and all functions are enabled by default.

[0100] Figure 7 A schematic diagram of storing fault data provided by an embodiment of the present invention is as follows: Figure 7 As shown, the NVM of this embodiment includes two 256-byte storage blocks Error_Block_Cur and Error_Block_His, which respectively store the fault data of the most recent SOC restart and all historical fault data. Before the MCU and the SOC are powered off, the fault data can be stored according to the fault index (error index) transmitted by the fault management module.

[0101] Figure 8 A schematic diagram of a data format of fault data provided by an embodiment of the present invention is shown in FIG. Figure 8 As shown, the data format of the fault data stored in the 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 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, starting from byte 5 and stored backward in sequence in a manner of one BIT representing one fault. The fault indexes 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.

[0102] This embodiment stores the faults that occur through NVM, providing important data for subsequent fault analysis and system optimization. Moreover, each fault index stored is mapped to 1 bit, which saves more space and improves storage efficiency compared to storing the fault name and fault identifier.

[0103] Fig. 9 A schematic diagram of reporting fault information provided by an embodiment of the present invention, Fig.10 A schematic diagram of another method for reporting fault information provided by an embodiment of the present invention is shown in FIG. Fig. 9 and 10 As shown, this embodiment reports a fault only when the state of the fault changes.

[0104] Fig.11 A schematic diagram of a fault storage module storing fault information provided by an embodiment of the present invention, such as Fig.11 As shown, cur00-cur15 corresponds to Error_Block_Cur in the non-volatile memory, and bak00-bak15 corresponds to Error_Block_His in the non-volatile memory.

[0105] Embodiment 3

[0106] Fig.12 This is a flow chart of a fault management method based on intelligent driving provided in Embodiment 3 of the present invention. The method can be applied to the situation of managing vehicle faults in the intelligent driving scenario, wherein the method can be implemented by a fault management system based on intelligent driving and is generally integrated on the vehicle. For the contents not yet fully described in this embodiment, please refer to the above embodiments.

[0107] like Fig.12 As shown, a fault management method based on intelligent driving provided by Embodiment 3 of the present invention includes the following steps:

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

[0109] The fault may be a fault of a module in the vehicle. The fault status code may be an identifier indicating the state of the fault, which may be used to determine whether the fault has occurred. The fault information may be relevant information of the fault, and the fault information may include a fault identifier and a fault status code, etc.

[0110] In this embodiment, a fault occurring in the vehicle may be detected by the fault detection module, and when it is determined that a fault status code corresponding to the fault has changed, fault information corresponding to the fault may be sent to the fault management module.

[0111] S320. Determine, by the fault management module, a fault handling result of the fault according to the fault information, and send the fault handling result to a fault handling module.

[0112] In this embodiment, the fault management module can analyze the fault information, obtain the fault handling result of the fault, and send the fault handling result to the fault handling module.

[0113] S330. Manage corresponding functions of the intelligent driving vehicle according to the fault handling result through the fault handling module.

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

[0115] This embodiment provides a fault management method based on intelligent driving, including: 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 by the fault detection module; the fault management module determines the fault processing result of the fault according to the fault information, and sends the fault processing result to the fault processing module; the fault processing module manages the corresponding function of the intelligent driving vehicle according to the fault processing result. By sending the 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 processing module manage the fault, which can reduce resource consumption and improve the real-time performance of fault processing, and solve the problems of resource waste and low real-time performance when processing faults occurring in intelligent driving in the prior art.

[0116] Furthermore, the fault information includes a fault identifier and a fault status code corresponding to the fault, and determining the fault handling result of the fault according to the fault information by the fault management module includes: searching for a corresponding fault response operation from a fault list according to the fault identifier; determining the fault handling result of the fault according to a fault level corresponding to the fault response operation and the fault status code; wherein the fault level includes a common fault level, a system-on-chip fault level, and a domain controller fault level.

[0117] Furthermore, the fault handling result of the fault is determined according to the fault level corresponding to the fault response operation and the fault status code, including: 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 used as the fault handling result of the fault; when the fault status code is a fault recovery code, the function to be restored is determined according to the fault level corresponding to the fault response operation, and restoring the function to be restored is used as the fault handling result of the fault.

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

[0119] Furthermore, the management of the corresponding functions of the intelligent driving vehicle according to the fault handling results by the fault handling module includes: function exit or function recovery of the corresponding functions of the intelligent driving vehicle according to the fault handling results; wherein the fault handling results include: function exit and function recovery of specified parts of functions, system-level chips or domain controllers.

[0120] Furthermore, the method also includes: when the fault management module determines that the fault handling result includes the function exit of the system-level chip or domain controller, sending a power-off request to the power management module; and restarting the system-level chip or domain controller according to the power-off request through the power management module.

[0121] Further, restarting the system-on-chip or the domain controller according to the power-off request through the power management module includes: when receiving the power-off request, after waiting for a preset time interval, restarting the system-on-chip or the domain controller according to the power-off request.

[0122] 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 in the random access memory of the fault storage module; when receiving the power-off request through the power management module, sending a storage request to the fault storage module; when receiving the storage request through the fault storage module, storing the data in the random access memory to the local non-volatile memory.

[0123] Furthermore, storing the data in the random access memory to a 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 the 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; clearing the data in the random access memory; wherein, the first storage error block is used to store fault data that occurs after the last system-level chip restart of the vehicle, and the second storage error block is used to store fault data that occurs during the life of the vehicle.

[0124] Embodiment 4

[0125] Fig.13 A schematic diagram of a vehicle 10 is shown that may be used to implement an embodiment of the present invention. The components shown herein, their connections and relationships, and their functions are provided as examples only, and are not intended to limit implementations of the inventions described and / or claimed herein.

[0126] like Fig.13 As shown, the vehicle 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the vehicle 10 can also be stored. The processor 11, ROM 12 and RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

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

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

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

[0130] Various implementations 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 chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0131] Computer programs for implementing the methods of the present invention 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, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0132] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, 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 foregoing.

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

[0134] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0135] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0136] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0137] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A fault management system based on intelligent driving, characterized in that: The system comprises: 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; The fault detection module is used to send the fault information corresponding to the detected 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 of the fault according to the fault information, and send the fault handling result to the fault handling module; The fault processing module is used to manage the corresponding functions of the intelligent driving vehicle according to the fault processing result.

2. The system according to claim 1, characterized in that The fault information includes a fault identifier and a fault status code corresponding to the fault, and the fault management module is specifically used to: Finding a corresponding fault response operation from a fault list according to the fault identifier; Determining a fault handling result of the fault according to the fault level corresponding to the fault response operation and the fault status code; The fault levels include common fault levels, system-on-chip fault levels and domain controller fault levels.

3. The system according to claim 2, characterized in that The fault management module is specifically used for: When the fault status code is a fault occurrence code, determining a function to be exited according to the fault level corresponding to the fault response operation, and taking exiting the function to be exited as a fault processing result of the fault; When the fault status code is a fault recovery code, the function to be restored is determined according to the fault level corresponding to the fault response operation, and restoration of the function to be restored is used as the fault processing result of the fault.

4. The system according to claim 2, characterized in that The fault list includes at least the following fields: Fault type, fault name, fault identification, debounce, recovery identification, fault response operation, and applicable items.

5. The system according to claim 1, characterized in that The fault processing module is specifically used for: Exit or restore the corresponding function of the intelligent driving vehicle according to the fault handling result; The fault handling result includes: function exit and function recovery of a specified part of functions, system-level chip or domain controller.

6. The system according to claim 1, characterized in that The system further comprises: a power management module; The fault management module is further configured to send a power-off request to the power management module when it is determined that the fault processing result includes a function exit of the system-level chip or the domain controller; The power management module is used to restart the system-on-chip or the domain controller according to the power-off request.

7. The system according to claim 6, characterized in that The power management module is specifically used for: When a power-off request is received, after waiting for a preset time interval, the system-on-chip or the domain controller is restarted according to the power-off request.

8. The system according to claim 6, characterized in that The system further comprises: a fault storage module; The fault management module is further configured to store the fault index corresponding to the fault identifier of the fault in the random access memory of the fault storage module after receiving the fault information; The power management module is further configured to send a storage request to the fault storage module upon receiving the power-off request; The fault storage module is used to store the data in the random access memory into a local non-volatile memory when receiving the storage request.

9. The system according to claim 8, characterized in that The fault storage module is specifically used for: When receiving the storage request, writing the data in the random access memory into a first storage error block in a local non-volatile memory; Performing an OR operation on the data in the first storage error block and the data in the 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; Clearing data in the random access memory; Among them, the first storage error block is used to store fault data that occurred after the last system-level chip restart of the vehicle, and the second storage error block is used to store fault data that occurred during the life of the vehicle.

10. A fault management method based on intelligent driving, characterized in that: The method is implemented by a fault management system based on intelligent driving according to any one of claims 1 to 9, and the method comprises: 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 by the fault detection module; Determine, by the fault management module, a fault handling result of the fault according to the fault information, and send the fault handling result to the fault handling module; The fault handling module manages the corresponding functions of the intelligent driving vehicle according to the fault handling results.

11. A vehicle, characterized in that: The vehicle comprises: at least one processor; and 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, and the computer program is executed by the at least one processor so that the at least one processor can execute the fault management method based on intelligent driving as described in claim 10.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to implement the fault management method based on intelligent driving described in claim 10 when executed by a processor.

Images