A system analysis and architecture design method satisfying functional safety decomposition independence

Abstract

The application discloses a system analysis and architecture design method meeting functional safety decomposition independence, and completes a preliminary system safety architecture design; based on the preliminary system safety architecture, the object of the independence safety analysis is determined; the independence safety analysis is carried out based on multiple aspects including shared resources, shared information input, anti-environmental interference, system coupling, components of the same type and communication; if there is a common cause or a cascade failure in the independence safety analysis process, additional safety mechanisms or measures are added until the objects of the independence safety analysis are all completed, and the optimal system architecture is obtained. Based on the functional safety standard requirements, after the functional safety decomposition of the automobile electronic system, the independence analysis is carried out, the system architecture is continuously updated and iterated through continuous analysis, so that the time of the main function and the monitoring function of the system is independent of each other, and the common cause or the cascade failure is avoided.

Description

Technical Field

[0001] This invention relates to the technical field of automotive electronics, and in particular to a system analysis and architecture design method that satisfies the independence of functional safety decomposition. Background Technology

[0002] In 2000, the International Electrotechnical Commission (IEC) issued the international standard IEC 61508 for the functional safety of electronic, electrical, and programmable electronic systems. With the widespread application of safety-related electronic and electrical systems in automobiles, the automotive industry's demand for functional safety standards for electronic and electrical systems has become increasingly urgent. Therefore, ISO 26262, a functional safety standard specifically for automotive electronic and electrical systems, was also issued.

[0003] Functional safety has long been widely applied in the rail and aircraft industries. With the development of autonomous driving technology in recent years, the potential harm to people caused by electronic and electrical failures in automobiles under autonomous driving functions must be taken seriously. The design of functional safety systems for autonomous driving products has become a crucial aspect. Designing functional safety system solutions that meet the ISO 26262 standard while balancing system performance and enterprise costs is of paramount importance.

[0004] Currently, the most common approach in functional safety system design is a three-layer safety architecture-based functional safety decomposition scheme, such as... Figure 1 As shown. This safety design scheme has two main advantages:

[0005] I. Minimize the impact on the basic functions of the controller system. The technologies of various components and OEMs are constantly accumulating, gradually adding new functions on top of existing ones. Therefore, before functional safety is implemented, the application functions (hereinafter referred to as main functions) are already relatively mature. To minimize the impact on application functions, functional safety is separated from the system design to achieve this goal.

[0006] Second, independently analyze and design safety boundaries to ensure safety at the bottom line. Functional safety aims to minimize the harm caused by system failures, often sacrificing performance and user comfort. After functional safety decomposition, the functional monitoring layer only needs to focus on the safety boundaries of key parameters and perform fault detection and handling, without affecting the basic functions' performance and user comfort adjustments.

[0007] According to the requirements of ISO 26262 standard, after performing functional safety decomposition at the system design level, independence analysis is a necessary task to ensure that the main functions and monitoring functions are independent of each other and to avoid common causes or cascading failures. Summary of the Invention

[0008] The purpose of this invention is to meet the needs of the prior art and provide a system analysis and architecture design method that satisfies the independence of functional safety decomposition.

[0009] To achieve the above objectives, the technical solution provided by this invention is: a system analysis and architecture design method that satisfies the independence of functional safety decomposition, comprising:

[0010] Complete the initial version of the system security architecture design; the completed system security architecture includes the main functional layer, the functional monitoring layer, and the software runtime environment monitoring layer;

[0011] Based on the initial system security architecture, the objects of independent security analysis are determined to be: the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer.

[0012] Based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, components of the same type, and communication, independent security analysis is conducted on the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer, respectively.

[0013] During the independence security analysis, if common causes or cascading failures exist, additional security mechanisms or measures are added until the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer have all completed the independence security analysis, and the optimal system architecture is obtained.

[0014] To go further, the functional safety level of the main functional layer after functional safety decomposition is QM(X), the functional monitoring layer after functional safety decomposition is ASIL X(X), and the software operating environment monitoring layer after functional safety decomposition is ASILX.

[0015] Furthermore, based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, similar components, and communication, an independent security analysis is conducted on the main functional layer and the functional monitoring layer, including:

[0016] A1. Analyze whether there are common causes or cascading failures caused by shared resources. If so, proceed to step A7; otherwise, proceed to step A2.

[0017] A2. Analyze whether there are common causes or cascading failures caused by the input information. If so, proceed to step A7; otherwise, proceed to step A3.

[0018] A3. Analyze whether there are common causes or cascade failures caused by environmental factors. If so, proceed to step A7; otherwise, proceed to step A4.

