ISO 26262:2018, 2nd Edition: What Changes?

If you’re involved somehow in design for automotive electronics, you probably have more than a cursory understanding of the ISO 26262 standard. What your organization is working from is most likely the 2011 definition. The most recent update is formally known as ISO 26262:2018, less formally as ISO 26262 2^nd Edition.

Figure 1. Overview of the ISO 26262:2018 series of standards (Source ISO/FDIS)

Standards should evolve, but what changed and why? I’ve been a member of the ISO 26262 working group for many years, and particularly involved in how it should be interpreted for IP, and I’ve got to tell you, I have struggled. From my perspective, it was originally written around an implicit expectation that chips are built from scratch entirely within one organization, and this is a dated assumption. There was also not enough guidance for IP-based design or design distributed across multiple companies or sites. The workaround for an IP supplier has been to use the Safety Element out of Context (SEooC) mechanism. But this depends heavily on human interpretation, by the component vendor on what may be relevant to the integrator and vice-versa, with little guidance from the 2011 version of the standard. I complained (whined?) quite a bit to the committee about these problems and they eventually invited me to the working group. I wasn’t the only one confused and other people joined, and we seem to have had an impact; our efforts have resulted in a lot more clarification, organization and practical examples in the latest standard. I think the new Part 11 of the updated standard provides a lot more detail and useful examples for us in the semiconductor and semiconductor IP industry.

You’re probably wondering how safety standards apply as more automation appears in vehicles. Back in 2013 when I joined the working group, the common view was that if something went wrong in that automation, a light would flash, or a beeper would beep and the driver would take back control. But technology is moving a lot faster than that expectation, to the point it may be safer for a backup system to take over control. The industry has coined a new term, “fail operational”, to address this (see this nice explanation by NXP); the system doesn’t just fail silently, it becomes fault-tolerant. As we approach autonomous driving, if the system fails, we must have a faster response backup than depending on the driver.

Increased system autonomy inserts a new set of safety concerns: What happens when the system causes a safety issue even though there are no systematic errors and no random errors (like due to cosmic rays, etc.)? In other words, what if the intended functionality of the system results in a safety issue? These type of issues created by new automation technologies are not handled in ISO 26262:2018 2^nd edition, which continues to focus on the resilience of hardware and software to safety-related risks and the processes used to create the hardware and software. These system safety concerns will be addressed in a new standard, commonly called SOTIF for Safety Of The Intended Functionality (aka ISO/PAS 21448:2019)  How do you manage for acceptable levels of safety when key components of the system are non-deterministic, as machine-learning (ML) systems inevitably are? What kinds of redundancy between ML systems are acceptable and how can the failure rate be quantified? How should we test and qualify these systems? Further out still are whatever requirements there might be around SAE levels 3 through 5, where true autonomy takes over. ISO 26262 is reasonably not trying to eat the whole elephant in one go.

Security issues also weren’t a big concern in 2011 but are obviously hot now. How should security be factored into safety analysis? Part 2, “Management of functional safety,” of the updated spec takes a step towards this by requiring a design organization create and maintain “effective communication channels” between functional safety, cybersecurity and other organizations relevant to functional safety. It doesn’t spell out what exactly you need to do to prove you have met this expectation, but that’s not uncommon in ISO 26262. Integrators generally set the bar for suppliers to meet what they consider to be necessary and sufficient. If you’re a supplier and you think that’s not fair, then you need to negotiate your position with lots of facts and create a mutual understanding. If you want a seat at the table, that’s how it works.

This is a point I’ve argued for a long time. “Compliance” isn’t a one-off exercise where you show a certificate to your customer and you’re done. Your customers, the integrators, are primarily concerned with how they are going to demonstrate compliance to their customers. The bar keeps rising because the technology is evolving rapidly and ultimately the vehicle manufacturer carries most of the liability. A certificate at most is a pass to enter the competition as a vendor. In addition to that, the integrator can ask you to re-demonstrate all aspects of compliance and to make changes to your processes, work products or product. I’ve said before that developers need to be thinking beyond the letter of the standard and thinking more about the spirit of the standard. Part 2 clauses 6.4.9 and 6.4.10 introduce new guidance on confirmation measures and confirmation reviews which should give some idea of these expectations.

Here’s an example of just part of the requirement in a confirmation review: judge whether the key work products … provide sufficient and convincing evidence of their contribution to the achievement of functional safety. In other words, even though you do all expected rote safety stuff (fault simulations, etc), an independent reviewer still has to believe it all adds up to improvement in functional safety.

Chapter 11 of the 2^nd Edition is going to be the most immediately interesting to semiconductor and IP design teams, and also to the fabs. There’s a big section on dealing with IP, from the perspectives of the IP developer and the integrator and how these two should interact, including discussion on integrating the IP as a SEooC. I’ll highlight just one topic from this section: If the IP integrator determines that the fulfilment of safety requirements is not possible with the supplied IP, a change request to the supplier can be raised … In other words, even though you (the IP supplier) think your IP is finished, if the integrator needs something additional to meet her safety objective, you may be on the hook to provide it. Of course, there will be fact-based negotiations but if an integrator thinks she cannot get her customer to accept her element unless you make a change, then you will most likely feel a commitment to positively respond to your customer’s new requirement (and maintain the opportunity to pursue future business with her). The wakeup call is that ISO 26262 certifications don’t absolve you of the need to share information and additional evidence or work products with your customer, even if you have a certificate of some type, and doesn’t take away the possible need to make product or work product changes in support of your customer’s requirements.

There’s more in the 2^nd Edition, for example on applications to motorcycles, trucks and busses, but I’ll wrap up by mentioning that there’s quite a bit of detail on determining base failure rates. This information was sprinkled through the earlier rev of the standard, now it’s consolidated into Part 11, Clause 4.6, “Base failure rate for semiconductors.” The challenge here is that a lot of designs are moving to advanced semiconductor process nodes where reliable information (at least over the lifetimes required for automotive applications) is sparse at best. There’s a fairly lengthy discussion on assumptions and mechanisms for calculating these failure rates.

Overall, there’s a lot of good progress in ISO 26262:2018, 2^nd Edition, in plugging holes that have become apparent over time and making it easier to understand and use. That’s probably the best way to view this update; cleaning up and refining safety requirements and guidance more or less as we originally understood them. ISO 26262:2018 does not address the non-systematic and random safety issues that will occur with autonomous systems using neural networks; that is coming in the SOTIF standard. So for engineers working on level 3 and beyond systems, both ISO 26262:2018 and ISO/PAS 21448:2019 should be on your bookshelf.

For more information about ISO 26262:2018 Part 11, download the 39-slide Arm TechCon presentation titled, “Fundamentals of ISO 26262 Part 11 for Semiconductors,” by Arteris IP Functional Safety Manager Alexis Boutillier and ResilTech Scientific Advisor Dr. Andrea Bondavalli, or watch my very popular SemiEngineering “Tech Talk: ISO 26262 Drilldown” video.