Abnormal supervision system, method, storage medium, and vehicle

Abstract

The disclosure discloses an abnormal supervision system, method, storage medium and vehicle. The supervision method implemented by the abnormal supervision system based on the disclosure can reduce the processing load of an external high-security level MCU; and when performing abnormal repair, the situation that an individual subsystem is abnormal but needs to be reset for the whole SoC can be avoided.

Description

Technical Field

[0001] This disclosure generally relates to the field of intelligent driving. More specifically, this disclosure relates to an anomaly monitoring system, method, storage medium, and vehicle. Background Technology

[0002] Advanced Driver Assistance Systems (ADAS) are a type of active safety technology. This technology continuously senses the surrounding environment while the vehicle is in motion, collects data, identifies, detects, and tracks static and dynamic objects, and combines this data with navigation map data to perform system calculations and analyses. This allows the driver to anticipate potential dangers, effectively increasing driving comfort and safety.

[0003] ADAS has a safety diagnostic mechanism, which is a mechanism for reporting and repairing abnormal events when hardware or software anomalies occur within the system. Existing reporting mechanisms are generally implemented based on an MCU-SoC supervision architecture. The MCU (Micro Controller Unit) is an external, high-security MCU used to monitor abnormal events in the SoC (System on Chip) running ADAS.

[0004] Existing anomaly reporting mechanisms based on MCU-SoC supervisory architectures have the following drawbacks:

[0005] 1. Existing SoCs are internally divided into multiple subsystems, including performance domain subsystems, real-time domain subsystems, boot domain subsystems, and security domain subsystems. Abnormal events generally occur within each subsystem, and each subsystem uniformly reports operational abnormalities to the MCU, causing excessive load on the MCU.

[0006] 2. A software / hardware failure in a subsystem causes the subsystem software to freeze, requiring a complete SoC reset, which is too costly to repair. Summary of the Invention

[0007] In order to address at least one or more of the technical issues mentioned above, this disclosure proposes an anomaly monitoring scheme for on-chip systems in several aspects, dividing the on-chip system into at least two layers of monitoring units to independently monitor each subsystem of the on-chip system.

[0008] In a first aspect, this disclosure provides an anomaly monitoring system for monitoring a chip system having a System-on-a-Chip (SoC), the SoC having multiple first subsystems and second subsystems. The anomaly monitoring system includes: a first-level monitoring unit operating within each first subsystem, for monitoring operational anomalies of the first subsystem and, based on the anomaly type, selecting to report the corresponding operational anomaly to a second-level monitoring unit; and a second-level monitoring unit operating within the second subsystem, for collecting operational anomalies of each subsystem within the SoC.

[0009] In a second aspect, this disclosure provides an anomaly monitoring method for monitoring a chip system with a System-on-a-Chip (SoC), the SoC having multiple first subsystems and second subsystems. The method includes: a first-level monitoring unit monitoring operational anomalies in the first subsystem; wherein the first-level monitoring unit operates in the first subsystem, and there is a one-to-one correspondence between the first-level monitoring unit and the first subsystem; if an operational anomaly occurs in the first subsystem, the first-level monitoring unit selects to report the corresponding operational anomaly to a second-level monitoring unit according to the anomaly type; and the second-level monitoring unit collects operational anomalies from each subsystem within the SoC; wherein the second-level monitoring unit operates in the second subsystem.

[0010] In a third aspect, this disclosure provides a computer-readable storage medium storing computer program code of an anomaly monitoring method, which, when run, executes the aforementioned anomaly monitoring method.

[0011] In the fourth aspect, this disclosure provides a vehicle in which the chip system is installed is monitored by the anomaly monitoring system described above.

[0012] Through the anomaly monitoring scheme provided above, this disclosed scheme divides the monitoring hierarchy within the on-chip system. Specifically, it designates specific subsystems (e.g., security domain subsystems) as intermediate layers for anomaly reporting (i.e., second-level monitoring units). This allows some operational anomalies to be repaired within the second-level monitoring units, eliminating the need to report all operational anomalies to the MCU, thus reducing the MCU's processing load. Furthermore, each subsystem has a monitoring unit capable of independent anomaly reporting. This enables higher-level monitoring units to accurately locate the subsystem from which the anomaly was reported, allowing for targeted repair operations (e.g., reset) of the affected subsystem. This avoids situations where a single subsystem anomaly necessitates a full SoC reset. Attached Figure Description

[0013] The above and other objects, features, and advantages of exemplary embodiments of this disclosure will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0014] Figure 1 A simplified deployment diagram of the anomaly monitoring system and the chip system it monitors, as shown in this disclosure embodiment, is provided.

[0015] Figure 2 This diagram illustrates a simplified alternative deployment relationship between the anomaly monitoring system and the chip system it monitors, representing an embodiment of this disclosure.

[0016] Figure 3 This diagram illustrates the structural layout of the FMU deployment in this embodiment.

[0017] Figure 4 A schematic diagram illustrating the security redundancy mechanism for anomaly reporting in this disclosure embodiment is shown;

