Fault processing system and method, and storage medium and electronic apparatus

By introducing a distributed fault handling system with fault management units and central fault management units in the automotive electronic and electrical architecture, the hardware design complexity and software processing load problems caused by centralized fault management are solved, and timely and efficient fault detection is achieved and handle.

WO2025001291A1PCT designated stage expired Publication Date: 2025-01-02SANECHIPS TECH CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/080581
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-06-25
Filing Date
2024-03-07
Publication Date
2025-01-02

Smart Images

  • Figure CN2024080581_02012025_PF_FP_ABST
    Figure CN2024080581_02012025_PF_FP_ABST
Patent Text Reader

Abstract

A fault processing system and method, and a storage medium and an electronic apparatus. The system comprises: a fault management unit, which is connected to a security domain system and is configured to, when a fault occurs in the security domain system, perform first fault processing on the fault which occurs in the security domain system, and when the accumulated number of executions of the first fault processing exceeds a preset threshold and the fault has not been processed successfully, send to a central fault management unit fault information of the fault which has not been processed successfully; and the central fault management unit, which is connected to both the fault management unit and a system reset management unit, and is configured to perform second fault processing on the fault according to the fault information.
Need to check novelty before this filing date? Find Prior Art

Description

Fault handling system and method, storage medium, and electronic device

[0001] This disclosure claims priority to the Chinese patent application filed with the China Patent Office on June 25, 2023, with application number 202310757251.3 and invention name “Fault handling system and method, storage medium, electronic device,” the entire contents of which are incorporated by reference into this disclosure. Technical Field

[0002] The embodiments of the present disclosure relate to the field of automotive electronic functional safety technology, and more specifically, to a fault handling system and method, a storage medium, and an electronic device. Background Art

[0003] To meet increasingly complex application scenarios, automotive chipsets within current electrical / electronic architecture (E / E) systems are trending towards large-scale integration. This poses significant challenges to the design of functional safety architectures within these chipsets. The commonly used fault management approach in automotive chipsets currently utilizes a centralized fault management architecture, requiring centralized processing of fault management signals from all subsystems within the chip. This significantly complicates the design and physical implementation of the chip's hardware architecture, placing a significant processing load on the chip's operating software, hindering timely fault detection and resolution.

[0004] With respect to the problem in related technologies that faults cannot be detected and processed in a timely manner, no effective solution has been proposed.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a fault handling system and method, and a storage medium electronic device, to at least solve the problem in the related art that faults cannot be detected and handled in a timely manner.

[0007] According to one embodiment of the present disclosure, a fault handling system is provided, including: a fault management unit, connected to a security domain system, configured to perform a first fault handling on the fault occurring in the security domain system when a fault occurs in the security domain system, and to send fault information of the unhandled fault to a central fault management unit when the cumulative number of executions of the first fault handling exceeds a preset threshold and the fault is not handled successfully; the central fault management unit is respectively connected to the fault management unit and a system reset management unit, and configured to perform a second fault handling on the fault based on the fault information.

[0008] According to another embodiment of the present disclosure, a fault handling method is also provided, including: in the event that a fault occurs in the security domain system, performing a first fault handling on the fault occurring in the security domain system by the fault handling unit; in the event that the cumulative number of executions of the first fault handling exceeds a preset threshold and the fault is not handled successfully, obtaining fault information of the unhandled fault by the central fault handling unit; and performing a second fault handling on the fault according to the fault information by the central fault handling unit.

[0009] According to another aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program, wherein the program executes the fault handling method described in the above claims when running.

[0010] According to another aspect of an embodiment of the present disclosure, an electronic device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the above-mentioned fault handling method through the computer program. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0012] FIG1 is a schematic structural diagram of a fault handling system according to an embodiment of the present disclosure;

[0013] FIG2 is a schematic diagram of a fault handling system according to an optional embodiment of the present disclosure;

[0014] FIG3 is a schematic structural diagram of a fault management unit according to an embodiment of the present disclosure;

[0015] FIG4 is a schematic diagram of a hardware environment of a chip according to a fault handling method according to an embodiment of the present disclosure;

[0016] FIG5 is a flowchart of a fault handling method according to an embodiment of the present disclosure;

[0017] FIG6 is a flowchart of a fault handling method according to an optional embodiment of the present disclosure;

[0018] FIG7 is a schematic diagram of a fault handling device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the embodiments described are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present disclosure.

[0020] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure 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 numbers used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof 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.

