Fault Classification according to ISO 26262

How to define the failure modes of components in the automotive sector? In this article, we introduce the main reliability calculation methods that must be carried out during the development phase at the hardware level.

ISO 26262 key-points

The ISO 26262 series of standards is an adaptation of the IEC 61508 series of standards needed to address the specific needs of the road vehicle sector.

Some of its key-points are:

• Provides a reference for the automotive safety life cycle and supports the adaptation of activities to be performed during the life cycle phases, i.e. development, production, operation, service and decommissioning
• Provides an automotive-specific risk-based approach for determining integrity levels, Automotive Safety Integrity Levels (ASILs)
• Uses ASILs to specify which of the requirements of ISO 26262 are applicable to avoid unreasonable residual risk

 

A brief introduction to Hardware metrics vs. Safety Life-cycle

The ISO 26262 reference safety lifecycle encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.

In regard to fault classification, it is done during the development phase at the hardware level.

 

First of all, remind the “Fault” definition

• Failure: termination of an intended behaviour of an element or an item due to a fault manifestation. Termination can be permanent or transient
• Failure Mode: manner in which an element or an item fails to provide the intended behaviour
• Failure Mode Coverage (FMC): proportion of the failure rate of a failure mode of a hardware element that is detected or controlled by the implemented safety mechanism
• Failure Rate: probability density of failure divided by probability of survival for a hardware element

 

Try to classify the failure modes

• Safe fault (S): Fault whose occurrence will not significantly increase the probability of violation of a safety goal
• Single-point fault (SPF): Hardware fault in an element that leads directly to the violation of a safety goal and no fault in that element is covered by any safety mechanism
• Residual fault (RF): Portion of a random hardware fault that by itself leads to the violation of a safety goal, occurring in a hardware element, where that portion of the random hardware fault is not controlled by a safety mechanism
• Multiple-Point Fault (MPF): individual fault that, in combination with other independent faults, leads to a multiple-point failure

 

A Multiple-Point Fault may be:

1. Detected MPF: Multiple-Point Fault that is detected, within a prescribed time, by a safety mechanism, that prevents it from being Latent
2. Perceived MPF: Multiple-Point Fault whose presence is deducted by the driver within a prescribed time interval
3. Latent MPF: Multiple-Point Fault whose presence is not detected by a safety mechanism nor perceived by the driver within the multiple-point fault detection interval

 

 

Where λ is the total failure of safety-related hardware element.

 

The Failure Modes Classification helps to take decisions

The following path shows the decision steps for classifying a failure mode:

 

 

Following Step: Architectural Metrics Evaluation

The Hardware Architectural Metrics evaluate the effectiveness of the hardware architecture with respect to safety.

It must be calculated for each safety goal defined in the Safety Requirements Specifications, considering the entire safety relevant hardware (SR, HW).

The Hardware Architectural Metrics need to be evaluated for ASIL C and D, recommended for ASIL (B).

 

• SPFM (Single-Point Failure Metric) reflects the robustness of the item to single-point and residual faults.
  For example, a high SPFM implies that the proportion of single-point faults and residual faults in the hardware of the item is low.
• LFM (Latent Failure Metric) reflects the robustness of the item to latent faults. A high LFM implies that the proportion of latent faults in the hardware is low.

 

This means that the achievable ASIL is a function of Hardware Architectural Metrics:

How to evaluate Random Hardware Failures?

Even the Random Hardware Failures need to be evaluated to demonstrate that the probability of safety goal violation due to random hardware failures is sufficiently low.

Also in this case, the Hardware Architectural Metrics need to be evaluated for ASIL C and D, recommended for ASIL (B).

The PMHF (Probabilistic Metric for random Hardware Failures) method is commonly the most widely used and gives the ASILs below:

 

Lastly, FMEDA ends the Failure Classification process

In order to structure a methodical classification of failure rates for each safety goal, we can use the FMEDA method.

Here is an example of a complete calculation by using the FMEDA method:

 

---

Go back to the blog