[FUSA] A Brief Explanation of ISO26262-Part 5 (Production development at the HW level)

Hi there! Continuing to my previous post named Different Types of Hardware Faults in ISO26262 and How to metric it? [2] in which I presented the type of faults mentioned in ISO26262 Part 5.

In this article, I attempt to explain the main objectives and purpose of ISO 26262-Part 5: Product development at the hardware level in order for we can understand HOW to derive Hardware Safety requirements (HWSRs) and allocate HWSRs to suitable HW elements from a part of Technical Safety Requirements (TSRs).

Introduction

Before talking in details of ISO26262-Part 5, we review the Safety Concept Development Flow as in Figure 1:

As we see in Figure 1, ISO26262-Part 5 mostly mentions to develop Specification of Hardware Safety requirements (HWSRs) at Component Level. In addition, ISO26262-Part 5 also introduces the following work packages (see in Figure 2):

• Part 5-5: Initiation of product development at the hardware level
• Part 5-6: Specification of hardware safety requirement
• Part 5-7: Hardware design
• Part 5-8: Hardware architectural metrics
• Part 5-9: Evaluation of violation of the safety goal due to random HW failures
• Part 5-10: Hardware integration and testing.

In the scope of this post, we only focus on HW safety concept explanation to guide to develop Specification of Hardware Safety requirement (see in Figure 3).

The Objectives of ISO26262-Part 5

ISO 26262 Part 5 focuses on the production and development of hardware in the context of functional safety for automotive systems. Its main objectives and purposes include:

1. Hardware Safety Requirements (HWSRs) Specification

The first objective of Part 5 is to write the hardware safety requirements specification. The purpose of writing this work product is to refine technical safety requirements that are allocated to both hardware and software into requirements allocated exclusively to hardware or software. The requirements allocated to hardware are specified in this work product and are called hardware safety requirements.

Finally, to verify that HWSRs and the HSI specification are consistent with the TSC and SyAD in ISO26262-Part 4 (see more detail in the reference [5])

The outputs of HWSR Specification are:

• HW safety requirements specification (including test and validation criteria)
• HW-SW interface specification (refined)
• HW safety requirements verification report

Note #1: If HWSRs are NOT derived from TSRs, then now ASIL can be determined. Therefore, these HWSRs are without ASIL.

Note #2: Each HWSR shall be allocated to the related HW elements. As a result each HW element shall be developed in compliance with the highest ASIL of any of the requirements allocated to it.

2. Hardware Design Specification

The objective of this work product is to develop a hardware design that is consistent with both the system design from ISO26262-Part 4 and fulfills the hardware safety requirements. The design shall be done in two levels.

• The first level is called hardware architectural design and it specifies all components in the design and the interaction between them.
• The second level is called detailed hardware design and consists of the electrical schematics of the components and the interactions between them. Due to the fact that we are using existing components in our design we will not develop the detailed hardware design.

In order to avoid systematic faults the hardware architectural design shall exhibit the following properties (modularity, adequate level of granularity, and simplicity) by use of the principles listed in Table 1:

Note #3: Non-functional causes for failure of a safety-related hardware component shall be considered during hardware architectural design, as well as hardware detailed design, including the following influences, if applicable: temperature, vibrations, water, dust, EMI, noise factor, or cross-talk originating either from other hardware components of the hardware architecture or from its environment.

3. Hardware Safety Analysis Report

A safety analysis is performed on the hardware design in order to support the hardware design. The analysis can later be used for verification of the hardware design. Safety analyses of the hardware design to identify the causes of failures and the effects of faults shall be applied in accordance with Table 2 and ISO 26262-9:2018, Clause 8.

The first step of the analysis is to identify the faults on hardware parts that might lead to a violation of a safety goal. A fault in this manner is not necessarily at a low level, a fault can be a more general failure mode of a hardware element, such as a value failure. Which means a hardware element outputs a different value than intended.

Note #4: The identification of faults can be done with techniques such as FMEA or FTA (see more details in [3]).

When the faults are identified they shall be classified as single point faults, residual-faults, latent faults, or multi-point faults. According to [2], we know that: a residual fault is a portion of a fault in a hardware component which is not covered by a safety mechanism, that leads to the violation of a safety goal. That means that in order for a fault on a hardware component to be a residual fault instead of a single-point fault, the hardware component must be protected by a safety mechanism but the safety mechanism does not cover this certain fault.

The next step of the analysis is to provide evidence of the effectiveness of the safety mechanisms to avoid single-point and latent faults. After this the diagnostic coverage with respect to residual faults and with respect to latent faults is evaluated, that is what proportion of the faults on a hardware part is covered by a safety mechanism.

4. Verification of hardware design

The hardware design shall be verified in accordance with ISO 26262-8:2018, Clause 9, and by using the hardware design verification methods listed in Table 3 to provide evidence for the following:

• that it fulfils the hardware safety requirements;
• that it is compatible with the hardware-software interface specification; and
• the suitability of the safety-related special characteristics to achieve functional safety during production and service.

Test cases are derived using various methodologies during this process.

