Automotive functional safety

To all those Functional Safety Engineers, who are immersed too deep inside the ISO26262, buckle your seat belts! Let us take a tour outside the 26262!! The ISO26262 primarily focuses on “System” Safety. However, the overall Safety in the context of car is far beyond just system safety. It is about measures and features that are designed to minimize the risk of accidents, protect vehicle occupants, and reduce the severity of injuries in the event of a hazardous situation. It covers various aspects of vehicle design, technology, driver assistance systems and even environmental aspects that are aimed at both preventing accidents as well as to minimize injuries and harm in the event of an accident.  Automakers and regulatory bodies have taken continuous efforts to improve Safety standards, implement newer technologies and develop safer designs, and hence several standards have also been introduced. We can broadly group these standards into the following buckets: System Safety (which includ

 

 

 

 

  Typically, Safety development happens in a top-down approach. We start with identifying hazards and associated Safety goals for an item for a specific vehicle. Then we identify the Safety path in the system for that Safety goal, identify the Safety related HW, SW and System elements, and finally develop these elements in compliance to ASIL. Safety Element Out Of Context (SEooC) development is different from regular Safety development in the sense that it is a bottom-up approach. We first decide what is the HW, SW or System element that must be developed as ASIL and then formulate assumptions on the ASIL level, the Safety goals, the item or System, and the context/environment in which the Safety element will be used. In short, we decide on the scope or boundary for the element. SEooC approach is used for developing SW, HW or System elements where the developer is sure that this element will be used as a Safety element in not just the context of 1 Safety program, but the Safety ele

Safety Element is a HW, SW or System Element that is Safety relevant. When we say “Safety relevant”, it means that it is in some way contributing to achieving or violating the Safety goal. Let’s assume a Safety goal for an Instrument Cluster system, “The Airbag telltale must be indicated on the TFT during Ignition ON when activated”.   A diagrammatic representation of this system is given below. There are two Controllers in the System, a Vehicle processor and a Graphics processor. The telltale is turned ON based on CAN signals received from the Airbag ECU. The Inputs for this Safety goal is the CAN input and Ignition, and the output is the bitmap indicated on the TFT display. The picture shows the path of the telltale in the System, from input until output. As it can be noticed, there are several HW and SW components that participate in this path. These are all in some way contributing towards indicating the Airbag telltale on the TFT. Or, if they weren’t functioning properly, it migh

Few days ago, we were participating in a meeting with a few colleagues and going through the Safety manual of a Software vendor who was providing us two ASIL Components, X and Y.  There were several requirements stated in this Safety manual that we had to satisfy. There was one such requirement that stated: “The Integrator shall ensure that the version number for the code of Component X and Component Y that is integrated in the System shall be compatible. These version numbers are hard coded in ROM – Required ASIL level: ASIL B”.  The Software colleague in our meeting immediately jumped in and said "Oh, this is easy, I can do a review in the Integrated SW and check that the version no of X and Y are compatible.” Later, he paused and said, “ Oh… but wait, this is an ASIL B requirement - so that means I cannot check just by a review, the SW needs to check during run time that the version numbers are compatible. If they are not compatible, it needs to trigger a safe state!" Anot

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

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

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

"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 11 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

Myth 1: No Safety was implemented before ISO 26262   Fact: Automotive Systems have always had Safety measures and mechanisms in place Cars have been around for a century and ISO26262 for not even a decade! Cars have always had several safety features such as brakes, airbag, seat belts, tire pressure monitoring etc. But its not that just these features were implemented and nothing additional was done for Safety before the standard was published. Way back in the 1960s, Federal Motor Vehicle Safety and Regulatory standards such as FMVSS were introduced. This standard and its equivalents specified rules to avoid crashes, and contain impact during a crash. Additionally, Independent organizations like IIHS in the US evaluated several aspects of safety such as crashworthiness and crash avoidance and gave ratings to promote safety considerations in cars. These led to specifying requirements for Safety for components, System and design features.  Automakers have always been interested in the to