Interpreting the functional safety standard isn’t as simple as just looking at the document.
You might think that when you get into a debate with a customer or a supplier about the exact interpretation of some aspect of ISO 26262, all you have to do is go to the standard, look it up, and there’s the answer you all need, plain as day. That would be ideal but often doesn’t reflect reality. To realize why, you have to understand the background to the standard.
ISO 26262 was initially written by specialists in the electromechanical systems market with only a few semiconductor experts involved. This imbalance led to a heavy focus on process with not so much attention to semiconductor functional safety analysis details. (And it was a huge motivator for me and many other experienced semiconductor and semiconductor IP experts to volunteer get involved!) Also, ISO 26262 is a massive specification with many sections we call “parts,” each developed by independent international working groups, which means that there are inevitable inconsistencies between those parts. In the 2018 second edition, we added Part 11, “Guidelines on the application of ISO 26262 to semiconductors,” with guidelines and examples for semiconductor and IP companies, plugging a major hole. The working groups also tried to clean up some of the inconsistencies between parts, and even clauses and diagrams within the same section, to better clarify requirements. The second edition is definitely an improvement. But guess what – it is still isn’t perfect.
Why? Partly ambiguity. Because what I think is clear, you may not think is clear. And some of this ambiguity is intentional: This is a voluntary (though widely followed) standard, aiming to preserve flexibility for innovation and differentiation. The committees don’t want to be too prescriptive, which inevitably leads to some ambiguity.
All very understandable, but those of us in the trenches wind up in a lot of interpretation debates. Not everyone we work with has been living the standard and its evolution for years. They’ll read something in Part 11, for example, and tell me that we have to do XYZ precisely in this way. I get why they read it that way, but they’re wrong. I tell them they need to look at Part 11 and some statements in Part 5 and Part 10. Part 11 is guidance and examples, but the requirements are in those earlier sections. Generally, after we get through that discussion, we come to an agreement, but it takes time. And it happens a lot with customers relatively new to ISO 26262.
One topic (of many) that prompts a lot of debate is the Safety Element out of Context (SEooC). What should my customer expect from me, in testing and documentation, for what I supply – a highly configurable soft IP/RTL? I can’t verify its safety metrics in every possible customer use case because I don’t control its use in a chip, have any idea a priori of the architecture of the chip, or understand how that chip will be used at the system level in a module, or the use of that module in a car.
SEooC is a concept intended to bound what an IP provider should focus on for analysis under what conditions I expect and provides a framework for explaining this analysis and assumptions of use to my IP users. This helps integrators higher in the value chain know how to incorporate my safety capabilities and documentation into their analysis and documentation. SEooC seems like it would have a lot of wiggle room, but experts up and down the value chain have settled on agreement on what they expect in practice. Part of that is shown in the diagram above – which shows an analysis of what clauses apply fully, and which apply only partially to a soft IP. (By the way, this process is called “tailoring.”)
Over time, I’ve built spreadsheets to cross-reference sections of the standard with my notes on collective interpretation (it’s so large it’s become a database!). It includes pointers to potential ambiguities or holes in the ISO 26262 text and diagrams with references to the specific clauses to help me analyze certain situations. In updating my database with changes from the first edition to the second edition, I came across some interesting facts. For example, FMEA and FMEDA didn’t appear in the first edition of the standard, only in the latest edition! More than that, there are still quite a few areas where interpretation depends as much on experience and/or de facto agreements of best practices, guided by the working understanding of expert developers and users of the ISO 26262 standard, from IP developers to automotive OEMs. In essence, all of us in this automotive ecosystem negotiate with our suppliers and integrators/customers to determine what makes mutual sense from a technology and process perspective, and familiarity with the spec is key to an efficient negotiation process.
In other words, ISO 26262 expertise is not just about reading the document or even setting up the processes. It’s also about being thoroughly immersed in how the standard is practiced today and how the underlying requirements within the specification apply to your particular situations. We are all working together in the process of continuous learning and improvement.
Related
ISO 26262 Knowledge Center
Tech Talk: ISO 26262 Drilldown
What’s required to gain a solid foothold in the automotive electronics market.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply