Fault reporting and processing system based on multi-domain fusion automobile chip and vehicle

Abstract

This invention discloses a fault reporting and processing system and vehicle based on a multi-domain fusion automotive chip, comprising: a safety island fault processing center, a vehicle control ASIL D domain, and multiple business domains; each business domain includes a business subsystem, configured with a business core and an intra-domain fault processing center; each business subsystem is configured with a subsystem fault management center, and each business module is configured with a security mechanism and a module fault processing center; the module fault processing center is used to merge similar faults and output a module fault interrupt; the subsystem fault management center is used to merge similar faults and output a subsystem fault interrupt; the intra-domain fault processing center is used to process subsystem fault interrupts and output a business domain fault interrupt; the safety island fault processing center is used to uniformly collect, configure, manage, identify, classify, and proactively respond to reported faults; the vehicle control ASIL D domain receives fault information reported by the safety island fault processing center and performs fault confirmation and vehicle control. This invention is primarily applicable to the field of vehicle technology.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, specifically to a fault reporting and processing system and vehicle based on a multi-domain fusion automotive chip. Background Technology

[0002] In related technologies, the current automotive electronic and electrical architecture is evolving towards a centralized, multi-domain integration approach. Multi-domain integrated automotive chips will become the core hardware carrier of intelligent vehicles. The technology of fault reporting and processing systems is also rapidly developing along with the increasing chip integration and functional complexity. It has evolved from simple fault reset of traditional single-domain controllers to multi-domain collaborative fault perception, reporting, and hierarchical processing, with core research focusing on the real-time performance, accuracy, traceability, and security of fault information processing. Current mainstream solutions are all based on single-domain chips, resulting in limited business domain coverage. Furthermore, when a chip contains multiple business domains, issues such as fragmented fault management, slow response, and difficulties in cross-domain collaboration can easily arise. Therefore, how to develop an integrated fault reporting and processing system that leverages the cross-domain collaborative characteristics of multi-domain integrated chips is a pressing technical problem that the industry needs to address. Summary of the Invention

[0003] This invention provides a fault reporting and processing system and vehicle based on a multi-domain fusion automotive chip, in order to solve the technical problems of single business domain coverage and poor multi-business domain coordination in the prior art, and at least provide a beneficial option or create conditions.

[0004] This invention provides a fault reporting and processing system based on a multi-domain fusion automotive chip, comprising: a safety island fault processing center, a vehicle control ASIL D domain, and multiple service domains; the safety island fault processing center is communicatively connected to each of the service domains; the vehicle control ASIL D domain is communicatively connected to the safety island fault processing center via a safety bus. Each business domain contains at least one business subsystem, each business subsystem contains multiple business modules, each business domain is configured with a business core and an intra-domain fault handling center; each business subsystem is configured with a subsystem fault management center, and each business module is configured with a security mechanism and a module fault handling center. The module fault handling center is used to merge similar faults detected by the security mechanism within the module according to preset response measures and then output a module fault interruption. The subsystem fault management center is used to merge the module faults reported by each business module within this business subsystem according to preset response measures and output the subsystem fault interruption. The domain fault handling center is used to process the subsystem faults and interruptions reported by each business subsystem within the business domain, report them to the business core of the business domain for collection and processing, and output the business domain fault interruption when encountering a fault that cannot be handled internally or when the business core loses its self-processing capability. The security island fault handling center is used to receive business domain fault interruptions reported by each business domain, and to collect, configure, manage, identify, classify and actively respond to all reported business domain fault interruptions, as well as to exchange information with each business domain through inter-core communication to complete the closed-loop handling of manageable faults. The vehicle control ASIL D domain is used to receive fatal fault information reported by the safety island fault handling center that the safety island fault handling center cannot handle, and to perform decision-making and control with the highest reliability.

[0005] Furthermore, the business domains include: cockpit business domain, intelligent driving business domain, or vehicle control business domain.

