Part 2: Developing a Safety Element out of Context according to ISO 26262

In our previous blog 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”.

In this second part of the blog we will consider how the development process defined by ISO 26262 is adapted for SEooC development, and take a closer look at some of the key activities.

Not all of the activities described in ISO 26262 need to be performed by the SEooC developer – some activities may be deferred and instead performed by the item developer. ISO 26262:10 describes example development processes for a system, a hardware component and a software component developed as an SEooC. Here are some points to look out for when working on the activities that apply to your SEooC development:

• In order to derive technical safety requirements for the SEooC it will be necessary to make assumptions about the top-level system in which the SEooC will be integrated. It’s important to document these assumptions in as much detail as possible, stating sources and rational if available. Make sure these assumptions are fully traced down to the requirements driving the SEooC development. Some of these assumptions will drive functional requirements not relating to safety – these should also be documented. If some of the assumptions turn out not to be valid at the point of integration it will be important to understand the impact.
• Clearly define and document the boundary of the SEooC, and include a description of the interfaces and the functionality. Is the purpose of the SEooC clearly defined?
• Make sure that all documentation is ready to be understood by a customer. All work products, including all requirements and assumptions made, will be made available to the integrator at the end of the development process. Therefore it makes sense to keep these in a customer readable format throughout development if possible. If separate customer documentation is created then there should be full traceability to all assumptions and requirements derived during the development process. Again, it’s usually easier to do this from the outset than to try to add it on later.
• When carrying out safety analysis and analysis of dependent failures it is important to take all assumed requirements into account. If the analysis uses a safety measure based on an assumed requirement, the traceability to the original assumption needs to be explicit to allow the integrator to assess the impact of an invalid assumption.

In our next post we will be looking at the integration of an SEooC into the item (or new context), and will have some tips for maintaining successful communication with the integrator.

By Alison Young, Functional Safety Consultant