Functional Safety Methods for ECU Hardware Evaluation and Integration Verification

Author | Unknown

Produced by | Automotive Electronics and Software

#01Overview

Following ISO26262-5, the functional safety method requires not only an analysis of the hardware safety requirements and hardware design of the ECU, but also the evaluation and verification of the ECU hardware. This primarily includes the security assessment of the hardware architecture, which involves a comprehensive analysis of the hardware topology, including failure modes, the impact of failure modes on safety objectives, failure rates and distributions, safety mechanisms for failure modes, and the fault coverage capability of safety mechanisms. During the assessment, industry-recognized data, field data, actual operational historical data, and evaluations by industry experts must be used to ensure the accuracy and reliability of the data.

#02Hardware Architecture Metric Evaluation

2.1 Objectives and Content

The core purpose of evaluating hardware architecture metrics is to deeply analyze and verify the ability of the hardware architecture design to cope with random hardware failures. This evaluation process provides solid quantitative evidence for the effectiveness of the hardware architecture through a series of carefully designed hardware architecture metrics, ensuring that it can fully meet the high standards required for functional safety. Specifically, these key metrics include Single Point Fault Metric (SPFM) and Latent Fault Metric (LFM), which together assess the extensive coverage of the hardware architecture for single point faults and latent faults, providing strong support for the overall reliability of the system.

The comprehensive evaluation of hardware architecture metrics mainly revolves around the following two crucial core metrics:

Single Point Fault Metric (SPFM): This metric focuses on measuring the coverage of the hardware architecture in the face of single point faults and the residual faults they may cause. A higher SPFM value not only indicates that the hardware architecture can demonstrate excellent fault tolerance and recovery capabilities when encountering single point faults, but also reflects its high robustness in design, effectively reducing the risk of overall system failure due to single point failures.

Latent Fault Metric (LFM): This metric focuses on assessing the hardware architecture’s ability to identify and respond to latent faults. Latent faults are often difficult to predict and are highly concealed, while a high LFM value indicates that the hardware architecture has fully considered these potential threats during design, significantly enhancing the system’s resistance to latent faults through redundancy design, fault detection, and isolation mechanisms, ensuring that the system can operate continuously and stably.

2.2 Calculation of Hardware Evaluation Metrics

The calculation of hardware architecture metrics is based on the failure rates of hardware components and the diagnostic coverage of safety mechanisms. The specific calculation methods are as follows:

Single Point Fault Metric (SPFM):

Where:

λSPF is the failure rate of single point faults;

λRF is the failure rate of residual faults;

λSR,HW is the total failure rate of safety-related hardware components.

Latent Fault Metric (LFM):

Where:

λMPF,L is the failure rate of latent faults

2.3 Evaluation of Hardware Architecture Metrics

ASIL levels serve as key indicators for measuring automotive functional safety, directly determining the performance requirements of the hardware architecture in response to potential faults. For different ASIL levels, SPFM and LFM set clear target values to ensure that the hardware architecture meets the corresponding safety standards:

ASIL B: This level requires the hardware architecture to have high reliability, with SPFM needing to reach 90% or above, and LFM needing to be no less than 60%. This means that under the ASIL B level, the hardware architecture should effectively cope with the vast majority of single point faults and maintain a certain level of prevention against latent faults.

ASIL C: With the increase in safety requirements, the ASIL C level imposes higher demands on the fault tolerance of the hardware architecture. SPFM needs to reach 97% or above, while LFM needs to reach 80% or above. This setting ensures that the hardware architecture can maintain stable operation under extreme conditions, significantly reducing safety risks due to failures.

ASIL D: As the highest level, ASIL D has almost stringent safety requirements for the hardware architecture. SPFM needs to reach 99% or above, while LFM needs to reach 90% or above. This indicates that under the ASIL D level, the hardware architecture can almost completely resist single point faults and latent faults, providing the highest level of safety assurance for passengers.

However, in practical applications, the hardware architecture may not directly meet these target values. Therefore, the ISO26262-5 standard provides two alternative methods:

Allocation of Target Values: By refining and allocating target values to each hardware component level and providing rational explanations for each component to meet these target values, the overall safety performance of the architecture can be ensured.
Diagnostic Coverage: For fault detection-based safety mechanisms, diagnostic coverage can be used as an alternative metric to assess the system’s ability to identify and respond to faults.

During the verification phase of hardware architecture metrics, ensuring the correctness and completeness of the calculation process is crucial. The verification process must cover the following aspects:

Reasonableness of Data Sources: Ensure that failure rate data comes from reliable industry standards or statistical analyses to guarantee the accuracy and authority of the data.

Accuracy of Calculation Processes: Rigorously review the correctness of calculation formulas and parameters to ensure the authenticity and reliability of the calculation results.

Compliance of Target Values: The final calculation results must align with the requirements of the ASIL levels to ensure that the hardware architecture meets the corresponding functional safety standards.

#03Assessment of Safety Goal Violations Due to Random Hardware Failures