[0021] Automotive functions are particularly important for the safety of safety-related E / E systems in the automotive field. When developing automotive E / E systems, including software and controller hardware, automotive engineers inevitably make mistakes or errors, which can cause system functional failures, leading to malfunctions and potentially harmful consequences. These failures caused by human error are considered systemic failures. Controller hardware failures due to aging or external environmental factors can also lead to corresponding malfunctions and potentially harmful consequences. Hardware failures are random and follow a certain probability distribution, hence the name "random hardware failures."

[0022] To prevent these two types of failures in automotive E / E systems, the concept of functional safety was developed. Currently, automotive functional safety design generally adheres to the ISO 26262 standard, which is derived from the IEC 61508 standard. This standard primarily targets automotive-specific electrical components, electronic devices, programmable electronic devices, integrated circuit chips, and other components specifically used in the automotive field. It aims to raise international standards for the functional safety of automotive electronic and electrical products.

[0023] ISO 26262 is based on the V-model. Automotive functional safety development activities begin in the concept phase, which primarily includes definition of relevant items, hazard analysis and risk assessment, and functional safety solution development. Based on the hazard risk assessment, the system or system component is assigned a required Automotive Safety Integrity Level (ASIL), ensuring that the system product's functional safety meets automotive safety requirements. ASIL is typically categorized into four levels: A, B, C, and D, with D being the highest safety level and A the lowest. Similar hazard events are then grouped and categorized to derive safety goals. If similar safety goals are derived, they can be merged to inherit the highest ASIL level. The safety requirements of automotive E / E systems determine the ASIL level. Higher ASIL levels correspond to greater implementation costs (e.g., R&D costs, development cycle, and technical requirements) for safety measures, as well as higher diagnostic coverage. In the ISO 26262 standard, achieving ASIL-D requires single-point fault metrics and multi-point fault metrics to be greater than or equal to 99% and 90%, respectively. Therefore, implementing functional safety in automotive E / E systems is complex and challenging.

[0024] In order to meet the requirements of functional safety, the onboard chips in the automotive E / E system will be designed with corresponding software and hardware safety mechanisms to prevent systematic failures or random hardware failures. Safety mechanisms are very important technical means to ensure the functional safety of onboard chip systems. For example, hardware redundancy, memory signatures, error correction codes (ECC), parity checks (Parity), cyclic redundancy checks (CRC), clock monitoring, voltage monitoring, and safe state import. The safety mechanism needs to detect the fault in a timely manner when the system fails and report it to the system so that the system can respond to the fault according to the type of fault and the degree of fault damage, thereby avoiding the occurrence of latent faults or the harmful effects directly caused by the fault.

[0025] In the related art, the design of onboard chips in current automotive E / E systems tends to be large-scale integrated to meet increasingly complex application scenarios. This poses a significant challenge to the design of functional safety architectures in onboard chips. Currently, the commonly used fault management method in onboard chips is a centralized fault management architecture. Fault management signals from all subsystems within the chip require centralized processing by the system, which greatly complicates the hardware architecture design and physical implementation of the chip. It also places a heavy processing load on the chip's operating software, making it impossible to detect and handle faults in a timely manner. To this end, the present disclosure provides a fault handling system and method, a storage medium, and an electronic device.

[0026] This embodiment provides a fault handling system that can be applied to chips, such as in-vehicle chips, including but not limited to in-vehicle central gateway chips, in-vehicle smart cockpit chips, etc. As shown in Figure 1, the system includes: a fault management unit 120 and a central fault management unit 140, wherein:

[0027] The fault management unit 120 is connected to the security domain system 160 and is configured to perform a first fault processing on the fault of the security domain system 160 when a fault occurs in the security domain system 160, and send fault information of the unsuccessfully processed fault to the central fault management unit 140 if the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed.

[0028] The central fault management unit 140 is connected to the fault management unit 120 and the system reset management unit 180 respectively, and is configured to perform a second fault process on the fault according to the fault information.

[0029] According to the fault handling system of the disclosed embodiment, a fault management unit performs a first fault handling process on a fault occurring in the security domain system. If the cumulative number of executions of the first fault handling process exceeds a preset threshold and the fault is not successfully handled, the fault information of the unhandled fault is sent to the central fault management unit. Upon receiving the fault information of the unhandled fault, the central fault management unit performs a second fault handling process on the fault information. This system solves the problem of the prior art in being unable to detect and handle faults in a timely manner. By providing a fault management unit and a central fault management unit, the system achieves the effect of timely fault detection and handling.