[0018] Figure 5 An exemplary method flowchart of an anomaly monitoring method according to an embodiment of this disclosure is shown; and

[0019] Figure 6 An exemplary flowchart of an anomaly monitoring method according to another embodiment of this disclosure is shown;

[0020] The relationship between the reference numerals and the modules in the figures is as follows:

[0021] 10—SoC, 20—MCU, 11—First Subsystem, 12—Second Subsystem, 21—Security System, 111—First Layer Supervision Unit, 121—Second Layer Supervision Unit, 211—Third Layer Supervision Unit. Detailed Implementation

[0022] The technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, not all of them. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0023] It should be understood that the terms "first," "second," and "third," etc., that may be used in the claims, specification, and drawings of this disclosure are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" as used in the specification and claims of this disclosure indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or sets thereof.

[0024] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0025] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0026] The specific embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0027] As mentioned in the background section, from a system design perspective, existing anomaly reporting mechanisms based on MCU-SoC supervision architectures are no longer suitable for today's highly complex SoCs. On one hand, due to the high complexity of SoCs and the numerous sources of anomalies, typically distributed across different SoC subsystems, each subsystem cannot directly report anomalies to the MCU. Even if all anomaly signals from all subsystems converge on the MCU, it could still complicate the MCU supervision software design and impose excessive load. On the other hand, each SoC subsystem often runs an independent software system. When the MCU detects a software / hardware fault in one SoC subsystem causing a software freeze, resulting in a full SoC reset, the cost is substantial.

[0028] In view of this, the embodiments disclosed herein propose an anomaly monitoring system to meet the system functional safety requirements of such high-performance SoC chips. In some embodiments, the anomaly monitoring scheme disclosed herein satisfies the time constraints of the safety mechanism while covering as many anomaly checkpoints distributed within the SoC as possible without omission. Therefore, the anomaly monitoring scheme of the embodiments disclosed herein introduces a multi-level monitoring design approach, distributing monitoring behaviors (optionally including diagnostic behaviors) to different hardware entities at various levels at the system level.

[0029] Figure 1 This diagram illustrates a simplified deployment relationship between the anomaly monitoring system and the monitored chip system. As shown, the chip system requiring security monitoring in this disclosure includes a System-on-a-Chip (SoC). The SoC contains multiple processing cores, each running a subsystem (depending on the specific situation; one subsystem can run on one processing core, or multiple subsystems can run on one processing core through virtual kernel partitioning; the diagram only illustrates one scenario). In this embodiment, the anomaly monitoring system performs layered monitoring of the multiple subsystems running on the SoC. Specifically, a subsystem with a high hardware security level (e.g., the processing core corresponding to this subsystem has a lockstep mechanism and memory isolation mechanism) is selected as the second subsystem 12. A second-layer monitoring unit 121 is deployed in the second subsystem to collect operational anomalies of each subsystem within the SoC. Other subsystems besides the second subsystem in the SoC are designated as first subsystems 11. A first-layer monitoring unit 111 is deployed in each first subsystem to monitor operational anomalies within that first subsystem and, based on the anomaly type, reports the corresponding operational anomaly to the second-layer monitoring unit.

[0030] Operational anomaly: refers to an anomaly in the hardware module or software program that occurs during the operation of a subsystem.

[0031] Exception type: refers to the category of runtime exceptions classified according to specific rules.

[0032] In a more complete chip system scenario, the chip system also includes the MCU. Figure 2 This is another simplified deployment diagram of the anomaly monitoring system and the chip system it monitors. As shown in the diagram, the chip systems requiring security monitoring in this disclosure include an MCU and a SoC. The MCU is an external, high-security MCU used to monitor anomaly events in the SoC running ADAS. The deployment of the SoC is shown in the diagram. Figure 1 Similarly, this will not be repeated here.

[0033] A safety system 21 (e.g., Safety RTOS) runs in the MCU. A third-level monitoring unit 211 is deployed in the safety system to monitor the operating status of each subsystem within the on-chip system based on the operating anomalies reported by the first-level monitoring unit and / or the second-level monitoring unit.

[0034] In one implementation, operational anomalies can be categorized according to their severity. For example, based on increasing severity, the anomaly types could be: warning-level anomalies, error-level anomalies, and fatal error-level anomalies.

[0035] In another implementation, operational anomalies can be categorized based on the reporting target. For example, there could be a first reporting type and a second reporting type. The first reporting type is set to report operational anomalies to the second-level monitoring unit, and the second reporting type is set to report operational anomalies to the third-level monitoring unit. The reporting target needs to be pre-defined based on the hardware and software characteristics of the second subsystem and the MCU, as well as the repair efficiency of various operational anomalies.

[0036] In practical applications, the classification of exception types can be determined according to actual needs, and no restrictions are imposed here.

