Functional Safety – What and How

I’ve written before about how the automotive industry adheres to functional safety (FS) as defined in the ISO 26262 standard, along with other SemiWiki bloggers. That standard certainly defines the What part of FS, however it doesn’t mandate how you meet the standard, what tools you should be using, file formats or even languages. Fortunately for us, the pragmatists at Accellera Systems Initiative are focused on the How part of FS, as witnessed by their recent organization of a Functional Safety Working Group (FSWG), and publication of a 27 page white paper on their efforts to define standards for sharing functional safety data. I also spoke with Allessandra Nardi who chairs the FSWG, and works at Cadence as the Sr. Software Engineering Group Director, Automotive solutions.

The stakeholders in the FSWG are in four areas:

Most of the EDA industry is focused on two stakeholders: EDA Experts, IP Experts. Our EDA customers are typically the last two stakeholders: Silicon Experts, System Experts. The new standardization will provide FS data exchange plus traceability through these analysis and work products:

• FTA – Fault Tree Analysis
• FMEA – Failure Modes and Effect Analysis
• DFA – Dependent Failure Analysis
• FMEDA – Failure Modes and Effects and Diagnostic Analysis

Terminology

In the semiconductor design world we use familiar words to define layers of abstraction, like: IP, Component, Module, System. In the FS world of ISO 26262 there’s a slightly different set of words for these same four layers:

The general FS workflow has 10 steps that are inter-related, also known as data elements contained in work products:

Challenges Today

Today when two suppliers deliver work products to a customer, then multiple data formats are typically used, causing headaches for the integrator to resolve:

With a standardized FS data exchange format, the promise is that suppliers only need to follow the standard, and can then deliver the same work products to multiple customers:

The supply chain will be able to streamline FS data exchange between IP, Component, Module and System levels, saving time and avoiding integration challenges.

Traceability

When a requirement changes, how will that impact my IP, Components, Modules and ultimately the System being designed? Traceability is the answer, for both requirements and verification, plus with litigation you need to know at which level FS was compromised. Evidence created through each development layer needs to be traceable, justified and then documented as a safety case, which is then kept around for years after the design work has been completed.

FS Data

You can expect that the FSWG will provide us with a FS data exchange that is interoperable throughout the supply chain, provides traceability, and uses automation in EDA tools. Here’s the scope of the FSWG shown in green, where the first efforts are below the green dotted lines:

IEEE

Just like many standards efforts over the years, once completed and published, the Accellera Functional Safety standard will be considered for contribution to IEEE.

FS Scope

With a standardized FS data model, you can see how all layers in the EDA ecosystem will be used together.

The FS data exchange goals are to be both ASCI and machine parsed, flexible, tool agnostic, and support differing views per abstraction level.

Summary

Functional safety adherence keeps us all safe while driving a car, flying in a jet, receiving medial care and using electronics in industrial applications, so it makes a lot of sense to create standards for exchanging FS data. Accellera has created a FSWG to address the How part through a standard for exchanging FS data, so take a look at their white paper to get all of the details, and maybe even participate with them.

Related Blogs

• An Accellera Update. COVID Accelerates Progress
• DVCon 2020 Virtual Follow-Up Conference!
• Accellera Tackles Functional Safety, Mixed-Signal
• Functional Safety Comes to EDA and IP