[0030] To avoid the detection load on the fault management unit caused by centralized fault management, as shown in Figure 2, in an embodiment of the present disclosure, the fault management unit 120 includes multiple fault management subunits, and the security domain system 160 includes multiple security domain subsystems. The number of fault management subunits is equal to the number of security domain subsystems, and the security domain subsystems are connected one-to-one with the fault management subunits. Furthermore, through the one-to-one connection between the security domain subsystems and the fault management subunits, an independent fault management subunit can be configured for each security domain subsystem, enabling real-time fault detection and handling for each security domain subsystem. Furthermore, by configuring an independent fault management subunit for each security domain subsystem, faults occurring in each security domain subsystem within the chip can be accurately located and responded to. This avoids the significant difficulties in the chip's hardware architecture design and physical implementation caused by centralized management of all security domain subsystems within the chip, which can also result in a high processing load on the chip's operating software, hindering the design and implementation of functional safety chips with high efficiency, high coverage, and timely fault handling response.

[0031] Among them, the security domain system 160 is configured to process and control functional data. For example, N security domain subsystems with different functions are designed inside the chip according to different application function requirements. For example, the N security domain subsystems with different functions include a security domain subsystem of a low-latency controller area network (Controller Area Network, abbreviated as CAN) / local area network interconnect (Local Interconnect Network, abbreviated as LIN) communication engine, a security domain subsystem of a network switching hardware engine, a security domain subsystem of a functional safety peripheral interface, a security domain subsystem of an on-chip storage controller, a security domain subsystem of a peripheral component interconnect express (PCIE), a security domain subsystem of a double data rate (DDR), etc.

[0032] In an embodiment of the present disclosure, the fault management unit 120 is configured to determine the level of fault information and / or the type of fault information of the fault that has occurred when a fault occurs in the security domain system; and perform a first fault processing according to the level of the fault information and / or the type of the fault information.

[0033] Among them, the level of fault information can be determined based on a preset database, wherein the preset database includes data information and the level corresponding to the data information. For example, when it is determined that a fault occurs in the security domain system, the security domain subsystem in the security domain system where the fault occurs can be determined, and then the data information corresponding to the security domain subsystem where the fault occurs can be determined, so that the level corresponding to the data information of the fault can be obtained from the preset database; the level of fault information can also be determined based on the scope of fault impact, for example, when the fault affects fewer users, the level of fault information is determined to be low, and when the fault affects more users, the level of fault information is determined to be high; the level of fault information can also be determined based on the display value of the fault information, for example, when the display value is 1, the level of the fault information is determined to be high.

[0034] The type of fault information can be determined based on the fault information's attribute information; the type of fault information can also be determined based on the fault manifestation of the fault information; or the type of fault information can be determined based on the fault signal reported by the security domain system. For example, when the type of fault information is determined based on the fault information's attribute information or the fault manifestation of the fault information, the fault information types include, but are not limited to, mechanical faults, electrical faults, brake faults, steering faults, tire faults, and the like. For another example, when the type of fault information is determined based on the fault signal reported by the security domain system, the fault information types include shared safety mechanism fault types and non-shared safety mechanism fault types. A shared safety mechanism fault can be understood as a data communication fault between security domain subsystems in a security domain system; a non-shared safety mechanism fault type can be understood as a fault in the safety mechanism of each security domain subsystem in the security domain subsystem.

[0035] Prioritize high-level fault information. Once the high-level faults are processed, low-level fault information can be processed. For example, safety-related faults can be classified as high-level faults, while non-safety-related faults can be classified as low-level faults. It should be noted that when processing low-level fault information, if a high-level fault is detected, the high-level fault will be processed first.

[0036] In the embodiments of the present disclosure, the first fault handling includes, but is not limited to, resetting, restarting or shutting down the power supply, replacing a light bulb, etc. Specifically, the first fault handling method for a fault with a high-level fault message is resetting, while the first fault handling method for a fault with a low-level fault message is not resetting. That is, the first fault handling method is to determine the type of the low-level fault message. For example, if the fault message is determined to be a tire fault, the sensor is used to determine that the tire pressure is insufficient, and the tire is then inflated.

[0037] In an embodiment of the present disclosure, the fault management unit 120 is configured to perform the first fault management on the fault again if it determines that the first fault processing is not successful, and obtain the cumulative number of executions of the first fault management and determine whether the cumulative number of executions exceeds a preset threshold.

[0038] That is, when the fault management unit 120 performs the first fault processing on the fault that occurs, it can determine whether the first fault processing is successful. If it is determined that the first fault processing is not successful, it can perform the first fault processing on the fault again.

[0039] Among them, it is possible to determine whether the first fault handling is successful based on running the test within a preset time. For example, after the first fault handling is performed on the fault, the security domain subsystem corresponding to the fault can be restarted, and the security domain subsystem can be detected to determine whether the last fault occurred within the preset time. If the last fault occurred, it is determined that the first fault handling was not successful. If the last fault did not occur, it is determined that the first fault handling was successful. It is also possible to determine whether the first fault handling is successful based on the restart function. For example, if it is determined that the fault type of the fault is the headlights, the headlights can be restarted. After restarting, if the headlights are normal, it is determined that the first fault handling is successful. If the headlights are abnormal, it is determined that the first fault handling was not successful.

