Safety Q&A on ISO 26262 and beyond with VP John Buszek

John Buszek is the Vice President of Products and Services at AutonomouStuff. His work with our engineers and customers often involves considerations for complex automotive safety standards.

The ISO 26262 standard represents the benchmark for electric and/or electronic systems safety in production automobiles. A rigorous, risk-based analysis is necessary to achieve such certification — and it comes at great cost to manufacturers.

John recently took the time to answer some questions about how ISO 26262 and related standards impact autonomous vehicle development.

What are some challenges developing autonomous vehicles towards the ISO26262 standard?

Software development time and cost are among the many challenges. That’s not unique to autonomous driving, but there is even more time and cost in developing ASIL autonomous system software when compared to other domains of automotive electronics, due to the increased complexity. Moving prototype autonomy software into a development process required by ISO 26262 is a very significant investment. 

When it comes to developing autonomous systems for production, is software development the primary cost for achieving state-of-the-art safety?

It’s a big one! Beyond increased development cost, achieving ISO 26262 certification can involve increases to your system cost, AKA the BOM. For example, once you try to certify your system, throughput you thought you had available on your compute platform for primary application functions will often be distributed towards functions intended to detect hardware failures, which could result in increased compute performance requirements. Also, you may need to have redundant hardware in order to detect transient random hardware failures or to enable safe states across all failure modes. Redundancy in computing can have a significant impact system BOM cost. Achieving metrics required for ASIL certification, while optimizing system cost, is a major area of innovation in autonomous driving development. 

Are there any other technology challenges that rise from the need for redundancy in autonomous systems?

Yes — synchronization. We see many different sensor modalities grouped together in autonomous driving for various perception tasks. These sensors must be sampled in sync, with data transfer between sensor and ECU running as close to real-time as possible. Diverse redundancy in compute can also be a synchronization challenge, as often the outputs of the redundant compute systems are intended to be compared to check for failures. Keeping high performance machines in high frequency lock step is very involved. You need very precise timing shared across machines. This means the performance machines need some amount of real-time embedded computing for safety critical functions and networking. Along with real-time compute requirements, non-deterministic behaviors in performance CPU and GPU architectures must also be considered in the synchronization strategy.

You mention inserting software and hardware into the design to keep the system safe in the presence of failures. But what about all the situations where there is no failure and the system is functioning normally? How is the autonomous driving industry working to ensure the system is safe even when there are no failures?

There is a standard in automotive uses to ensure the safety of the intended functionality (SOTIF) in the absence of a fault — ISO/PAS 21448. While ISO 26262 is all about safety in the presence of faults, ISO/PAS 21488 offers design and testing guidance to engineers to ensure a system can achieve safety without failure. For example, with the many driving scenes that can be encountered, AI algorithms in autonomous systems could have potential for worse performance in certain driving situations. The purpose of SOTIF is to enable engineers to design and test the system to avoid or reduce the probability of entering potentially unsafe conditions.