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

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

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 are working in the software of a safety critical product, you are most probably using an ASIL 'certified' Operating system in it.  The market is flooded with various ASIL-certified Operation Systems (OSs) from various Tier 2s. On top of it, several Tier 1s and OEMs themselves are developing their own OS in ASIL compliance. This blog summarizes the ASIL-certified OSs that are available in the market, what features they provide and what do they promise for its users. Disclaimer : We have analyzed only the public literature available for the various OSs and written this article based on what we learnt from them. We do not have working experience in most of these OSs. Hence, we could have missed describing some of the features that are available in these OSs simply because it was not stated in their public literature. We have structured the content of this article as follows: What are the broad expectations of an Operating System from a Functional Safety perspective? What ar...