Before starting playing with an RTOS it is advisable to acquire some general concepts about Real Time Systems and then about RTOSes for embedded use. Initially we will use a very generic terminology, we will map those terms in more specific terms in next chapter.

Imagine a realtime system as something composed by one or more, likely many, realtime processes. Our definition of realtime process is: an entity that, in response to an external events, produces a reaction in a finite time.

We will not yet go into details about the nature of those entities nor what a event or a reaction can be, an abstract approach is preferable at this point, moreover, we are assuming that there can be a single possible event and a single possible reaction, this is not necessarily the case.

A complex systems can always be decomposed in a set of elementary processes connected in a network, the system has a set of input and output signals, we can still consider them events and reactions but on a system level. A system can also have a global state, information that can optionally be accessed by the various processes in the system.

Note that in a system, there are like multiple paths leading from an event to a reaction, lets name those paths activities.

A small summary:

• Process. An elementary entity that in response to an event produces a reaction.
• Activity. A set on dependent interconnected processes.
• System. A set of dependent or independent activities.
• Event. An event triggering a reaction from a process.
• Reaction. The programmed reaction to an event.
• Response Time. The time between an event and the programmed reaction.

Processes, activities and, by extension, systems can classified in one of the following categories.

• Non Real Time. A non real time system is a system where there are no deadlines involved. Non realtime systems could be described as follow:

“A non real time system is a system where the programmed reaction to an event will certainly happen sometime in the future”.

• Soft Real Time. A Soft Real Time (SRT) system is a system where not meeting a deadline can have undesirable but not catastrophic effects, a performance degradation for example. Such systems could be described as follow:

“A soft real time system is a system where the programmed reaction to an event is almost always completed within a known finite time”.

• Hard Real Time. An Hard Real Time (HRT) system is a system where not meeting a deadline can have catastrophic effects. Hard realtime systems require a much more strict definition and could be described as follow:

“An hard real time system is a system where the programmed reaction to an event is guaranteed to be completed within a known finite time”.

Note that into a system, processes of all kinds can be present at the same time, each one potentially with a different classification. The classification of an activity into a system must be considered equal to the classification of the qualitatively worst process influencing it. If a system includes activities with different classification then it is a mixed system, this is a common case. An example:

In this system the process 2 is non-realtime, its response time cannot be estimated. Because of this the internal path I2→O1 must be considered non-realtime as well. Note that also process 1 could be affected by the non-deterministic response time of process 2 because there is some global data sharing. If mutual exclusion is used then process 1 and 2 affect each other for the duration of the worst case time spent in the mutual exclusion zone.

Processes never react in a constant time, at a sufficiently small time scale any physical process is bound to have jitter.

When assessing the response time of a system the jitter of each single internal process must be accounted for and, note, the only meaningful value is the worst case jitter. Unbounded or not assessed jitter is not compatible with an hard realtime system.

An RTOS is an operating system whose internal processes are guaranteed to be compliant with (hard or soft) realtime requirements. The fundamental qualities of an RTOS are:

• Predictable. It is the quality of being predictable in the scheduling behavior.
• Deterministic. It is the quality of being able to consistently produce the same results under the same conditions.

RTOS are often confused with “fast” operating systems. While efficiency is a positive attribute of an RTOS, efficiency alone does not qualifies an OS as RTOS but it could separate a good RTOS from a not so good one.

An RTOS is not a magic wand, your system will not be “realtime” just because you are using an RTOS, what matters is your system design. The RTOS itself is just a toolbox that offers you the required tools for creating a realtime system, you can use the tools correctly or in the wrong way.