|
|
|
www.design-reuse-embedded.com |
|
Taking Self-Driving Safety Standards Beyond ISO 26262
f we want to be serious about autonomous vehicles, the safety standard landscape needs to evolve beyond pass/fail checklists.
Kurt Shuler, semiengineering.com, Dec. 05, 2019 –
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.
Back
Contact Us
Partnership Offers