Automotive functional safety ISO26262

This is a recording of our Functional Safety Systems Webinar that was conducted on 10-November-2021. Click on the image below to download the webinar slides

This is a recording of our Functional Safety Systems Webinar that was conducted on 10-November-2021.

ISO26262’s HW Evaluation talks about 3 Classes of HW Components – Class I, II or III. There are 3 attributes we must use to determine this Class. Once we identify the Class, we need to evaluate them accordingly. At a first glance, this approach sounds simple and straight forward. However, when we read deeper, we realize that the ISO Standard is ambiguous in describing how to determine HW Classes. While it does give 3 attributes, it does not mention how to correlate them. This makes it difficult to conclude how to classify some of the HW elements, especially the medium and high complexity HW ICs. In this blog, we have shared our 2 cents on HW classification of Class II and Class III elements. HW elements are classified based on 3 attributes: Complexity Ease of Identification of failure modes and  Availability of Safety mechanisms Based on these 3 attributes, Class of a HW element is identified as shown below. Can you see the gap in the above table? It does not define how to correlat...

ECC (Error correction code/Error correcting code) is a method of detecting and correcting errors in digital data. It is widely used in detecting and correcting errors in data in memories and also for ensuring transmission integrity.  In this article, we have answered some specific questions that are frequently asked about ECC by Safety beginners: From a functional safety perspective, what is the purpose of ECC? Is ECC a mandatory safety mechanism? Is ECC a mechanism to achieve freedom from interference or independence? What aspects must be considered in a System that uses ECC-capable hardware (memories and communication buses) From a functional safety perspective, what is the purpose of ECC? The broad purpose of ECC is to make Memories and transmission much more stable and reliable. That’s why ECC is not only used in Safety critical systems such as Automotive, aviation, defense etc but also in safety-irrelevant ‘maximum-availability’ systems such as file servers and critical datab...

For every safety critical system, FTT requirements are specified by the OEM. What we often notice is that SW teams do not know the complete picture of how these timings are fulfilled. They tend to think that if testing proves that the FTT time is met, that is sufficient. Then they start to see that even though the Safety SW or HW of the System has not changed, suddenly FTT time measurements from testing start to change noticeably. In some cases that these measurements exceed the required FTT, and now suddenly the team is left wondering how this happened. " We did not change the Safety SW. Looks like the Non-safety part of the system is causing this change but we do not have control over it " they say. If you look at it from the ISO26262 Part-6 V model perspective, on the left side of the V is the Architecture design and the right side of the V is the Verification and Testing.  The argument of proving that FTT was met via testing is in the right side of the V. However, what we...

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

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

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

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