Automotive functional safety ISO26262

Me: “How many bugs did you find during SW Unit testing?" SW developer/Unit testing responsible: "None" Me:" Were any bugs identified during system bench testing that required changes to your code? SW developer: "Yes, a few" Me: “Why didn't you find those bugs during Unit testing?" SW developer: --Silence-- Me: “Are you sure you did an effective SW Unit testing?" SW developer: "I am sure. My statement and branch coverage are 100% and all my Unit test cases have passed! " Me: --Silence--

  Watch our latest video where we explain in real detail, the What, When, Who and How of HW Evaluation!

In the amazing book “ Rework ”, the authors bring up the concept of ‘ Focus on what won’t change ’. This particular concept resonates with us as this is exactly what we emphasize when we consult our clients. When we work on functional safety with our clients, we go back to basics of software engineering and help the client understand the basics better. Even as our clients use AI tools for coding and producing other work products, we keep emphasising the core aspects of SW development. To that end, we created a presentation on SW development principles and did a training for one of our clients; check the slides below.  

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