Taking Self-Driving Safety Standards Beyond ISO 26262

I participated in a couple of sessions at Arm TechCon this year, the first on how safety is evolving for platform-based architectures with a mix of safety-aware IP and the second on lessons learned in safety and particularly how the industry and standards are adapting to the larger challenges in self-driving, which obviously extend beyond the pure functional safety intent of ISO 26262. Here I want to get into some detail on this range of standards because we’re going to need to understand a lot more about these if we want to be serious about autonomous cars.

Let’s start with some evolving requirements for functional safety, the topic covered by ISO 26262. The standard itself doesn’t specify what safety mechanisms should be used but it does require (in ISO 26262-2) that you need to deliver credible evidence that the safety mechanisms you provide are sufficient. This is a neat little twist – the burden is on you (and your customers and suppliers) to demonstrate functional safety no matter how complex your design may become.

And they are becoming a lot more complex. We now have designs in safety-critical systems (ASIL D) in which not all IP components individually meet that expectation and cannot reasonably be expected to be brought up to that level. How can a system be at ASIL D if parts of it are at lower ASIL levels, or even may be safety indifferent (QM)? The answer lies in being able to isolate and test those components regularly and if they fail to meet expectations, leave them isolated. This has also led to the concept of a fully ASIL D safety-island which can initiate such testing and report problems back to command-central in the car, to be able to support fail-operational responses.

Another mechanism in this diagnostic framework is detecting errors through timeouts from requests to acknowledgement on the bus. Pretty reasonable that this would be a good method to look for misbehaving components. ISO 26262-1 and 5 describe the fault handling time interval (FHTI), usually well within time to detect fault, but of course does not specify how this should be accomplished, just as it doesn’t specify the isolation and safety island mechanisms. These are design responses to the documented requirements.

In Arteris IP Resilience Packages we support all of these capabilities. Dream Chip Technologies talked in an earlier panel about using our NoC technology both to build a safety island, to provide the network between IPs naturally, and to manage IP isolation and independent testing on that network. They also program and test timeouts for request/response per IP through our NoC safety features.

So far this is purely functional safety. ISO/PAS 21448, “Safety of The Intended Functionality (SOTIF)” is a follow-on to ISO 26262 with the goal of defining what should happen at the system level when other than systematic or random error initiators occur- think about software and ML certainly, but also misuse or environmental factors. Safety concerns here are not necessarily determined by system failures; they could be determined by scenarios which weren’t considered in the design of the autonomous driving systems. A simple example might be driving on an icy road; SOTIF requires that these kinds of conditions be included for threat modeling and risk mitigation.

SOTIF is certainly a start in the right direction, though my feeling is that it is currently rather too philosophical to be actionable in engineering design and validation practices. We’ll see what emerges in follow-on releases.

Another very interesting standard, sponsored by Underwriters Laboratories (UL) is UL 4600. What I like about this is that it defines a standard of care for the design of an autonomous vehicle, with a focus on creating and defending well thought out safety cased. These must be presented with very methodical documentation of:

• Why the developer thinks the vehicle is safe
• Why we should believe their argument
• A list of #DidYouThinkOfThat? Cases which allow incorporating lessons learned

UL 4600 doesn’t provide a simple pass/fail checklist and doesn’t set absolute standards for what should be considered safe or what kind of tests should be run, but it does insist on a comprehensive list of safety cases with goals and claims which must be demonstrated to be supported by evidence. And a list of possible exceptions/cases not tested must be included (and can evolve). This is at minimum very auditable. I think this is an important step.

ISO 26262, ISO/PAS 24148 (SOTIF), and UL 4600 are the three main standards I think are important today for autonomous driving. For semiconductor engineers, ISO 26262 is still the most actionable today. Progress is being made at the system level though there’s still a lot of work to be done to more exactly determine how we should define safety in autonomous vehicles, much less how we should implement and evaluate safety.