Freedom from interference

Freedom from interference is currently a buzzword in automotive industry and also a ISO26262 peculiarity, since is not part of IEC61508 vocabulary. Why is it so? Simply because of software complexity deployed in automotive and due to increasingly higher need to deal with failures that could emerge out of it (software).

Let's start with the basics. As per its definition (part one - 1.49) it is used to prevent cascading failures. What are they? Failures occuring in one element (be it SW or HW component) and affecting or propagating to another one. Careful! They are not dual-point failures! Dual point is when both elements are faulty and they become active (can lead to violation of safety goal) only when the two elements interact (for instance when a OS task is "mistakely" reading a value from a "corrupted" RAM location).

ISO26262 has a different approach than IEC61508 in that it does not consider elements, or safety (instrumented) systems, hosting different mixed SIL functions. Actually for IEC61508 "mixed-SIL" systems is simply a matter of hardware (even the guidelines for different SIL sub-systems implementing a single safety function, are given in part 2, Hardware implementation). Therefore it talks about dependent failures only in the context of safety and non-safety-related failures (also in part two) and demands that software requirements for the highest SIL level shall apply, in case of mixed-SIL system. It leaves indeed a backdoor open, by mentioning that, when not possible to separate them in HW, then "sufficient independence" has to be shown (see below)

ISO26262 expands exactly on this "backdoor", by slightly changing the existing failure classification and suggesting some informative (in an Annex) guidelines on how to show qualitative evidence of independence. It brings in the notion of cascading failures, as being complementary failure types to common cause failures, both of them being sub-categories of dependent failures. In contrast to ISO26262, which treats common cause failure as any event or root cause which can make two separate elements fail, IEC61508 regards common cause failures at system level, mainly as system failures making a redundant or multi-channel architecture to fail. Dependent failures are, in case of IEC61508, a type of "animal" similar to ISO26262 cascading failures. In order to make things visually better to perceive and maybe more descriptive, I made the table below

To further simplify them I made this other one:

I wrote this with the hope to clear out some of the confusions that the terminology can create, since I support the view that once you don't know exactly the terms are you talking about, is difficult to construct a safety argument. A step further, beyond that, would be to see some real-world examples on how to tackle those failure types. For those which can be quantitatively estimated, the IEC61508 provides pretty thorough guidelines on how to analyse them, but what about the qualitatively estimated ones? Can you perform tests to check freedom from interference? Can you prove "sufficient" independence via analysis? Then when would you know that you gathered "sufficient" proof? Based on the guidelines in ISO26262-6 (Annex D) AUTOSAR safety measures are a good way to go. It provides a detailed fault model for each of the cascading failures identified by ISO26262 (timing & execution, memory, exchange of information), as well as a software analysis method.