ISO 26262-Compliant Safety Analysis Methods

The primary characteristics of FMEA is that it begins with analyzing the causes of failures of each architectural component and then deduces the impacts to the overall system, and thus to develop the optimization measures for potentially unacceptable failures. In typical automotive applications, FMEA can be conducted by qualitative or quantitative methods in analyzing failures and malfunctions in safety system designs. Generally implemented as an inductive (bottom-up) approach, FMEA focuses on how failures occur within system components, and how these failures impact the overall system.

Failure Modes, Effects and Diagnostic Coverage Analysis (FMEDA)

The Failure Modes, Effects and Diagnostic Coverage Analysis (FMEDA) method was initially developed by exida in the 1990s, and was adopted as a recommended analysis method in the ISO 26262 functional safety standard in 2011. FMEDA can be seen as a quantitative extension of the FMEA, as it considers quantitative failure rates of hardware components. This includes the failure rates and the distributions of failure modes for these components, while also taking into account the safety mechanisms for the corresponding failure modes and their diagnostic coverage to detect critical failure modes.

FMEDA is mainly utilized during the hardware architectural design and hardware detailed design. At the hardware design level, it is essential to calculate the hardware architectural metrics, such as Single-Point Fault Metric (SPFM) and Latent Fault Metric (LFM). Iterative application of FMEDA can improve the hardware designs.

Fault Tree Analysis (FTA)

Fault Tree Analysis (FTA), developed by Bell Labs in the early 1960s, was used to evaluate the launch systems of ballistic missiles. This analysis method was then standardized by International Electronical Commission (IEC) in 2006 and has been referenced in automotive industry standards such as ISO 26262 as a potential or recommended analysis method.

FTA can be applied in both qualitative and quantitative techniques. For example, starting with qualitative fault analysis, quantitative statistics can then be integrated to strengthen the analysis and resulting in a quantitative variant of the analysis.

In contrast to FMEA, FTA is a deductive (top-down) method (see Figure 3) that enables the identification of base events or combinations of base events that may lead to the defined top event failure. Typically, as undesirable system event, the top event can violates a safety goal or the safety requirements derived from a safety goal.

To perform FTA, it is possible to start with the top undesirable event, then progressively builds a graphical tree structure. The interaction of potential causes for the undesirable even is represented by Boolean logic operations, such as AND, OR, and NOT gates. The quantitative variant of FTA can be implemented to calculate the third Probabilistic Metric for random Hardware Failures (PMHF) metric, which is also a recommended method in ISO 26262.

Safety analyses are typically associated with design phase activities, such as the concept phase, system development and hardware development phases. These analyses are associated with activities in the concept, system and hardware development phases, such as architectural design and integration verification of system hardware (see Figure 7). Similarly, during the software development phase, safety analyses are linked to software development activities, such as software architectural unit design and verification activities (Figure 8).

Safety Analyses in Hardware Design Phase

1. Qualitative Safety Analyses in Hardware Design Phase

In the hardware design phase, various safety analysis techniques are applied in combination. One aspect is qualitative safety analysis of the hardware design. For example, the qualitative FTA method aids in identifying the causes of failures and the effects of faults. For safety-related hardware components/parts, the qualitative FMEA method helps to identify different types of faults, particularly whose classified as safe faults, single-point failures or residual failures, and multi-point failures. Similarly, according to the recommendations of the ISO 26262 standard, it is suggested to use a combination of deductive and inductive analysis methods for safety analyses.

2. Quantitative Safety Analyses in Hardware Design Phase

On the other hand, when discussing random hardware failures, it is necessary to perform quantitative safety analyses related to hardware design. Quantitative safety analyses assist in evaluate or calculate metrics related to hardware architectural design. Hardware architectural design metrics include Single-point Fault Metric (SPFM), Latent Fault Metric (LFM), and Probabilistic Metric for Random Hardware Failures (PMHF). Typically, FMEDA methods are conducted in quantitative analyses to evaluate the suitability of the hardware architectural design with respect to the detection and control of safety-related random HW failures. This is done by analyzing scenarios where safety goals are violated due to random hardware failures, and thus calculating specific metrics for the hardware architectural design.

2.1. Failure classification of safety-related hardware components

Failures occurring in safety-related hardware components should be categorized as:

a） Single point fault

b） Residual fault

c） Multiple point fault

d） Safe fault

Multi-point faults need to be differentiated between latent, detected and perceived faults. Thus, safety-related hardware components failures are categorized as in Figure 9.

Among these：

-Distance n indicates the number of independent faults that simultaneously lead to a violation of safety goals (single-point or residual faults n = 1, dual-point faults n = 2, etc.).

-Faults at distance n are located between the n-ring and n-1-ring.

-Unless explicitly related to technical safety concepts, multi-point faults with a distance strictly greater than 2 are considered safe faults.