[0006] Furthermore, the module fault handling center, the subsystem fault management center, and the domain fault handling center are configured to merge and refine fault interruptions layer by layer according to the fault type and severity level.

[0007] Furthermore, the inter-core communication is used to achieve cross-domain information collaboration when fault handling requires reference to the status information of other business domains.

[0008] Furthermore, the security island fault handling center interacts with each business domain through inter-core communication during the fault handling process to obtain cross-domain status information and assist in fault handling.

[0009] Furthermore, the system-level fault interruption output by the safety island fault handling center is a summary output of the faults that it has identified but have not completed closed-loop handling.

[0010] Furthermore, the safety island fault handling center communicates with the vehicle control ASIL D domain via a safety bus, which is a dedicated bus that meets functional safety requirements.

[0011] Furthermore, the inter-core communication between the security island fault handling center and each business domain is physically or logically isolated from the security bus.

[0012] Furthermore, the module failure interruption, subsystem failure interruption, and service domain failure interruption all carry corresponding fault type and severity level information.

[0013] On the other hand, a vehicle is provided, characterized in that the vehicle integrates a fault reporting and processing system based on a multi-domain fusion automotive chip, as described in any one of the above technical solutions.

[0014] This invention offers at least the following advantages: The system of this invention, through the construction of a reasonable framework, achieves the layered extraction and merging of fault information from the module level, subsystem level, business domain level, security island level, and ASIL D level, enabling fault handling across multiple business domains. It also avoids communication congestion and processing bottlenecks caused by massive amounts of raw fault reports, improving the efficiency of cross-domain collaboration. Furthermore, a corresponding vehicle is provided; the beneficial effects of the vehicle are similar to those of the system and will not be repeated here. This invention is primarily applicable to the field of vehicle technology. Attached Figure Description

[0015] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0016] Figure 1 This is a system block diagram of a fault reporting and processing system based on a multi-domain fusion automotive chip. Figure 2 This is a detailed system connection diagram of a fault reporting and processing system based on a multi-domain fusion automotive chip; Figure 3 This is a schematic diagram of the system connection structure of the business domain. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] It should be noted that although functional modules are divided in the system diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] In vehicle-related technologies, the current automotive electronic and electrical architecture is evolving towards centralization and multi-domain integration. Multi-domain integrated automotive chips will become the core hardware carrier of intelligent vehicles. The technology of fault reporting and processing systems is also rapidly developing along with the increasing chip integration and functional complexity. It has upgraded from simple fault reset of traditional single-domain controllers to multi-domain collaborative fault perception, reporting, and hierarchical processing, with core research focusing on the real-time performance, accuracy, traceability, and security of fault information processing. Current mainstream solutions are all based on single-domain chips, covering only a limited range of business domains. Therefore, how to develop an integrated fault reporting and processing system that leverages the cross-domain collaborative characteristics of multi-domain integrated chips is a crucial technical issue that the industry urgently needs to address.

[0020] refer to Figure 1 and Figure 2 , Figure 1 This is a schematic diagram of the system connection structure of a fault reporting and processing system based on a multi-domain fusion automotive chip. Figure 2 This is a detailed system connection diagram of a fault reporting and processing system based on a multi-domain fusion automotive chip. Figure 2 In the diagram, orange represents the business domain, which can be the cockpit domain, intelligent driving domain, vehicle control ASIL B domain, etc., and outputs business domain error interrupts to the system; blue represents inter-core communication, used for collaborative fault handling among multiple services; gray represents the safety island domain, including the safety island error management center and the safety processor; and yellow represents the vehicle control ASIL D domain, which is responsible for the ultimate safety loop for system faults.

[0021] To address the technical problems existing in the prior art, this application discloses a fault reporting and processing system based on a multi-domain fusion automotive chip.