[0037] Taking anomaly types categorized by severity as an example, when configuring each layer of supervisory units, it is set that fatal error-level anomalies must be reported to the third-level supervisory unit (i.e., only the third-level supervisory unit is configured with an anomaly repair mechanism corresponding to fatal error-level anomalies, or only the third-level supervisory unit has the ability to repair fatal error-level anomalies). Fatal error-level anomalies can be reported level by level (i.e., from the first-level security supervisory unit to the second security supervisory unit, and then from the second-level security supervisory unit to the third security supervisory unit), or directly from the first-level security supervisory unit to the third security supervisory unit. If the anomaly type is a warning-level or error-level anomaly, the first subsystem reports this anomaly type to the second-level supervisory unit. Simultaneously with reporting to the second-level supervisory unit, if the warning-level or error-level anomaly is one that the first-level security supervisory unit can repair locally, the anomaly repair mechanism will also be executed. When the second-level monitoring unit detects that the processing status of the warning-level or error-level anomaly is "resolved" within the set monitoring time, it does not need to continue reporting the warning-level or error-level anomaly to the third-level monitoring unit, thereby reducing the processing load of the MCU.

[0038] Regarding the selection of the second subsystem

[0039] Since the second-level supervisory unit is responsible for monitoring the malfunctions of various subsystems within the on-chip system, the second subsystem containing this unit needs to have enhanced security features to report errors externally even when other subsystems fail. These security features include, but are not limited to, lockstep mechanisms and memory isolation mechanisms.

[0040] Lockstep mechanism: This refers to the fact that the corresponding processing core has a hardware self-test module that can periodically execute the same instructions and compare the results after executing the same instructions. If the results are inconsistent, it is determined that an operational abnormality has occurred.

[0041] Memory isolation mechanism: Store critical programs and data in isolated memory areas so that other programs will not occupy the isolated memory areas when running.

[0042] During system configuration, processing cores with lockstep and memory isolation mechanisms are typically selected, and a security domain subsystem is deployed. Therefore, when setting the hierarchy of supervisory units, the security domain subsystem is preferentially chosen as the second subsystem. The remaining performance domain subsystem, real-time domain subsystem, or startup domain subsystem are designated as the first subsystem.

[0043] Regarding the reporting method

[0044] Heartbeat mode: The lower-level monitoring unit periodically sends heartbeat messages to the upper-level monitoring unit via the Serial Peripheral Interface (SPI) bus. This heartbeat message includes a running status flag, which indicates whether the corresponding subsystem has experienced a malfunction. It should be noted that "lower layer" and "upper layer" are relative concepts in this disclosed embodiment and do not specifically refer to a particular monitoring unit layer. For example, the second layer is the upper layer relative to the first layer, and the second layer is the lower layer relative to the third layer.

[0045] FMU Mode: The Fault Management Unit (FMU) is a hardware module used to collect abnormal interruption signals reported by the first subsystem to the second subsystem. Specifically, the FMU in the first subsystem collects abnormal interruption signals from the hardware modules within that subsystem, and, in response to the abnormal interruption signals indicating operational abnormalities, reports the operational abnormalities to the FMU in the second subsystem. In one implementation scenario, if the abnormal interruption signal is high, it indicates that the first subsystem sending the abnormal interruption signal has experienced an operational abnormality; if the abnormal interruption signal is low, it indicates that the first subsystem sending the abnormal interruption signal is operating normally, and vice versa.

[0046] For example, please refer to Figure 3The FMU uses a tree-like structure to establish multi-level interconnected FMU signals. Each FMU signal is configured with a unique identifier and recorded in the FMU signal routing table of the anomaly monitoring system. Specifically, each first subsystem has multiple first-level FMU signals (equivalent to leaf nodes in the tree diagram), corresponding to various operational anomalies within that first subsystem. The second subsystem has multiple levels of FMU signals: second-level FMU signals corresponding to operational anomalies in the second subsystem, and second-level FMU signals corresponding to the first subsystem. All second-level FMU signals are connected to a third-level FMU signal. Only one second-level FMU signal corresponding to the first subsystem may be configured (e.g., ...). Figure 3 As shown, all the primary FMU signals in the first subsystem are connected to a single secondary FMU signal; in another implementation, a secondary FMU signal can be configured for each first subsystem. The specific configuration of the secondary FMU signal can be determined according to actual needs and is not limited here.

[0047] When a lower-level FMU signal is high (the second level is the upper level relative to the first level), its corresponding upper-level FMU signal will also be high, and this propagation continues upwards to the third-level FMU signal, triggering the Error pin. The MCU can use this Error pin to detect operational abnormalities in the SoC. FMU mode is a hardware signal reporting method with high signal transmission timeliness and better stability.

[0048] Error pin: The Error pin is one of the pins in the hardware connection between the SoC and the MCU, and is used for error communication between the SoC and the MCU.

[0049] Mailbox Mode: A Mailbox is a hardware module that enables data transfer between subsystems within the SoC by configuration. A corresponding Mailbox channel is configured between the second subsystem and the first subsystem. The second-level supervisory unit utilizes the Mailbox and its onboard inter-core communication software framework, IPC (Inter-Process Communication), to collect operational anomalies from the first-level supervisory unit. Unlike the FMU reporting path, the Mailbox reporting path includes not only hardware anomaly signals but also other anomalies, such as sensor malfunctions connected to the subsystem where the first-level supervisory unit resides, and application program failures.

