Automotive functional safety ISO26262

There was a time when mobile phones did exactly what its original intent was — make calls and send messages. They had no app stores, no background services, no operating system updates, nothing fancy and yet they were extremely reliable at their intended function. Today’s smartphones run powerful operating systems that can handle complex functions, multitasking, isolation, security, and continuous updates. They are indispensable for complex use cases—but unnecessary for making a simple phone call. Automotive software faces a similar paradigm shift. As the industry moves toward safety-compliant RTOSs and HPC operating systems, there are still simple ECUs with limited functionality running a bare-metal (No OS!) and having ASIL A or ASIL B safety goals. Is an OS necessary for such cases? Can functional safety be achieved in such systems? This is the question we will explore in this article. We will approach this topic as follows: What is bare-metal programming? Why do bare-metal embedded ...

4 years ago, we researched on the landscape of ASIL qualified RTOSs available in the market. You can find the article here . While we were already familiar with several well-known and widely adopted solutions, we were surprised that the ecosystem was far broader and diverse than we had anticipated, with many more RTOS options addressing automotive functional safety needs. Fast forward to the start of 2026, how has this market changed? What new operating systems have entered the market, and how has their role changed in response to the industry’s rapid transformation? That’s what this article is about. With the steady rise of semi-autonomous and fully autonomous vehicles, and the transition towards a software-on-wheels paradigm, it is not surprising that the notion of an “Operating system” has significantly shifted. Traditionally, an operating system is “a software that manages computer hardware and software resources and provides common services for computer programs.” It sandwiches be...

Welcome to our second blog post of functionalsafetyfirst.com on Cybersecurity. In our previous article, we introduced you to some of the key ISO 21434 terms and applied them to the well-known Jeep Cherokee cyberattack. For those who may have missed it, you can find it here . In this article, we will explore additional ISO 21434 attack-related terminologies, using the same Jeep Cherokee cyberattack as example.  Attack related terms! - Weakness & Vulnerability Weakness - is a defect or flaw in an asset that can cause undesirable/unwanted behaviour. Examples: Missing requirement or specification Missing/Incorrect implementation of security protocols such as Media Access Control Security (MAC) for communication among ECUs in vehicle network Using outdated software without the latest security patches makes vehicles vulnerable to digital break-ins, as attackers may already know and exploit these security gaps A weakness of an asset may or may not lead to a vulnerability. For example,...

Welcome to our first ever blog post of functionalsafetyfirst.com on... Cybersecurity !! Cybersecurity in vehicles is evolving faster than ever — and much like functional safety, it’s become a non-negotiable pillar of modern automotive development. It’s no surprise that functional safety engineers are now exploring ISO/SAE 21434, while cybersecurity experts are diving into ISO 26262. The two worlds are converging rapidly. But if you’re a functional safety engineer stepping into cybersecurity for the first time, where do you start? How do you get comfortable with the “cyber language” — the new terms, the lifecycle, the regulations, and the mechanisms like encryption, secure boot, secure OTA, and intrusion detection? This article is our attempt to make that journey simpler. In this article, we will introduce you to a few terms used in the ISO 21434, with short relatable examples. Towards the end, we will look at applying these terms to one of the most prominent and publicized remote hacki...

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

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