[0040] In order to make it easier for those skilled in the art to understand the detection of the security domain system by the fault management unit in the present disclosure, that is, the real-time detection of the security domain subsystem by the fault management subunit, the optional embodiments of the present disclosure are explained in the following manner.

[0041] For example, taking a fault management subunit detecting the corresponding security domain subsystem as an example, as shown in FIG3 , the fault management subunit includes an online hardware self-test module 302, a communication interface module 304, a fault injection module 306, a fault recording module 308, a fault collection and control module 310, a fault processing interface module 312, a fault processing monitoring module 314, and a security domain subsystem 316. Among them, the online self-test module 302 is connected to the corresponding security domain subsystem 316, and is responsible for the logic built-in self-test (LBIST) and memory built-in self-test (MBIST) of the security domain subsystem 316. Self-Test, MBIST); the communication interface module 304 is connected to the fault management communication bus 1110, and is responsible for transmitting the configuration information and fault information of the fault management subunit; the fault injection module 306 is connected to the corresponding security domain subsystem 316, and is responsible for the fault injection test of the internal memory security mechanism, hardware redundancy safety mechanism, and custom safety mechanism of the corresponding security domain subsystem 316; the fault recording module 308 is connected to the corresponding security domain subsystem 316, and is responsible for recording the fault information of the internal memory security mechanism, hardware redundancy safety mechanism, and custom safety mechanism of the corresponding security domain subsystem 316; the fault collection and control module 310 is connected to the corresponding security domain subsystem 316, the fault handling interface module 312, The fault handling monitoring module 314 is connected to the corresponding security domain subsystem 316 and is responsible for collecting all faults within the corresponding security domain subsystem 316 and performing system management based on fault type. The fault handling interface module 312 is connected to the corresponding security domain subsystem 316, the fault collection and control module 310, and the fault handling monitoring module 314. It is responsible for receiving fault handling signals from the fault collection and control module 310 and then outputting them to the corresponding security domain subsystem 316 and the fault handling monitoring module 314. The fault handling monitoring module 314 is connected to the corresponding security domain subsystem 316, the fault collection and control module 310, and the fault handling interface module 312. As a safety mechanism for the fault collection and control module 310, it monitors the fault handling of the fault collection and control module 310. This enables the fault management subunit to detect, record, and handle faults in the connected security domain subsystem in real time.

[0042] Because the security domain subsystem 316 includes a logic component and a storage component, each security domain subsystem 316 corresponds to a security mechanism. Therefore, the online hardware self-test module 302 detects potential faults in the security mechanism. After the security domain subsystem 316 is powered on, the online hardware self-test module 302 detects whether the chip hardware is faulty. This involves testing the chip's logic, which automatically generates test vectors, outputs these test vectors, and compares the outputs with expected outputs. Testing the chip's storage involves self-testing the chip's embedded memory. Because embedded memory is deeply embedded in the chip's logic, it cannot be directly tested through external stimulation. Therefore, a circuit must be designed into the chip to automatically self-test the embedded memory.

[0043] Among them, the fault injection module 306 performs a fault injection test on the internal security mechanism of the security domain subsystem 316. The security mechanism is designed to detect certain faults, but the security mechanism itself may also have problems. Therefore, the fault injection module 306 is used to test the security mechanism. For example, detecting a fault in the internal memory security mechanism of the security domain subsystem 316 can be achieved by obtaining a one-bit signal and a multi-bit signal from the internal memory of the security domain subsystem 316, and simulating the two-bit errors based on the one-bit signal and the multi-bit signal to determine whether the internal memory security mechanism of the security domain subsystem 316 reports the two-bit errors. If the two-bit errors are reported, it indicates that the internal memory security mechanism of the security domain subsystem 316 is normal, that is, the internal memory security mechanism of the security domain subsystem 316 has not failed. If the two-bit errors are not reported, it indicates that the internal memory security mechanism of the security domain subsystem 316 has a problem, that is, the internal memory security mechanism of the security domain subsystem 316 has failed.

[0044] In an embodiment of the present disclosure, the central fault management unit 140 is configured to determine that the fault of the target security domain subsystem has not been successfully handled based on the fault information, and send a reset instruction to the system reset management unit 180; the system reset management unit 280 is configured to reset the target security domain subsystem according to the reset instruction, obtain the reset result of the target security domain subsystem, and send the reset result to the central fault management unit.

[0045] Here, reset can be understood as restoring factory settings.

