Skip to main content

Posts

Functional Safety Systems Webinar

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

Functional Safety Systems - Part 4 - Webinar

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

The inconclusive debate - Class II or Class III

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

ASIL Certification for HW Components and HW Evaluation

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

Should I use “ASIL certified” HW Components?

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

Faults in the ISO 26262

 

Cascading Failures

 

ASIL Operating Systems - Which is your pick?

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

ECC (Error Correction Codes)

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 databases

How to achieve FTT by design

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