Chapter2

REAL TIME OPERATING SYSTEM

2.1 REAL-TIME SYSTEMS DEVELOPMENT

Real-time processing normally requires both parallel activities and fast response. In fact, the term realtime is often used synonymously with multi-tasking or multi-threading, although this is not strictly correct: small real-time systems, as used in dedicated equipment controllers, can perform perfectly adequately with just a simple looping program. As long as the response is good enough, no further complexities need be introduced. But, if a large number of different inputs are being monitored by a single processor, or the input data streams are complex and structured, the simple polling loop approach will prove inflexible and slow, and a multi-tasking solution will be required. Whatever style of implementation is chosen as appropriate, the need remains to deal with several concurrent activities over a period of time.

2.1.1 OUTLINE REAL-TIME CATEGORIZATION SCHEME

Specified limit on system response latency Event-driven scheduling Low-level programming Software tightly coupled to special hardware Dedicated specialized function The computer may be inside a control loop Volatile variables Multi-tasking implementation Run-time scheduling Unpredictable environment System intended to run continuously Life-critical applications

Although there is no clear dividing line between real-time and non-real-time systems, there are a set of distinguishing features which can assist with an outline classification schema to identify real-time applications. They are timing, interrupt driven, low-level programming, specialized hardware, volatile data i/o ,multi-tasking real-time systems ,run-time scheduling ,unpredictability ,life-critical code .

2.2 PROGRAMMING STRUCTURES

It is now well accepted that computer programs can all be broken down into three fundamental structures: Linear sequences of instructions Iterative loops of instructions Branches guarded by selection statements In addition, multi-tasking code requires two more structures: Parallel or concurrent instructions Critical groups of exclusive instructions

2.3 ACCESS TO HARDWARE

When debugging real-time code extra difficulties emerge, such as the impossibility of usefully single stepping through doubtful code, or reproducing elusive, time critical input situations. Because real-time computer systems are often working in tight integration with the surrounding equipment, they need to have efficient access to hardware. This means that the normal hardware/software separation, imposed by an operating system for security purposes, has to be broached. The application software must be able to directly read input ports and write to output ports. With Unix and Windows, these operations are forbidden to all but supervisorlevel code. To run all the application tasks with supervisor permission would incur unnecessary risk, so special device driver routines are needed to provide the I/O facilities that real-time programs require.

2.4 MACHINE I/O AND HARDWARE/SOFTWARE COST TRADEOFF

All machine instruction sets must include some mechanism allowing the programmer to transfer data into and out of the computer. To that end, Intel provides its CPUs with special IN and OUT instructions which operate solely on ports located within a designated I/O address space. To an increasing extent, product functionality has been invested in the embedded software rather than special purpose hardware.

2.5 HARD, SOFT AND FIRM

Response latency is also an interesting contradiction in citing minimum response delay (latency) as the key factor when characterizing real-time systems. Often the distinction is drawn between hard and soft realtime systems. Hard systems impose tight limits on response times, so that a delayed result is a wrong result. The examples of a jet fuel controller and a camera shutter unit illustrate the need to get a correct value computed and available at the right time. Soft real-time systems need only meet a time-average performance target. As long as most of the results are available before the deadline, the system will run successfully, with acceptably recognizable output. Audio and video transmission and processing equipment are examples of real-time systems

which must achieve an average throughput performance. Only when responses are delayed repeatedly will a seriously unacceptable error occur. The category of firm is also being mooted as a crossover between the other two, because real-world systems do not always fall into either category for response deadlines. A somewhat clearer distinction is visible between large and small real-time systems development. Design techniques, management methods, implementation languages and many other critical aspects are dealt with differently by groups operating at the two extremes of this application spectrum. Large systems could be production plant monitoring equipment, air traffic control and telecommunication networks. Real-time systems, large and small, are becoming a routine part of our everyday life.

2.6 REAL-TIME SYSTEMS IMPLEMENTATIONS

It is common for real-time programs to be divided into many semi-independent concurrent tasks which are scheduled by an RTE or operating system. Each task deals with one aspect or function of the total system activity. Alternatively, simple real-time systems can be implemented in a single program using procedural loops or incorporating a cyclic executive. These results in several problems occurring, such as inflexible timing for device polling, fixed task priorities and limited intertask communication. Also the performance of such systems rapidly deteriorate if the user requirements become more elaborate as extra facilities are demanded or timing constraints vary from those originally specified. It is under similar circumstances that programmers start looking around for a suitable RTE to release them from VxWorks Wind River VRTX Microtec OS 9000 Microware QNX QNX SS Ltd pSOS Integrated Sys MicroC/OS Microsis LynxOS LynuxWorks

2.7 CAPABILITIES OF COMMERCIAL REAL-TIME OPERATING SYSTEMS

This section describes several real-time operating systems that run on common processors and have sizable user bases. They are LynxOS, pSOSystem , QNX ,VRTX and VxWorks. In many respects, these operating systems are similar. The commonalities, you can replace the noun the operating system.

1. Conformance to Standards :The operating system is compliant or partially complaint to the Real-Time POSIX API standard, so you have preemptive fixed priority scheduling, standard synchronization primitives, and so on, but the operating system may support only threads or processes (i.e., not both) and may implement only a subset of standard functions. The operating system also has its own set of API functions, which may differ significantly from the corresponding POSIX functions and, in the cases where they are similar, may have more features. Some of the operating systems also provide AT&T System V and BSD system call interfaces (e.g., LynxOS) and Willows Wim32 Library (e.g., QNX). 2. Modularity and Stability: the kernel is small, and the operating system configurable. In particular, the operating system can be scaled down to fit with the application in ROM in small embedded systems. By adding optional components to the kernel, the operating system can be configured to provide I/O, file, and networking services. 3. Speed and Efficiency: Most of the operating systems are microkernel systems. Unlike microkernel systems of old, which usually have higher run-time overhead than monolithic operating systems, these microkernel operating systems have low overhead. In some, sending a message to a system service provider incurs no context switch. Important timing figures such as contact-switch time, interrupt latency, semaphore get/release latency, and so on, are typically small. 4. System Calls: Nonpreemptable portions of kernel functions necessary for mutual exclusion are highly optimized and made as short deterministic as possible. 5. Split Interrupt Handling: Similarly, the nonpreemptable portion of interrupt handling and the execution times of immediate interrupt handling routines are kept small. The bulk of the work done to handle the each interrupt is scheduled and executed at an appropriate priority. 6. Scheduling: All real-time operating systems offer at least 32 priority levels, which is the minimum number required to be Real-Time POSIX compliant; most offer128 or 256/255. They all offer the choice between FIFO or round-robin policies for scheduling equal-priority threads. They allow you to change thread priorities at run time, but none provides adequate support for EDF scheduling and good look for user-level bandwidth-preserving servers and slack stealers. 7. Priority Inversion Control: The operating system provides the priority inheritance but may allow you to disable it to save the overhead if this mechanism if you choose to use a resource access-control scheme that does not need priority inheritance. The system may also provide ceiling-priority protocol. 8. Clock and Timer Resolution: The operating system may provide a nominal timer resolution down to nanoseconds. However, even on the fastest processor today, the operating systems take about a microsecond to process a timer interrupt, so you should not expect to be able to release a thread periodically with a period down to microseconds or precision and granularity in time down to tens and hundreds of nanoseconds.

9. Memory Management: The operating system may provide virtual-to-physical address mapping but does not do paging. The operating system may not offer memory protection. Even when it does, it provides the user with the choice among multiple levels of memory protection, ranging from no protection to provide virtual memory. 10. Networking: The operating system can be configured to support TCP/IP, streams, and so on.