Hello! This is Hermes Solutions. Today, we will take a general look at ISO 26262 Part 5.
What is the Hardware Level?
In ISO 26262, the hardware level refers to a series of activities and processes that implement technical safety concepts, analyze hardware faults, and coordinate with software development. This includes planning the activities and processes needed to develop hardware that meets safety requirements.
Why is the Hardware Level Important?
Hardware level development is crucial for realizing the system’s technical safety concept, analyzing the potential causes and impacts of hardware faults, and ensuring close coordination between hardware and software development. Like the system level, an integrated approach to hardware and software is essential for ensuring safety.
Key Stages of Hardware Level Development
ISO 26262 Part 5 divides safety activities at the hardware level into six main categories:
1. General Topics and Planning
- This involves planning the activities and processes necessary for hardware development, including the hardware implementation of the technical safety concept, potential hardware fault analysis, and coordination with software development.
2. Specification of Hardware Safety Requirements
- Here, hardware safety requirements derived from the technical safety concept and system architecture design specifications are detailed. The Hardware-Software Interface (HSI) specifications are also updated during this process.
3. Hardware Design
- This includes hardware architecture design and detailed hardware design at the circuit level. It verifies whether the hardware meets safety requirements, is compatible with HSI specifications, and aligns with system architecture design specifications.
4. Evaluation of Hardware Architectural Metrics
- To assess the suitability of the hardware architecture design, two metrics are used: the Single Point Fault Metric (SPFM) and the Latent Fault Metric (LFM). These evaluate the hardware architecture’s ability to handle random hardware failures.
5. Evaluation of Safety Goal Violations due to Random Hardware Failures
- This evaluates whether the residual risk of safety goal violations due to random hardware failures is sufficiently low. Two methods (PMHF and EEC) are used for this assessment.
- 6PMHF (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.
6. Hardware Integration and Verification
To verify that the developed hardware complies with hardware safety requirements, hardware components are integrated and tested. Test cases are derived using various methodologies during this process.
Summary
ISO 26262 Part 5 provides key insights into:
Coordination of safety activities at the hardware level.
Consideration of both systematic and random hardware failures in hardware design.
Systematic analysis of hardware design safety.
Close coordination of hardware and software development.
We hope this overview helps you understand the overall aspects of product development at the hardware level according to ISO 26262 Part 5. Thank you!