[0019] A4. Analyze whether there are common causes or cascade failures due to system coupling. If so, proceed to step A7; otherwise, proceed to step A5.

[0020] A5. Analyze whether there are common causes or cascading failures caused by the same type of components. If so, proceed to step A7; otherwise, proceed to step A6.

[0021] A6. Analyze whether there are common causes or cascading failures caused by communication. If so, proceed to step A7; otherwise, the independence security analysis of the main functional layer and the functional monitoring layer ends.

[0022] A7. Add corresponding security mechanisms or control measures;

[0023] A8. Update and iterate the system security architecture based on the added security mechanisms or control measures, and return to step A1.

[0024] To go further, when analyzing whether there are common causes or cascading failures due to shared resources, the analysis should be conducted from three dimensions: system, hardware, and software.

[0025] When analyzing common causes or cascading failures due to shared resources, add the following corresponding security mechanisms or control measures:

[0026] System level:

[0027] When a power failure causes the entire system to fail, the power chip must meet ASIL X level, and the central controller unit must monitor the external power supply.

[0028] In the event of a communication error, the data is protected using end-to-end (E2E) technology.

[0029] Hardware level:

[0030] When a clock malfunction causes timing errors, monitor the external clock.

[0031] When there is an error in the digital or analog input / output, dual-channel acquisition is used to perform E2E data verification.

[0032] Software level:

[0033] When shared software modules are present, a validity check should be performed.

[0034] When an I / O driver error occurs, the driver module must meet ASIL X level.

[0035] When shared variable parameters cause incorrect assignments, data redundancy backups, design reviews, and static code analysis should be implemented.

[0036] To go further, when analyzing whether there are common causes or cascading failures due to environmental factors, the analysis should be conducted from both system and hardware perspectives.

[0037] System level:

[0038] Will interference from external factors, including temperature, humidity, light, and vibration, cause the main functional layer to affect the functional monitoring layer during system operation?

[0039] Hardware level:

[0040] Analyze the characteristics of the circuit and the factors of the same material and covering.

[0041] To go further, when analyzing whether there are common causes or cascading failures due to system coupling, the analysis should be conducted from both system and software perspectives.

[0042] When the analysis reveals common-cause or cascading failures due to system coupling, the following corresponding safety mechanisms or control measures should be added:

[0043] System level:

[0044] When different factors lead to the same product failure through a completely identical production process, necessary quality certification must be performed.

[0045] When the repair processes for different elements are completely consistent, the requirements of production, maintenance, and release standards are met.

[0046] Software level:

[0047] When shared software tools are available, the development tools for ASIL modules need to be rated by TCL.

[0048] When the same modeling programming language is used, establish consistent modeling or coding standards;

[0049] When the same compiler is available, the compilation and integration tools perform TCL rating, design review, and static code analysis.

[0050] To go further, when analyzing whether there are common causes or cascading failures due to the influence of the same type of components, the analysis should be conducted from three dimensions: system, hardware, and software.

[0051] When the analysis reveals common-cause or cascading failures caused by the same type of components, the following corresponding safety mechanisms or control measures should be added:

[0052] System level:

[0053] When a common cause or cascading failure occurs due to actuators of the same type, actuator redundancy is implemented, diagnostic feedback is provided from the actuator end, and the actuator end performs self-diagnosis.

[0054] When a common cause or cascade failure is caused by the same type of sensor, different types of sensor inputs are used, the validity of the input is judged, and the sensor self-diagnoses.

[0055] Hardware level:

[0056] When using a shared clock, monitor the external clock.

[0057] When sharing a microcontroller, the MCU diagnostic mechanism is executed;

[0058] When sharing digital and analog inputs and outputs, dual-channel acquisition is used to perform E2E data verification;

[0059] Software level:

[0060] When the same source code is available, the main function and the function monitoring layer use heterogeneous algorithms and maintain software core partitioning.

[0061] Going further afield, when the analysis reveals common causes or cascading failures due to communication, security mechanisms or controls include E2E protection, ECC verification, and control flow / procedure flow checks.

[0062] Going further, after analyzing whether there are common causes or cascading failures due to communication, it also includes undefined or unsummarized common causes or cascading failures, such as time synchronization anomalies, unreasonable resource allocation, and software partitioning errors.

[0063] The beneficial effects of implementing this invention are as follows:

[0064] Based on functional safety standards, the functional safety of automotive electronic systems is decomposed and independence analysis is performed. Through continuous analysis, the system architecture is continuously updated and iterated to ensure that the main functions and monitoring functions of the system are independent of each other in time, and to avoid common causes or cascading failures. Attached Figure Description

