An RTOS, (pronounced R-Toss) is a real time operating system and has several characteristics that are very different than a Desktop Operating System such as Microsoft Windows. First and foremost, all real time operating systems are hidden or embedded and most are embedded within a much larger system. Although RTOS’ are now being used more and more in computer electronics than ever before and can be embedded as a software device that executes on a hard-disk drive given that it has the right type of design and middleware. RTOS’ have been around for many years and are embedded and hidden in everyday devices that you are probably not even aware of. They are in such things as, automobile systems, airplane systems, human bio-medical devices, robots, and in control and command centers. They are intended to be highly secure as well as highly deterministic.
You might hear or read that an RTOS is in “real time”. However, the term "real-time" pertains more to being highly "deterministic" or "reliable”. In essence, an RTOS must be able to do what it was designed to do and within the appropriate time-frame. This deterministic behavior is mission critical for some types of embedded systems and not so critical for others. With this in mind, there are three types of deterministic RTOS behaviors and each have constraints that differentiates one RTOS from another as follows: “Timing”, “Hard Timing”, and “Soft Timing” constraints. These constraints are designed based upon an RTOS reaction time for execution. An example of just a “Timing Constraint” would be a Service Request execution orchestrated by its Service Oriented Architecture and has no real mission critical impact. An RTOS with a ”Hard Timing” constraint would be one that is mission critical and where the RTOS must react upon demand with zero lag time. If it doesn't, it will explicitly fail. Upon its failure, the consequences could have a “deadly” or “disastrous” impact. If you think about a bio-medical device, such as a heart defibrillator, which is an embedded device or an RTOS with mission critical “Hard Timing” constraints it is designed to bring a person’s heart back into a regular heart beating state at the very moment that person’s heart stops beating. If there is any lag time in the RTOS reaction time to such a mission critical event, the RTOS has explicitly failed to execute what it was designed to do, and the consequences to that person is “death”.
Thus, a RTOS with ’hard timing” constraints is one where an RTOS must be highly secure and deterministic in its goals and behaviors. It cannot fail to do what it was designed to do or else it will have undesirable, if not deadly, consequences. On the other hand, an embedded RTOS that has "Soft Timing” constraints are not considered mission critical, and were designed to allow a small amount of lag time in its deterministic behaviors. For instance, if a consumer computing device implements an embedded RTOS with “Soft Timing” constraints, and it was designed to perform multiple tasks simultaneously where each task executes only for a short time before it is temporarily interrupted while the system updates its machine registers' or for loading the registers with data for the next task. Upon this temporary interruption, only a small amount of computational latency or lag timeis necessary. Thus, the system will not have failed in what it was designed to do based upon its "Soft Timing" constraints.
That is the simplistic overview of an RTOS and the behaviors that differentiate each type of RTOS in the marketplace today. However, an RTOS is a very complex system and there are many other technical characteristics that also must be considered when designing and implementing an RTOS, such as Memory Size, CPU Power, Code Optimization, as well as its Execution Model. That is very different from a Desktop Operating System. However, the technical aspects of those characteristics are outside the purview of this blog.
There are many other technical characteristic that also must be considered when designing and implementing an RTOS, such as Memory Size, CPU Power, Code Optimization, Operating System Kernel, as well as a design for its Execution Model that is very different from a Desktop Operating System. However, the technical aspects of those characteristics are outside the purview of this blog.