Automotive functional safety

We recently conducted a training on Functional Safety Software. We started to discuss Software Safety requirements (SSRs), stating something like “SSRs are derived from the Technical Safety requirements (TSRs). Start by looking into those requirements in TSR that are assigned to SW”. Immediately, one of the trainees asked “oh, all we need to do is to filter out the TSRs for SW, and put them into a new document, name this document as SSR and that’s it we are done?” No marks for guessing that we shouted a loud and clear “NOOOO!!!” This is the subject of this blog. Once you have the TSR, how should you derive the SSR? We will tell you the actionable steps that you can take and also give you an example of how we have derived SSRs from TSRs. Firstly, let’s look at the actionable steps in the process of deriving the SSR: Read and understand the TSRs assigned to SW. What is the Software supposed to do? Is this clearly specified? The first step before starting the SSR is to ensure that SW Requ

If you have heard about Safety manuals but have not read one, or if you have read a Safety manual, tried to apply it and found it very challenging, this article is for you. In this blog, we talk about: Who needs a Safety manual? What is a Safety manual and what does it describe? Best Practices when working with Safety manuals Interestingly, ISO26262 never mentions “Safety manual” except in Part 11 for Semi-conductors, though its parent IEC 61508 describes the role of Safety manuals. Refer this article . Who needs a Safety manual? Let us assume that you are a Safety Manager or a Systems/Software/Hardware architect involved in the start of an Autonomous driving solution and the Safety goals of the program are at ASIL D.   Your technical sales team has already shortlisted two Microcontrollers that are at ASIL D, and now you are asked to evaluate both from a Safety perspective. Your first stop for information is the Safety manual of these Micros. You look through the Safety manual to

  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

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