[0065] Figure 1 This is the three-layer security architecture adopted in this invention;

[0066] Figure 2 Here is a system example that incorporates a three-tier security architecture;

[0067] Figure 3 This is a flowchart illustrating the principles of system analysis and architecture design based on the main functional layer and the functional monitoring layer. Detailed Implementation

[0068] The present invention will be further described below with reference to specific embodiments:

[0069] This embodiment provides a system analysis and architecture design method that satisfies the independence of functional safety decomposition, including the following steps:

[0070] S1. Complete the initial version of the system security architecture design, specifically as follows: Figure 2As shown, it includes external sensor inputs, a central controller unit, and actuators. For the central controller unit, hardware peripherals include power supply, clock, memory, and digital / analog input / output devices.

[0071] According to the requirements of ISO 26262 standard, to satisfy the coexistence of elements, QM modules cannot affect ASIL modules, and low ASIL level modules cannot affect high ASIL level modules.

[0072] The completed system security architecture includes a main functional layer, a functional monitoring layer, and a software runtime environment monitoring layer;

[0073] in,

[0074] The main functional layer includes modules for perception fusion, planning and decision-making, and control execution in the autonomous driving system. After functional safety decomposition, its level is QM(X). It should be noted that, to minimize the impact of functional safety applications on the original application functions, the main functional layer can maintain independent design and analysis.

[0075] After functional safety decomposition, the functional monitoring layer is classified as ASIL X(X). The specific decomposition principle is explained and the standard requirements are given in ISO 26262-9-2018, and will not be repeated in this embodiment.

[0076] The software runtime environment monitoring layer, after functional safety decomposition, is classified as ASIL X.

[0077] S2. Based on the initial system security architecture, the objects of independent security analysis are determined to be: the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer.

[0078] S3. Based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, components of the same type, and communication, independence security analysis is performed on the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer, respectively. During the independence security analysis, if common causes or cascading failures exist, additional security mechanisms or measures are added until the independence security analysis of the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer are all completed, and the optimal system architecture is obtained.

[0079] like Figure 3 As shown, based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, similar types of components, and communication, an independent security analysis is conducted on the main functional layer and the functional monitoring layer, including:

[0080] A1. Analyze whether there are common causes or cascading failures caused by shared resources. If so, proceed to step A8; otherwise, proceed to step A2.

[0081] A2. Analyze whether there are common causes or cascading failures caused by the input information. If so, proceed to step A8; otherwise, proceed to step A3.

[0082] A3. Analyze whether there are common causes or cascade failures caused by environmental factors. If so, proceed to step A8; otherwise, proceed to step A4.

[0083] A4. Analyze whether there are common causes or cascade failures due to system coupling. If so, proceed to step A8; otherwise, proceed to step A5.

[0084] A5. Analyze whether there are common causes or cascading failures caused by the same type of components. If so, proceed to step A8; otherwise, proceed to step A6.

[0085] A6. Analyze whether there is a common cause or cascading failure due to communication. If so, proceed to step A8; otherwise, proceed to step A7.

[0086] A7. Analyze whether there are undefined or unsummarized common causes or cascading failures. If so, proceed to step A8; otherwise, the independence security analysis of the main functional layer and the functional monitoring layer ends.

[0087] A8. Add corresponding security mechanisms or control measures;

[0088] A9. Update and iterate the system security architecture based on the added security mechanisms or control measures, and return to step A1.

[0089] In the above analysis, when analyzing whether there are common causes or cascading failures due to shared resources, the analysis is conducted from three dimensions: system, hardware, and software.

[0090] When analyzing common causes or cascading failures due to shared resources, add the following corresponding security mechanisms or control measures:

[0091] System level:

[0092] When a power failure causes the entire system to fail, the power chip must meet ASIL X level, and the central controller unit must monitor the external power supply.

[0093] In the event of a communication error, the data is protected using end-to-end (E2E) technology.

[0094] Hardware level:

[0095] When a clock malfunction causes timing errors, monitor the external clock.

[0096] When there is an error in the digital or analog input / output, dual-channel acquisition is used to perform E2E data verification.

[0097] Software level:

[0098] When shared software modules are present, a validity check should be performed.

[0099] When an I / O driver error occurs, the driver module must meet ASIL X level.

[0100] When shared variable parameters cause incorrect assignments, data redundancy backups, design reviews, and static code analysis should be implemented.

