Automotive functional safety ISO26262

In our previous post , we introduced the topic of ASIL certification for HW elements. In this article, we will give you an idea of what is done as part of ASIL Certification. We will then introduce the concept of HW Evaluation , how it is to be done and what are the challenges in doing it.   Note: ISO26262 does not talk about "Certification" and what is the way to "certify" a component.  ASIL Certification means that a component was developed according to ISO26262, it was audited by Independent Safety Auditors and the Auditor confirmed that the Component meets the qualitative and quantitative expectations for that ASIL level. The Idea behind “ASIL Certification” Basics first. How is Safety is achieved in an Item? By sufficiently preventing Systematic failures - by good design and following ASIL development processes By introducing safety mechanisms to detect random hardware failures and achieving the required quantitative Hardware Metrics for that ASIL level.  Let u...

Safety beginners are quite often very confused about how Safety affects the hardware design and choice of components in the BOM.  “Should I use ASIL certified Micro controllers, CAN transceivers, PMICs and switches in my ASIL program? What about the resistors and capacitors? Do we even have ASIL certified passives in the market?” they ask. In this blog and next ones to come, we will clear the confusion surrounding “ASIL” certification and qualification of Hardware elements. We will cover several questions surrounding this topic. This blog post will cover the following questions: 1. Background – How the ASIL certification for HW really started 2.Scope of ASIL Certification for HW – Which HW elements are expected to be ASIL Certified and which need not be Background – How the ASIL certification for HW really started It was in the ISO26262-2018 edition, Part 8, Clause 13 “Evaluation of Hardware elements” that for the first time, the idea of “ASIL certified” ICs was introduced. In this...

 

If you are working in the software of a safety critical product, you are most probably using an ASIL 'certified' Operating system in it.  The market is flooded with various ASIL-certified Operation Systems (OSs) from various Tier 2s. On top of it, several Tier 1s and OEMs themselves are developing their own OS in ASIL compliance. This blog summarizes the ASIL-certified OSs that are available in the market, what features they provide and what do they promise for its users. Disclaimer : We have analyzed only the public literature available for the various OSs and written this article based on what we learnt from them. We do not have working experience in most of these OSs. Hence, we could have missed describing some of the features that are available in these OSs simply because it was not stated in their public literature. We have structured the content of this article as follows: What are the broad expectations of an Operating System from a Functional Safety perspective? What ar...

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