[0022] The fault reporting and processing system based on a multi-domain fusion automotive chip includes: a safety island fault processing center, a vehicle control ASIL D domain, and multiple service domains; the safety island fault processing center is communicatively connected to each service domain; the vehicle control ASIL D domain is communicatively connected to the safety island fault processing center via a safety bus.

[0023] Each business domain contains at least one business subsystem, each business subsystem contains multiple business modules, and each business domain is configured with a business core and an intra-domain fault handling center. Each business subsystem is configured with a subsystem fault management center, and each business module is configured with a security mechanism and a module fault handling center. The module fault handling center is used to merge similar faults detected by the security mechanism within the module according to preset response measures and output a module fault interruption.

[0024] The subsystem fault management center is used to merge the module faults and interruptions reported by various business modules within this business subsystem according to preset response measures, and then output the subsystem fault interruption.

[0025] The domain fault handling center is used to process the subsystem faults and interruptions reported by each business subsystem within the business domain, report them to the business core of the business domain for collection and processing, and output the business domain fault interruption when encountering a fault that cannot be handled internally or when the business core loses its self-processing capability.

[0026] The security island fault handling center is used to receive business domain fault interruptions reported by each business domain, and to collect, configure, manage, identify, classify and proactively respond to all reported business domain fault interruptions. It also interacts with each business domain through inter-core communication to complete the closed-loop handling of manageable faults.

[0027] The vehicle control ASIL D domain is used to receive fatal fault information reported by the safety island fault handling center that the safety island fault handling center cannot handle, and to perform decision-making and control with the highest reliability.

[0028] The business domains include: cockpit business domain, intelligent driving business domain, or vehicle control business domain.

[0029] In some further specific embodiments, the module fault handling center, the subsystem fault management center, and the domain fault handling center are configured to merge and refine fault interruptions layer by layer according to fault type and severity level. The inter-core communication is used to achieve cross-domain information collaboration when fault handling requires reference to the status information of other business domains.

[0030] In some further specific embodiments, the safety island fault handling center interacts with each business domain via inter-core communication during the fault handling process to obtain cross-domain status information to assist in fault handling. The system-level fault interrupt output by the safety island fault handling center serves as a summary output of faults that it has identified but have not completed closed-loop handling. The safety island fault handling center communicates with the vehicle control ASIL D domain via a safety bus, which is a dedicated bus that meets functional safety requirements. The inter-core communication between the safety island fault handling center and each business domain is physically or logically isolated from the safety bus.

[0031] In some further specific embodiments, the module failure interruption, subsystem failure interruption, and service domain failure interruption each carry corresponding fault type and severity level information.

[0032] refer to Figure 3 , Figure 3 This is a schematic diagram of the system connection structure of the business domain. Figure 3 In the diagram, the blue box represents the module level, and Module Error Management is the module fault handling center; the green box represents the subsystem level, and SUBx Error Management is the subsystem-level fault interruption handling center; the orange box represents the domain level, where the Domain safety processor is the domain's service core, and Domain Error Management is the domain's fault handling center.

[0033] The fault reporting and processing system based on the multi-domain fusion automotive chip is integrated into a multi-domain fusion system-on-a-chip (SoC).

[0034] Taking three business domains as an example, these three business domains are: cockpit business domain (Domain1), intelligent driving business domain (Domain2), and vehicle control business domain (Domain3).

[0035] Each business domain is configured with a corresponding business core (Domain Safety Processor) and an in-domain fault handling center (Domain Error Management).

[0036] Taking the Intelligent Driving Business Domain (Domain2) as an example, it contains multiple business subsystems, such as the perception subsystem, decision-making subsystem, and execution management subsystem. Each business subsystem further contains multiple business modules; for example, the perception subsystem includes a camera driver module, an image signal processing module, and a target detection module.

[0037] Each business module is equipped with a Safety Mechanism (SM) and a Module Error Management center. Each business subsystem is equipped with a Subsystem Error Management center.

