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.
- What is an SEooC?
- Examples of SEooC
- 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?
Conclusion
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.