Automotive functional safety

This is a frequently asked question in the world of Automotive Safety, especially for programs up to ASIL B. There are contradicting answers to this question even amongst Safety Industry experts and every answer is based on its own rationale. In this blog, we have provided a background on what is core self-test and why is it needed from a functional safety standpoint. Background Typically, when we develop an item that is required to be ASIL compliant, it is state-of-the-art to choose a Microcontroller that is designed for ISO 26262 compliance. Microcontrollers that are ASIL certified are developed as per the HW development processes specified by ISO26262. They also incorporate safety mechanisms to detect, correct or prevent (if possible) systematic and random faults. These safety mechanisms provide sufficient diagnostic coverage against faults and enable the Microcontroller to achieve a FIT rate that is sufficiently low, so that the Item that is integrating it can meet its required FIT

The ISO26262 provides a bookish definition for Systematic faults and failures. In this post, we have explained our understanding of what these mean. To do so, we have described the following aspects: An easy way to understand systematic faults & systematic failures Possible scenarios in which systematic faults could occur Challenges with complete elimination of systematic failures Probability of systematic failures An easy way to understand systematic faults & systematic failures In simple terms we would like to call Systematic faults as "Method or Process faults”. It is any fault in the way of applying methods or processes whose consequent failure shows up in a deterministic way. This consequent failure is what is called a Systematic failure. What do we mean by "deterministic"? It means that if the same fault is injected into the system 'n' no of times under specific conditions, the same failure will occur every time. The failure is not really tied to th

ASIL Decomposition – What is it anyway! Let us start with the ISO 26262 definition for ASIL Decomposition: “ Apportioning of redundant safety requirements to elements, with sufficient independence, conducing to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements .” If you feel completely lost or confused as though you read a statement in a language that you have never heard of, then you are not alone! ASIL decomposition is considered as one of the advanced topics in the safety domain and many feel intimidated to venture into this topic. The idea behind this blog is to demystify the decomposition concept and to present you with some pointers on how to use decomposition. If we have to breakdown the definition into ‘plain’ English, it would look something like this: ASIL decomposition is a method by which the requirements could be broken down into redundant requirements that are then allo

Fault Injection Testing is an age-old testing technique to understand how a system behaves when it is stressed in unusual ways. Nearly half a century back, it all started with simulating failures in hardware. However later, Industries also started thinking about fault injection testing in software, though not exactly called that way. It was performed as part of "Robustness testing" and "stress testing". Even the DO-178B SW Safety Standard for Aviation does not have the term "fault injection testing". ISO26262 has made an attempt to explicitly define what this type of testing means and has provided guidelines on when and how to perform it. In this article, we have explained what the goal of fault injection testing is and what is the expectation of the ISO26262 Standard on this topic. Further, we have defined  (in our own words) a "Systematic approach" to do Fault Injection tests in Software, so as to maximize its effectiveness. Before we go into f

Anyone who has done a complete end-to-end safety development will definitely be familiar with tools qualification. Even if you have not done the complete safety life cycle and have just worked on a particular skills area (Skills = Systems or hardware or software), you would have supported the functional safety manager in the qualification of the software tools that are used by the systems, hardware or software team. As part of this blog, let us explore why we need tool qualification and as well define a systematic yet simple approach to performing tool qualification. Before we deep dive into the approach that needs to be followed for doing the qualification, let us understand the reason for doing such an activity. 1.1        Why do we need to qualify the tools? Given the complexity of the ECUs that we are presently working on, the development of an item will not be possible without the use of a variety of software tools. The software could be something that is used by the systems team