[0038] The Safety Island Error Management center is connected to the intra-domain error management centers of the cockpit business domain, intelligent driving business domain, and vehicle control business domain via an internal chip bus or inter-core communication channel. The vehicle control ASIL D domain communicates with the Safety Island Error Management center via a safety bus, which is a dedicated on-chip bus that meets the ISO26262 ASIL D functional safety requirements.

[0039] The following example illustrates the complete fault handling process, specifically the "image data timeout" fault in the camera driver module of the perception subsystem in the intelligent driving business domain.

[0040] The security mechanism within the camera driver module detected an "image data timeout" fault. This security mechanism sends the fault information to the module's fault handling center. The fault information includes, but is not limited to, the fault type and severity level.

[0041] The module fault handling center handles faults according to a preset response measure table. This table records the handling methods for different fault conditions. For example, for faults with a severity level of "warning," the measure is "record and report"; for faults with a severity level of "error," the measure is "interrupt the current task and report."

[0042] If the fault is assumed to be classified as "error," the module fault handling center will merge it with similar faults reported by other safety mechanisms within the module (such as multiple consecutive timeouts) within a time window, ultimately outputting a module error interrupt carrying the fault code ERR_CAM_TIMEOUT and the severity level ERR_LEVEL. The above process is a module-level merging process.

[0043] The subsystem fault management center of the perception subsystem collects module fault interruptions reported by all modules within the subsystem (including the camera driver module, ISP module, and target detection module). Assuming that only the camera driver module has reported ERR_CAM_TIMEOUT, the subsystem fault management center, based on subsystem-level response measures (e.g., if any perception input module reports an error, the entire system reports a "perception subsystem degradation" fault), converts this module fault interruption into a subsystem fault interrupt, carrying the information: SUB_ERR_SENSOR_DEGRADE, with a SERIOUS level. The above process is a subsystem-level merging process.

[0044] The fault handling center within the intelligent driving business domain collects subsystem faults and interruptions reported by the perception subsystem. Simultaneously, the decision-making subsystem may also report a "lack of valid perception input" fault. The fault handling center aggregates these interruptions and reports them to the intelligent driving business core.

[0045] The Intelligent Driving Business Core determines whether the current fault can be handled automatically based on its internal fault handling logic. For example, if only a single camera is faulty, it can switch to radar fusion mode to continue operation. If all cameras are currently malfunctioning and the Intelligent Driving Business Core determines that safety cannot be guaranteed independently, it triggers a domain error interrupt and reports it to the safety island fault handling center.

[0046] During this process, if the intelligent driving business core needs to refer to the status information of the cockpit domain, it can request driver status data from the cockpit business core through the inter-core communication path, thereby achieving precise processing under cross-domain information collaboration.

[0047] The Security Island Fault Handling Center receives business domain faults and interruptions reported from the Intelligent Driving business domain and other business domains. Security Island centrally collects, manages, and categorizes all reported faults.

[0048] The safety island has a built-in system-level fault interruption response table. For example, in the case of a "failure of all cameras in the intelligent driving domain" fault, the safety island can perform the following proactive responses: notify the cockpit domain via inter-core communication, display "Intelligent driving system downgraded, please take over immediately" on the instrument panel; notify the vehicle control domain to limit the vehicle speed to 20km / h; record the fault log and trigger a system-level fault interrupt for external monitoring. If the safety island can complete the above closed-loop handling, the fault handling process terminates here.

[0049] Of course, let's assume a more serious scenario: the safety island fault handling center detects an uncorrectable ECC error in its internal storage unit, rendering it unable to reliably perform fault management tasks. In this case, the safety island fault handling center determines that it cannot handle this fatal fault and reports ERROR information to the vehicle control ASIL D domain via the safety bus.

[0050] As the highest-level functional safety unit within the system, the vehicle control ASIL D domain, upon receiving this information, executes the ultimate decision and control: for example, triggering the entire vehicle to enter a safe state, including cutting off high voltage, activating hazard lights, and ensuring the vehicle decelerates controllably until it stops. This decision is unaffected by faults in other business domains, thus achieving a complete active closed loop from fault detection to ultimate safety response.

