Do we need an RTOS for FuSa?

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 engineers resist an RTOS?
• Advantages of an RTOS
• Considerations while implementing Functional Safety in a bare-metal system

What is bare-metal programming?

For those unfamiliar to software, let's first understand what a bare-metal is and how is it different compared to an RTOS (Real-time Operating System).

Bare-metal programming can be defined as a software development where the application executes directly on a microcontroller or processor, managing hardware resources itself without relying on an operating system. A bare-metal is like an infinite loop that runs all the time. All tasks are executed sequentially within this infinite loop. 'Do something, do something else, do something else, then repeat' until an Interrupt occurs. When an interrupt occurs, the processor saves the context of the loop and switches to service the interrupt. It resumes the execution of the Infinite loop after the Interrupt is serviced.

Image credits: https://microcontrollerslab.com/wp-content/uploads/2020/09/Bare-Metal-Embedded-Systems-introduction.jpg

A bare-metal could also be programmed to run specific tasks within the Super loop in a specific periodicity. For e.g., a bare-metal could use a periodic timer interrupt to read a free running HW timer and can schedule tasks at specific frequencies based on how much this timer has elapsed.

Why do bare-metal embedded engineers resist an RTOS?

For embedded engineers who have always done bare-metal programming, using an RTOS seems like asking for too much. 

• The simplicity of a bare-metal seems to be lost. 
• RTOS might seem like introducing overheads into the system, not being able to extract every bit and juice of the CPU and memory. 
• It feels tedious and time-consuming to understand how the RTOS works and how to use its APIs correctly and integrate the application successfully with the OS. 
• Not to forget, of course worrying about the licensing costs for the RTOS if not using an Open source one.

Advantages of an RTOS

An RTOS offers several advantages to a System which a bare-metal cannot offer. Infact, it is not even fair to compare an RTOS and a bare-metal considering that an RTOS can

1. Provide the capability to schedule tasks in a deterministic manner which leads to being able to achieve hard real-time requirements and design a highly deterministic system (ofcourse only if the OS is ‘used’ correctly!). In this regard, RTOS offers event-based services which a bare-metal does not provide.
2. Ability to manage HW resources such as memory, I/Os, peripherals etc, enabling shared access to resources in a controlled manner.
3. Provide error handling capabilities for invalid/undefined conditions and to take the most suited action depending on the error
4. Capability to protect the stack by providing stack overflow/underflow detection mechanisms
5. An RTOS is scalable and can offer HW based spatial partitioning and temporal partitioning for different tasks. It is state-of-the-art for both safety and non-safety products.

Considerations while implementing Functional Safety in a bare-metal system

The first set of questions to ask for a system that uses only a bare-metal is –

• Is this ‘simple’ system able to ‘deterministically’ achieve its functional and non-functional requirements (including timing requirements) using a bare-metal? 
• Would the system’s functions stay as it is and not be scaled up in future, for all vehicles in which the ECU/system is used? 
• Is the system able to deterministically achieve the FTTI requirements derived from its safety goals?

If the answer is a loud and clear ‘Yes’ to all the above questions, this safety-critical simple system may continue to use a bare-metal to achieve its safety goals. However, terms and conditions apply – like

1. Implementing the required safety mechanisms/measures
2. qualifying the bare metal code
3. protecting the bare metal data memory
4. using qualified compilers etc 

In short words, we basically qualify the system according to ASIL development practises. 

However, if the answer is not a resounding ‘Yes’, the Program should migrate to an RTOS. Teams should understand the benefits that an RTOS brings to the System from functional, safety and cybersecurity perspectives and overlook the short-term struggles in porting to the same. 

In the context of software-defined vehicles, continuing to rely solely on bare-metal software is increasingly comparable to using a feature phone in a smartphone world. The sense of control and simplicity is real—but it comes at the cost of scalability, flexibility, and long-term maintainability. The question is no longer whether bare-metal can work, but whether it can continue to work as system complexity and safety/security expectations rise.