[0050] In practical applications, when a lower-level monitoring unit reports operational anomalies to an upper-level monitoring unit, two or more reporting methods can be used to form a safety redundancy mechanism for anomaly reporting. This ensures that at least one reporting method can successfully report the operational anomaly to the upper-level monitoring unit, enabling the anomaly to be repaired in a timely manner. For an example, please refer to [link to example]. Figure 4 , Figure 4 This illustrates a safety redundancy mechanism that uses both heartbeat mode and FMU mode simultaneously. When a hardware module in the first subsystem malfunctions, the error is reported to the second subsystem via both the heartbeat path (in bold) and the FMU path (in thin line).

[0051] Regarding the configuration of each layer of supervision units

[0052] —First-level supervision unit

[0053] Operating environment: All subsystems except the security domain subsystem (e.g., performance domain subsystem, real-time domain subsystem, or startup domain subsystem);

[0054] Monitoring target: The deployed subsystem. By receiving abnormal interruption signals from within the subsystem, the monitoring can determine if the deployed subsystem has experienced operational abnormalities.

[0055] Reporting to: Second-level or third-level supervisory units;

[0056] Reporting methods: at least one of the following: heartbeat mode, FMU mode, and Mailbox mode;

[0057] Anomaly repair targets: Some warning-level anomalies (e.g., software anomalies and sensor anomalies); If the first-level monitoring unit detects software anomalies and sensor anomalies, in addition to reporting these operational anomalies, it can also determine whether the operational anomaly is one that can be repaired locally. If so, the first anomaly repair mechanism is executed. This first anomaly repair mechanism is a set of repair mechanisms corresponding to operational anomalies that the first-level monitoring unit can repair locally.

[0058] —Second-level supervision unit

[0059] Operating environment: Security domain subsystem (also known as safety island, whose hardware resources are inaccessible from the outside). The security domain subsystem is deployed in a processing core with lockstep mechanism and memory isolation mechanism.

[0060] Targets of supervision: First subsystem and second subsystem;

[0061] Reporting target: Third-level supervision unit;

[0062] Reporting method: heartbeat mode and / or Error pin;

[0063] Exceptions to be repaired: Warning-level exceptions or partial error-level exceptions;

[0064] After receiving an operational anomaly reported by the first-level monitoring unit, the second-level monitoring unit determines whether the anomaly is one that the first-level monitoring unit can repair. If not, it directly executes the second anomaly repair mechanism. If so, it sets a first timer, starting from the date the operational anomaly is received. When the first timer exceeds the first repair time limit, the second anomaly repair mechanism is executed. This first timer is a timer representing the waiting time for anomaly repair, as recorded by the second-level monitoring unit. The first repair time limit is the maximum time threshold for the second-level monitoring unit to wait for anomaly repair. The second anomaly repair mechanism is the set of repair mechanisms corresponding to operational anomalies that the second-level monitoring unit can instruct the first-level monitoring unit to repair.

[0065] —Third-level supervision unit

[0066] Operating environment: MCU's security system; the third-layer supervisory unit can be integrated as a software component into the AUTOSAR-based MCU firmware. AUTOSAR (AUTotmotive Open System Architecture) is a standard protocol jointly established by major global automakers, automotive component suppliers, and automotive electronics software system companies.

[0067] Targets of supervision: First subsystem and second subsystem;

[0068] Exception handling targets: all fatal error-level exceptions, error-level exceptions, and warning-level exceptions;

[0069] After receiving an operational anomaly reported by the first or second layer monitoring unit, the third-layer monitoring unit determines whether the anomaly is one that the first or second layer monitoring unit can repair. If not, it directly executes the third anomaly repair mechanism. If so, it sets a second timer, starting from the date the operational anomaly is received. When the second timer exceeds the second repair time limit, the third anomaly repair mechanism is executed. This second timer is a timer for the duration of waiting for anomaly repair, as counted by the third-layer monitoring unit. The second repair time limit is the maximum time threshold for the third-layer monitoring unit to wait for anomaly repair. The third anomaly repair mechanism is a set of repair mechanisms for repairing operational anomalies in the first or second subsystem.

[0070] It should be noted that the anomaly repair capabilities of the monitoring units are backward compatible. That is, the third-level monitoring unit has an anomaly repair mechanism for all operational anomalies. For anomalies that cannot be repaired solely by the third-level monitoring unit, a second timer is set locally within the third-level monitoring unit. This timer starts counting from the moment the operational anomaly is reported by the first or second-level monitoring unit. When the second timer exceeds the second repair time limit, it indicates an unknown situation has occurred, and the first or second-level monitoring unit cannot repair the operational anomaly as usual. In this case, the third-level monitoring unit needs to intervene and execute the third anomaly repair mechanism to repair the relevant operational anomaly. Similarly, operational anomalies that the first-level monitoring unit can repair locally can also be repaired by the second-level monitoring unit. For anomalies that the first-level monitoring unit can repair, a first timer is set locally within the second-level monitoring unit. This timer starts counting from the moment the operational anomaly is reported by the first-level monitoring unit. When the second timer exceeds the first repair time limit, it indicates an unknown situation has occurred, and the first-level monitoring unit cannot repair the operational anomaly as usual. In this case, the second-level monitoring unit needs to intervene and execute the second anomaly repair mechanism to repair the relevant operational anomaly.

