ISO 26262 – The Second Edition: what’s in it… and what isn’t
A new version of the automotive safety standard arrives later this year. Review the main updates and see how it will combine with the incoming SOTIF autonomous driving standard.
Carmakers are steadily integrating higher volumes of automated driving features into road vehicles, making functional safety a top priority for their whole industry. To address that, the automotive giants and the companies that supply their electrical and/or electronical (E/E) systems follow the ISO 26262 standard, established in 2011 by the International Organization for Standardization. Until now, ISO 26262 has addressed many aspects of functional safety for passenger vehicles with a maximum gross weight of 3,500kg. Later this year, an update to the standard will be published. It includes a lot of upgrades, eliminates the weight limit, and will thereby expand its coverage to other vehicle categories, including heavier road cars, trucks, busses, and motorcycles. Notably, the second edition will also include guidelines on the design and use of semiconductors in an automotive functional safety context.
What will remain missing from ISO 26262:2018, however, is detail on how to handle the development of autonomous vehicles. This missing topic will be addressed in a new standard to follow the second ISO 26262 release, ISO/PAS 21448. It is more commonly referred to as SOTIF, standing for ‘Safety of the Intended Functionality’.
The considerations ultimately addressed by ISO 26262 and SOTIF will touch on all parts of the automotive supply chain. The design automation software, for example, will be required to address the quality and reliability of the components in an automotive product environment.
ISO 26262 defines the functional requirements for the risk assessment and the confidence in the use of such software tools. This is described in Clause 11 of ISO 26262, Part 8. It sets down the requirements applying to tool qualification documentation for all software used in automotive design, manufacturing, and in-system operation.
This is already set out and required in the current edition of the standard. What, though, are the significant incoming changes?
Coming in the second edition of ISO 26262
What is new and significant in the second edition?
The second edition of ISO 26262 includes several important changes and additions with implications for software vendors. These include:
- Updates to the PMHF (Probabilistic Metric for Hardware Failure) equation and verification of safety analysis.
- Extending the process to ensure confidence in the use of software tools to include vendor validation
- Guidelines on the application of ISO 26262 to semiconductors in the standard’s new Part 11.
ISO 26262 delivers a minimum set of requirements to fulfill functional safety aspects, but it does not – and cannot – cover all safety aspects of a product. It is the responsibility of the system supplier to ensure that the product meets the highest safety, reliability, and performance metrics. Ensuring software tool safety compliance is part of that process.
Confidence in the use of software tools
From an ISO 26262 perspective, software tools used to create components for automotive systems must be qualified to do their job in a functional safety design environment. Proof is delivered by way of a certified qualification report.
All the software tool qualification and classification requirements are described in Part 8 of the standard. It specifically defines a set of ‘tool confidence levels’ (TCL1-3). These classify the confidence requirements. TCL is thus a measure of the possibility of the software being responsible for a failure in a component, and of the ability of the software to detect that problem. TCL1 is the highest; TCL3 is the lowest.
For a software tool used in the development of an automotive system, ISO 26262 states that, “[The analysis should ensure that] the risk of systematic faults in the developed product due to malfunctions of the software tool leading to erroneous outputs is minimized. And that the development process is adequate with respect to compliance with ISO 26262, if activities or tasks required by ISO 26262 rely on the correct functioning of the software tool used.”[1]
ISO 26262 describes four qualification methods for achieving a certain confidence level (shown in Tables 1 and 2 for TCl2 and TCL3), but not all of them are required. Different methods are recommended according to the design’s targeted Automotive Safety Integration Level (ASIL). For example, if the component is aiming for the base ASIL-A or ASIL-B levels, methods 1a and 1b are “highly recommended” (++), and methods 1c and 1d are “recommended” (+).
Table 1: Qualification of software tools classified TCL3 (ISO 26262)
Table 2: Qualification of software tools classified TCL2 (ISO 26262)
The software tool qualification for TCL 2 only provides a “highly recommended” (++) verification method (1c). The development process method (1d) for qualification has been demoted to “recommended” (+).
The four methods are just a part of the tool qualification process. The software tool qualification report will be an executive summary of the classification and validation process, the results, recommendations, project-specific process measures, and detailed information about the use of the tool. Software development tools classified as TCL1 are suitable for use on components targeting ASIL-D, the most stringent of the four ASIL levels.
New ISO 26262 Part 11 on semiconductors
Semiconductor companies that are Tier-2 automotive suppliers must meet many tough requirements set by their OEM and Tier-1 clients. They must show evidence that the development of ICs and systems delivered to those customers follow – or have followed – appropriate design, verification, and validation flows that use qualified software tools. ISO 26262 supports this by describing the requirements for tool qualification.
The second edition of ISO 26262 includes a new chapter (Chapter 11) that gives guidelines on the application of ISO 26262 to semiconductors.
Part 11 provides a comprehensive overview of functional-safety related items for the development of a semiconductor product. It includes general descriptions of a semiconductor component and its development and possible partitioning. It moves on to address important items related to ISO 26262, including sections about hardware faults, errors, and failure modes. It also addresses intellectual property (IP), specifically with regard to any ISO 26262-related IP with one or more allocated safety requirements.
Automated driving and the move toward SOTIF
In 2014, SAE International established a common terminology for automated driving in the J3016 standard. It describes six levels of automated driving. Greater degrees of Autonomous Driving (AD), also known as driverless-driving or self-driving, are gradually introduced from Level 2 onward.
Figure 1: The six levels of autonomous driving (SAE International)
Autonomous driving is at an early stage. The cars we see on the road today are typically Level-2 vehicles. The industry is only now taking its first steps toward the commercial launch of Level-3 autonomous vehicles. While Level-3 vehicles are a reality, they still face legal and regulatory challenges that hamper the implementation. Vehicles capable of meeting the definitions of ‘high’ and ‘full’ autonomous driving— Level 4 and Level 5 —are for the future.
ISO 26262 remains the foundation for providing safe systems, safe hardware, and safe software. These aim to ensure independent, safe operation in the event of a failure. The ISO 26262 standard establishes state-of-the-art processes and architecture, clearly setting rules that allow a system to be safe.
The SOTIF standard, still currently in development, will provide guidelines for Level-0, Level-1, and Level-2 autonomous drive (AD) vehicles. Even these levels of autonomy still have the world’s AD experts struggling to define how to make a system safe.
They face a conundrum: Autonomous vehicles must be safe even when they do not fail. So the SOTIF standard is being drafted to provide guidance that assures an autonomous vehicle functions and acts safely during normal operation.
Topics covered in SOTIF will therefore include:
- Detail on advanced concepts of the AD architecture
- How to evaluate SOTIF hazards that are different from ISO 26262 hazards;
- How to identify and evaluate scenarios and trigger events;
- How to reduce SOTIF related risks;
- How to verify and validate SOTIF related risks; and
- The criteria to meet before releasing an autonomous vehicle.
This will comprise the foundations of an AD methodology. Next, comes the implementation. Autonomous verification and validation must meet many tests, from simulation to full vehicle, which include factors encompassing the entire 4D environment such as weather, road condition, surrounding landscape, object texture, and possible driver misuse.
SOTIF will provide many methods and guidelines for the inclusion of environmental scenarios for use during advance concept analysis and, later on, validation. The SOTIF committee would like to guide users through the documentation of different scenarios, the safety analysis of those scenarios, the verification of both safety scenarios and various trigger events, and the validation of the vehicle in the environment with applied safe systems. These factors will be paramount to compliance with the upcoming standard on AD.
These advanced concepts, evaluations, and tests will go well beyond previous development processes. With that in mind, our reliance on test platforms, software tools, digital-twin simulations, or hardware in the loop, is set to become more important than ever.
So when developing your AD system, you absolutely must be confident that your team has access to the best-in-class software tools.
References
- INTERNATIONAL STANDARD ISO 26262:2011: “Road vehicles — Functional safety“, Parts 1-9, first edition, 2011-11-15
- ISO/DIS 26262:2016, “Road vehicles — Functional safety”, September 2016
- ISO/DIS 26262-11:2016(E), “Road vehicles — Functional safety, Part 11: Guideline on application of ISO 26262 to semiconductors”
- ISO/FDIS 26262-8:2018(E), Road vehicles — Functional safety, Part 8: Supporting processes
- “ISO 26262 second edition: what’s new for semiconductor test?”, Mentor Whitepaper
- “Functional safety in AI-controlled vehicles”, Mentor Whitepaper
About the Authors
Joe Dailey is the Global Functional Safety Manager at Mentor, a Siemens Business. With over 25 years of experience, he established the Mentor Safe program which focuses on specific functional safety activities including supporting processes, safety architecture, safety analysis, and training. Dailey holds a Master’s degree in Business Management from Arizona State University and a Bachelor of Engineering in Electrical Engineering from Youngstown State University.
Juergen Schloeffel is Program Manager in the area of EDA and DFT at Mentor Development in Hamburg, Germany. His interests include advanced testing techniques, design automation for DSM technologies, and automotive testing. He has a diploma in Physics from Goettingen University. Before joining Mentor, Schloeffel held various R&D positions at NXP and Philips Semiconductors for more than 20 years.
