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?
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).
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