In addition to ensuring the effectiveness of the hardware architecture in meeting safety goals through hardware architecture metrics evaluation, attention must also be paid to random hardware failures and their impact on safety goals, demonstrating that the risk of safety goal violations due to random hardware failures is sufficiently low. This assessment ensures that the hardware design maintains functional safety in the face of random failures.

3.1 Assessment Methods

The assessment methods for safety goal violations due to random hardware failures constitute a core aspect of functional safety assessment, mainly including the following two complementary assessment approaches:

Probability Metric of Random Hardware Failure (PMHF): This method focuses on precisely assessing the potential impact of hardware failures on established safety goals through quantitative analysis. It requires us to scientifically and reasonably calculate the probability of hardware failures based on a deep understanding of hardware failure mechanisms and to judge the specific threat level to system safety.

Evaluation of Each Cause for Safety Goal Violation (EEC): This method places greater emphasis on a detailed analysis of hardware failures, requiring us to investigate each potential hardware failure individually and analyze its specific impact on safety goals, ensuring that we can comprehensively capture all possible safety hazards and avoid missing any potential failure paths that could lead to safety goal violations.

PMHF Assessment

The process is as follows:

Define Target Values: Based on the different ASIL levels, we set clear target values for PMHF. For example, at the ASIL B level, we require PMHF to be less than 10^-7 per hour; while at the more stringent ASIL D level, this standard is raised to PMHF less than 10^-8 per hour, ensuring that the probability of hardware failures meets the corresponding safety requirements at different safety levels.
Failure Rate Calculation: In this step, we need to accurately calculate the failure rates of hardware components and fully consider the impact of the diagnostic coverage of safety mechanisms on fault detection efficiency to derive more accurate failure probability values.
Exposure Time Assessment: Additionally, we need to conduct a comprehensive assessment of the exposure time of failures, including the time from occurrence to detection, the actual driving time of the vehicle, and the time required for repairs, to ensure that we can fully grasp the actual impact that failures may cause.

EEC Assessment

EEC assessment focuses more on a detailed analysis of hardware failures:

Failure Classification: We first classify hardware failures into different types such as single point failures, residual faults, and latent faults to more accurately locate and analyze the causes of failures.
Failure Assessment: Subsequently, we assess each failure individually, deeply analyzing its specific impact on safety goals to ensure that we can comprehensively capture all possible failure paths that could lead to safety goal violations.
Diagnostic Coverage Assessment: Finally, we also need to assess the diagnostic coverage of safety mechanisms to ensure that failures can be detected and handled in a timely and effective manner, further reducing the potential threat of failures to system safety.

3.2 Validation of Assessment Results

To ensure the technical correctness and completeness of the assessment results, we also need to strictly validate the assessment results:

Reasonableness of Data Sources: We will carefully check the sources of failure rate data and diagnostic coverage data to ensure their authenticity and reliability.
Accuracy of Calculation Processes: We will repeatedly verify the correctness of calculation formulas and parameters to avoid distortion of assessment results due to calculation errors.
Compliance of Target Values: We will also compare the assessment results with the requirements of ASIL levels one by one to ensure that the assessment results fully meet the established safety standards.

#04Hardware Integration and Verification

4.1 Objectives

To ensure that the developed hardware components strictly adhere to and meet the established hardware safety requirements, thereby ensuring the functional safety and reliability of the entire automotive electronic and electrical system. The achievement of this goal relies on hardware integration and verification activities, which aim to efficiently integrate various hardware components into the system and verify through rigorous testing processes whether they meet the expected functional safety standards.

The implementation of hardware integration and verification work relies on input information. The inputs for hardware integration and verification mainly include the following aspects:

Hardware Safety Requirements Specification: It clearly lists all safety requirements that hardware components must meet. These requirements cover specific standards for hardware in terms of functionality, performance, reliability, and fault response, providing clear guidance and constraints for hardware design and verification.
Hardware Design Specification: It describes various aspects of hardware design, including hardware architecture, component selection, connection methods, signal transmission paths, etc. It serves not only as a work guide for the hardware design team but also as an important reference for the hardware integration and verification team during the verification process. By reviewing the hardware design specification, the verification team can gain a comprehensive understanding of the details of the hardware design, ensuring the comprehensiveness and accuracy of the verification process.
Hardware Safety Analysis Report: This report is a conclusive document derived from the safety analysis of the hardware. It details potential issues, risks, and corresponding countermeasures regarding hardware safety. The hardware safety analysis report provides valuable safety information for the hardware integration and verification team, helping them focus on key areas that may affect hardware safety during the verification process, ensuring that the hardware can meet established safety requirements after integration and verification.

4.2 Verification Methods

It is necessary to adopt diversified and systematic verification methods to ensure the reliability and safety of the hardware, specifically including the following core aspects:

Functional Testing: This phase aims to comprehensively verify whether the hardware components perform all functions accurately as expected under normal operating conditions. By simulating actual working scenarios, it checks whether the hardware can achieve all the functional characteristics specified in the design, ensuring its efficiency and stability during normal operation.

