Avoiding re-inventing the wheel is a key part of efficient product development. In embedded programming, this concept started with trusted libraries and has been enhanced with concepts such as object-oriented programming and Java, which enable us to create today’s complex systems.

Safety standards also promote the reuse of proven software elements, though this introduces complex challenges. Introducing elements to a project that do not have the same level of rigor applied to their development will inevitably lead to weaknesses. As a result, safety standards have specified ways to validate these components for use in a safety project.

But the drive for efficiency can lead to concepts that don’t work in safety-critical systems. Custom-off-the-shelf (COTS) software is a term used in many industries in many ways, and though it has a very specific meaning in industrial safety, it can become an excuse to take short cuts, which is not acceptable in safety projects. A system is only as strong as its weakest point. Software of unknown pedigree/provenance (SOUP) is used in the medical standard IEC 62304, but there are good reasons for not having something “unknown” in a safety project. You can test it to death, but in the end, how do you maintain something for years to come when its origins are unknown?

Defining a Safety Element out of Context

In the automotive world, the Safety Element out of Context (SEooC) defined in ISO 26262-10 is the method for using components in a vehicle that were not originally designed for that specific project.

The term SEooC is a little unwieldy but it clearly defines the problem. All software libraries you integrate into a system are effectively developed “out of context”: they are designed to provide a specific functionality with no awareness of how it will be used in the target system. The “element” indicates that this is a unit or module with a specific range of functionality; and “safety” indicates that this module is specifically developed in the context of a set of safety requirements.

There are two basic types of software SEooCs (derived from ISO 26262-10-9):

1. Proven-in-Use Approach. This type of software uses the proven-in-use argument (and additional measures) to validate a COTS component to a specified safety level. ISO 26262-8-14 specifies how this should be achieved, but there is a lot open for debate in the software context. The concept of observable errors is key – having records of the use of a product so that all errors can be reliably recorded and aggregated to give an accurate picture of the software’s reliability. This needs to be factored into the specific configuration. How relevant these results are to the target project is complex, as a safety project almost certainly has a different configuration and working environment in field test cases used to establish the reliability of software. And can you trust a piece of software not developed to safety standards to reliably report all errors?

2. ISO 26262-6 Approach. The standard way to develop a software element in automotive safety systems is defined in section 6 of the ISO 26262 standard for developing functional safety in road vehicles. It is derived from the complete V-model development of the target system defined in the preceding sections of the standard, and is, in itself, a V-model. Because the element is developed out of context (i.e., not derived from the safety plan for the target project), additional measures must be applied. The primary additional measure is the creation of a set of assumptions that the SEooC was designed to work within. These assumptions must be validated on the target platform during integration.

Full Software Lifecycle Maintenance

This is a critical part of any safety project development: the ability to respond to issues raised during the development or after release. Once a project is mature there needs to be a methodology to reliably modify the project when issues are raised. A key strength of the ISO 26262-6 approach is that a full and accurate impact analysis can be made and the resulting changes implemented correctly because all of the standard artefacts have been created with traceability between design, implementation, and test.

The further you get from the project release, both in terms of time and personnel, the more essential it is to have the artefacts and their related processes available in order to safely make changes. This method ensure future maintainability.

Reuse Across Industries

It makes practical sense to use many embedded components across multiple industries. For example, a file system to store data or a network stack to communicate data are not industry specific, and ideally the benefits gained from one project should be leveraged in new projects regardless of the industry to which they are being applied. From a software perspective, the safety requirements for developing software across different industries are broadly similar, but with varying degrees of rigor depending on the safety level required. Taking a SEooC approach developed according to ISO 26262-6 provides a sound basis for mapping artefacts across standards (e.g., to IEC 61508 for industrial functional safety or IEC 62304 for medical devices). 

Defining an ASIL Level for SEooCs

In all safety standards, levels of safety are specified. The more critical the effect of a failure in the target system, the more stringent the defined measures for implementing and validating the software.

Choosing an Automotive Safety Integrity Level (ASIL) for a SEooC can be problematic. The easy answer is to always develop to the highest ASIL level (ASIL D) so that integration with any project is possible without major rework and mapping across industries standards is also easier. The downside is that it makes those SEooCs far more expensive than those developed to a lower ASIL.

How to Source SEooCs

SEooCs can supply embedded components as a core part of safety systems and reduce costs. However, designing embedded components for reuse in a safety context is inevitably complex, so sourcing these components must be done thoughtfully. To get the best result they need to be developed in an environment that can handle the needs of safety product lifecycles.

The best practice is to develop a full ISO 26262 section 6 safety element with the assumptions and test cases prepared for reuse. This needs to be backed up by a project management system that allows each customer use of a SEooC maintained in a semi-independent project so that the full software maintenance lifecycle can be applied to that project independently.

For more information, visit www.hcc-embedded.com.