Real Time Operating System(RTOS)

Real Time Operating System(RTOS)

1. Introduction to Real-Time Operating Systems

The sections below outline basic concepts and language related to real-time operating systems. Subsequently, you have read through this paper, it is urged that you visit Building a Real-Time System with NI Hardware and Software next to learn more about how National Instruments can help you construct a superior real-time system in as little time as possible.

What is a Real-Time OS?

In general, an operating system (OS) is responsible for managing the hardware resources of a computer and hosting applications that work on the computer. An RTOS performs these chores, but is also specially designed to run applications with very precise timing and a high level of dependability. This can be particularly important in measurement and automation systems where downtime is costly or a program delay could cause a safety risk.

To be considered "real-time", an operating system must have a known maximum time for each of the critical operations that it behaves (or at least be able to insure that maximum most of the time). Some of these operations include OS calls and break handling. The operating systems that can absolutely guarantee a maximum time for these operations are commonly named to as "hard real-time", while operating systems that can only guarantee a maximum most of the time are denoted to as "soft real-time". In drill, these strict categories have limited usefulness - each RTOS solution demonstrates unique performance characteristics and the user should carefully investigate these features.

To fully grasp these concepts, it is helpful to see an example. Think that you are designing an airbag system for a new model of automobile. In this example, a minor mistake in timing (causing the airbag to deploy too early or too late) could be catastrophic and cause harm. Thus, a hard real-time system is required; you need assurance as the system designer that no individual cognitive process will exceed certain timing constraints. On the other hand, if you were to design a mobile phone that received streaming video, it may be ok to lose a modest total of data occasionally even though on average it is important to hold up with the video stream. For this application, a soft real-time operating system may serve.

The main detail is that, if programmed right, an RTOS can guarantee that a program will melt down with very consistent timing. Real-time operating systems do this by providing programmers with a high level of command over how tasks are prioritized, and typically also allow checking to get sure that important deadlines are taken on.

In contrast to real-time operating systems, the most popular operating systems for personal computer utilization (such as Windows) are called general-purpose operating systems. While more in-depth technical data on how real-time operating systems differ from general-purpose operating systems is fed in a section below, it is important to recall that there are advantages and disadvantages to both types of OS. Operating systems like Windows are designed to maintain user responsiveness with many programs and services running (ensuring "fairness"), while real-time operating systems are planned to move critical applications reliably and with precise timing (paying attention to the programmer's priorities).

Important Terminology and Concepts

Determinism: An application (or critical piece of an application) that runs on a hard real-time operating system is referred to as deterministic if its timing can be guaranteed within a certain margin of error.

Soft vs Hard Real-Time: An OS that can absolutely guarantee a maximum time for the operations it performs is referred to as hard real-time. In contrast, an OS that can usually perform operations in a certain time is referred to as soft real-time.

Jitter: The amount of error in the timing of a task over subsequent iterations of a program or loop is referred to as jitter. Real-time operating systems are optimized to provide a low amount of jitter when programmed correctly; a task will take very close to the same amount of time to execute each time it is run.

2. Example Real-Time Applications

Real-time operating systems were projected for two general classes of applications: event response and closed-loop control. Event response applications, such as automated visual inspection of assembly line parts, require a response to a stimulus in a certain quantity of time. In this visual inspection system, for example, each piece must be photographed and studied before the assembly line goes.

By careful programming an application that works on a hard real-time operating system, designers working on event response applications can ensure that a reaction will happen deterministically (within a certain maximum amount of time). Looking at the parts inspection example, using a general-purpose OS could result in a part not been inspected in time - thus delaying the assembly line, pulling the party to be discarded, or sending a potentially defective part.

In contrast, closed-loop control systems, such as an automotive cruise control system, continuous process feedback data to adjust one or more productions. Because each output value depends on treating the input data in a specified amount of time, it is critical that loop deadlines are satisfied in order to ensure that the right outputs are created. What would take place if a sail control system failed to define what the throttle setting should be at a given peak in time? Once once more, hardened real-time operating systems can ensure that control system input data is treated in a reproducible amount of time (with a fixed worst-case maximum).

It should also be noted that many applications that must run for extended periods of time can benefit from the reliability that an RTOS can provide. Because real-time operating systems typically run a minimum band of software rather than many applications and processes at the same time, they are easily suited for systems that require 24-7 operation or where down-time is impossible or expensive.

3. Below the Hood: How Real-Time OSs Differ from General-Purpose OSs

Operating systems such as Microsoft Windows and Mac OS can provide an excellent platform for training and running your non-critical measurement and control applications. Even so, these operating systems are planned for different use cases than real-time operating systems, and are not the ideal platform for racing applications that need exact timing or extended up-fourth dimension. This segment will identify some of the major under-the-hood differences between both types of functioning systems, and explain what you can expect when programming a real-time application. 

Setting Priorities

When programming an application, most operating systems (of whatever type) allow the coder to set a precedence for the overall application and even for different tasks within the application (threads). These priorities serve as a signal to the OS, dictating which operations the designer feels are most significant. The finish is that if two or more tasks are ready to play at the same time, the OS will function the task with the highest precedence.

In practice, general-purpose operating systems do not invariably follow these programmed priorities strictly. Because general-purpose operating systems are optimized to run a mixture of applications and processes simultaneously, they typically turn to make certain that all tasks receive at least some processing time. As a consequence, low-priority tasks may in some cases have their priority boosted above other higher priority projects. This ensures some amount of run-time for each task, simply implies that the designer's wishes are not invariably observed.

In contrast, real-time operating systems fall out the programmer's priorities much more rigorously. On most real-time operating systems, if a high priority task is using 100% of the processor, no other lower priority projects will be given until the higher priority task finishes. Hence, real-time system designers must program their applications carefully with priorities in mind. In a typical real-time application, a designer will place time-critical code (e.g. Event response or a control code) in one section with a real high precedence. Other, less-important code such as logging to disk or network communication may be united with a section with a lower precedence.

Interrupt Latency

Interrupt response time is measured as the measure of time between when a device generates an interrupt and when that device is serviced. While general-purpose operating systems may contain a varying quantity of time to react to a given interrupt, real-time operating systems must assure that all interrupts will be serviced within a certain maximum amount of time. In other words, the interrupt latency of real-time operating systems must be restrained. 

Performance

One common misconception is that real-time operating systems deliver better functioning than other general-purpose operating systems. While real-time operating systems may offer more honest operation in some instances due to less multitasking between applications and services, this is not a pattern. Actual application performance will depend on CPU speed, storage architecture, program characteristics, and more. 

Though real-time operating systems may or may not increase the speed of execution, they can offer a lot more accurate and predictable timing characteristics than general-purpose operating systems.

for more tutorials please goto here.......