Automotive functional safety

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 correlate th

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 cla

Anyone who has done a complete end-to-end safety development will definitely be familiar with tools qualification. Even if you have not done the complete safety life cycle and have just worked on a particular skills area (Skills = Systems or hardware or software), you would have supported the functional safety manager in the qualification of the software tools that are used by the systems, hardware or software team. As part of this blog, let us explore why we need tool qualification and as well define a systematic yet simple approach to performing tool qualification. Before we deep dive into the approach that needs to be followed for doing the qualification, let us understand the reason for doing such an activity. 1.1        Why do we need to qualify the tools? Given the complexity of the ECUs that we are presently working on, the development of an item will not be possible without the use of a variety of software tools. The software could be something that is used by the systems team