Skip to main content

Posts

Showing posts with the label Drivvize

Prevention and Detection - FMEA and ISO26262

If you have performed a Design FMEA, you might be familiar with the terms “Current Prevention Controls” and “Current Detection Controls” that is used in the template. FMEA is typically performed as per AIAG-VDA FMEA standard. This standard defines the meaning and purpose of these terms. FMEA is performed for both Design and Processes. Design FMEAs are performed for the Product, System, HW or SW. In the parallel Functional Safety world, similar cousin terms ‘Prevention Measures’ and ‘Detection Measures’ are commonly used. However, there is no fixed definition to these terms in ISO26262 (i.e., you wouldn’t be able to find these terms defined in Part-1). The terms are much more understood logically in the context of functional safety. The goal of this article is to help the reader understand what these terms in these two worlds mean. The article will also explain how the AIAG VDA FMEA standard has bridged the functional safety gap in its 2019 edition. “Current Prevention Controls” and “Cu

HW Safety Process in a jiffy!

OTA - Boon or Bane

“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

The 7 Habits of a Highly Effective Safety Manager

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

Pitfalls Tier 1s fall into while Integrating ASIL Micros

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

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