Automotive functional safety

In our previous blog, we introduced you to the first 5 Safety highlights of Adaptive Autosar. In this blog, let us discuss the remaining 6 highlights. 6. Safe Service oriented Communication HAD use cases demand dynamic upgrade of software applications throughout the entire vehicle lifecycle and to subsequently add new software functions, for instance via over-the-air software updates. Applications may be developed and tested independent of each other in distributed working groups and then integrated into the overall system at any time. Using Service-oriented communication between the software applications makes this possible. Service-Oriented Communication (SoC) is the main communication pattern for AA Applications. The concept of service-oriented communication is based on the idea that there are applications that provide a service on the communication system and other applications subscribe to this service.  The data will only be sent to the subscribers. Here is a picture from Autosar

In our previous blog , we introduced you to the 11 Safety highlights of Adaptive Autosar. In this blog, let us discuss the first 5 highlights. 1. Safety considerations for high performance oriented hardware While CA is targeted to run on Microcontrollers that offer hard real time performance, Adaptive AUTOSAR Platform is targeted to run on complex SOCs with hardware accelerators such as accelerators for advanced graphics processing, deep learning accelerators, DSPs, Multi-cores etc in order to achieve high performance. Obviously, this means that there is a lot of concurrent processing going on. To achieve deterministic execution for Safety functions, AA provides design guidelines for using parallel processing technologies .  An ASIL compliant Hypervisor must be used to partition and isolate the Safety critical aspects of the System from the non-Safety related System. 2. Support for Safe and Secure use of C++ While the CA supports only C language, AP support C++ since it is the language

  Adaptive AUTOSAR (AA) is the buzz word in the context of highly automated driving (HAD). It is the AUTOSAR consortium’s solution for high performance computing and flexible over-the-air updates in HAD and also other ECUs such as Domain Controllers, Infotainment systems etc.  While Classic AUTOSAR (CA) offers an excellent solution to handle traditional ECUs with deeply embedded software and hard real time requirements, it cannot handle HAD and other such intelligent ECUs because its design does not support the high performance and flexibility requirements of these ECUs. This sprung the need to develop a new platform for such ECUs and thus was born AA. An OEM or Tier-1 chooses AA so that they do not have to reinvent the wheel for an architectural solution for the Intelligent ECUs. Due to the safety criticality of these Intelligent ECUs, AA incorporates several safety aspects as part of its architecture. In this blog, we have highlighted 11 of the key differentiating aspects.  However,

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