[Author’s Note: This series of articles predates my joining the AV industry. It may have some inaccuracies, but I am leaving it up in case it helps people]
Today’s post finally wraps up SIS Engineer’s initial foray into the strange and exotic world of automotive functional safety, with a focus on autonomous vehicles. In part 1 of this article we covered parts 1-4 of ISO 26262, which covers the vocabulary, general requirements, conceptual design, and the system-level design. In part 2, we dedicated the entire post to covering part 5 of the standard, which covers product development at the hardware level and specifies required probabilistic metrics, including Automotive Safety Integrity Level (ASIL).
Note: Over the course of these posts, the new 2nd edition of ISO 26262 was released. Note that these posts are all based on the 1st edition.
In today’s final part 3 of this series, we will briefly cover parts 6-10 of ISO 26262. As a reminder, parts 6-10 consist of:
- Product development at the software level
- Production and operation
- Supporting processes
- Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis
- Guideline on ISO 26262 (Informative)
These last 5 parts cover a lot of diverse material. In order to make this post marginally readable, we will just hit the highlights and cover some interesting topics. Then we will wrap up with some closing thoughts.
Note: It turns out that trying to summarize a technical standard in a blog post is a little like trying to write a poem about the IRS tax code. Lesson learned.
Note that our highlights skip straight to sections 8-10. This is not to downplay the importance of section 6 (software development) and section 7 (production and operation). These sections, especially software development, are key to achieving functional safety. I just happen to find the topics in the later sections more interesting and/or intriguing. Hopefully you will too! 😉
Supporting Processes (part 8)
Part 8 covers a selection of supporting processes that are required to successfully implement the requirements of the rest of the standard. These processes include: distributed development, safety requirements specification, configuration management, management of change, documentation, software tools, and qualification of components. We will concentrate on just three topics: Safety Requirements, Verification, and Proven in Use.
Specification and Management of Safety Requirements
I chose to focus on this topic because I think it is an area where ISO 26262 and the automotive industry have a clear advantage over what I have observed in the application of IEC 61511. We noted in an earlier post that ISO 26262 has a more sophisticated model of the Safety Requirements Specification (SRS) that is hierarchical. This model (shown below from Figure 2 in the standard) is further developed in this part.
Figure 2: Structure of Safety Requirements
The section requires that safety requirements have certain characteristics, attributes, and properties:
| Each Safety Requirement | Set of All Safety Requirements | |
| Characteristics | Attributes | Properties |
|
|
|
The requirements above all contribute to a key goal for safety requirements: traceability. Traditionally, the process industries have tended towards a lengthy narrative SRS supported by even lengthier design standards. This approach has not supported traceability. Some modern SIS Safety Lifecycle tools have improved this somewhat with database-driven SRS tools. However, traceability for SRS requirements remains elusive in the process industries.
On the other hand, the software development industry already has a host of requirements management tools available (e.g. IBM DOORS, JAMA) and proven in massively complex software development projects. Without firsthand experience, it is hard to know how effectively these tools are being used for automotive functional safety. However, I think ISO 26262 already provides a better basis and clearer expectations for the SRS. IEC 61511 users and committee-members could learn something here.
Verification
We mentioned way back in part 1 that Verification was not in the definitions list, but that it is still applied rigorously throughout the standard. Specific verification requirements are provided in other parts of the standard (e.g. part 6.11 for software verification). Part 8 of the standard provides a broader view of verification over all phases of the lifecycle.
The main similarities and differences between verification in IEC 61511 versus ISO 26262 include:
- Both require verification of deliverables at each step / phase of the lifecycle
- Both require verifications plans
- ISO 26262 goes further requiring a verification specification (i.e. traceability, pass/fail criteria)
- ISO 26262 verifications are hierarchical, matching the structure of the safety requirements
The verification specification should not be confused with a validation specification (i.e. full functional test procedure) which is more common in the process industries. Verifications under IEC 61511 are generally less formal and often take the form of checklists. This may be because IEC 61511 systems are generally less complex and have fewer parties involved.
Proven in Use (and Component Qualification)
Proven in Use and Hardware Component Qualification are covered separately, but I lump them together here because they are related. The question is: “How do we determine if components may be used in an ISO 26262 compliant system?“
For basic parts (e.g. resistors, capacitors, etc.), they rely on standard quality qualifications. More complex components and systems are integrated per the lifecycle requirements of ISO 26262. This approach is generally analogous to the IEC 61511 approach (i.e. electrical components are specified, devices are designed per IEC 61508, and systems are integrated per IEC 61511)
Things get interesting in the gray area of “intermediate” parts and components. These are the subject of this section of the standard. There are three ways intermediate components may be qualified:
- Testing
- Analysis
- Proven in Use
Item 1 is noteworthy because, although you sometimes see testing included in IEC 61508 analyses, there is no Route in IEC 61508 based on testing, i.e. Route 1H is based on analysis and Route 2H is based on field data.
This addition strikes me as a good alternative (anything is better than some SIL certificate “analyses” I have seen!), but I am a bit skeptical. In my opinion, ISO 26262 does not provide sufficient detail to define the requirements for testing-based qualification. They may be opening themselves up for abuse, with testing-based qualifications based on invalid tests, non-applicable environments, etc.
ASIL and Safety Analysis (part 9)
Part 9 of the standard is short, coming in at only 25 pages (including all the fluff). However, it covers several key concepts. We will highlight all of them briefly below.
ASIL Decomposition
A fancy term for a simple concept. ASIL targets are applied to safety goals, but it may be possible for more than one item to address a safety goal, so the ASIL target may be split between the items. In IEC 61511 vocabulary, two properly designed, independent “stacked” SIFs may have additive SILs, i.e. SIL 1 + SIL 1 = SIL2.
This concept is well established in IEC 61511, although you do occasionally run into “deniers”. My position is that this is a perfectly acceptable practice as long as good SIS engineering practice is followed.
Coexistence of Elements
Speaking of good SIS engineering practice, this section covers how to handle systems where components have different ASIL levels, or where some components are safety critical and some are not. This is very similar to IEC 61511 requirements.
Dependent Failures
Also known as common cause failures. Similar to IEC 61511, common cause must be considered at each phase of the lifecycle, including operation and maintenance.
Safety Analysis
Just like SIL, quantitative calculations are required for ASIL metrics. The methods are recognizable, including FMEA, Reliability Block Diagrams, Fault Trees, Markov Models, etc.
Sadly, ISO 26262 follows the same misguided path as IEC 61511 for systematic failures:
“The quantitative analysis methods only address random hardware failures. These analysis methods are not applied to systematic failures in ISO 26262”
I won’t rehash that issue here, but I… uh… disagree.
Guideline on ISO 26262 (part 10)
Part 10 of the standard is a must-read if you hope to absorb the contents and intentions of ISO 26262. It is an informative (i.e. non-normative) part of the standard and provides guidance on the requirements of all of the other parts.
Relationship with IEC 61508
Section 4 in particular is a good read, as it addresses the relationship between ISO 26262 and IEC 61508. Note that unlike IEC 61511, the automotive ISO 26262 standard does not list IEC 61508 as a normative reference.
Safety Requirements Structure
If the earlier discussion on hierarchical safety requirements was a mystery to you, section 10.7 provides some illustrative examples of the structure.
Safety Element Out of Context (Part 10.9)
For those of you wondering about “ASIL Certificates”, part 10.9 introduces a similar concept of Safety Element out of Context (SEooC). To be clear, the word certificate is used nowhere in ISO 26262. However, the SEooC concept is intended to address systems (i.e. collections of components) which have been designed and integrated per ISO 26262, but not designed for a particular application. Sound familiar?
This section also includes some discussion on how the SEEoC approach differs from the hardware and software qualification approaches discussed previously. Honestly, the difference between hardware qualification for a “complex” component versus a SEooC is a little fuzzy to me.
SOTIF and Other Topics
ISO 26262 is not the full story on automotive functional safety. What happens when all software and hardware works as designed, but the vehicle still has unsafe behavior? This question has been given the name Safety of the Intended Functionality (SOTIF), and has its own new standard in ISO 21448. This standard is still focused on Advanced Driver Assistance Systems (ADAS) rather than autonomous vehicles, but it is a step in the direction of more comprehensive standards.
We noted earlier that the 2nd edition of ISO 26262 is now out. Some overviews of the changes can be found:
- ISO 26262 – The Second Edition: what’s in it… and what isn’t
- Overview of the 2nd Edition of ISO 26262: Functional Safety – Road Vehicles
Another broad issue still being studied is how to confidently validate safety systems when the behavior of the system is itself non-deterministic (e.g. Bayesian learning).
Conclusion
Whew! We made it. Thanks for sticking with me. This ended up being a harder project than I expected, mostly due to the surprising differences in vocabulary and approach between the standards. We found a lot of common ground, but I had to find the secret decoder ring first!
Doing this sort of comparison really makes you consider what are the fundamental assumptions going into functional safety practices. ISO 26262 does some things differently because of real differences between industries. Other things are different just to be different, and I think some things are different because they are trying to be better than earlier standards. We can all learn from each other.
There is is still more standards work to be done, as autonomous vehicles debut new technologies and challenges not covered in the current standards. It’s an interesting time to be a functional safety engineer!
I hope you found this series informative and not too dry. Thanks for reading! Please follow us on LinkedIn!
