Automotive functional safety ISO26262

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...

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 missi...

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...

Everyone in the industry is becoming more and more nervous that they will waste billions of dollars," ~ Klaus Froehlich, head of research and development at BMW. In case you are wondering what Klaus is talking about, he is talking about autonomous vehicle investments that various companies are making. Why is there a sudden change in the outlook of various OEMs and other players in the Autonomous Vehicle (AV) segment? Let us look at what has happened in AV development and how the positive attitude of OEMs and Tier 1s has nose-dived to the point that their top executives have started taking about fear of losing money in their investments.What has contributed to this sudden change? Some of the factors that are critical are: The technology is still not mature enough to be able to mass-produce AVs and we are still 5-10 years away to reach that state. The market segment for AVs is still not clear. Should the OEMs target the common person? Alternatively, should they target ride-hailing c...

Software Safety Analysis (SSA) is a kind-of-a verification activity that is performed on the Software to prove that it achieves all the Safety goals and provides the required Independence and freedom from interference.  Quite often we have seen that it is not clear for Software teams on how to do this analysis and which parts of the Software should they set their focus on. Also, in many cases, the activity is started towards the fag end of the project nearly when the safety software development has been completed, treating it more as a paper work to be completed.                             In this article, we present an 8-step method for performing a meaningful analysis. Before applying the method, here are some aspects to keep in mind: Basis and stage of the analysis SSA must be performed during the Architecture stage, based on the static and dynamic aspects of the Architecture. This provides the opportu...

In this blog post, let us discuss about one of the most common myths that is associated with functional safety. We often hear that ‘nothing’ needs to be done for ASIL-A and a Quality Managed (QM) development of the software is sufficient to achieve ASIL-A compliance. Unfortunately, nothing could be farther from the truth. Let us deep dive a bit to understand what QM means, what ASIL-A means and what difference exists between these two. Knowing the deeper meaning of these terms will help us to see where the boundary of QM stops & where ASIL development starts. As an additional bonus, we have also thrown in the difference between an ASIL-A & ASIL-B development so as to scale up the discussion around this topic.  As mentioned earlier, QM refers to ‘ Quality Managed ’. What this means is that the development process follows a standard and repeatable methodology for the development of the system. An example for such a methodology could be Capability Maturity Model (CMM) or ASPIC...