Automotive functional safety

  One of the most common mistakes that we have seen developers make when working on a safety program is to think too much about the audit/assessment. We constantly get questioned about whether the things they are doing are sufficient for an audit or whether there would be Non-Compliances (NC) that could arise for doing things in a particular way. Unfortunately, this is a wrong thought process to have. The most important stakeholder for a safe product is the people who will be using the product or the people who could be affected by the safe product (Think pedestrians sharing the same road as the vehicle that is deemed safety relevant). As a developer the thought process should be about doing all the right things relating to safety. A non-exhaustive list of ‘Right Things’ are given below: Understanding what a safe product looks like and what it takes to develop it (Think technology, process, methods & tools) Transparently stating the limits and limitations of your product (Safety

With the advent of enticing user experience, Electrification and ADAS features in the car, vehicle architecture is strongly headed towards Domain Controllers. In this article, let us discuss the following aspects: What is a Domain controller? Why are OEMs going towards Domain Controllers? What considerations should we have for functional safety in Domain Controllers? In case multiple suppliers are involved in the development of the Domain controller, what challenges exist and how to handle them? What is a Domain controller? Why are OEMs going towards Domain Controllers? Traditional vehicle architectures are de-centralized and distributed with one ECU typically implementing 1 feature/function. Every time a new function/feature is added, a new ECU is added. This kind of an architecture is extremely complex and heavy in terms of wiring (lots of cables, contacts, fusing, relays etc) and makes it very expensive to package all the ECUs into a car. Also, with the increased focus on automated

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