Part 3: Developing a Safety Element Out of Context according to ISO 26262

In the previous two editions of our blog (Part 1 and Part 2) we looked at some of the first activities that are likely to be encountered when developing a Safety Element out of Context (SEooC) as defined by ISO/DIS 26262-10.2:2017, “Guideline on ISO 26262”. We then moved on to consider how the development process defined by ISO 26262 is adapted for SEooC development.

In this edition we’ll take a look at the integration of an SEooC into an item or new context, focussing on how to maintain successful communication between an integrator and supplier.

If the development timelines of an SEooC and the system in which it will be integrated overlap it is useful if information regarding the SEooC can be made available as early as possible. The assumptions made during the development of an SEooC, especially any safety mechanisms assumed to be performed by system level hardware or application software, will have major implications for the integrator’s system development. If this information is shared early in the project there can be time allocated to develop the required mechanisms. It should be stressed, however, that these preliminary assumptions may change as the project progresses.

Assumptions on system level safety mechanisms documented before safety analysis is complete may change if the analysis highlights any weaknesses in the safety concept. Additional safety mechanisms added at this stage may place an extra burden on the customer in terms of application software management of safety mechanisms, a performance impact, or even additional safety mechanisms required in system level hardware or application software. When describing the impact that additional mechanisms may have on an integrator it is useful to share the results of analysis, showing why these measures are necessary. Try to give as much rationale as possible, especially where estimates have been made on the diagnostic coverage of a safety mechanism. Exactly what will an integrator need to do to achieve the diagnostic coverage level stated?

Full traceability of requirements and assumed requirements is essential, and will help illustrate to customers where the documented assumptions influence the safety analysis. It will be the integrator’s responsibility to verify that assumed requirements have been implemented correctly. Strong traceability of these assumptions from the initial requirements, to safety analysis and customer documentation will help integrators to fully trace these requirements into verification and validation results.

It is important to remember that an SEooC will form only part of the integrator’s system. Each of the work products delivered by an SEooC developer will form part of a larger suite of work products, forming a higher-level safety argument. It’s helpful to consider how work products produced by an SEooC developer can be re-used or adapted by the integrator. Consider how the results of analysis can be presented to allow their inclusion in the system level analysis. If the same tools are being used can information be shared in native format, while protecting confidential information?

A good level of communication between an SEooC developer and integrator is vital for a successful integration. Communication in both directions should not only help the integrator understand the rationale behind decisions made during the SEooC development, but will also give the SEooC developer a greater understanding of their customer’s needs, which may guide future SEooC developments.

By Alison Young, Functional Safety Consultant

To get the latest insights read our newest blog entry Is ISO 26262 SEooC now in context?