Time For FMEDA Reuse?

How do designers quantify safety in electronic systems? Through one or more tables called Failure Modes, Effects and Diagnostic Analysis – FMEDA. In fact, an FMEDA does not have to be a table; it could be manifested in scripts or some other form, but a table is the easiest way to think of this information. Think of an FMEDA for an IP, as the concept extends easily to a system-on-chip (SoC). The table has a row for each failure mode that the IP experts can imagine might lead to a critical safety problem. Following identifying information for that failure mode is a description of the effect – the safety problem it might cause. Through fault simulation, the safety engineer determines the likelihood of the root cause problem leading to that effect. If the likelihood is significant, the designer will propose a mitigation technique, such as a parity check to detect the problem or an error-correcting code (ECC) check to correct it. A completed FMEDA then represents a comprehensive safety quality document for that IP, a characterization that an SoC integrator can use when determining the FMEDA for the whole design.

Fig. 1: The multiple challenges in creating FMEDAs.

Scalability

There is a problem with this approach. An FMEDA, in this instance, is a flat characterization of IP safety which might be acceptable if all the IPs were hard. When characterizing other aspects of the IP, designers can build the FMEDA, store it with the IP, then use that table in SoC characterization. Most IPs these days are configurable, such as a network-on-chip (NoC). No one FMEDA could be built to handle all cases. The SoC developer must build the FMEDA for the configuration that will be used. The IP supplier can provide help and hints, but the integrator must do all the analysis. If configurations change during design, those FMEDAs must again be rebuilt.

Intuitively, this is wasteful. Think again of the NoC IP. While the instantiated topology of the NoC will probably change as the design evolves, it most likely will not change radically. And the influence of these alterations on the FMEDA will be even more limited. Rebuilding the FMEDA from scratch on each reconfiguration ignores much that is unaltered. In other cases, there are predictable changes from previous results. Re-analyzing each reconfiguration will work, but it presents a scalability problem as design sizes grow. In a process that does not scale well, steps may be missed, and safety can be compromised. For the integrators, re-building FMEDA is a great deal of work in an already full design schedule. Reducing that effort can make their lives easier.

Reuse through modeling

Arteris has written a forward-looking white paper on how this problem could be solved through reuse. The important aspects of FMEDA could be captured in safety models developed by the IP supplier based on understanding the IP architecture and detailed characterization. An FMEDA for a fully configured IP can then be built by an integrator using a compiler drawing on these models and the IP RTL. This should be a much easier task for integrators. The SoC safety team can still run full flat FMEDA prior to signoff as a double-check; every reconfiguration will not need an analysis.

Fig. 2: The proposed FMEDA generation process.

The compiler could build a conventional FMEDA table for the integrator or pass a script to a script-driven tool for use in SoC FMEDA generation. Today that level of integration seems to be primarily internal in the big automotive semiconductor houses. Typically, this script aggregates the IP level tables with FMEDAs for integration fabrics, power, and controls. Designers applying in-context requirements and assumptions of use into abstract fault modes create a use case of interest. There is an opportunity to standardize the organization of FMEDAs, which could simplify aggregating such input from multiple IP suppliers. The developing proposal, IEEE P2851, should enable this effort. It may also help define standards for aggregation and abstraction. This would encourage the development of commercial tooling to fully automate the flow from FMEDA development for IPs to FMEDA development for an SoC.

One more consideration in automation is traceability. Safety requirements are a critical component in system requirements for automotive electronics and should be tied into the traceability infrastructure along with design and test. Adding traceability automation would complete a robust system for developing and tracking safety characterization.

Click here to download a white paper on this subject. Additionally, a presentation on this topic is available here.