Is ISO 26262 SEooC now in context?

Google analytics is a wonderful thing. Since we published our series of blogs on ISO 26262 Safety Element out of Context (SEooC) at the end of 2017, this series has been a clear leader in our rankings, hence this has brought us to a fourth blog on SEooC and since the release of the second edition of ISO 26262 at the beginning of this year, to the question – is there now clarity for those teams implementing products in accordance with the SEooC process?

ISO 26262 Edition 2

Edition 2 of ISO 26262 has added SEooC as a term in part 1 and part 11 has introduced a number of sections that describe SEooC activities in the terms of semiconductors, one the biggest areas of the application of SEooC. Part 10 which had a detailed procedural definition of SEooC has been reworked to clarify a number of SEooC aspects

Where arguably SEooC requires further clarification is the role it plays in part 4 of ISO 26262 and how the roadmap of work products applies to SEooC. Part 4 defines activities on the integration relevant for SEooC, but still does not relate the Technical Safety Requirements Specification to SEooC activities. Part 3 of the standard also makes no references to assumed requirements when considering the Functional Safety Requirements Specification.

The SEooC Process

The activities of defining assumed requirements given in ISO 26262-10:2018 taking teams through a ‘mock’ hazard analysis and risk assessment and functional safety requirements definition, is an activity relatively easily defined in words, but something that in practice is far more difficult to achieve. Much will depend on the team defining the assumptions, their knowledge of the market, the potential applications and use cases. For some devices the potential list of applications can be very large and hence generate many use cases which can impact the assumed requirements significantly. For larger organisations with applications teams and product specialists this activity can be mastered with out too much gnashing of teeth and heated discussions, but for smaller organisations and particularly those new to the sector this can be a daunting task. The documentation of assumed requirements is now well handled in part 11 with several discussions around the role of the ‘safety manual’ or ‘safety application note’. However, neither the safety manual nor the safety application note are referenced in part 1 of ISO 26262 but there is a link in part 10 to these two documents. Arguably either of these two documents should be defined as a work product ideally in part 4 of the standard.

Where next?

In summary the second addition of ISO 26262 has gone some way down the road to address the lack of clarity in SEooC, but there is still a bit to go, particularly before new teams in the industry can easily master the activity. In our next blog (Integration of ISO 26262 and IATF 16949: Like Pieces of a Puzzle) we will be focussing on the relationship between functional safety and quality management as we look at the relationship between ISO 26262 and the quality management system requirements in IATF 16949:2016.

Alastair Walker – Functional Safety Consultant