It’s been a long time coming, but the eagerly awaited second edition of ISO 26262 will soon be released. One of the topics that has led to much discussion over the years, since the first edition was released, is the usage of the tables defining methods and techniques in the standard.

One of the big improvements in the second edition is the removal of the table entry (Table 4 ISO 26262-6:2011) highly recommending diverse software design for ASIL D only.

The inclusion of a superior definition of safety-oriented analysis approach encourages more of an analysis-based approach for both the software architectural level and corresponding safety mechanisms. Annex E of ISO 26262-6:2018 provides a good rationale for how this safety-oriented analysis should be applied.

Ultimately the need for diversity or other means of implementing safety mechanisms should be defined on a project by project basis, rather than defining a need based on the ASIL level.

Annex E also helps to promote the interaction with the Safety Plan which was not as well represented in the first edition. Safety Element out of Context (SEooC) has been a topic that perhaps lacked as much guidance as was really needed, but again Annex E focuses the reader’s attention on the relationships within a distributed development.

The use of tables in ISO 26262 has led to many heated discussions and often not always the most pragmatic solutions. We have all seen ISO 26262 projects where the solution is driven by the contents of the tables rather than the needs of the given item or element. Many other industries do not use tables to define safety mechanisms e.g. ISO 14971 in the medical device sector. However, this sometimes leads to a lack of clarity and guidance on the mechanisms required for the implementation.

Ultimately, a pragmatic solution to implement functional safety is required.

By Alastair Walker, Functional Safety Consultant