Skip to main content


System Safety ≠ Product Safety!!

To all those Functional Safety Engineers, who are immersed too deep inside the ISO26262, buckle your seat belts! Let us take a tour outside the 26262!! The ISO26262 primarily focuses on “System” Safety. However, the overall Safety in the context of car is far beyond just system safety. It is about measures and features that are designed to minimize the risk of accidents, protect vehicle occupants, and reduce the severity of injuries in the event of a hazardous situation. It covers various aspects of vehicle design, technology, driver assistance systems and even environmental aspects that are aimed at both preventing accidents as well as to minimize injuries and harm in the event of an accident.  Automakers and regulatory bodies have taken continuous efforts to improve Safety standards, implement newer technologies and develop safer designs, and hence several standards have also been introduced. We can broadly group these standards into the following buckets: System Safety (which includ

What is the Ideal level of system architecture for safety?

The System Architecture is a key input document for the technical safety concept (TSC)/Requirements (TSRs). Interestingly, it is also a work product that gets refined by the TSC, often leading to defining new System elements and Interfaces to satisfy Safety requirements. However, several people do not understand why a System Architecture is needed to create the TSC! Shouldn’t it not be that the System Architecture implements the TSRs? Also, what is the right level of information required in a Safety System Architecture?  This article is an attempt to bridge this knowledge gap and support the creation of more ‘Safety friendly!!” System Architectures 😃 What is the purpose of a System Architecture with respect to Safety? To understand the purpose for System Architecture with respect to Safety, we first need to know the steps involved in doing a technical safety concept. Please refer the flowchart below. Figure 1: Steps involved in creating a TSR. To begin the technical safety concept, we

Screw the Audit

  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

Functional Safety for Domain Controller (DC) ECUs

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

SW SEooC Verification

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 .

Getting started in ADAS!

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: Overview of ADAS: Complete course on Self-driving cars: ADAS Features: ACC: Reverse Parking Collision Avoid Ass

Calibration Data


Configuration Data


Flow of Functional Safety Requirements


Frequently asked Questions from our Systems Webinar

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