[0101] The common information inputs mentioned above mainly involve a common external CAN bus, Ethernet input, RTE layer information, and internal hardware and software signals. The most significant common cause or cascaded failure point is the external sensor input. Figure 2 In the system security architecture, external signals are input to the main function (QM(X)) and the function monitoring layer (ASIL X(X)) for processing, and are processed separately at the software and hardware levels, which can meet the independence requirements.

[0102] In the above analysis, when analyzing whether there are common causes or cascading failures due to environmental factors, the analysis is conducted from two dimensions: system and hardware.

[0103] System level:

[0104] Will interference from external factors, including temperature, humidity, light, and vibration, cause the main functional layer to affect the functional monitoring layer during system operation?

[0105] Hardware level:

[0106] Analyze the characteristics of the circuit and the factors of the same material and covering.

[0107] In the above analysis, when analyzing whether there are common causes or cascading failures due to system coupling, the analysis is conducted from two dimensions: system and software.

[0108] When the analysis reveals common-cause or cascading failures due to system coupling, the following corresponding safety mechanisms or control measures should be added:

[0109] System level:

[0110] When different factors lead to the same product failure through a completely identical production process, necessary quality certification must be performed.

[0111] When the repair processes for different elements are completely consistent, the requirements of production, maintenance, and release standards are met.

[0112] Software level:

[0113] When shared software tools are available, the development tools for ASIL modules need to be rated by TCL.

[0114] When the same modeling programming language is used, establish consistent modeling or coding standards;

[0115] When the same compiler is available, the compilation and integration tools perform TCL rating, design review, and static code analysis.

[0116] In the above analysis, when analyzing whether there are common causes or cascading failures due to the influence of the same type of components, the analysis is carried out from three dimensions: system, hardware, and software.

[0117] When the analysis reveals common-cause or cascading failures caused by the same type of components, the following corresponding safety mechanisms or control measures should be added:

[0118] System level:

[0119] When a common cause or cascading failure occurs due to actuators of the same type, actuator redundancy is implemented, diagnostic feedback is provided from the actuator end, and the actuator end performs self-diagnosis.

[0120] When a common cause or cascade failure is caused by the same type of sensor, different types of sensor inputs are used, the validity of the input is judged, and the sensor self-diagnoses.

[0121] Hardware level:

[0122] When using a shared clock, monitor the external clock.

[0123] When sharing a microcontroller, the MCU diagnostic mechanism is executed;

[0124] When sharing digital and analog inputs and outputs, dual-channel acquisition is used to perform E2E data verification;

[0125] Software level:

[0126] When the same source code is available, the main function and the function monitoring layer use heterogeneous algorithms and maintain software core partitioning.

[0127] In the above analysis, when there are common causes or cascading failures due to communication, security mechanisms or control measures include E2E protection, ECC verification, and control flow / program flow checks.

[0128] Similarly, in the same way, independence analysis is performed on the main functional layer (QM(X)) and the software runtime environment monitoring layer (ASIL X), and the monitoring functional layer (ASIL X(X)) and the software runtime environment monitoring layer (ASIL X). After identifying the relevant failures, corresponding security mechanisms are added, and the entire system design is updated to meet the functional safety requirements.

[0129] The above-described embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Therefore, any changes made in accordance with the shape and principle of the present invention should be covered within the protection scope of the present invention.

Claims

