Automotive functional safety ISO26262

  How important is the DIA? This was the question one of our team members asked us when we started reviewing a DIA. It is a simple yet profound question, for there are a lot of nuances to be unpacked as part of the answer. << Assumption for the article: We are standing in the shoes of a Tier-1 supplier. For a Tier-1, their customer is the OEM. This implies that the DIA will be between the Tier-1 and OEM FuSa managers. >> Straight up, the DIA is the first document with which we start discussions with the customer. The discussions on the DIA should ideally start at the RFI/RFQ stage itself. Starting the DIA at the RFI/RFQ stage ensures that the work products agreed upon with the customer are properly estimated (time and money) during the quote. This, in turn, means that the Tier-1 is able to plan their work accordingly. As an example, we had an OEM who asked us to perform FMEDA calculations for an ASIL-A program. (I’m sure you are all aware that FMEDA becomes mand...

“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 in...

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