[0071] The anomaly monitoring system described in this embodiment divides the monitoring hierarchy within the on-chip system. Specific subsystems (e.g., security domain subsystems) are designated as intermediate layers (i.e., second-layer monitoring units) for anomaly reporting. This allows some operational anomalies to be repaired at the second-layer monitoring unit, eliminating the need to report all anomalies to the MCU and reducing the MCU's processing load. Furthermore, each subsystem has its own monitoring unit capable of independent anomaly reporting. This allows higher-level monitoring units to accurately pinpoint the subsystem from which the anomaly occurred and perform targeted repair operations (e.g., reset) on that subsystem, avoiding the need for a full SoC reset due to anomalies in only a few subsystems. Moreover, each subsystem's anomalies have a repair mechanism in place at either the first or second-layer monitoring unit, eliminating the need for layer-by-layer reporting and repair, improving anomaly repair efficiency, and further reducing the processing burden on higher-level monitoring units.

[0072] Accordingly, based on the above-described anomaly monitoring system, this disclosure also provides an anomaly monitoring method. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 An exemplary method flowchart of an anomaly monitoring method according to an embodiment of this disclosure is shown.

[0073] like Figure 5 As shown, in step 501, the first-level monitoring unit monitors the operation of the first subsystem; wherein, the first-level monitoring unit operates in the first subsystem, and the first-level monitoring unit corresponds one-to-one with the first subsystem.

[0074] In this disclosed embodiment, "operational anomaly" refers to an anomaly in the hardware module or software program that occurs during the operation of the subsystem.

[0075] like Figure 2 As shown in the embodiments disclosed herein, the anomaly monitoring system includes a first-layer monitoring unit, a second-layer monitoring unit, and a third-layer monitoring unit, which are respectively deployed in the first subsystem, the second subsystem, and the system running on the MCU of the SoC. The SoC may have multiple first subsystems, each with one first-layer monitoring unit deployed. The SoC has one second subsystem, and the second-layer monitoring unit deployed on the second subsystem monitors not only the operational anomalies of each first subsystem but also the operational anomalies within the second subsystem itself.

[0076] In step 502, if an operational anomaly occurs in the first subsystem, the first-level monitoring unit determines the anomaly type of the operational anomaly.

[0077] The exception type in this disclosure refers to the category of runtime exceptions classified according to specific rules.

[0078] In one implementation of exception types, runtime exceptions can be categorized according to their severity. For example, based on increasing severity, exception types could be: warning-level exceptions, error-level exceptions, and fatal error-level exceptions. An example is:

[0079] Warning-level anomalies are generally defined as operational anomalies that do not affect the normal operation of the SoC, such as SRAM ECC 1-bit error. Although an operational anomaly occurs, the subsystem can repair itself according to the parity check mechanism.

[0080] Error-level exceptions are generally defined as operational exceptions that the first subsystem cannot repair itself locally, such as SRAM ECC2-bit errors. These types of errors may cause immediate failures or may not cause failures for a considerable period of time.

[0081] Fatal error-level exceptions are generally defined as operational exceptions that will quickly cause the entire SoC system or any subsystem to become inoperable. For example, a Watchdog Timer interrupt. If the Watchdog Timer times out, it usually means that the system has frozen and can only be reset.

[0082] In another implementation of the anomaly type, operational anomalies can be categorized based on the reporting object. For example, there could be a first reporting type and a second reporting type. The first reporting type is set to report operational anomalies to the second-level monitoring unit, and the second reporting type is set to report operational anomalies to the third-level monitoring unit. The reporting object needs to be pre-defined based on the hardware and software characteristics of the second subsystem and the MCU, as well as the repair efficiency of various operational anomalies.

[0083] In practical applications, the classification of exception types can be determined according to actual needs, and no restrictions are imposed here.

[0084] When the second-level monitoring unit receives an operational anomaly reported by the first-level monitoring unit, the second-level monitoring unit determines whether the anomaly is one that the first-level monitoring unit can repair. If so, it starts a third timer. When the anomaly is repaired, the third timer stops. When the third timer exceeds the reporting time limit, the second-level monitoring unit reports the operational anomaly to the third-level monitoring unit. The third timer represents the time taken by the first-level monitoring unit to repair the operational anomaly, as counted by the second-level monitoring unit. If the time exceeds the preset reporting time limit, the corresponding operational anomaly is reported to the third-level monitoring unit.

[0085] In step 503, the first-level monitoring unit selects to report the operational anomaly to the second-level monitoring unit or the third-level monitoring unit according to the anomaly type of the operational anomaly; wherein the second-level monitoring unit runs in the second subsystem, and the third-level monitoring unit runs in the MCU.