1. A system analysis and architecture design method that satisfies the independence of functional safety decomposition, characterized in that, include: Completed the initial version of the system security architecture design; The completed system security architecture includes a main functional layer, a functional monitoring layer, and a software runtime environment monitoring layer; Based on the initial system security architecture, the objects of independent security analysis are determined to be: the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer. Based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, components of the same type, and communication, independent security analysis is conducted on the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer, respectively. During the independence security analysis, if common causes or cascading failures exist, additional security mechanisms or measures are added until the main functional layer and the functional monitoring layer, the main functional layer and the software runtime environment monitoring layer, and the functional monitoring layer and the software runtime environment monitoring layer have all completed the independence security analysis, and the optimal system architecture is obtained. Based on multiple aspects including shared resources, shared information input, resistance to environmental interference, system coupling, similar components, and communication, an independent security analysis is conducted on the main functional layer and the functional monitoring layer, including: A1. Analyze whether there are common causes or cascading failures caused by shared resources. If so, proceed to step A7; otherwise, proceed to step A2. A2. Analyze whether there are common causes or cascading failures caused by the input information. If so, proceed to step A7; otherwise, proceed to step A3. A3. Analyze whether there are common causes or cascade failures caused by environmental factors. If so, proceed to step A7; otherwise, proceed to step A4. A4. Analyze whether there are common causes or cascade failures due to system coupling. If so, proceed to step A7; otherwise, proceed to step A5. A5. Analyze whether there are common causes or cascading failures caused by the same type of components. If so, proceed to step A7; otherwise, proceed to step A6. A6. Analyze whether there are common causes or cascading failures caused by communication. If so, proceed to step A7; otherwise, the independence security analysis of the main functional layer and the functional monitoring layer ends. A7. Add corresponding security mechanisms or control measures; A8. Update and iterate the system security architecture based on the added security mechanisms or control measures, and return to step A1; When analyzing whether there are common causes or cascading failures due to the influence of the same type of components, the analysis should be conducted from three dimensions: system, hardware, and software. When the analysis reveals common-cause or cascading failures caused by the same type of components, the following corresponding safety mechanisms or control measures should be added: System level: When a common cause or cascading failure occurs due to actuators of the same type, actuator redundancy is implemented, diagnostic feedback is provided from the actuator end, and the actuator end performs self-diagnosis. When a common cause or cascade failure is caused by the same type of sensor, different types of sensor inputs are used, the validity of the input is judged, and the sensor self-diagnoses. Hardware level: When using a shared clock, monitor the external clock. When sharing a microcontroller, the MCU diagnostic mechanism is executed; When sharing digital and analog inputs and outputs, dual-channel acquisition is used to perform E2E data verification; Software level: When the same source code is available, the main function and the function monitoring layer use heterogeneous algorithms and maintain software core partitioning.

2. The system analysis and architecture design method that satisfies the independence of functional safety decomposition according to claim 1, characterized in that, The functional safety level of the main functional layer after functional safety decomposition is QM(X), the functional monitoring layer after functional safety decomposition is ASIL X(X), and the software runtime environment monitoring layer after functional safety decomposition is ASIL X.

3. The system analysis and architecture design method that satisfies functional safety decomposition independence according to claim 1, characterized in that, When analyzing whether there are common causes or cascading failures due to shared resources, the analysis should be conducted from three dimensions: system, hardware, and software. When analyzing common causes or cascading failures due to shared resources, add the following corresponding security mechanisms or control measures: System level: When a power failure causes the entire system to fail, the power chip must meet ASIL X level, and the central controller unit must monitor the external power supply. In the event of a communication error, the data is protected using end-to-end (E2E) technology. Hardware level: When a clock malfunction causes timing errors, monitor the external clock. When there is an error in the digital or analog input / output, dual-channel acquisition is used to perform E2E data verification. Software level: When shared software modules are present, a validity check should be performed. When an I / O driver error occurs, the driver module must meet ASIL X level. When shared variable parameters cause incorrect assignments, data redundancy backups, design reviews, and static code analysis should be implemented.

4. The system analysis and architecture design method that satisfies the independence of functional safety decomposition according to claim 1, characterized in that, When analyzing whether there are common causes or cascading failures due to environmental factors, the analysis should be conducted from two dimensions: system and hardware. System level: Will interference from external factors, including temperature, humidity, light, and vibration, cause the main functional layer to affect the functional monitoring layer during system operation? Hardware level: Analyze the characteristics of the circuit and the factors related to the same material and covering.

5. A system analysis and architecture design method that satisfies functional safety decomposition independence according to claim 1, characterized in that, When analyzing whether there are common causes or cascading failures due to system coupling, the analysis should be conducted from both system and software perspectives. When the analysis reveals common-cause or cascading failures due to system coupling, the following corresponding safety mechanisms or control measures should be added: System level: When different factors lead to the same product failure through a completely identical production process, necessary quality certification must be performed. When the repair processes for different elements are completely consistent, the requirements of production, maintenance, and release standards are met. Software level: When shared software tools are available, the development tools for ASIL modules need to be rated by TCL. When the same modeling programming language is used, establish consistent modeling or coding standards; When the same compiler is available, the compilation and integration tools perform TCL rating, design review, and static code analysis.

6. A system analysis and architecture design method that satisfies functional safety decomposition independence according to claim 1, characterized in that, When analysis reveals common-cause or cascading failures due to communication, security mechanisms or controls include E2E protection, ECC verification, and control flow / procedure flow checks.

7. A system analysis and architecture design method that satisfies functional safety decomposition independence according to any one of claims 1-6, characterized in that, After analyzing whether there are common causes or cascading failures due to communication issues, it also includes undefined or unsummarized common causes or cascading failures, such as time synchronization anomalies, unreasonable resource allocation, and software partitioning errors.

Images