[0046] The central fault management unit 140 is configured to control the fault handling system to power off if the reset result indicates that the target security domain subsystem is not reset successfully. For example, after the fault system is powered off, the fault can be reported for repair based on the fault type.

[0047] Among them, when the reset result indicates that the target security domain subsystem is reset successfully, fault detection is performed on the security domain system in real time.

[0048] The central fault management unit 140 is configured to determine the type of fault information based on the fault information, and if the fault information type is determined to be a shared security mechanism fault type, perform a second fault handling procedure on the fault according to the corresponding handling method for the shared security mechanism fault type. That is, if a fault occurs in the security domain system, the fault type of the fault can be determined. If the fault type is determined to be a shared security mechanism fault type, this indicates that the fault management unit does not have the authority to handle faults of the shared security mechanism fault type, and therefore a higher-level central fault management unit is required to perform fault handling. For example, if it is determined that the shared storage between the first security domain subsystem and the second security domain subsystem has failed, the central fault management unit can accurately determine that the failed shared storage is located in the first security domain subsystem, and therefore can replace the storage path, that is, store the data of the shared storage in the second security domain subsystem.

[0049] In order to make the fault handling system more perfect, as shown in Figure 2, the fault handling system also includes a fault management communication bus 1110, an application domain processor system 1112, a system storage unit 1114, a system bus 1116, and a security domain processor system 1118, wherein: the application domain processor system 1112 is connected to the system bus 1116, the system storage unit 1114 is connected to the system bus 1116, the security domain system 160 is connected to the system bus 1116 and the fault management unit 120, the fault management unit 120 is connected to the security domain system 160 and the fault management communication bus 1110, the security domain processor system 1118 is connected to the fault management communication bus 1110, the central fault management unit 140 is connected to the fault management communication bus 1110 and the system reset management unit 180, and the system reset management unit 180 is connected to the central fault management unit 140.

[0050] Among them, the application domain processor system 1112 is responsible for non-functional safety data processing and control, and can be implemented using a high-performance CPU system. For example, high-performance CPU models include ARM Cortex-A53, ARM Cortex-A57, ARM Cortex-A72, etc.

[0051] The system storage unit 1114 is responsible for providing a cache for system data and is implemented using an on-chip SRAM (Static Random-Access Memory, SRAM) memory.

[0052] Among them, the system bus 1116 is responsible for providing a data transmission path between the application domain processor system 1112, the system storage unit 1114 and the security domain system 160. It can be implemented using a high-performance NIC or NOC bus topology. For example, the high-performance NIC bus is ARM CoreLink NIC-400, and the high-performance NOC bus is Arteris FlexNoC. The communication protocol can adopt a high-performance bus protocol, such as AXI, AHB, etc.

[0053] Among them, the fault management communication bus 1110 is responsible for providing fault management configuration information and data transmission paths between the security domain processor system 1118, the fault management unit 120 and the central fault management unit 140. It can be implemented using high-performance NIC and NOC bus topology structures. For example, the high-performance NIC bus is ARM CoreLink NIC-400, and the high-performance NOC bus is Arteris FlexNoC, etc. The communication protocol can adopt AXI-lite, AHB-lite, APB, etc.

[0054] Among them, the security domain processor system 1118 is responsible for functional safety data processing and control, and is implemented using a CPU system that can provide real-time functional safety performance. For example, full-performance CPU models include ARM Cortex-MO, ARM Cortex-M7, ARM Cortex-R5, ARM Cortex-R52, etc.

[0055] According to the fault handling system of the embodiment of the present disclosure, hierarchical and graded processing of internal faults of the on-board chip is performed through a functional safety architecture composed of a distributed fault management unit, a central fault management unit, a safety domain system, a system reset management unit, a fault management communication bus, an application domain processor system, a system storage unit, a system bus, and a safety domain processor system. This reduces the transmission path of fault signals within the chip and reduces the complexity of the chip hardware architecture design and physical implementation, thereby improving the speed and energy efficiency of the chip. Moreover, based on equipping each safety domain subsystem with an independent fault management unit, fault detection can be performed in real time and fault processing and fault information reporting can be performed according to the level of the fault information that has occurred, thereby ensuring accurate positioning and response to faults occurring in each safety domain subsystem within the chip, effectively reducing the load of centralized fault detection, and can detect and process faults efficiently and promptly. Reasonable fault handling measures are adopted for detected faults, and the availability of the chip system is improved when a fault occurs, thereby improving the safety of the system.