Fault Injection Testing: To deeply assess the robustness and fault tolerance mechanisms of the hardware, this test artificially injects predefined fault conditions into the system, observing and recording the hardware’s detection, response, and handling processes for these abnormal situations. This process is crucial for revealing potential vulnerabilities in fault handling and helps enhance the overall safety and reliability of the system.

Electrical Testing: This test focuses on the electrical performance of the hardware within specified voltage and current ranges, including key parameters such as current consumption, voltage stability, and signal integrity. Through precise measurement and analysis, it ensures that the hardware meets design requirements at the electrical level, avoiding failures caused by electrical incompatibility or exceeding limits.

The specific verification process can be divided into the following stages:

Develop Testing Plans: Based on the hardware’s safety requirements and functional specifications, carefully plan and develop a detailed testing plan. This plan should cover all necessary testing scenarios, expected results, resource allocation, and timelines, providing clear guidance for subsequent testing execution.
Execute Tests: Strictly follow the testing plan to implement functional testing, fault injection testing, and electrical testing one by one. During the testing process, ensure the controllability and consistency of the testing environment to accurately assess hardware performance.
Result Analysis: Conduct in-depth analysis of the collected testing data, comparing expected results with actual performance to confirm whether the hardware meets established safety standards and functional requirements.
Problem Resolution: For any issues or non-conformities identified during testing, promptly develop and implement effective solutions, followed by retesting to verify whether the issues have been adequately resolved.

The final results of the verification activities must be systematically recorded in the form of a verification report, which should be detailed and clearly structured, mainly including:

Testing Plans and Test Cases: Elaborate on the logic behind the development of the testing plan, testing objectives, testing strategies, and specific test case designs, providing readers with comprehensive background information on the testing.
Summary of Testing Results: Objectively record the execution status and results of each test, detailing both successful test cases and failures to facilitate subsequent problem tracking and improvement.
Problem Analysis and Solutions: For any issues identified during testing, conduct in-depth analysis of their root causes, propose and implement targeted solutions, and record the effectiveness of the solutions to ensure that all issues are effectively managed.

#05Practical Cases and Applications

5.1 Case Background

Assuming we are developing an automotive electronic control system that includes an MCU, multiple sensors, and actuators. The goal of this system is to achieve the vehicle’s AEB function, with the safety goal being “to ensure that the vehicle initiates braking within 100 milliseconds upon detecting an obstacle ahead.”

5.2 Evaluation of Hardware Architecture Metrics

Calculation of Hardware Architecture Metrics

We designed a hardware architecture that includes redundant sensors and backup actuators. The microcontroller adopts a dual-core lockstep architecture to enhance reliability. Each hardware component is developed according to the highest ASIL level assigned to it.

We calculated the SPFM and LFM metrics of the hardware architecture:

SPFM: By analyzing the failure rates of hardware components and the diagnostic coverage of safety mechanisms, the SPFM value was calculated to be 98%.

LFM: By analyzing the failure rates of latent faults, the LFM value was calculated to be 92%.

Verification of calculation results ensures that they meet the requirements of ASIL D level (SPFM ≥ 99%, LFM ≥ 90%). Although the SPFM value is slightly below the target value, by increasing redundancy design and optimizing safety mechanisms, the requirements were ultimately met.

5.3 Assessment of Safety Goal Violations

PMHF Assessment

We defined the target value of PMHF as 10 ⁻⁸ h⁻¹, and calculated the failure rates of hardware components. By considering the diagnostic coverage of safety mechanisms and fault exposure time, the PMHF value was determined to be 8×10 ⁻⁹ h⁻¹, meeting the target value requirements.

EEC Assessment

We classified and assessed each hardware failure to ensure that all possible failure paths were covered. By assessing the diagnostic coverage of safety mechanisms, we confirmed that all failures could be detected and handled in a timely manner.

5.4 Hardware Integration and Verification

Hardware Integration

We integrated the microcontroller, sensors, and actuators into the system and developed a detailed testing plan.

Functional Testing

Functional tests were executed to verify the system’s performance under normal operating conditions. All test cases passed, and the system functioned normally.

Fault Injection Testing

By injecting faults, we verified the system’s fault detection and handling capabilities. The test results indicated that the system could timely detect faults and enter a safe state.

Electrical Testing

We performed electrical testing to verify the hardware’s performance within specified voltage and current ranges. All test cases passed, and the hardware performance met the requirements.

Verification Report

All testing plans, test cases, and results were recorded, and the verification report detailed the testing processes and results. For any issues identified during testing, we developed solutions and verified their effectiveness.

#06Conclusion

Through hardware architecture metrics evaluation, safety goal violation assessment, and hardware integration and verification, the development team can systematically conduct hardware development, ensuring that the hardware design meets functional safety requirements. In the actual development process, combining specific technical safety concepts and system architecture design, and conducting hardware design and verification according to standard requirements can ensure the functional safety of automotive electronic systems.

/ END /