[0086] Taking anomaly types categorized by severity as an example (i.e., anomaly types include: warning-level anomalies, error-level anomalies, and fatal error-level anomalies), fatal error-level anomalies are required to be reported to the third-level supervisory unit (i.e., only the third-level supervisory unit is configured with an anomaly repair mechanism corresponding to fatal error-level anomalies, or only the third-level supervisory unit has the ability to repair fatal error-level anomalies). If the anomaly type is determined to be a warning-level or error-level anomaly, the first-level supervisory unit chooses to report the runtime anomaly to the second-level supervisory unit.

[0087] The anomaly monitoring method described in this embodiment allows the first-level monitoring unit to selectively report some operational anomalies to the second-level monitoring unit (i.e., some operational anomalies can be repaired in the second-level monitoring unit), eliminating the need to report all operational anomalies to the MCU and reducing the MCU's processing load. Furthermore, each subsystem has a monitoring unit capable of independently reporting operational anomalies, enabling the higher-level monitoring unit to accurately locate the subsystem from which the anomaly occurred. This allows for targeted repair operations (e.g., reset) of the affected subsystem, avoiding the need for a full SoC reset due to anomalies in only a few subsystems.

[0088] In practical applications, there are multiple ways to report operational anomalies. This disclosure provides another embodiment where at least two reporting methods can be selected and executed simultaneously to create safety redundancy. Furthermore, if both hardware and software reporting mechanisms exist, the software method can be used to update the interrupt status of the hardware circuit caused by operational anomalies, enabling the third-level supervisory unit running in the MCU to maintain the current operational status of each subsystem in the SoC in a timely manner. Please refer to [link to relevant documentation]. Figure 6 , Figure 6 An exemplary method flowchart of an anomaly monitoring method according to another embodiment of this disclosure is shown.

[0089] In step 601, the first-level supervisory unit detects a fatal error-level anomaly in the first subsystem.

[0090] In this disclosed embodiment, the first-level supervisory unit reports the fatal error-level exception simultaneously through both FMU mode (the a-process corresponding to 602a to 606a below) and heartbeat mode (the b-process corresponding to 602b to 606b below).

[0091] In step 602a, the first-level supervisory unit determines the hardware FMU signal corresponding to the fatal error level exception and sets the hardware FMU signal to a high level.

[0092] In step 603a, the second-level monitoring unit sets the Error pin to a high level based on the high-level hardware FMU signal.

[0093] For example, you can refer to Figure 4 When the corresponding FMU signal in the first subsystem is set to high level, the high-level FMU signal in the first subsystem will be propagated to the higher-level FMU signal. When the highest-level FMU signal is set to high level, the Error pin connected to the SoC and MCU will also be pulled to high level.

[0094] In step 604a, the third-layer supervision unit detects an operational anomaly in the SoC through the Error pin and starts the second timer.

[0095] The second timer starts counting when the Error pin is set high, waiting for the operational exception to be repaired. This second timer is a timer that tracks the duration of the wait for exception repair, as recorded by the third-level monitoring unit.

[0096] In step 605a, the third-level monitoring unit determines whether the second timer has exceeded the second repair time limit.

[0097] When the second timer exceeds the second repair time limit, step 606a is executed, and the third-level supervisory unit runs the third anomaly repair mechanism. The second repair time limit is the maximum time threshold for the third-level supervisory unit to wait for anomaly repair. The third anomaly repair mechanism is a set of repair mechanisms for repairing operational anomalies in the first or second subsystem. When a fatal error-level anomaly occurs in the SoC, the first and second-level supervisory units often lack repair capabilities, and the operational anomaly remains unrepaired. Therefore, the Error pin remains high for an extended period. When the second repair time limit is exceeded, the third-level supervisory unit executes the third anomaly repair mechanism (e.g., resetting the corresponding first subsystem).

[0098] When the second timer exceeds the second repair time limit, step 607 is executed, and the third-level supervision unit determines that the operation abnormality has been repaired.

[0099] In step 602b, the first-level supervision unit periodically updates the current hardware state and updates the next heartbeat message.

[0100] If the system is still in an interrupted state, the information about the runtime exception will be encapsulated in the next heartbeat message.

[0101] If the status remains normal, the information indicating normal operation will be encapsulated in the next heartbeat message.

[0102] In step 603b, the second-level monitoring unit detects an operational anomaly in the first subsystem through a heartbeat message and reports the anomaly to the third-level monitoring unit through a heartbeat message.

[0103] In step 604b, the second-level monitoring unit determines whether the corresponding first subsystem has been repaired normally based on the current heartbeat packet message.

[0104] If so, then step 605b is executed, the second-level monitoring unit restores the Error pin to a low level, and feeds back a normal operation signal to the third-level monitoring unit through a heartbeat message.

[0105] If not, proceed to step 606b and wait for the third-level supervisory unit to execute the third anomaly repair mechanism.

[0106] In step 607, the third-level monitoring unit determines that the operational anomaly has been repaired.

