What is a Real Time Operating System?

The term Real Time Operating System (or RTOS, for short) is often used, especially in the context of embedded systems. Though there exist many definitions for what an RTOS is, to me the term only makes sense in the context of the system in which it is operating. Therefore, to determine what an RTOS is, we first need to examine what it means to have an embedded system. 

An embedded system is an application specific combination of hardware and software intended to fulfill a specific duty (or set of duties). This definition precludes things like your smartphone because it is more akin to a general compute platform. Rather, embedded systems are designed to carry out a set of specific tasks. At the highest level, these tasks boil down to one loop: sense, control, and actuate.  

The sense portion consists of gathering pertinent information on the environment in which the embedded system is operating. By pertinent, I mean that the information is related to the purpose of that embedded system. For example, if the system is a soil moisture monitor, the sense portion would consist of sensors connected directly to the microcontroller for things like current moisture level, ambient temperature, and ambient humidity. Sensing comes in the form of hardware sensors, signals over a network (such as CAN, LIN, Ethernet, or UART), or even as the output from some other sense – control – actuate loop running alongside in the same system.  

The control portion is the on-board logic in the system. It can be as simple as if this then that or can consist of multiple layers of filtering, controls algorithms (such as PIDs) and state flows. It is the brains of the embedded system and is responsible for transforming sensed inputs into actionable outputs. 

The actuate part of the system is the response of the control portion, which derived its decision from the sense portion. Actuation, like sensing, can be a broad set of actions. The output of a sense – control – actuate loop may be a physical one, like turning on a valve through driving a digital output. It may be a network-based output, like sending information over a CAN bus or through Ethernet. Or it may be even more abstract, like enqueuing an element to a FIFO (First in First Out queue) for consumption by other sense – control – actuate loops. The last point means we can have cascaded sense – control – actuate loops. 

Now to return to our definition of what an RTOS is; the previous discussion was a primer for what it means to be real time. A real time system is one in which the sense – control – actuate loop can correctly and reliably manage the state of the system within its physical confines. In our example of the soil moisture monitor, the task of the embedded system may be to maintain a moisture level of 30% in the soil. The time constant [https://en.wikipedia.org/wiki/Time_constant] of the system may be on the order of minutes, meaning it takes a considerable amount of time to go from 30% soil moisture down to 29%. So long as the sense – control – actuate loop can run fast enough to manage this task of never letting soil moisture go below 30%, I would consider it to be real time.  

A more challenging task would be keeping a car in the center of its lane automatically. Here the sense – control – actuate loop could consist of cameras sensing the position of the vehicle relative to its lane, and software to interpret these camera signals and run a controls algorithm to produce an actuation of the steering wheel. The time constant in this system is exceedingly small, because in the matter of hundreds of microseconds the position of the vehicle relative to the lane could change. Hence, if the loop can run fast enough to reliably accomplish the task of keeping the vehicle centered, it would be real time.  

To put it another way, the required speed at which we must be able to sense and control the environment our system operates in dictates whether it is real time. A real time soil monitoring system can run orders of magnitude slower than a real time lane centering system; yet both are real time. 

The second part of the term RTOS is the Operating System. An operating system provides a layer of abstraction over the hardware and gives a consistent and unified API (Application Programming Interface) for developers to use hardware resources. The term becomes a little less clear cut in an embedded system, mainly because the abstraction over hardware is often less well defined. What you do get in an embedded-centric OS is a scheduler for tasks. 

A task is a function which gives the programmer the appearance of an independent thread of control. It has its own call stack and is the basic entity which can be scheduled to run on a CPU by the OS. The scheduler picks between tasks based on some algorithm (which we will get into below) to run, and can optionally kick out one task in the middle of its running to switch in another task (known as preemption).  

Combining all this together, an RTOS is a class of operating system that gives the ability to the programmer to run sense – control – actuate loops in a way such that all of them can run to meet their respective deadlines. The ability portion is italicized because as we will see, running an RTOS is a necessary but not sufficient criteria for achieving a real time system.  

Tasks

As mentioned previously, a task is an independent thread of control. It has its own call stack, meaning it is free to call any functions it desires. Each task has a task control block (TCB), which can hold the entire context of the CPU, such as local registers. This gives the OS the ability to save the state of the program within a task and restore the state of the program of another task. In this way, multiple tasks can all co-exist on the same processor. Tasks in an RTOS are almost exclusively made up of an infinite loop. This is because the software is application specific, and the expectation is that these tasks run the same control code forever, either being switched out to other tasks by the scheduler or voluntarily giving up the CPU on their own.  

The relationship between sense – control – actuate loops and tasks is a little ambiguous. The concept of a sense – control – actuate loop is an abstraction of what an embedded system does, whereas tasks are the concrete manifestation of software written in an embedded device. A control loop may be contained within a task, where it senses, performs calculations, and drives some outputs. It may be spread over multiple tasks. It’s conceivable that a system designer puts in place one task to do all the sensing, another for performing controls calculations, and a third for actuating outputs. Conversely, one task may run several of these sense – control – actuate loops. One of the most common arrangements of tasks is by the deadlines of the control loops they run. This usually appears as having periodic tasks, such as a 10ms task, 100ms task, and 1000ms task.  

The most important feature of a task is that it is the basic schedulable entity. Only one task at a time can run on one CPU, and the OS scheduler looks at the set of tasks in the system to determine which one to run next. When it is time to switch in a task, either voluntarily or not, the context of the task is saved, and the CPU switches context to that of another task. When the old task gets scheduled again, it resumes right where it left off (the exact assembly instruction it left off with). How this is achieved is different for every processor architecture.  

Finally, the most important parameter of a task from the point of view of an RTOS is its priority. Each task must have a priority, because most scheduling algorithms use the priority of a task to properly give it enough CPU time relative to the other tasks in the system. The matter of selecting what code gets run in what task, and in turn, what priority each task is assigned, are some of the two most important decisions for a system designer. 

Different RTOS’s use priority in different ways. Some systems use task priorities to select which task from a pool to give to the CPU to run. What this means is whenever it is time to select a new task to run on the processor, we select the task with the highest priority from the set of tasks that are ready to be run. Other systems use priority as merely an indicator of how much time a task should get in a time slice. For example, high priority tasks may be allocated 50% of a time slice, medium priority tasks 30%, and low priority tasks only 20%.  

To facilitate scheduling of tasks, most every RTOS keeps a simple state associated with each task in the system. At a minimum, the states that a task can be in are: 

• Running – the task is actively running on the CPU. It can get kicked out either voluntarily or by the scheduler itself (preempted).  
• Ready – the task is ready to run on the CPU, but it just isn’t now, because there is some other task that currently is running. 
• Blocked – the task cannot be selected to run on the CPU because it has indicated that it is not yet ready. This can be due to a variety of reasons, the most common being this task’s time slice has not yet come up, or it is waiting for some system event to place it in the ready state. 

Conclusion

We now know what real time is in the context of an embedded system. We’re also aware that the definition of real time varies depending on the constraints of the system in which the embedded software runs. Based on that we developed our understanding of an RTOS, and its basic unit of work; a task. In the next post about embedded RTOS’s, we’ll discuss scheduling techniques and common pitfalls when designing a real-time embedded system which uses an RTOS.