Skip to main content

SEooC for Dummies


Typically, Safety development happens in a top-down approach. We start with identifying hazards and associated Safety goals for an item for a specific vehicle. Then we identify the Safety path in the system for that Safety goal, identify the Safety related HW, SW and System elements, and finally develop these elements in compliance to ASIL.

Safety Element Out Of Context (SEooC) development is different from regular Safety development in the sense that it is a bottom-up approach. We first decide what is the HW, SW or System element that must be developed as ASIL and then formulate assumptions on the ASIL level, the Safety goals, the item or System, and the context/environment in which the Safety element will be used. In short, we decide on the scope or boundary for the element.

SEooC approach is used for developing SW, HW or System elements where the developer is sure that this element will be used as a Safety element in not just the context of 1 Safety program, but the Safety element finds use in several Safety goals or Safety requirements, and probably cuts across items and vehicles (i.e., ECUs and OEMs). In such cases, it is much more efficient in terms of development costs and effort to integrate the same element (SEooC) in several programs instead of developing separate Safety elements for every program.

In this blog, we have covered the following topics.

  1. What is an SEooC?
  2. Examples of SEooC
  3. What is similar and different between “in Context” and “Out of Context” development?

What is an SEooC?

SEooC means Safety Element out of context. Let us break this apart as Safety Element + Out of Context.

If you are not familiar with what a Safety Element is, please check out our earlier post.

What does Out of Context mean?

“Out of context” means to develop an element as ASIL without the context of the actual Safety goals or System. i.e., without knowing what the Safety goals are or how the System will be.

Let us take a SW CRC library. Its main responsibility is to provide Interfaces to calculate CRC based on different CRC algorithms. CRC is a Safety mechanism that is used for ensuring Integrity of Memories and communication. A SW library can be used for calculating CRC for an E2E (End to end protected) communication or for Memory. From the perspective of the developer of the CRC library, it does not matter whether the CRC is used in an Instrument cluster ECU or Headlights ECU or Rear view Camera ECU. It does not matter whether it is used for Memory or Communication - its functionality remains the same. In other words, it does not add any value for a SW CRC Library developer to know the exact Safety goals – the only pre-requisite is to be sure that CRC is used as a Safety mechanism in the System, and to know which algorithm has to be used.

Another such example is the Operating system. Its main responsibility with respect to Safety is to provide guaranteed scheduling of the Safety related tasks and spatial partitioning and protection of Higher ASIL processes from lower ASIL or QM processes in terms of memory, hardware and resources. Its responsibility does not change in relation to the ECU in which it is used or the exact Safety goals of the System.

Let us take one final case of a Microcontroller. Microcontrollers are typically designed to support specific Applications. For example, Renasas’s RCAR Generation 3 is mainly designed for Instrument cluster, Infotainment and telematics Applications. Infineon’s Aurix TC3xx is designed for a host of Safety applications such as braking, Airbag, power steering to fail operational sensor based systems for Autonomous driving.  These micros are used by several OEMs for their ECUs, so these Micros cannot be designed for specific safety goals. Hence, they are designed by making assumptions on the Safety goals or Safety features for the application it supports.

If you take an Instrument Cluster, the Safety goals are most commonly on a physical LED, a Soft telltale or Warning shown in the TFT, a CAN output, a chime, or a digital or analog Input processing and indication, such as Vehicle speed. There has been a wealth of experience from implementation of Safety in various instrument clusters by various OEMs to safely conclude that the Safety goals can only be on these functionalities. Hence, Micro suppliers are able to make assumptions on the Safety goals for the Applications they want to support, and provide features in the Micro to support the “assumed” Safety goals. This means that for example if the Micro supports a TFT telltale Safety goal, it would provide a peripheral to verify the integrity of the pixel data rendered in the display.

Examples of SEooC

We already discussed some examples above. Here is a consolidation:

  • ASIL compliant HW Components, such as Microcontrollers, PMICs
  • ASIL compliant SW such as Operating Systems, Libraries, Low level drivers, Middleware stack or a standalone SW unit
  • ASIL compliant Systems (for e.g., an electric parking system, a combination of systems or even an ECU)

What is similar and different between “in Context” and “Out of Context” development?

Here is a table that compares SEooC with a Safety element developed in context.

The key differentiating factor for an SEooC is the "Assumptions of use". Since it does not have the knowledge of the context in which it is integrated, several assumptions are made regarding the Safety goals, the operating environment, the functionality etc and this provide a set of “external” requirements for the integrating item/system regarding how the SEooC must be used. For example, an OS supplier may provide an ASIL certified OS that offers memory and timing protection features, but for these features to work correctly, he might make several assumptions regarding the contexts in which the OS APIs are allowed (or not allowed) to be called, and how the safety features must be configured.  The item has to validate these assumptions by calling the OS APIs only in the allowed contexts and configuring the features correctly. If this is not done correctly, the ASIL OS may get “downgraded” to non-ASIL. 


SEooC development undoubtedly offers benefits in terms of saving costs and engineering effort, however one needs to be very cautious during the concept phase. For instance, during the bottom-up approach for a HW or SW element out-of-context, the technical safety concept plays a very vital role in ensuring that all the high level assumptions regarding the item and the context/environment of the SEooC are discussed and analyzed thoroughly and captured. If this is not done well, the SEooC supplier might eventually find himself in a situation that the element is not useable for the Safety features that it was targeted for, and this might lead to a need to change the SEooC and go through the development activities all over again.

SEooC’s provide a “Safety manual” where the assumptions of use are described. In our next blog, we will go deeper into Safety manuals and best practices on how to work with them.