[0107] In this disclosed embodiment, both FMU mode and heartbeat mode are executed simultaneously to form a security redundancy mechanism for reporting operational anomalies, thereby improving the security of the monitored chip system. Furthermore, through the heartbeat mode process, the second-layer monitoring unit can promptly learn that the corresponding operational anomaly has been corrected and update the Error pin in a timely manner. This allows the third-layer monitoring unit to also synchronize the information that the operational anomaly has been corrected, improving the monitoring efficiency of the anomaly monitoring system.

[0108] Accordingly, this disclosure also provides a vehicle in which the chip system is installed is monitored by the aforementioned anomaly monitoring system. The specific anomaly monitoring process can be found in the embodiments of the aforementioned anomaly monitoring system and method, and will not be repeated here.

[0109] It should be noted that, for the sake of brevity, this disclosure describes some methods and their embodiments as a series of actions and combinations thereof. However, those skilled in the art will understand that the solutions disclosed herein are not limited by the order of the described actions. Therefore, based on the disclosure or teachings of this document, those skilled in the art will understand that some steps can be performed in a different order or simultaneously. Furthermore, those skilled in the art will understand that the embodiments described in this disclosure can be considered optional embodiments, that is, the actions or modules involved are not necessarily essential for the implementation of one or more solutions disclosed herein. In addition, depending on the solution, the description of some embodiments in this disclosure may have different emphases. In view of this, those skilled in the art will understand that parts not described in detail in a certain embodiment of this disclosure can also be referred to the relevant descriptions of other embodiments.

[0110] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, method, or computer program product. Therefore, the present invention can be specifically implemented as entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system," etc. Furthermore, in some embodiments, the present invention can also be implemented as a computer program product contained in one or more computer-readable media, which contains computer-readable program code.

[0111] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (not exhaustive) of a computer-readable storage medium may include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0112] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0113] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0114] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0115] While numerous embodiments of this disclosure have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and intent of this disclosure. It should be understood that various alternatives to the embodiments of this disclosure described herein may be employed in the practice of this disclosure. The appended claims are intended to define the scope of this disclosure and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. An anomaly supervision system for supervising a chip system having a system on chip (SoC) having a plurality of first subsystems and a second subsystem, characterized in that, The abnormality supervision system comprises: a first layer supervision unit running in each first subsystem, configured to supervise running abnormalities of the first subsystem, and according to an abnormality type of the running abnormalities, select corresponding running abnormalities to be reported to a second layer supervision unit, so as to perform targeted repair operations on the subsystems with running abnormalities; wherein the abnormality type comprises a warning level abnormality, an error level abnormality and a fatal error level abnormality; and the second layer supervision unit running in the second subsystem, configured to collect running abnormalities of each subsystem in the system on chip. The chip system further comprises a microcontroller MCU, and the abnormality supervision system further comprises: a third layer supervision unit running in the microcontroller, configured to supervise running states of each subsystem in the system on chip according to the running abnormalities reported by the first layer supervision unit and / or the second layer supervision unit.

2. The abnormality supervision system according to claim 1, wherein the second layer supervision unit is further configured to report corresponding running abnormalities to the third layer supervision unit according to a processing state of the running abnormalities.

3. The abnormality supervision system according to claim 1, wherein the first layer supervision unit is further configured to report the running abnormalities to the second layer supervision unit or the third layer supervision unit according to the abnormality type of the running abnormalities.

4. The abnormality supervision system according to claim 3, wherein correspondingly, when the first layer supervision unit performs the reporting operation, it is further configured to: if the abnormality type of the running abnormalities is a warning level abnormality or an error level abnormality, report the running abnormalities to the second layer supervision unit; if the abnormality type of the running abnormalities is a fatal error level abnormality, report the running abnormalities to the third layer supervision unit.

5. The abnormality supervision system according to any one of claims 1 to 4, wherein when the first layer supervision unit performs the reporting operation, it is further configured to report the running abnormalities through at least one mode of a heartbeat packet mode, a fault management unit FMU mode and a Mailbox mode; and when the second layer supervision unit performs the reporting operation, it is further configured to report the running abnormalities through a heartbeat packet mode and / or an Error pin.

6. The abnormality supervision system according to claim 5, wherein the heartbeat packet mode comprises that a lower layer supervision unit periodically sends a heartbeat packet message to an upper layer supervision unit through a serial peripheral interface SPI bus; wherein the heartbeat packet message comprises a running state flag bit, and the running state flag bit indicates whether a corresponding subsystem has a running abnormality.

7. The abnormality supervision system according to claim 5, wherein the FMU mode comprises: an FMU in a first subsystem collects abnormality interrupt signals of hardware modules in the subsystem, and in response to an abnormality interrupt signal indicating a running abnormality, reports the running abnormality to an FMU in a second subsystem.

8. The abnormality supervision system according to any one of claims 1 to 4, wherein The first layer supervision unit is further configured to determine whether the operation exception is an exception that can be repaired by the first layer supervision unit, and if so, execute a first exception repair mechanism; The second layer supervision unit is further configured to determine whether the operation exception reported by the first layer supervision unit is an exception that can be repaired by the second layer supervision unit, and if so, execute a second exception repair mechanism; The third layer supervision unit is further configured to execute a third exception repair mechanism on the operation exception reported by the first layer supervision unit and / or the second layer supervision unit.