[0051] This invention constructs a reasonable framework to achieve the layer-by-layer extraction and merging of fault information from the module level, subsystem level, business domain level, security island level and ASIL D level, thereby avoiding communication congestion and processing bottlenecks caused by massive amounts of original fault reports.

[0052] From another perspective, this solution constructs a "three-layer, two-line" fault management architecture, which aims to solve the core pain points of decentralized fault management, slow response, and difficulty in cross-domain collaboration in multi-domain integrated chips.

[0053] The "three layers" refer to the spatial fault management hierarchy: Local Execution Layer (Module / Subsystem Level): Responsible for immediate fault detection, initial merging, and rapid response, prioritizing processing speed. Domain Decision Layer (Business Core): Responsible for summarizing and analyzing faults within its business domain and making closed-loop decisions within the domain, balancing processing efficiency and accuracy. Global Arbitration Layer (Safety Island / ASIL D Domain): Responsible for centralized arbitration, final decision-making, and vehicle-level safety safeguards for cross-domain, high-security-level faults, prioritizing the highest reliability.

[0054] The "two lines" refer to the time-related processing flow: The "bottom-up" fault extraction and reporting line: Fault information starts at the module level, undergoing merging and refinement layer by layer, converging the original, scattered, massive amounts of faults into a small number of high-value, clearly located "fundamental fault events," which are then reported to higher levels, greatly reducing the processing load on upper levels and avoiding "alarm storms." The "top-down" fault decision-making and execution line: After making a decision, the higher-level management center (such as a safety island / vehicle control ASIL D) decomposes and distributes specific isolation, degradation, and recovery instructions to the corresponding lower-level units for execution, forming a closed-loop processing system.

[0055] The core advantage of this architecture lies in its rationally distributed deployment of resources and responsibilities required for fault handling. Simple faults are resolved locally at lower levels, while complex faults are refined and handled centrally and intelligently at higher levels, achieving an optimal balance between efficiency, resources, and security.

[0056] The following example illustrates the "three-layer, two-line" fault management architecture.

[0057] Implementation scenario: Comprehensive handling of multiple module processing anomalies in the body domain on a multi-domain fusion automotive SoC chip that integrates the intelligent cockpit domain (cockpit business domain), L2+ level intelligent driving domain (intelligent driving business domain), and body control domain (vehicle control business domain).

[0058] Fault occurrence and hierarchical processing ("bottom-up" extraction). Original fault: During vehicle operation, multiple modules in the body domain control subsystem simultaneously malfunction and report faults.

[0059] Then, module-level merging is performed: within their respective module error management centers, the fault categories are identified and merged into a module-level comprehensive fault event (Module error interrupt) and reported to the vehicle body domain control subsystem.

[0060] Subsystem-level merging: The Body Domain Control Subsystem Fault Management Center (SUBx Error Management) receives faults reported by multiple modules. Based on a rule base, the fault management center merges multiple faults across modules and infers a higher-level, more confident subsystem-level fault interrupt.

[0061] Further processing and decision-making within the domain: This refined subsystem fault is reported to the vehicle domain's business core (Domain Safety Processor). The business core determines the fault based on internal policies and makes a domain-specific decision. Simultaneously, through inter-core communication, it sends a request to the cockpit domain's business core, requesting that a clear alarm be displayed on the instrument panel.

[0062] Further cross-domain upgrades and global arbitration (a "top-down" closed loop): Simultaneously, the intelligent driving domain detects that the vehicle is entering a congested section of road ahead through its front-facing camera. The ADAS business core anticipates that frequent start-stop control will be required, which may exacerbate the burden on the fault domain. Therefore, the ADAS domain reports the contextual information of "congestion prediction" along with the fundamental fault event from the vehicle body domain to the chip's global safety island.

