In a previous blog from Renesas functional safety experts (Customer Value of Automotive Business (Series 16): Renesas Functional Safety Support for Automotive (1) – An Overview), ISO 26262 is described as the standard accepted and followed by the automotive industry for providing guidance to mitigate risks due to faults in electrical and electronics (E/E) systems. ISO 26262 Part 5 is one of 12 volumes of the standard, and it is devoted to functional safety compliance for product development at the hardware level; semiconductor components developed by Renesas that are utilized in vehicles are subject to the requirements defined in Part 5. Section 8 of this Part further focuses on the hardware requirements for the "evaluation of architectural metrics". To this end, we will explore the concept of the FMEDA (failure mode effects and diagnostic analysis) and the need for a customizable tool to generate real-life application-based metrics results for analysis.
This is the second Blog in our functional safety series in which we will attempt to encapsulate the concepts of the specific hardware architectural metrics used for control and detection of failures, their calculations, and mitigation techniques. As there are different types of faults that could result in a failure, the metrics under this analysis are limited to random hardware faults. Let's introduce these metrics and the concept of Failures in time (FIT):
- FIT (failure in time), an inherent characteristic of hardware (component or element), is a unit that represents the probability that a failure will occur due to a fault in the E/E elements. One FIT is equal to one failure per one billion hours of operation. Calculation of the base failure rate value (or raw FIT) for a given component or system is quite complex, with multiple sources and handbooks, and expert opinions to consider. The base failure rate is the probability of failure assuming no mitigation steps are considered.
- Single-Point Fault Metric (SPFM): this metric is used for evaluating the robustness of the design against faults that alone could result in a violation of the safety goal. For example, corrupted data, when not detected, could lead to incorrect outputs to actuators and result in a critical situation. For the strictest level of safety defined in the standard (Automotive Safety Integrity Level D, or ASIL D), the SPFM should achieve > 99% -- simply stated, over 99% of Single Point Faults should be detected and mitigated.
- Latent-Fault Metric (LFM): this metric is used for evaluating the robustness of the design against faults that could lead to a violation of the safety goal only if coupled with other faults. An example of this "Multiple-point Fault" would be the combination of
1) a fault in an implemented safety mechanism, such as a clock monitor, and
2) a fault in the monitored clock.
The incorrect clock frequency could negatively affect any number of operations in the ECU, resulting in failure.
For ASIL D compliance, over 90% of Multiple-Point Faults should be detected and mitigated. -
Probabilistic Metric for random Hardware Failures (PMHF): this metric is a quantitative target that represents the average probability of failure per hour over the operational lifetime of the system. For ASIL D compliance, a E/E system is targeted to achieve a PMHF of less than 10 FIT. PMHF and raw FIT both represent a failure probability with the difference being that raw FIT is an expression of the robustness of the technology, while PMHF is the expression of the robustness (safety) of the solution.
For our purposes, the key point for safety analysis via FMEDA is to evaluate the capability of the design to meet the target metrics SPFM, LFM, and PMHF described above. Another aspect that must be considered is the need for configurability of the FMEDA tool. Most Renesas components intended to be used in a safety-related context are developed in a way that allows for the product to be used in a multitude of systems, applications, and vehicles. Referred to as a Safety Element out of Context (SEooC), the safety requirements of a said element under analysis are dictated by the target use case; changes in the configuration of the FMEDA are needed for precise use case analysis. (For the remainder of this discussion, the SEooC described will be a "component.")
Renesas has developed a proprietary FMEDA tool coined "CAR Tool": CAR = Customizable Analysis Report. This CAR tool implements a TÜV-NORD approved methodology for component safety analysis. [TÜV-NORD is a renowned international safety certification body.] It's critical that a customizable tool is available for system and component safety analysis; depending on the safety goals identified by the system integrator, multiple parameters must be modifiable for a precise analysis of each safety goal. This means that for each safety goal, an independent analysis should be possible, where adjustments can be made and results analyzed for confirmation of that safety goal's target ASIL compliance.In addition to being customizable, the CAR Tool is constructed for use to guide the system integrator in a step-by-step fashion and to adjust parameters and settings in a logical manner. This is achieved by the use of various modules for entering and modifying parameters/values based on the actual use case. We will step through a high-level customization, and introduce other key concepts along the way.
For proper analysis, an appropriate level of component granularity is needed. ISO 26262 recommends using the term "element" to identify these component subsections or hardware parts; we will continue with that nomenclature moving forward.
Analysis Parameters
Multiple safety goals can be defined for the SEooC under analysis, with each safety goal having different timing parameters (e.g. time constraint to mitigate a fault) and ASIL targets. The Analysis Parameters module provides the entries to establish these varied safety goals.
FIT Characteristics
FIT was defined earlier and noted as a calculation/value that could be determined by a variety of methods. The CAR Tool can handle different FIT distribution approaches: manual, by formula, as a portion of the whole die, or based on size. While the CAR Tool introduces FIT Characteristics to be utilized during analysis, users can also create and add FIT Characteristics to be used in lieu of, or in addition to the ones defined by Renesas.
Fault Characterization
There are multiple fault characterizations in the CAR Tool that can be allocated to each element. Common examples of fault characterizations and corresponding elements:
- Memory array (element) with fault characterizations of single-bit failure, double-bit failure and multi-bit failure.
- Clock/Oscillator (element) with fault characterizations of low frequency, high frequency and jitter.
In both examples, each element is assigned fault characterizations with three failure modes. The Renesas tool allows users to modify how these modes are distributed (examples for three modes: 50%/25%/25% or 90%/8%/2%, etc.).
Users also have the ability to add and remove fault models and failure modes, and can even define their own fault characterizations.
Hardware Description
The Hardware Description module contains physical information about the elements (such as size, FIT, PIN/DIE nature), and also includes other basic component features (such as the granularity to use for the analysis). This module is used to allocate Fault Characterization and other characteristics to each element.
Granularity --
Important considerations for defining the granularity of a component include, e.g.
1) Can the element be effectively analyzed with respect to failure modes and safety mechanism allocation?
2) Is the granularity size practical so that an analysis of each element is feasible?
Renesas has defined the granularity in the CAR Tool depending on the component, as well as the considerations above. Architectural granularity is NOT a customizable feature of the CAR Tool, but since this is also an industry-wide topic that safety experts are passionate about, IEEE is currently considering a granularity standard that will allow customers (system integrators) and suppliers (like Renesas) to start from a common knowledge base.
FIT allocation --
In the CAR Tool, when performing analysis of permanent faults, Renesas allocates the raw FIT to each element based purely on the percentage of the component die size that the element consumes. This simply means that a fault can occur with equal probability at any location in/on the die.
For the analysis of transient faults, FIT characteristics are allocated according to the nature of the element (F/F, RAM bits, FLASH bits).
Fault Characterization allocation --
In this module, a fault characterization (defined above) is allocated to each element.
Hardware Element Functionality --
The CAR Tool allows for analyzing different use cases related to a single element, or for creating larger use cases that involve more than one element. This use case analysis is feasible by considering the “safety-relatedness” of each element, described in the next section.
SR/NSR --
Safety-related vs. Not Safety-related attribute allows the system integrator to consider if a given element is required for a given Safety Goal. If an element is deemed NSR, then the FIT allocated to it is not considered in the analysis; no safety mechanism is needed. Each element shall be designated as either SR or NSR.
Safety Mechanisms
A concept that was mentioned previously is that of a "safety mechanism". Safety mechanisms are features in the E/E system that are implemented to detect and mitigate faults so that the component has improved capability to meet its safety targets. This could be achieved by a pure hardware circuit in an ECU component (such as a clock monitor or voltage monitor), a dedicated component at the system level (such as a watchdog timer), a snippet of software code for confirming a safety-related calculation or data, or a combination of any of these.
Safety mechanism timing is also critical: what is the amount of time the mechanism will take to detect a fault and mitigate and prevent failure? The CAR Tool takes this into account and alerts the user if the defined safety mechanism time is not sufficient so that modifications can be made (e.g., by utilizing a different safety mechanism, or adjusting the timing of a SW mechanism.)
(Note that for the images in this article, a demo library has been used for concept introduction; in the true product version, the complexity and depth of the designs are much more detailed.)
In this CAR Tool module, many safety mechanisms are defined; the user can consider and add additional mechanisms, enable/disable each mechanism, and adjust safety mechanism timing.
Hardware Analysis
As we near the end of the analysis in order to determine if the target metrics can be achieved, this module is used to set important attributes for fault analysis. Fault impact and fault coverage can be assigned and modified. The analysis is supported by links to content from the preceding modules, limiting the chance of user errors. Safety mechanisms defined in the previous module can be allocated to the elements, with the corresponding level of coverage.
Analysis Results
The final module presents the results of the FMEDA analysis by providing metric numbers for SPFM and LFM at user-defined levels; achieved metrics can be seen taking the component in aggregate, per selected user-defined subsets of the design, or at an elemental level. Results for PMHF are available at the same granular level.
ISO 26262 Part 10 informs us that all faults, per element and per component, can be classified into one of six categories; the CAR Tool Analysis Results module includes this breakdown as well.
Other Features:
In addition to standard tool features, such as error logging and change history, the CAR Tool includes other gems for in-depth analysis, audit/assessment evidence, graphical views of the results, and others…
- Filters are invaluable in parsing potentially massive component libraries.
- Documents can be embedded for quick access.
- Multiple variants of a single device can be handled by a single CAR Tool project (variances could include different memory sizes or reduced/increased peripheral set.)
- Pin Analysis: from a use case perspective, handling of the component I/O can differ greatly. Upcoming versions of the CAR Tool will include an integrated module for precise I/O definition and analysis.
For more information on Renesas's CAR Tool, visit the following URL, which also contains helpful demonstration videos and documentation access:
https://www.renesas.com/products/automotive-products/car-tool
See also:
Renesas Functional Safety Support for Automotive (1) – An overview
Renesas Functional Safety Support for Automotive (3) – Applying the ISO 26262 Standard to SEooC Software