How does ISO 26262 address open source software?
This article offers an in-depth look at topics related to Functional Safety.
For expert-level training—including certification-based programs—on these topics and more, explore our Automotive trainings. To learn how we support product development, compliance, and organizational safety goals with consulting support, visit our Functional Safety & Cybersecurity page—or contact us directly.
We previously wrote about updates on the Third Edition of the ISO 26262 Standard. One of the updates included the additional topic of using pre-existing software architectural elements (PSAE), as addressed by the ISO/PAS 8926:2024 specification which was recently released in January of 2024. Although we don’t expect the release of the Third Edition of the ISO 26262 standard until sometime in 2027, we can gain some insights to how the standard will handle open source software by looking into the Publicly Available Specification (PAS) ISO/PAS 8926:2024.
In the past 9 or 10 years, with the increased interest in automated drive, we’ve been asked frequently about how open source operating systems, such as Linux, can be used in automotive functional safety. In the Second Edition of the ISO 26262:2018 standard we were left mostly with guidance in Part 8, Clause 12 Qualification of software components. However, the Second Edition doesn’t specifically address pre-existing software such as open source software, whereas ISO/PAS 8926:2024 now tries to take it on. The ISO/PAS 8926:2024 specification specifically states that open source operating systems are within the scope of the specification, in addition to legacy code, other libraries not developed according to ISO 26262 and software elements developed under other safety-related domains, such as aviation.
The main new concept introduced in this PAS is the creation of classes for PSAEs. By evaluating the uncertainty of two domains, provenance-related and complexity-related, the Class for the software element can be determined. Then based on that Class, the development rigor is determined.
The provenance-related uncertainty looks at the likelihood of systematic faults impacting the software architecture and is expressed in three ratings:
- P1: evidence exists that the software development process followed a national or international standard (ISO/IEC/IEEE 12207, IEC 61508, RTCA DO-178C, etc.);
- P2: P1 can’t be fully claimed, however it is believed that the gaps are sufficiently small between the actual software development process and those of standards;
- P3: everything else.
- C1: complexity measures indicate that the software element is not of high complexity;
- C2: complexity measures indicate high complexity, however it is evaluated as acceptable as the systematic faults are seen as sufficiently low;
- C3: everything else.
Only when a rating of P3 and C3 exists, does the specification state that it is not recommended to use the software element for functional safety. All other ratings are allowed for functional safety. For C1 combined with P1 or P2, and in some cases C2 with P1, then the classification becomes Class I. Class I simply follows the software qualification guidance in Part 8, Clause 12. Everything else remaining then falls into the classification of Class II. Class II is an expansion of Part 8, Clause 12, by adding more rigor. The additional rigor includes: assigning and refining existing software safety requirements; evaluating the operational context including software safety analyses; and increasing the verification activities.
Like the Hazard Analysis and Risk Assessment (HARA), it will take some time in practice to see how companies apply the provenance-related and complexity-related uncertainty ratings. SRES provides a software specific training on the ISO 26262:2018 standard where we discuss the content of ISO/PAS 8926:2024. We look forward to discussions with clients as this specification evolves and is built into the actual Third Edition of the ISO 26262 standard.