[0056] According to one aspect of an embodiment of the present disclosure, a fault handling method is provided. The fault handling method can be executed in a chip. Take running on a chip as an example. Figure 4 is a hardware structure block diagram of a chip of a fault handling method according to an embodiment of the present disclosure. As shown in Figure 4, the chip may include one or more (only one is shown in Figure 4) processors 402 (the processor 402 may include but is not limited to a microprocessor (Microprocessor Unit, abbreviated as MPU) or a programmable logic device (Programmable logic device, abbreviated as PLD)) and a memory 404 configured to store data. In an exemplary embodiment, the above-mentioned chip may also include a transmission device 406 configured to have a communication function and an input and output device 408. It will be understood by those skilled in the art that the structure shown in Figure 4 is only for illustration and does not limit the structure of the above-mentioned chip. For example, the chip may also include more or fewer components than those shown in Figure 4, or a different configuration having the same function as that shown in Figure 4 or more functions than those shown in Figure 4.

[0057] The memory 404 can be configured to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the fault handling system in the embodiment of the present disclosure. The processor 402 executes various functional applications and data processing by running the computer program stored in the memory 404, that is, implementing the above-mentioned method. The memory 404 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 404 may further include a memory remotely located relative to the processor 402, and these remote memories may be connected to the chip via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0058] Transmission device 406 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communications provider of the switching device. In one embodiment, transmission device 406 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 406 may be a radio frequency (RF) module configured to communicate with the Internet wirelessly.

[0059] FIG5 is a flow chart of a fault handling method according to an embodiment of the present disclosure, which is applied to the above chip. As shown in FIG5 , the fault handling method includes:

[0060] Step 520: When a fault occurs in the security domain system, a fault processing unit performs a first fault processing on the fault occurring in the security domain system.

[0061] Among them, the fault management unit includes: multiple fault management sub-units, and the security domain system includes: multiple security domain subsystems; among them, the number of multiple fault management sub-units is the same as the number of multiple security domain subsystems, and the security domain subsystems are connected to the fault management sub-units in a one-to-one correspondence.

[0062] In an embodiment of the present disclosure, multiple fault management subunits can detect corresponding multiple security domain subsystems in real time. When a fault occurs in a security domain subsystem, the fault management subunit can perform a first fault processing on the fault occurring in the security domain subsystem.

[0063] Wherein, when a fault occurs in the security domain subsystem, the level of fault information and / or the type of fault information is determined, and then the first fault processing is performed according to the level of the fault information and / or the type of the fault information.

[0064] Step 540 : When the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed, the central fault processing unit obtains fault information of the unsuccessfully processed fault.

[0065] In an embodiment of the present disclosure, when the first fault processing is performed according to the level of fault information and / or the type of fault information, it can be determined whether the first fault processing is successful. When it is determined that the first fault processing is unsuccessful, the first fault processing is performed again on the fault, and the cumulative number of executions of the first fault processing is obtained and it is determined whether the cumulative number of executions exceeds a preset threshold. When the cumulative number of executions of the first fault processing exceeds the preset threshold and the fault is not successfully processed, the unsuccessful fault is sent to the central fault processing unit so that the central fault processing unit obtains the unsuccessful fault information.

[0066] In one embodiment of the present disclosure, when it is determined that the type of fault information is a shared safety mechanism fault type, the shared safety mechanism fault type is sent to the central fault management unit so that the central fault management unit performs a second fault processing on the fault according to the processing method corresponding to the shared safety mechanism fault type.

[0067] Step 560: The central fault processing unit performs a second fault processing on the fault according to the fault information.

[0068] In an embodiment of the present disclosure, when the central fault processing unit obtains unprocessed fault information, it determines the target security domain subsystem corresponding to the unprocessed fault information, and based on the connection between the central fault management unit and the system reset management unit, sends a reset instruction to the system reset management unit so that the system reset management unit resets the target security domain subsystem according to the reset instruction, obtains the reset result of the target security domain subsystem, and sends the reset result to the central fault management unit.

[0069] The central fault management unit receives the reset result, and when the reset result indicates that the target security domain subsystem is not reset successfully, controls the fault handling system to power off.

[0070] In one embodiment of the present disclosure, the type of the fault information is determined, and when it is determined that the type of the fault information is a shared safety mechanism fault type, the second fault processing is performed on the fault according to the processing method corresponding to the shared safety mechanism fault type.

[0071] In an optional embodiment of the present disclosure, for example, taking the application scenario of the fault handling method as an on-board central gateway chip as an example, as shown in FIG6 :

[0072] Step 1: During chip operation, perform real-time fault detection on the security mechanism within each security domain subsystem;

[0073] Step 2: The security mechanism within the security domain subsystem detects a fault in the security domain subsystem, and the fault management subunit corresponding to the security domain subsystem identifies the fault type.