5. Analysis of Safety Goal Violations due to Random Hardware Failures

The objective of this clause is to evaluate the probability that a safety goal is violated due to a random hardware failure. The result can then be used in a rationale that the residual risk of a safety goal violation is sufficiently low. Two alternative methods (PMHF and EEC) to conduct this evaluation are proposed.

• PMHF (Probabilistic Metric for Hardware Failure): PMHF probabilistically evaluates the likelihood of safety goal violations due to hardware failure. It expresses the system’s reliability numerically, with target values varying by ASIL grade. PMHF is measured in FIT (Failure In Time) units, with 1 FIT representing a failure probability of once in 10^9 (one billion) hours.

• EEC (Evaluation of Each Cause): The EEC method analyzes the impact of each hardware element’s fault on safety goal violations. This allows for a more detailed assessment of how individual faults affect the overall system safety.

Normally, the Evaluation of Probabilistic Metric for Random Hardware Failures (PMHF) method is used and the criteria for each ASIL level is showing in Table 6:

6. Specification of Dedicated Measures for Hardware

In the hardware safety analysis report, the diagnostic coverage (DC) with respect to residual faults of hardware parts was evaluated. The diagnostic coverage is a measurement of how large part of the failure modes that will be prevented or detected by the safety mechanisms.

To calculate diagnostic coverage with respect to residual faults, the following Equation is used:

where: λRF denotes the total failure rate of all residual faults, and λTOT denotes the total failure rate of all faults.

This work product specifies the dedicated measures that must be taken for those hardware parts which had a diagnostic coverage is classed in ISO26262-Part 5 as following tables:

Add-on: How to Derive HW-SW Safety Requirements

Deriving hardware (HW) and software (SW) safety requirements from technical safety requirements involves a systematic approach. Here’s a general process to follow:

Key Steps to Derive HW and SW Safety Requirements

1. Understand Technical Safety Requirements: Review the technical safety requirements that are often derived from system-level safety goals. Ensure clarity on the intended functions, safety targets, and hazards.
2. Identify System Functions: Break down the technical safety requirements into specific system functions that must be performed to achieve safety. This includes understanding how the system operates under normal and fault conditions.
3. Analyze Safety Goals: Identify the safety goals associated with each function. These goals outline what must be prevented (e.g., hazards, failures) and provide a basis for deriving detailed requirements.
4. Perform Hazard Analysis: Conduct a hazard analysis to identify potential hazards related to system functions. This may involve methods like FMEA (Failure Mode and Effects Analysis) or FTA (Fault Tree Analysis).
5. Allocate Requirements: Allocate the derived safety requirements to HW and SW based on where safety functions will be implemented: i) Hardware Requirements: Focus on reliability, redundancy, and fault tolerance. Specify metrics such as failure rates, safety mechanisms, and diagnostic capabilities. ii) Software Requirements: Address functional correctness, error handling, and safety-related behaviors. Specify coding standards, testing requirements, and runtime monitoring.
6. Define Safety Metrics: Establish safety metrics for both HW and SW to measure compliance with safety goals. This includes metrics like diagnostic coverage and failure probabilities.
7. Document Requirements: Clearly document the derived HW and SW safety requirements, ensuring they are traceable back to the original technical safety requirements.
8. Review and Validate: Conduct reviews with stakeholders (e.g., safety engineers, system architects) to validate that the derived requirements effectively address the safety goals and are feasible for implementation.
9. Iterate as Necessary: The process may need to be revisited as design evolves or new information emerges, ensuring that HW and SW requirements remain aligned with technical safety requirements.

By following these steps, organizations can effectively derive and implement HW and SW safety requirements that align with technical safety objectives, thereby enhancing the overall safety of the system.

Key Considerations

• Consistency: Ensure that all derived requirements maintain consistency with the overall safety objectives and are aligned with the safety lifecycle.
• Traceability: Establish clear traceability from technical safety requirements to HW and SW safety requirements to facilitate verification and validation processes.
• Collaboration: Foster collaboration between hardware and software teams to ensure a comprehensive understanding of safety requirements across disciplines.

Conclusion

ISO 26262 Part 5 provides key insights into:

1. Coordination of safety activities at the hardware level.
2. Consideration of both systematic and random hardware failures in hardware design.
3. Systematic analysis of hardware design safety.
4. Close coordination of hardware and software development.

I hope this overview helps you understand the overall aspects of product development at the hardware level according to ISO 26262 Part 5. Thank you!

PS: I hope to receive your comments or your different opinions to learn more about this topic. I'm highly appreciate any debating ideas to help me fill my gaps while studying and practicing ISO26262 in advance.

References

[1] ISO26262:2018-Part 4, Part 5, Part 6

[2] Different Types of Hardware Faults in ISO26262 and How to metric it?

[3] Hazard Analysis Techniques for Functional Safety (Part 1: FTA and FMEA)

[4] Minimal Cut Sets in FTA and How to apply it in ASIL Decomposition

[5] Understanding about Technical Safety Concept (TSC) Development

[6] Safe Automotive soFtware architEcture (SAFE) by ITEA2