Automotive functional safety

If you are an SW SEooC developer, how do you know if you have sufficiently verified your SW? Our 2 -part videos will help you get an answer to this question. If you are new to SEooC, check out our earlier article .

If you are someone who has been working in the Automotive domain in various ECUs like power train ECUs, Infotainment, Instrument clusters, Body control etc and you are now getting started in the world of ADAS (Advanced Driver Assistance Systems), this article is for you! ADAS is the way to go for automotive innovation in this decade and THE Safety solution for lesser car accidents on the road. We have compiled here some extremely good articles and videos that can help you get started in ADAS. Read, Watch them. Have fun learning!! SAE Driving levels: https://autonomous-driving.org/2018/03/20/the-6-levels-of-autonomous-driving/ Overview of ADAS:  https://www.nhtsa.gov/equipment/driver-assistance-technologies#driving-control-assistance-30676 https://dewesoft.com/daq/what-is-adas Complete course on Self-driving cars: https://www.ipb.uni-bonn.de/sdc-2021/ https://www.ipb.uni-bonn.de/sdc-2020/ ADAS Features: ACC: https://www.youtube.com/watch?v=own_VaRZ9M8 Reverse Parking Collision Avoid Ass

 

We have posted some frequently asked questions that were asked during our Systems Webinar in the pdf attached here. Please click the link below to access it. Happy learning! Safety FAQs

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.

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

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

  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 ele

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

ASIL Decomposition – What is it anyway! Let us start with the ISO 26262 definition for ASIL Decomposition: “ Apportioning of redundant safety requirements to elements, with sufficient independence, conducing to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements .” If you feel completely lost or confused as though you read a statement in a language that you have never heard of, then you are not alone! ASIL decomposition is considered as one of the advanced topics in the safety domain and many feel intimidated to venture into this topic. The idea behind this blog is to demystify the decomposition concept and to present you with some pointers on how to use decomposition. If we have to breakdown the definition into ‘plain’ English, it would look something like this: ASIL decomposition is a method by which the requirements could be broken down into redundant requirements that are then allo