Automating Failure Mode Analysis For Automotive Safety

By Chuck Battikha and Doug Smith

If you’ve ever had to create a Failure Modes, Effects and Diagnostic Analysis (FMEDA), you know how difficult and painstaking a task it can be.

But FMEDAs are essential in ensuring that your SoCs satisfy ISO 26262 functional safety analysis requirements for automotive designs and for demonstrating that your design is indeed safe.

Because of the intensive and time consuming challenges involved in manually creating FMEDAs, not to mention the level of detailed knowledge required to carry them out correctly and completely, our consulting team at Mentor, A Siemens Business, developed a better and more efficient way to simplify the FMEDA process.

This is an area where Mentor EDA tools yield significant benefits. These tools can perform several useful functions such as read in a design, determine its transistor count, 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 failures in time (FIT) rates for each design component.

FMEDA allows key safety metrics to be determined for a design, but FMEDAs come with their own challenges. In this article, we will step you through how our automated FMEDA creation process addresses the challenges of the FMEDA process. By automating FMEDA creation, using the tools and methods described in this article, you will have more time to focus on exploring your design’s safety readiness and figuring out how to more effectively safety-harden your designs.

An automated FMEDA for automotive designs
The ISO 26262 standard requires quantitative analysis of safety related automotive IC designs. This analysis is used to generate three key functional safety metrics: the probability metric for random hardware failures (PMHF), the single-point fault metric (SPFM), and the latent fault metric (LFM). Standard and industry practice involves analyzing failure modes using a table where each design component is broken out and the effects of the failure is quantified in terms of FIT rates: the number of component failures per one billion operating hours. This process and table make up the FMEDA.

The first challenge is determining the base failure rate for all the different logic used within a design (standard cell, analog, memories, ROM, OTP, etc.) based on the number of transistors for each of the design blocks (logic and memory). This base failure rate should utilize widely-used standards and is the starting point for the FMEDA calculations.

Once the base failure rate challenge is resolved, the next step is the daunting task of performing all the FIT calculations for the entire design hierarchy to allow the creation of the full chip metrics: SPFM, LFM, and PMHF. Even more challenging is the fact that there are typically hundreds of modules in an integrated circuit, resulting in hundreds and hundreds of lines in an FMEDA spreadsheet for all modules or components that need to be called out, along with their various failure modes.

What’s needed is an easier, automated way to create the FMEDA spreadsheet intuitively, allowing you to traverse through the design, select what components are safety-related and need analyzed, and perform all the necessary calculations using the FIT rates.

We decided to use VisualBasic inside of Microsoft Excel to automate the tedious job of creating the hundreds of lines in an FMEDA based on data derived from Mentor, A Siemens Business, EDA tools. While the FMEDA creation part is performed in Excel on a Windows platform, the design extraction and base failure rate/diagnostic coverage calculations are performed in Linux using both an industry standard RTL simulator and a tool to perform the base failure rate calculations. Many companies mount their project directories on Windows desktops, making the process seamless, but files can also be copied (scp) back and forth with very little effort if project directories are not remotely mountable. (We also use Cygwin to fix any permissions issues created across the mounted network drives).

While macros could be called directly, we created an interactive interface within the spreadsheet for easy entry of all the setup information for the FMEDA process, as shown in Figure 1. Network mapping is provided to translate paths between Windows and Linux.

Figure 1: Excel-based interface for entering FMEDA setup information.

The first step involves specifying all the safety information about the design; for example, mission profile, technology lambda values, transistor counts for different design element primitives, and diagnostic coverage information for specific safety mechanisms (see Figure 2 and Figure 3).

Figure 2: Process information needed for FIT calculations.

Figure 3: Lambda information needed for FIT calculations.

Typically, the calculations of the SPFM and LFM are based on individual safety goals, not specific design modules or components. Safety goals are the design’s top most safety requirements, from which all hardware and software safety requirements are derived. We also define these goals in the spreadsheet, as shown in Figure 4, which can be used later to filter or aggregate results for each specific SPFM and LFM.

Figure 4: List of safety goals.

The next step in creating the FMEDA is looking at the design hierarchy and identifying what components are safety related. This is accomplished by using a simulation design compilation, which in our case is a Questasim work library (though any compiled library could work). We created a wizard to automate the process of creating a makefile and extracting the hierarchy (Figure 5).

Figure 5: Wizard for importing the design hierarchy.

Since too many levels of hierarchy would make the FMEDA unmanageable, we specify the design depth to limit how far down the hierarchy to traverse. We also want to separate out memories (no matter what level they are in the design), so we specify a regular expression to help us find the memories within the design.

With this information, we can execute our macros by clicking on “Generate makefile,” which creates a makefile and Tcl script to extract the design and memory hierarchy into a CSV file that is easily imported into Excel. Switching to a Linux terminal, we execute the makefile, and the design gets extracted automatically from the simulator. Next, we click the “Run make (Linux) button, which reminds us to run the Linux makefile before importing results.

Once the design extraction is run in Linux, clicking on “Import results” tells the VisualBasic macros to import and create a design and memory hierarchy worksheet, as shown in Figure 6.

Figure 6: Imported design hierarchy generated automatically.

At this point, a design block can be specified as an analysis block, which means the FIT rate will be calculated individually for it. It can also be designated as to whether it is safety related, whether it should be treated as a black-box, and whether or not it is a safety mechanism. The corresponding safety goal and safety mechanism type are also entered. The design memories are pulled out separately into a different worksheet (Figure 7).

Figure 7: Design memories automatically extracted from the design using the regular expression on the module/instance name.

Excel allows us to include conditional highlighting, which makes reading the design or memory worksheet easier to manage (Figure 8).

Figure 8: Conditional highlighting built-in for readability.

The design hierarchy worksheet makes adding and removing components from the safety analysis very easy — which is very useful for what-if analysis. Since the FMEDA generation is automatic, you can iterate through different safety mechanisms, regenerate the FMEDA and FIT rates, and observe the effect on the diagnostic coverage and overall FIT calculations.

Our next step is the actual FIT and diagnostic coverage calculations (Figure 9).

Figure 9: Step 2 runs the FIT calculations and imports results into an FMEDA.

Again, VisualBasic is used to create all the makefiles, the input and output directories, and the input files used for the FIT analysis (Figure 10). As with importing the design hierarchy, there is a step that needs to be done in Linux, namely, running the FIT calculations for each analysis block. FIT calculations on lower-level blocks must be performed first so the FIT results can be rolled up the design hierarchy. All dependencies are handled automatically using the generated makefiles.

Figure 10: Directories and files created by the wizard to generate the FIT calculations.

Once the FIT and diagnostic coverage calculations are complete, the “Import results” button loads the FIT calculations for each analysis block and memory, then places them into an auto-generated FMEDA (Figure 11).

Figure 11: Auto-generated FMEDA with FIT calculations.

The resulting FMEDA can be used as your project’s FMEDA or for what-if safety exploration. Since it is auto- generated, different safety mechanisms can be experimented with in the “Design Hierarchy” worksheet, and then the FMEDA regenerated very quickly using Mentor’s EDA tools. This may be particularly useful if you have access to safety mechanism insertion tools that safety-harden a design automatically by inserting protections like parity, ECC, redundancy, voting, etc.

We have already successfully introduced the methods and tools described in this paper at several customer sites to improve and facilitate their functional safety workflow. 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 here. To read a full description of our push-button solution for creating and automating the FMEDA process and more background on functional safety requirements as well as FMEDA itself, please download the whitepaper, Push-Button FMEDAs for Automotive Safety — Automating a Tedious Task.

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.