Automotive functional safety

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

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 opportunity to correct weaknesses at an early stage of the software development. Stati

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

Designing Software for Safety is an extremely complicated task, and the ISO 26262 Standard specifies several processes, methods and work products for the same. For a Software Architect who is new to Safety, this information is overwhelming.  Image courtesy: Shutterstock Here we present an overview on what are the responsibilities of a "Safety" Software Architect and how they are different from that of a typical embedded software architect. The Safety Software Architect also has some additional tasks: Decomposes the SW Safety Requirements with respect to ASIL tailoring Performs the Software Safety Analysis and Dependent Failure Analysis Support the Software Tool qualification process for tools used for SW development Support the qualification of Software components if necessary Every responsibility stated above is a complex task in itself and has several dependencies that must be taken care of. In our upcoming posts, we will cover some of these in greater detail. Meanwhile, he

"Lets get the Implementation done, and go out to an agency like XYZ, find out about the paper work and get our work certified" This is a language we have heard being spoken several times. MYTH 1: Functional Safety is just "paper work"! Fact: Functional Safety is the discipline of designing Safety into every stage of the product life cycle starting right at the concept phase For some one who has just started with functional safety, and refers the standard, this can be overwhelming: The 2nd edition of ISO26262 has 12 Parts 37 Clauses > 100 Work products! Here is a mindmap of the different work products needed (those starting with x.5.x) Why do we need so many work products? This is because Functional Safety is designed into - every phase of the product life cycle - processes as well as technical methods - every stage of every phase In other words, the Standard spans the entire breadth and width of how a safety-relevant product is built, right from concept till