[0074] Step 3: The fault management subunit corresponding to the security domain subsystem performs the first fault processing;

[0075] Step 4 determines whether the first fault handling is successful. If successful, proceed to step 1; if unsuccessful, proceed to step 5.

[0076] Step 5: The fault management subunit corresponding to the security domain subsystem performs a fault processing retry, obtains the number of fault processing retries, and determines whether the number of retries exceeds the preset number of retries. If the number of retries exceeds the preset number of retries, the process proceeds to step 4; if the number of retries does not exceed the preset number of retries, the process proceeds to step 6.

[0077] Step 6: The fault management subunit corresponding to the security domain subsystem reports the unsuccessfully processed fault information to the central fault management unit, so that the central fault management unit performs a second fault processing on the unsuccessfully processed fault;

[0078] Step 7: Determine whether the second fault handling is successful. If it is determined that the second fault handling is successful, proceed to step 1. If it is determined that the second fault handling is not successful, otherwise proceed to step 8.

[0079] Step 8: The control system enters a safe state.

[0080] According to the fault handling method of the disclosed embodiment, a fault management unit performs a first fault handling procedure on a fault occurring in the security domain system. If the cumulative number of executions of the first fault handling procedure exceeds a preset threshold and the fault is not successfully handled, fault information about the unhandled fault is sent to a central fault management unit. Upon receiving the fault information about the unhandled fault, the central fault management unit performs a second fault handling procedure on the fault information. By providing both a fault management unit and a central fault management unit, this system achieves the effect of timely fault detection and handling.

[0081] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present disclosure.

[0082] FIG7 is a structural block diagram of a fault handling device according to an embodiment of the present disclosure; as shown in FIG7 , the device includes:

[0083] The first processing module 720 is configured to perform a first fault processing on the fault occurring in the security domain system through the fault processing unit when a fault occurs in the security domain system;

[0084] An acquisition module 740 is configured to acquire, through the central fault processing unit, fault information of the unsuccessfully processed fault if the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed;

[0085] The second processing module 760 is configured to perform a second fault processing on the fault according to the fault information through the central fault processing unit.

[0086] With the above-described device, based on the first processing module, when a fault occurs in the security domain system, the fault handling unit performs a first fault handling on the fault occurring in the security domain system. Based on the acquisition module, if the cumulative number of executions of the first fault handling exceeds a preset threshold and the fault is not successfully handled, the central fault handling unit obtains fault information of the unhandled fault. Based on the second processing module, the central fault handling unit performs a second fault handling on the fault based on the fault information. By providing the fault management unit and the central fault management unit, this system effectively reduces the load of centralized fault detection and handling, and achieves efficient and timely fault detection and handling.

[0087] In an exemplary embodiment, the fault management unit includes: multiple fault management sub-units, and the security domain system includes: multiple security domain subsystems; wherein the number of the multiple fault management sub-units is the same as the number of the multiple security domain subsystems, and the security domain subsystems are connected to the fault management sub-units in a one-to-one correspondence.

[0088] In an exemplary embodiment, the first processing module 720 is configured to determine the level of fault information and / or the type of fault information that has occurred when a fault occurs in the security domain system; and perform the first fault processing according to the level of the fault information and / or the type of the fault information.

[0089] In an exemplary embodiment, the acquisition module 740 is configured to perform the first fault management on the fault again if it is determined that the first fault handling is not successful, and obtain the cumulative number of executions of the first fault management and determine whether the cumulative number of executions exceeds the preset threshold.

[0090] In an exemplary embodiment, the second processing module 760 is configured to determine that the fault of the target security domain subsystem has not been successfully handled based on the fault information, and send a reset instruction to the system reset management unit; the system reset management unit is configured to reset the target security domain subsystem according to the reset instruction, obtain the reset result of the target security domain subsystem, and send the reset result to the central fault management unit.

[0091] In an exemplary embodiment, the second processing module 760 is configured to control the fault processing system to power off when the reset result indicates that the target security domain subsystem is not reset successfully.

[0092] In an exemplary embodiment, the second processing module 760 is configured to determine the type of the fault information based on the fault information, and, if the type of the fault information is determined to be a shared safety mechanism fault type, perform the second fault processing on the fault according to the processing method corresponding to the shared safety mechanism fault type. Embodiments of the present disclosure also provide a storage medium including a stored program, wherein the program, when executed, executes any of the aforementioned methods.

[0093] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0094] S1, when a fault occurs in the security domain system, performing a first fault processing on the fault occurring in the security domain system by the fault processing unit;

[0095] S2, when the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed, obtaining fault information of the unsuccessfully processed fault through the central fault processing unit;

