Understanding and Simplifying FMEDAs
Failure Modes, Effects and Diagnostic Analysis (FMEDA) documents are critical tools used to achieve the safety requirements of automotive designs. But writing an FMEDA is a time consuming and difficult task. By automating this task, you can spend more time improving your design’s safety readiness. In this article, Chuck and Doug introduce a solution for smoothing the FMEDA process.
Automotive designs require functional safety analysis, typically accomplished using Failure Modes, Effects and Diagnostic Analysis (FMEDA). FMEDAs are used to determine each safety goal’s architectural metrics, which in turn determines if the design will meet the targeted Automotive Safety Integrity Level (ASIL) requirements. However, if you have ever written an FMEDA, you know how tedious a task this can be. By automating this time consuming and difficult task, engineers can spend more time on exploring and developing a design’s safety readiness and figuring out how to more effectively safety-harden their designs. In this article, we introduce a push-button solution for creating and automating the FMEDA process.
VENTURING INTO FMEDA
The ISO 26262 standard requires quantitative analysis of safety related automotive IC designs. This analysis is used to generate the key functional safety metrics: probability metric for random hardware failures (PMHF), the single-point fault metric (SPFM) and the latent fault metric (LFM). The standard provides targets for each of these metrics based on the ASIL requirements of the top-level system that automotive manufacturers expect the IC design to meet.
In the case of PMHF, automotive manufacturers will allocate a portion of their system PMHF to your design. Determining these metrics is accomplished by looking at ways the design can fail and result in a hazard—a source of potential harm or malfunctioning behavior. The standard and industry practice is to analyze the failure modes using a table where each design component is broken out and the effects of the failure is quantified in terms of failure rates or failures in time (FIT). This table is referred to as a Failure Modes, Effects and Diagnostic Analysis, or FMEDA.
The FMEDA lists each component and the percentage each failure mode contributes to the overall FIT rate. By including safety mechanisms in your design, you can mitigate the effect of the failure modes and reduce their contribution to the FIT rate. Each failure mode needs to be evaluated according to the following criteria: is it safety related, what percentage of the design is affected by the failure mode, is it covered by a safety mechanism and what percentage of the design is covered by the safety mechanism? Table 1 defines the common terms used in the creation of an FMEDA.
TABLE 1. FMEDA information needed for each failure mode
Having this information, the failure mode’s FIT rate, residual/single-point FIT rate, safe FIT rate, multi-point FIT rate and latent FIT rate can be calculated. For example, an FMEDA spreadsheet might take the form shown in Figure 1. Using an FMEDA allows the key safety metrics to be determined for a design, but FMEDAs come with their challenges. The first challenge is determining the base failure rate for all the different logic used within a design: standard cell, analog logic and different memory types (high speed/high density, read-only memories, one-time programmable memories and so forth). Estimating the base failure rate is described in detail in ISO26262:2018-11, Clause 4.6. Calculating it involves numerous Greek symbols representing various technology dependent values. Figure 2 shows an example worksheet for calculating the base failure rate.
FIGURE 1 – FMEDA spreadsheet fields
FIGURE 2 – Worksheet for calculating the base failure rate
A BETTER WAY
As automotive functional safety consultants, we created the base failure rate table in Figure 2 by hand. But we are always looking for a better and more efficient way to simplify the FMEDA process, which is one area where an EDA tool can really help. Such a tool must have the ability to read in a design, determine its transistor count for each specific technology type, measure the diagnostic coverage of each safety mechanism and perform the base failure rate calculation using either industry standard or custom mission profiles and technology values to automatically compute the FIT rates for each design component.
— ADVERTISMENT—
—Advertise Here—
These tools should allow us to either use defaults taken from standards like IEC 62380 (which ISO 26262:2018 is derived from) or SN 29500, or input values provided by a customer. After the tool determines the number of transistors for the logic and memory, it plugs that value into the equation, as shown in the IEC 62380 example in Figure 3.
FIGURE 3 – IEC 62380 FIT calculation
The beauty of this kind of tool is that maintenance and repeatability of the base failure rate calculations have been dramatically improved. The tool allows the consolidation of all the common variables in one place, and the design itself becomes the source for the transistor counts. In addition, as can be seen in Figure 3, the equations for creating the base failure rate are complex. Using spreadsheets to manage the creation of all terms and variables along the way can be error prone and a major support issue. Again, a tool that creates the final number based on provided information improves the review and documentation processes. It is necessary to control and manage only a small set of the key parameters.
The FIT calculation report simplifies the FMEDA calculations for each design component (Figure 4). The lambda values for stuck-at and transient failure modes (LambdaPermanent and LambdaTransient) and diagnostic coverage (DiagCoveragePerm and DiagCoverageTran) plug right into the SPF/RF FIT rates formula as described in ISO26262:2018-5, Clause C.3:
FIGURE 4 – FIT calculation report
Ideally, the tool should automatically determine the percentage of transistors that apply to each design component. With that in mind, the lambda (λ) values shown in Figure 4 already factor in the component’s contribution or area percentage of the base failure rate (BFR), as seen in this formula used to calculate lambda for SPF and RF faults:
GOING FURTHER WITH FMEDA
Now that we have removed the first challenge of determining the base failure rate, we must deal with the daunting task of performing all the FIT calculations to create the SPFM, LFM and PMHF. Even more challenging is the fact that there are typically hundreds of modules in an integrated circuit (IC), resulting in hundreds and hundreds of lines in an FMEDA spreadsheet for all modules or components that need called out, along with their various failure modes (Figure 5).
FIGURE 5 – FMEDA with hundreds of components to analyze. Note: The data in columns A and B is intentionally blurred to protect proprietary information.
Therefore, the second challenge is finding an easier and automated way to create the FMEDA spreadsheet intuitively, allowing the user to traverse through the design, select what components are safety-related and need analyzed and perform all the necessary calculations using the FIT rates. It should be noted that the FMEDA is an artifact of the safety analysis requirements of ISO 26262. As such, automotive manufacturers and their Tier 1 providers look for detail within the FMEDA to show and justify the results achieved. Simply calling out a final number is not sufficient. Think back to those high school exams, where show all your work was required.
As consultants, we get tasked with the tedious job of creating the hundreds and hundreds of lines in an FMEDA. Since FMEDAs tend to be spreadsheet-based, we decided to automate the process using Visual Basic inside of Microsoft Excel.
To learn more, we encourage you to read the following papers. Links to all of these are available in RESOURCES at the end of this article. We describe the steps of this automated push-button FMEDA solution in our paper Push-Button FMEDAs for Automotive Safety: Automating a Tedious Task [1]. A more detailed and accurate analysis is made by specifying the cone of influence of a safety mechanism instead of just the surrounding module. You can read a full treatment on this topic in our paper How Formal Reduces Fault Analysis for ISO 26262 [2]. Of course, the true diagnostic coverage will only be obtainable by using an actual fault campaign that injects faults and classifies the results. You will find extensive details on this in the paper It’s Not My Fault! How to Run a Better Fault Campaign Using Formal [3].
By automating the tedious task of FMEDA creation, using the tools and methods described in this article, you have more time to focus on exploring your design’s safety readiness and figuring out how you can better safety-harden your design. If you need help starting, automating, or performing your functional safety process, Mentor Consulting services is available to help you successfully bring your automotive design to market. For more information on our mission and how to contact us, please visit us at the link provided in RESOURCES below [4]. 
— ADVERTISMENT—
—Advertise Here—
RESOURCES
References:
[1] Push-Button FMEDAs for Automotive Safety: Automating a Tedious Task
[2] How Formal Reduces Fault Analysis for ISO 26262.
[3] It’s Not My Fault! How to Run a Better Fault Campaign Using Formal.
[4] For more information on our mission and how to contact us, please visit us at: https://www.mentor.com/training-and-services/consulting-services
Mentor, a Siemens Business | www.mentor.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2020 #360 – Get a PDF of the issue
Sponsor this Article
Chuck Battikha has more than 35 years of experience in the high technology industry and has been with the Mentor, A Siemens Business, Consulting Division for the last eight years, with a focus on functional verification consulting. His areas of expertise range from CPU development and fault tolerant computing verification to semiconductor and IP development. Over the past five years Chuck has further specialized in functional safety, including work in the medical, nuclear and automotive industries. Chuck earned a BSEE at Northeastern University.
Doug Smith is a functional verification consultant for Mentor, A Siemens Business, with expertise in UVM and formal technologies. Doug holds a master's degree in Computer Engineering from the University of Cincinnati and a bachelor's degree in Physics from Northern Kentucky University.
