Automotive functional safety

“Over The Air (OTA) updates have brought down the SW quality" A couple of months ago, I was discussing with a Senior manager (and close friend) in SW Quality and what he said about OTA shocked me. This cannot be true, I said to myself. There are definite benefits to using OTA and one of the foremost is the cost saving that this functionality brings to the table for OEMs. I started thinking about the benefits and could immediately list down the below. Reduction in cost of updating software Ease of use Ability to migrate to the latest and greatest feature that the OEM offers Last but not the least, address safety security concerns in a timely manner How could my friend be so wrong about this wonderful functionality? The SW upgrade of Tesla is one shining example of how OTA could be effectively utilized to not just provide a wonderful user experience but also could be used to increase the bottom line of an organization itself. With confirmation bias setting in, I had to reset my thin

3.140 safety manager person or organization responsible for overseeing and ensuring the execution of activities necessary to achieve functional safety (3.67) Note 1 to entry: At different levels of the item's (3.84) development, each company involved can appoint one or more different persons by splitting assignment in accordance with the internal matrix organization. The Safety Manager plays a key role in the success of a program and should be thought of as the linchpin on which the safety management of a project turns. It should come as no surprise that ‘Safety Manager’ is the only role that is explicitly called out in Part-1 of the standard. This person(s) is responsible for planning, tracking, and ensuring that safety in the program is implemented as expected. Based on our extensive experience in the successful execution of multiple programs, we have distilled the ‘what’ of this role into 7 essential habits that are critical for a person to become a highly effective safety manag

One of the most challenging topics for Tier 1s in a Safety program is the Integration of “ASIL” micro(s) into the System and fulfilling the Assumptions of Use (AoUs) provided in the Safety manual to ‘truly’ achieve the ASIL-ness of the Micro. Despite our experience over years integrating different ASIL Micros, we have, time and again, been surprised at what we have found. In this article, we have talked about the top 4 pitfalls we fell into. In the conclusion, we have given our recommendations on how to avoid these pitfalls. Even though we have focused only on ASIL Micros in this article, you may fall into the same pitfalls while integrating any other ASIL HW Components such as PMICs, Sensor ICs etc. Since the subject of our article is the Tier 1, wherever we have used the “you” pronoun, it refers to a person in the shoes of a Tier 1. Top 4 Pitfalls: 1. Micro is ASIL “suitable” but not ASIL “compliant”. 2. The Supporting SW (Drivers, stack, libraries) provided for the Micro are not

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

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

  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