Safety Element is a HW, SW or System Element that is Safety relevant. When we say “Safety relevant”, it means that it is in some way contributing to achieving or violating the Safety goal.
Let’s assume a Safety goal for an Instrument Cluster system, “The Airbag telltale must be indicated on the TFT during Ignition ON when activated”. A diagrammatic representation of this system is given below. There are two Controllers in the System, a Vehicle processor and a Graphics processor. The telltale is turned ON based on CAN signals received from the Airbag ECU. The Inputs for this Safety goal is the CAN input and Ignition, and the output is the bitmap indicated on the TFT display. The picture shows the path of the telltale in the System, from input until output. As it can be noticed, there are several HW and SW components that participate in this path. These are all in some way contributing towards indicating the Airbag telltale on the TFT. Or, if they weren’t functioning properly, it might lead to not being able to indicate the telltale on the TFT. Hence, all these elements are Safety relevant.
- Examples of HW elements in the above example are the Microcontrollers, the Display, the CAN Transceiver chip, the HW Ignition input, the SPI lines between the controllers, the LVDS and Memory chips. Not to forget, those tiny HW parts that are in this path such as the resistors, transistors, capacitors and the power supply, clock etc are also examples of Safety relevant HW elements.
- Examples of SW elements in the above example are the CAN Stack, the DIO drivers, the Application component that processes the telltale condition, the Inter-controller communication stack, the HMI Application on the Graphics controller etc. Not to forget the Operating system and other middleware and low level driver SW components (such as the SPI driver for the Inter-controller communication) that enable the executing and interactions between the SW components that are directly in the Safety path.
- The Safety-relevant System Element here is the Instrument cluster itself, which has the Inputs, Outputs and processing logic.
We take a
top-down approach during typical Safety development, going from Safety goal to Safety path
and then to Safety Elements.
But now, wait. Why should we even
identify Safety relevant elements?
The Identification of Safety relevant HW, SW and System elements is required in the program because these are the elements that must be developed in compliance to ASIL in order to meet the Safety goals. Ideally, they must be developed in the same ASIL level as that of the Safety goal. It does not add value from a Safety perspective to develop an element as ASIL if it does not contribute to the achieving or violation of the Safety goal. It is too costly and high effort consumed for no tangible Safety benefits.
Do we really need to develop every Safety relevant element as ASIL?
We just told you that the HW, SW and System Elements in the Safety path must be developed as ASIL. This is actually not completely true. Not all the elements in the Safety path need to be developed as ASIL. For example, simple hardware components such as resistors, transistors or capacitors are not required to be developed as ASIL as per ISO26262. They are at best developed at Automotive grade quality according to AEC-Q100.
ASIL Decomposition is also a commonly used strategy to decompose the system such that some of the Safety relevant elements (SW, HW or System) can be developed at QM or lower ASIL level.