Note that in the case of transient faults, the safety mechanism will restore the affected item to a fault-free state, even if the driver is never notified of its presence, such faults are considered as detected multi point faults. For instance, in the case of protecting memory from transient faults using error-correcting codes, the safety mechanism not only provides the CPU with corrected value, but also repairs the contents of the flipped bits within the memory array (e.g. by writing back the corrected value), thereby returning the affected items to a fault-free state.

2.1.1. Single Point Fault

A fault of a hardware element which is not prevented by any safety mechanism, and can directly lead to a violation of the safety goals. For example, unmonitored resistors with at least one failure mode (e.g. open circuit) may violate the safety goals.

2.1.2. Residual Fault

A fault in a hardware element that has at least one safety mechanism to prevent from violating the safety goals that can directly lead to safety goal violation. For example, checking a random memory (RAM) block using only the safety mechanism of the checkerboard RAM test may fail to detect certain kinds of bridging faults. Violations of the safety goals due to these faults cannot be covered by the safety mechanisms. Such faults are known as residual faults, when the diagnostic coverage of the safety mechanism is less than 100%.

2.1.3. Detected Two-Point Faults

A fault that is detected by the safety mechanism preventing its latent state can only lead to a violation of the safety goals when in conjunction with another independent hardware faults (related to two-point faults). For example, a flash memory fault protected by parity checks can detect a single bit fault according to the technical safety concept and trigger a response, such as shutting down the system and informing the driver through a warning light.

2.1.4. Perceived Two-Point Faults

A fault that can be perceived by the driver, either is detected or undetected by the safety mechanisms within a specific time period, but it can only result in a violation of the safety goals in combination with another independent hardware fault (related to two-point faults). For instance, a two-point fault which the function is clearly and distinctly affected by the consequences of the fault and can be perceived by the driver.

2.1.5. Latent Two-Point Faults

A fault that is neither detected by the safety mechanism nor perceived by the driver, a;pw the system to remain operational all the time, without notifying the driver, until a second independent hardware fault occurs.

For example, in flash memory protected by EDC: ECC corrects a single bit permanent fault value during reading, but this correction is not made within the flash memory, nor is there any signal indication. In this case. The fault cannot lead to a violation of the safety goals (since the fault bit has been corrected), but it is undetectable (due to the lack of signal indication for the single bit fault) nor imperceptible (since it does not impact the functionality of the application). If an additional fault occurs within the EDC logic, it can lead to the loss of control over the single bit fault, leading to a potential safety goal violation.

2.1.6. Safe Faults

Safety faults include the following two categories:

a）All n-point failures with n > 2, unless the safety concept indicates that they are relevant factors that violate the safety objective; or

b）failures that do not lead to a violation of the safety objective.

An example is a single bit fault that is corrected by ECC but not signaled in the case of flash memory protected by ECC and cyclic redundancy check (CRC). The ECC prevents the fault from violating the safety objective, but the ECC does not signal it. If the ECC logic fails, the CRC will be able to detect the fault and the system will shut down. Only when a single bit fault exists in the flash memory, the ECC logics fails, and the CRC checksum and monitoring fails, The safety objective will be violated (n=3).

2.2. Failure Modes and Failure Rates of Hardware Elements

2.2.1. Failure Modes of Hardware Elements

According to the fault classification model, the failure modes of hardware elements are categorized as shown in Figure 10.

2.2.2. Hardware Element Failure Mode Classification Process

The failure mode classification process is shown in Figure 11.

Only safety-related hardware elements of relevant items are considered. Hardware elements for safety faults or n-order multipoint faults (n>2) may be omitted from the calculation unless they are explicitly related to technical safety concepts. A graphical representation of the single point fault metric is shown in Figure 12.

Only safety-related hardware elements of relevant items are considered. Hardware elements for safety faults or n-order multipoint faults (n>2) are omitted from the calculation unless explicitly relevant in the technical safety concept. A graphical representation of the latent fault metric is shown in Figure 13.

2.3.3 Probability of Random Hardware Failure (PMHF) Measurement

As shown in Equation (1-4), the formula for calculating PMHF value is:

PMHFest = λSPF + λRF+ λDPF_det × λDPF_latent × Tlifetime (1‑4)

For each failure mode, calculate its contribution to the total PMHF value as a percentage.

2.4 Hardware Architecture Metrics Target Values

For specific metrics of hardware architecture design, the standard provides corresponding target values (as shown in Table 1), which typically depend on the highest ASIL level that the hardware design needs to meet. For ASIL A levels, the standard does not recommend target values, for ASIL D levels, the standard recommends the most stringent target values, and for some cases of ASILB and ASILC, the metrics are recommendations rather than mandatory requirements in the sense of the standard.

Safety Analysis in the Software Design Phase

1. Safety-Related Functions and Attributes