[0063] Centralized decision-making in the safety island: After receiving related information from two different domains, the safety island performs a global risk assessment. The safety island makes a more conservative global decision than a single vehicle body domain. To ensure absolute safety, it requests the execution of ASIL D level vehicle safety measures. This decision and all related data are reported to the highest safety level vehicle control ASIL D domain. After confirmation by the ASIL D domain, the highest reliability control command is executed.

[0064] On the other hand, this application also discloses a vehicle that integrates a fault reporting and processing system based on a multi-domain fusion automotive chip, as described in any of the above specific embodiments.

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

[0066] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0067] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.

[0068] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0069] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0070] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0071] Although the description of this application has been quite detailed and particularly focused on several of the described embodiments, it is not intended to limit itself to any of these details or embodiments or any particular embodiment. Rather, it should be considered as effectively covering the intended scope of this application by referring to the appended claims and taking into account the prior art, which provides for a broad possible interpretation of these claims. Furthermore, the foregoing description of this application with respect to embodiments foreseeable by the inventors is intended to provide a useful description, and non-substantial modifications to this application that have not yet been foreseen may still represent equivalent modifications.

[0072] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

Claims

1. A fault reporting and processing system based on a multi-domain fusion automotive chip, characterized in that, include: The system includes a safety island fault handling center, a vehicle control ASIL D domain, and multiple service domains; the safety island fault handling center is communicatively connected to each of the service domains. The vehicle control ASIL D domain is communicatively connected to the safety island fault handling center via a safety bus. Each business domain contains at least one business subsystem, each business subsystem contains multiple business modules, each business domain is configured with a business core and an intra-domain fault handling center; each business subsystem is configured with a subsystem fault management center, and each business module is configured with a security mechanism and a module fault handling center. The module fault handling center is used to merge similar faults detected by the security mechanism within the module according to preset response measures and then output a module fault interruption. The subsystem fault management center is used to merge the module faults reported by each business module within this business subsystem according to preset response measures and output the subsystem fault interruption. The domain fault handling center is used to process the subsystem faults and interruptions reported by each business subsystem within the business domain, report them to the business core of the business domain for collection and processing, and output the business domain fault interruption when encountering a fault that cannot be handled internally or when the business core loses its self-processing capability. The security island fault handling center is used to receive business domain fault interruptions reported by each business domain, and to collect, configure, manage, identify, classify and actively respond to all reported business domain fault interruptions, as well as to exchange information with each business domain through inter-core communication to complete the closed-loop handling of manageable faults. The vehicle control ASIL D domain is used to receive fatal fault information reported by the safety island fault handling center that the safety island fault handling center cannot handle, and to perform decision-making and control with the highest reliability.

2. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The business domains include: cockpit business domain, intelligent driving business domain, or vehicle control business domain.

3. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The module fault handling center, the subsystem fault management center, and the domain fault handling center are configured to merge and refine fault interruptions layer by layer according to fault type and severity level.

4. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The inter-core communication is used to achieve cross-domain information collaboration when fault handling requires reference to the status information of other business domains.

5. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The security island fault handling center exchanges information with each business domain through inter-core communication during the fault handling process to obtain cross-domain status information and assist in fault handling.

6. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The system-level fault interruption output by the safety island fault handling center is a summary output of the faults that it has identified but have not completed closed-loop handling.

7. A fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The safety island fault handling center communicates with the vehicle control ASIL D domain via a safety bus, which is a dedicated bus that meets functional safety requirements.

8. The fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The inter-core communication between the security island fault handling center and each business domain is physically or logically isolated from the security bus.

9. A fault reporting and processing system based on a multi-domain fusion automotive chip according to claim 1, characterized in that, The module failure interruption, subsystem failure interruption, and business domain failure interruption all carry corresponding fault type and severity level information.

10. A vehicle, characterized in that, The vehicle integrates a fault reporting and processing system based on a multi-domain fusion automotive chip as described in any one of claims 1 to 9.

Images