Automotive functional safety ISO26262

There is a saying that “ Well begun is half done ” which means a clearly understood scope of work and a well-defined plan makes the work easier. There are some key activities in Functional Safety that must be “Well begun”. Let us understand the key aspects of functional safety (FuSa) management in this article.  The foundation and pillars must be strong to build a safe house. To build a safe 'Item', the foundation and pillars that must be strong are: FuSa Process DIA (Development Interface Agreement) Safety Plan Safety Case The above picture represents a high-level Functional Safety framework.  This Framework Starts with DIA – to define the scope of work Progresses with Safety plan – to define the strategy how to perform the work  Ends with Safety case – to argue the achievement of Functional Safety compliance. This framework represents FuSa Process as the "Foundation" of FuSa Development, DIA as the Input to the Complete FuSa cycle and Safety Case as its Output. Safe

What is the difference between an operating system that is ASIL B Compliant vs ASIL D Compliant? What does an ASIL D Operating System additionally need to provide in terms of “features” compared to an ASIL B Operating System? Let us keep aside the process aspects of ASIL B vs ASIL D development and focus only on the technical aspects. To keep the focus on Safety, we have discussed in the context of RTOSs and not HPC OSs. Irrespective of the ASIL level that needs to be achieved by an Operating System, there are some basic aspects that an RTOS needs to provide such as: High availability and reliability - Guaranteed and correct execution of Safety tasks Maximum Performance - minimal latencies for interrupts, events, tasks etc Guaranteed Isolation of Safety related processes and its memory Guaranteed freedom from Interference (FFI) for Safety related tasks/threads Safe and reliable inter-process/inter-task/inter-thread communication Error handling related to Application’s use of the OS and

One of the best things that has happened in the last few months (After starting Drivvize ) is the chance to speak with a lot of companies who are getting started on their safety journey. Apart from being able to work on new technologies, it also gives us a sneak peek into the concerns and problems facing these companies with respect to FuSa implementation. What we have tried here is to consolidate the broad categories of issues faced. We have also tried to look at it from a 10,000 feet view to arrive at solutions that could be applied for most of these issues.  A word of caution: We recognize that every organization is unique and hence there could be some variations to the problems faced. Due to these variations (Ex: Process compliance levels, organizational maturity, organizational structure etc.), some fine tuning or customization of the broader solution will have to be done to get the solution to work.  Common Questions and General Observations and our proposed solutions: 1. We have

Quite often, Safety Engineers are confused between Functional Safety requirements (FSR) and Technical safety requirements (TSR).  What level of details are to be provided in both the requirements and where exactly to cut the boundaries between these two is unclear. We will discuss the same in this post. Requirements Hierarchy Functional Safety Requirements (FSR) are derived from Item definition, HARA and Safety goals and are traced back to Safety Goals. Each Safety goal shall have a minimum of one FSR associated with it. Technical Safety Requirements (TSR) are mainly derived from FSRs. Each FSR shall have a minimum of one TSR associated with it. The below image provides a hierarchical view of requirements/activities flow from ISO26262 Part 3 – Item definition to Part 5 Hardware Safety Requirements (HSR) and Part 6 Software Safety Requirements. Also visit our YouTube video which explains the flow of Functional Safety requirements. Difference between FSR and TSR This table gives the hig

If you are a SW Safety Engineer or a SW Engineer with practical hands-on experience in doing Safety activities, the Part-6 of the ISO26262 will be “Easy Peasy”. But if you are a Safety Engineer who never worked on SW but are asked to perform SW Safety Activities, then the Part-6 is surely “Tricky Dricky”!! This article is targeted towards Safety Engineers who are unfamiliar with SW. We have taken a specific set of requirements from Clause 5 of Part 6 and attempted to simplify it. This is Part 1 of Clause 5, and we will do another Part-2 for the same clause. Requirement 5.4.2 states the following:  5.4.2 The criteria that shall be considered when selecting a design, modelling or programming language are:  a) an unambiguous and comprehensible definition; EXAMPLE Unambiguous definition of syntax and semantics or restriction to configuration of the development environment.  b) suitability for specifying and managing safety requirements according to ISO 26262-8:2018 Clause 6, if modelling i

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

“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