The derivation of software safety requirements should consider the safety-related functionality and safety-related attributes required by the software. Failures in safety-related functions or safety-related attributes may lead to violations of the technical safety requirements assigned to the software.

Safety-related functions of software typically include:

• Functions that enable safe execution of the nominal function
• Functions that enable the system to achieve or maintain a safe or degraded state
• Functions related to detecting, indicating, and mitigating failures of safety-related hardware elements
• Self-testing or monitoring functions related to detecting, indicating, and mitigating failures in the operating system, underlying software, or the application software itself
• Functions related to onboard or offboard testing during production, operation, servicing, and end-of-life stages
• Functions that allow modification of software during production and service
• Functions related to performance or time-critical operations

Safety-related attributes typically include:

• Robustness to erroneous inputs
• Independence or non-interference between different functions
• Fault tolerance of the software, etc.

2. Safety Analysis in the Design Phase of Software Architecture

During the software architecture design phase, corresponding software safety analysis activities should be conducted, which the standard refer to as safety-oriented analysis methods. Safety-oriented analysis is essentially a form of qualitative analysis. Firstly, safety-oriented analysis helps provide evidence that whether the software is suitable to provide the specified safety-related functions and attributes as required by the desired ASIL level. Secondly, safety-oriented analysis helps to identify or validate safety-related software content. Finally, safety-oriented analysis supports the development of safety mechanisms and thus verifies the effectiveness of safety measures.

Relying on the requirement of non-interference or sufficient independence between safety-related elements, the standard recommends performing a Dependent Failure Analysis (DFA). DFA identifies relevant failures or potentially relevant failures and their effects. The objective and scope of the DFA depends on the sub-stage and the level of abstraction at which the analysis is performed. the elements of the failure of interest are defined before the analysis is performed (e.g., in the safety plan). This is also a part of the qualitative analysis.

3. Analysis of Safety-Related Failures at the Software Architecture Level

Embedded software provides the ability to specified functions, behaviors, and attributes, as well as the integrity required by the assigned ASIL. By applying safety-related failure analysis at the software architecture level to check or confirm the corresponding safety functions and attributes, along with the integrity of the corresponding assigned ASIL requirements.

3.1 Purpose of Safety Analysis at the Software Architecture Level

During the software architecture design phase, relevant failure analysis should be conducted to identify possible single events, faults or failures that could lead to failure behaviour of multiple software elements that require independence (e.g., cascading and/or common cause failures, including common mode failures), and single events, faults or failures that may initiate a chain of causality leading to a violation of a safety requirement that propagates from one software element to another (e.g., cascading failures). Through the failure analysis in the software architecture design phase, the degree of independence or non-interference achieved between relevant software architecture elements should then be tested.

3.2 Software Architecture Level Safety Analysis

Relevant failure analysis at the software architecture level shall consider the following aspects:

• Identifying potential design weaknesses, conditions, errors, or failures that could trigger a causal chain leading to violation of safety requirements (e.g., using inductive or deductive methods)
• Analyzing the consequences of possible faults, failures, or causal chains on the functions and attributes required of software architecture elements Analyzing functions and attributes that software architecture elements required and the consequences of possible faults, failures, or causal chains

3.3 Application Scenarios for Relevant Failure Analysis at the Software Architecture Level

The following scenarios may require failure analysis at the software architecture level:

• Applying ASIL decomposition at the software level
• Implementing software safety requirements, such as providing the evidence for the effectiveness of software safety mechanisms, where the independence between monitored elements and monitoring elements must be ensured

4. Deriving Security Mechanisms from Software Architecture Level Safety Analysis

The safety measures include safey mechanisms derived from safety-oriented analyses that cover issues related to random hardware failures and software failures. The results of the safety analyses performed at the software architecture level require the implementation of error detection safety mechanisms and error handling safety mechanisms.

4.1 Error Detection Safety Mechanism

Error detection safety mechanisms include:

• Range checks on input and output data
• Plausibility checks (e.g., using reference models of the desired behavior, assertion checks, or comparing signals from different sources)
• Data error detection (e.g., error detection codes and redundant data storage)
• External element monitoring (e.g., ASIC) or another software element that executes the program that performs the watchdog function. The monitoring can be logical, temporal, or both
• Temporal monitoring of program execution
• Diverse redundancy design
• Access violation control mechanisms implemented in software or hardware, used to allow or deny access to safety-related shared resources

The example in Figure 14 illustrates the interference caused by conflicting use of shared resources (e.g., shared processing elements). The QM software element interferes with and prevents timely execution of ASIL software elements (this interference can also occur between software elements with different ASIL levels). The upper half of the figure shows the software execution without interference mechanisms. By introducing "checkpoints" into the software and implementing timeout monitoring of them, timing perturbations can be detected, enabling appropriate countermeasures.