A person holds a domino piece as it begins to topple over, illustrating the chain reaction of falling dominoes.

Freedom from Interference: Control of Mixed ASIL Criticalities

Interference, within the context of Functional Safety, refers to a situation in which a failure in a component of a system may propagate to other components, resulting in a violation of safety requirements. This is especially important for systems with different ASIL (Automotive Safety Integrity Level) assigned to their components (called Mixed Criticalities).  

Addressing mixed criticalities in IC development is challenging to implement within a single chip at the hardware level. For this reason, most IC developments are designed with a single Safety Integrity Level (ASIL level) applied across the product and all functions and sub-components. Freedom from interference is less important in this scenario since any fault in the ASIL-rated elements will be detected and trigger a transition to a safe state.

There are specific product categories, such as video data transmission, which serve multiple input channels. Some of those channels do not require ASIL integrity (called Quality Managed or “QM”). For such applications, a thorough analysis of freedom from interference is crucial to prevent cascading failures of the QM channel, which can impact the ASIL-rated channels.
   

Let’s consider two use cases of multichannel operation.

1. Identical ASIL Integrity

In a typical data de-serializer, processing and transferring video data from multiple channels (refer to Figure 1), all channels are assigned to the same ASIL level (e.g., ASIL B). Assume that the application collects video data from two front-view cameras and forwards it to a System on Chip (SoC) to make critical decisions about breaking or steering. Both channels are developed according to ASIL B integrity. In the event of a single-point failure, it is detected, and an error signal is sent to the SoC, which begins the transition to a safe state. As such, there is zero possibility that a QM element without safety integrity will interfere with an ASIL-rated channel, since all sub-parts of the IC are designed to the highest applicable ASIL.

 

  Identical ASIL criticality in multi-channel applications

 Figure 1: Identical ASIL criticality in multi-channel applications


2. Mixed Criticalities

In a second case (Figure 2), let us assume that only one of the two channels is assigned to a QM function at the system level. In this scenario, one channel can be associated with a forward-looking camera (as shown in Figure 1), which is developed according to an ASIL integrity level. The second channel only processes data from a rear-view camera (for parking applications. This is not associated with an ASIL target. The entire transmission chain from the rearview camera to the SoC is regarded as a standard automotive function and rated as QM. For this reason, it would not require dedicated diagnostics to detect failures in mission mode.

 

 Mixed ASIL Criticality in multi-channel operation

Figure 2: Mixed ASIL Criticality in multi-channel operation

 

Methods to Prevent Interference


The concern with the second use case (Figure 2: Mixed Criticalities) is that a failure in the QM channel could also impact ASIL channel elements, leading to cascading failures.  To address this, ISO26262 requires a detailed Dependent Failure Analysis (DFA) to evaluate freedom from interference.

A DFA examines all design sub-parts to determine whether elements in a QM channel could cause failures in connected ASIL channel sub-parts. Although resource-intensive, this analysis is essential to provide the evidence required by ISO 26262. Mitigation options include preventing cascading failures or, at the very least, providing a way of detecting them early. However, prevention is always preferred.

Typical methods to address cascading failures can be summarized as follows:

  1. Prevention of cascading failures by design methods.

    This is the most effective but also the costliest approach. It requires complete physical separation of channels within the IC layout, along with individually assigned shared resources (e.g., clocks, power supplies, memories). This option is typically feasible only for new developments with explicit requirements for freedom from interference.


  2. Controlling the effects of cascading failures by dedicated detection mechanisms of the IC.

If failures in QM channels can be detected, the associated diagnostics can deactivate the affected channel. This is only possible if the IC is designed for ASIL integrity, and one channel is treated as QM at the system level. In this case, built-in ASIL safety mechanisms can supervise the QM channel. However, if the IC design includes QM-rated subcomponents for that channel, this approach is not viable because the required diagnostic coverage (DC) would be missing.

  1. Controlling the effects of cascading failure using system-level safety mechanisms.

System-Level Safety Mechanisms—such as end-to-end protection of the Video or Control Data submission—can detect faults in an ASIL channel induced by a cascading failure along the entire transmission path from camera to SoC and initiate a transfer to a safe state.

DFA analysis Supporting Freedom from Interference

DFA analysis is an efficient and powerful tool for supporting the identification of cascading failures in early development phases. It can also guide the design of system-level solutions using existing components to mitigate the potential effects of failures in channels with lower ASIL integrity than the target ASIL of the IC. Given the growing complexity of automotive systems, the demand for solutions that support mixed criticalities will only increase in the future.

Read more from the Automotive FuSa blog series.

  • Very good topic to think about.

    While your article focused on random hardware faults and the use of fault control mechanisms for mitigation, it would be interesting (maybe for a follow-on article) to also go into more detail about the potential for cascading effects of systematic faults from the lower QM or ASIL domain.  Could this be addressed with just improved systematic capabilities (i.e. fault avoidance alone) of the lower (versus safety mechanisms i.e., fault control) even if not called for by the lower alone.  It might be useful for a future article to focus on differences between addressing random hardware faults (fault control only) versus systematic faults (fault avoidance + fault control).

    Another related topic that might be interesting for a future article could be how decisions are made about the need for independence between functions.  For example, take a hypothetical battery monitor that can monitor cell voltages with up to ASIL C capability and can monitor environmental sensors via its GPIO with up to ASIL C capability.  How much independence is required between those two functions for any given customer?  Could they be used to fulfill an item-level safety concept where a decomposition argument was used to protect against the same hazard with ASIL C(D) cell voltage measurements coupled with ASIL C(D) temperature sensor measurements.  If they share some common elements (e.g. multiplexer, SPI encoder, power regulator) is it sufficient that those common elements be just ASIL C capable or would they need to be able to achieve ASIL D on their own or be split into separate ASIL C(D) capable elements for the two channels?