Automotive functional safety ISO26262

We were recently guiding the Software team of an organization, on writing Software Safety requirements (SSR). During a review, we asked them if they have written the Safety-relevant QM requirements in the SSR document. The Software team was surprised - " Should we write QM requirements in an SSR document? Shouldn't that not be done in a separate requirements document as per QM process? ", they asked. " Yes and No " - we said. " Depends on which type of QM it is ". " What do you mean by type of QM? " they raised their eyebrows, puzzled. In this article, we will explain the many shades of QM Requirements, and what kind of "QM" requirements must be written in a Safety requirement document (be it a TSR, SSR or HSR). Please note that ISO 26262 never talks about different types of QM explicitly, and the ideas shared in this article is coming from our experience. Broadly, QM Requirements can be classified as follows -  Non-Safety-relevant ...

With the recent announcement from Ministry of Road Transport and Highways, to mandate ADAS for heavy vehicles, India has taken a lead in the path towards safer highways. In the below document, we cover more ground about the mandated features and the implications for OEMs and Suppliers to meet these new regulations.  

  One of the things that we are proud of as a team is our ability to handle safety programs in crisis mode and bring them to a good shape in a short span of time. We have done it so many times in the past (When we were working in Tier-1 organizations) and as well recently as part of Drivvize to our clients that we have come to a point where we are able to crystalize our thoughts & actions and provide it as actionable steps to the broader community. In the below Mind Map, we have tried to capture our methodology of working through a safety program crisis. The following things have been assumed: We are speaking about Tier-1 projects only! Tier-1 is in-charge of both HW & SW development HW metrics are applicable Capable engineers are available to perform the safety activities (BIG BIG assumption!!) Note: Article written using NI (Natural Intelligence). No AI tools were harmed during the making of this article!!

Software component qualification (ISO26262-8, clause 12) is an activity widely used with the intent of reusing existing software for Safety. In our first article , we had discussed the big picture view of component qualification with the analogy of a jigsaw puzzle. In this second part of the article, we will cover the following topics: The broad steps that need to be carried out for SW component qualification Challenges in qualification and possible solutions The broad steps that need to be carried out for SW component qualification  Let us consider the example of a component qualification performed for a Math library that is proposed to be used in an ADAS system that has Safety goals which demand Math libraries to be safety relevant. Let’s assume that only the code for the Math library exists.  The Qualification activity could be broadly broken into 3 steps. Defining safety-relevant requirements and testing them Defining the Integration/User guide and performing Integration t...

Software component qualification (ISO26262-8, clause 12) is an activity widely used with the intent of reusing existing software for Safety. This article is covered as 2 parts and will cover the following topics: What’s the big picture view for component qualification? Why is it performed? A simple jigsaw puzzle analogy to understand the activity The Thumb Rule for Component Qualification Different perspectives of the qualification activity The broad steps that need to be carried out for SW component qualification Challenges in qualification and possible solutions This is Part-1 of the article and will cover topics 1-4 above. Part 2 of this article will cover topics 5 and 6. What’s the big picture view for component qualification? Why is it performed? When it comes to developing the software of a safety-critical system as ASIL, there are mainly 3 approaches. Developing the entire software of that system according to the highest ASIL level of that system Developing only some parts of th...

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

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

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