Skip to main content


Functional Safety Requirements (FSR) ≠ Technical Safety Requirements (TSR)

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

ISO26262 Part 6, Clause 5 for Dummies - Part 1

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

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