[0096] S3: Performing a second fault processing on the fault according to the fault information by the central fault processing unit.

[0097] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0098] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0099] Optionally, in this embodiment, the processor may be configured to execute the following steps through a computer program:

[0100] S1, when a fault occurs in the security domain system, performing a first fault processing on the fault occurring in the security domain system by the fault processing unit;

[0101] S2, when the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed, obtaining fault information of the unsuccessfully processed fault through the central fault processing unit;

[0102] S3: Performing a second fault processing on the fault according to the fault information by the central fault processing unit.

[0103] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0104] Optionally, specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0105] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices. Alternatively, they can be implemented using program code executable by the computing device, so that they can be stored in a storage device and executed by the computing device. In some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0106] The above is only a preferred embodiment of the present disclosure. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present disclosure. These improvements and modifications should also be regarded as within the scope of protection of the present disclosure.

Claims

1. A fault handling system, comprising: a fault management unit connected to the security domain system and configured to, in the event that a fault occurs in the security domain system, perform a first fault processing on the fault occurring in the security domain system, and, in the event that a cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed, send fault information of the unsuccessfully processed fault to the central fault management unit; The central fault management unit is connected to the fault management unit and the system reset management unit respectively, and is configured to perform a second fault processing on the fault according to the fault information.

2. The fault handling system according to claim 1, wherein: The fault management unit includes: a plurality of fault management sub-units, and the security domain system includes: a plurality of security domain sub-systems; wherein, The number of the multiple fault management subunits is the same as the number of the multiple security domain subsystems, and the security domain subsystems are connected to the fault management subunits in a one-to-one correspondence.

3. The fault handling system according to claim 1, wherein: The fault management unit is configured to determine, when a fault occurs in the security domain system, a level of fault information of the fault that has occurred and / or a type of the fault information; The first fault processing is performed according to the level of the fault information and / or the type of the fault information.

4. The fault handling system according to claim 1, wherein: The fault management unit is configured to, if it is determined that the first fault handling has not been successfully handled, perform the first fault management on the fault again, obtain the cumulative number of executions of the first fault management and determine whether the cumulative number of executions exceeds the preset threshold.

5. The fault handling system according to claim 2, wherein: The central fault management unit is configured to determine, based on the fault information, that the fault of the target security domain subsystem has not been successfully handled, and send a reset instruction to the system reset management unit; The system reset management unit is configured to reset the target security domain subsystem according to the reset instruction, obtain the reset result of the target security domain subsystem, and send the reset result to the central fault management unit.

6. The fault handling system according to claim 5, wherein: The central fault management unit is configured to control the fault handling system to power off when the reset result indicates that the target security domain subsystem is not reset successfully.

7. The fault handling system according to claim 1, wherein: The central fault management unit is configured to determine the type of the fault information according to the fault information, and when determining that the type of the fault information is a shared safety mechanism fault type, perform the second fault processing on the fault according to the processing method corresponding to the shared safety mechanism fault type.

8. A fault handling method, applied to the fault handling system according to any one of claims 1 to 7, comprising: In the event that a fault occurs in the security domain system, performing a first fault processing on the fault occurring in the security domain system by the fault processing unit; When the cumulative number of executions of the first fault processing exceeds a preset threshold and the fault is not successfully processed, obtaining fault information of the fault that is not successfully processed through the central fault processing unit; The central fault processing unit performs a second fault processing on the fault according to the fault information.

9. The fault handling method according to claim 8, wherein: The fault management unit includes: a plurality of fault management sub-units, and the security domain system includes: a plurality of security domain sub-systems; wherein, The number of the multiple fault management subunits is the same as the number of the multiple security domain subsystems, and the security domain subsystems are connected to the fault management subunits in a one-to-one correspondence.

10. The fault handling method according to claim 8, wherein: Performing a first fault processing on the fault occurring in the security domain system includes: In the event of a failure in the security domain system, determining a level of failure information of the failure and / or a type of the failure information; The first fault processing is performed according to the level of the fault information and / or the type of the fault information.

11. A computer-readable storage medium, the computer-readable storage medium comprising a stored program, wherein: When the program is running, the fault handling method described in any one of claims 8 to 10 is executed.

12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the fault handling method described in any one of claims 8 to 10 through the computer program.

Citation Information

Patent Citations

  • Transient fault processing method and system of vehicle bus control system and vehicle

    CN102975670A

  • Fault management system for vehicle-specification-level chip function safety

    CN110955571A

  • Vehicle fault grading processing method, device and equipment and readable storage medium

    CN114967642A

  • System fault processing method, central arithmetic unit and vehicle

    CN115237644A

  • System and method for vehicle-specific inspection and reconditioning

    US20220222984A1