THANK YOU.

We have received your request for registration. We will send you a confirmation e-mail once your request has been approved.

SUBSCRIBE TO OUR NEWSLETTER.

Please register below to sign up for our CoreAVI Newsletter.

PLEASE SIGN IN TO ACCESS TO OUR RESOURCES.

Login below using the username and password created when you registered for CoreAVI resources.

Lost your password?

Not registered yet?

Is Scalability and Reuse Across Functional Safety Standards Really That Important?

Multiple Safety Standards
By Neil Stroud

Having spent many years working in the functional safety domain tied to the semiconductor industry, I have found it fascinating to see how things have developed and changed over the years. We have matured significantly in the way we approach safety analysis and the associated hardware, software and collateral as a result of close collaboration throughout the supply chain and with our peers.  After all, we all have a responsibility to make the world a safer place and we can only truly do that by working together.  Personally, being a part of this collaboration has been inspiring.

Naturally, each market vertical is at a different point on the ‘safety maturity timeline’ with aviation and industrial having a long track record versus automotive and medical that are still in the comparatively early evolutionary stages. Also, each has its own related safety standard(s) such as DO-178C/254 for avionics, ISO 26262 for automotive and IEC 61508 for industrial coupled with unique challenges when it comes to safety design and deployment.  However, in my discussions throughout the ecosystem I increasingly hear about “scalability and reuse”.  So, why is this important and what are we doing to address it?

                                                  Figure 1. V-Model Diagram(1)

Scalability means many different things to many different folks so let me add some context. Put simply, what I am referring to in this discussion is the ability to take development and certification efforts for a given market or use case and use it in adjacent markets.  This impacts every point throughout the supply chain. To cite a couple of examples: an SoC vendor can develop a family of safety critical devices that target different applications and take the devices through the multiple safety certifications referenced earlier. In the software domain, a developer can write and certify software elements (drivers, libraries, operating systems, hypervisors etc.) that are also certified across these various safety standards. Taking this approach results in a lower total cost of ownership of functional safety within the ecosystem whilst in turn offering scale and flexibility throughout.

As a developer of any safety product knows, there are two key parts. Firstly, the features of the product itself – the functional and performance requirements, the connectivity, the safety detection mechanisms etc. These of course vary from use case to use case. Secondly, there is the process that must be followed when developing a safety product. This is known as the systematic process and is often referenced by the V-Model diagram (Figure 1). This defines the way in which a product is developed including requirements capture and traceability, verification and validation, inspections and sign off, safety culture and management, to mention a few topics. However, each safety standard outlines its own process requirements which, in the development of products addressing multiple markets, could lead to process inefficiencies due to parallel activities. The good news is that there is ‘overlap’ in the process requirements across these standards, meaning a ‘superset’ development process can be developed to encompass the needs of all the standards utilizing a gap and delta analysis (Figure 2).

‘Superset’ Process
                 Figure 2. ‘Superset’ Process

Making this process pivot does not come without some burden. Generally, teams developing safety systems must have very robust practices that are ingrained in the product lifecycle so making significant changes can be disruptive.  Also, carrying out the overall analysis comparing the status quo with the desired outcome is incremental work. However, the benefits of this transition far outweigh the upfront effort and cost not only for the developer but also for all parties downstream.

In summary, whilst taking this approach to safety development seems intuitive and obvious, there is work that needs to be done to make it a reality and once in place, it can cause some disruption in what is normally a ‘well-oiled machine’. However, the investment is worth it to help drive development efficiencies within your own developments as well as improving the total cost of ownership and time to safety for safety critical systems.

1 Clarus Concept of Operations, Federal Highway Administration, 2005

Neil Stroud / About Author
Neil Stroud joined CoreAVI in November 2020 as the VP, Marketing & Business Development. He has spent over 25 years in the semiconductor industry in technical, commercial, sales and strategy roles. For the past 15 years Neil has been an industry leader in the functional safety domain working closely with the ecosystem, customers, and partners across the automotive, industrial, avionics and transportation segments to build a safer world.

Neil has held various positions in world class corporations including Samsung, NEC, PMC-Sierra and Intel. Immediately prior to joining CoreAVI, Neil worked at Arm, during which time his roles included Senior Director of Technology Strategy where he led a team focused on functional safety, security, machine learning and real-time compute for the automotive and IoT business unit. Most recently, he had been leading the activities in industrial automation, robotics and industrial IoT.

Neil studied Electronic Engineering at Leicester Polytechnic and has spent time living in the UK, Germany, Sweden and most recently the United States.
More posts by Neil Stroud