Automotive functional safety

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

In this blog, we present a simple yet comprehensive approach of how to write a high-quality Technical Safety Requirement (TSR) document, which considers all the Safety relevant aspects of the System and sets the right direction for the Software and Hardware teams. To begin with, it is important to understand what is the difference between an FSR and TSR. FSR (Functional Safety Requirements) describe the WHAT , i.e., WHAT must be done to achieve Safety Goals. TSR describes the HOW . i.e., How the Safety requirements should be achieved. It describes the technical realization of the Functional Safety Requirements of the project. TSR is the starting point for SW and HW Safety. For a specific item, there are 8 topics that TSR should cover. The topics are: 1. Intended Functionality 2. Fault Handling 3. Graceful degradation and Safe State 4. Freedom from Interference and Independence 5. HW Metrics 6. Special cases 7. Production and Service 8. Fault Injection Testing 1. Intended Functionalit

As part of this blog post, we will cover the 2 facets of ISO 26262 and how these 2 facets go hand-in-hand in making a system safe. We consider these 2 facets to be like the sides of a coin. When a system is considered safe, it means that both these aspects are present in it. Let us deep dive a bit to understand what those are by using a very simple example. The first aspect of the ISO 26262 standard is the addressing of failure modes. As the ASIL increases, more and more failure modes need to be addressed as part of our system. The standard calls this the increasing diagnostic coverage. Let us take the example of the communication function and try to understand what we mean by this.  Given below is the list of failure modes that are possible for a communication function. Message delayed Message corruption Message-out-of-order Transmitter not available Masquerading To start with, you might want to have a technical solution in which we have a software component that detects the missing o

The ISO Standard specifies several methods on how to do Safety Software Architecture. These principles are generically stated. But most often these are not clear: - Why are these principles defined? - How do we ensure which principles we have achieved?  - Have we achieved the principle sufficiently?  For e.g., for a principle that states "restricted size of interfaces', why do I need this rule and how restricted should the size be? In this article, we first explain why these principles are needed in the context of Safety, and then propose a set of questions for each principle. These questions aim to act as a checklist to determine if the principle has been sufficiently satisfied. Assuming that most Organizations have well-defined guidelines for software architecture and the lessons learnt and best practices based on the experience from previous projects, these questions are intended to guide the architect or the reviewer of the architecture to think if all possible aspects hav