9. The exception supervision system of claim 8, wherein, The second layer supervision unit is further configured to start a first timer if the first layer supervision unit executes the first exception repair mechanism, and execute the second exception repair mechanism when the first timer exceeds a first repair time limit; The third layer supervision unit is further configured to start a second timer if the second layer supervision unit executes the second exception repair mechanism, and execute the third exception repair mechanism when the second timer exceeds a second repair time limit.

10. The exception supervision system of any one of claims 1 to 4, wherein, The first subsystem comprises a performance domain subsystem, a real-time domain subsystem, or a boot domain subsystem; The second subsystem comprises a security domain subsystem.

11. The abnormal supervision system according to any one of claims 1 to 4, characterized in that, The second subsystem runs in a processing core with a lockstep mechanism and a memory isolation mechanism.

12. An anomaly supervision method for supervising a chip system having a system on chip (SoC) having a plurality of first subsystems and a second subsystem, characterized by, The method comprises: The first layer supervision unit supervises operation exceptions of a first subsystem; wherein the first layer supervision unit runs in the first subsystem, and the first layer supervision unit corresponds to the first subsystem one-to-one; If an operation exception occurs in the first subsystem, the first layer supervision unit selects whether to report the operation exception to a second layer supervision unit according to an exception type of the operation exception, to perform a targeted repair operation on the subsystem that has the operation exception; wherein the second layer supervision unit runs in a second subsystem, and the exception type comprises a warning level exception, an error level exception, and a fatal error level exception; The third layer supervision unit runs in a microcontroller, and supervises operation states of each subsystem in the system on chip according to operation exceptions reported by the first layer supervision unit and / or the second layer supervision unit.

13. The method of claim 12, wherein, The first layer supervision unit selects whether to report the operation exception to the second layer supervision unit according to the exception type of the operation exception, comprising: The first layer supervision unit selects to report the operation exception to the second layer supervision unit or a third layer supervision unit according to the exception type of the operation exception.

14. The method of claim 13, wherein, Correspondingly, the first layer supervision unit selects to report the operation exception to the second layer supervision unit or the third layer supervision unit according to the exception type of the operation exception, comprising: If the exception type of the operation exception is a warning level exception or an error level exception, the operation exception is reported to the second layer supervision unit. If the abnormal type of the running abnormality is a fatal error level abnormality, the running abnormality is reported to the third layer supervision unit.

15. The method of claim 13, wherein, After the second layer supervision unit receives the running abnormality reported by the first layer supervision unit, the method further comprises: The second layer supervision unit determines whether the running abnormality is an abnormality that can be repaired by the first layer supervision unit, and if so, starts a third timer; When the running abnormality is repaired, the third timer stops timing; When the timing of the third timer exceeds the reporting time limit, the second layer supervision unit reports the running abnormality to the third layer supervision unit.

16. The method of claim 13, wherein, The method further comprises: The second layer supervision unit supervises the running abnormality of the second subsystem; If a running abnormality occurs in the second subsystem, the second layer supervision unit reports the running abnormality to the third layer supervision unit.

17. The method of claim 12, wherein, When the first layer supervision unit performs the reporting operation, the running abnormality is reported through at least one of a heartbeat packet mode, a fault management unit (FMU) mode, and a Mailbox mode.

18. The method of claim 16, wherein, When the second layer supervision unit performs the reporting operation, the running abnormality is reported through a heartbeat packet mode and / or an Error pin.

19. The method according to any one of claims 13 to 15, characterized in that, After determining that a running abnormality occurs in the first subsystem, the method further comprises: The first layer supervision unit determines whether the running abnormality is an abnormality that can be repaired by the first layer supervision unit, and if so, executes a first abnormality repair mechanism; The second layer supervision unit determines whether the running abnormality is an abnormality that can be repaired by the second layer supervision unit, and if so, executes a second abnormality repair mechanism; The third layer supervision unit executes a third abnormality repair mechanism on the running abnormality reported by the first layer supervision unit and / or the second layer supervision unit.

20. The method of claim 19, wherein, The method further comprises: If the first layer supervision unit executes the first abnormality repair mechanism, the second layer supervision unit starts a first timer after receiving the running abnormality reported by the first layer supervision unit, and executes the second abnormality repair mechanism when the timing of the first timer exceeds a first repair time limit; If the second layer supervision unit executes the second abnormality repair mechanism, the third layer supervision unit starts a second timer after receiving the running abnormality reported by the second layer supervision unit, and executes the third abnormality repair mechanism when the timing of the second timer exceeds a second repair time limit.

21. A computer-readable storage medium, characterized in that, A computer program code storing an abnormality supervision method, which, when executed, performs the method of any one of claims 12 to 20.

22. A vehicle characterized by The chip system loaded on the vehicle is supervised by the abnormality supervision system of any one of claims 1 to 11.

Images