ABSTRACT: The paper analyzes the performance of two different real-time operating systems. We survey the state-of-the-art in real-time operating systems (RTOSs) from the system synthesis point of view. This paper is intended to provide an overview of the basic concepts and practices that are associated with real time operating systems. Real-time applications vary tremendously in their scope, in the tightness of their performance specifications and in their cost constraints. Traditional applications were associated with the aerospace, nuclear power and defense industries. Such systems are large, and they must meet all deadlines and cost is not a critical issue. While these applications continue to be important, embedded controllers in the transportation, consumer electronics and communication industries now constitute a major share of real-time systems. RTOS's have a very long research history, which provides important theoretical results and useful industrial implementations. Convergence of applications, technology, and market trends of embedded systems implies a strong need for new generation of RTOS. This paper deals with a survey of classical academic and industrial RTOS work. I. INTRODUCTION TO OPERATING SYSTEM: An operating system is program that manages the computer hardware. It also provides a basis for application programs and acts as an intermediary between a user of a computer and computer hardware. The operating system controls and coordinates the use of the hardware among the various application programs for various users. II. REAL TIME SYSTEM:

One form of a special-purpose operating system is real time system. Real time systems are defined as those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which results are produced. A real time system is used when rigid time requirements have been placed on the operation of the processor or the flow of data; thus, it is often used as control device in an application. Examples of this type of real time system are command and control system, process control systems, flight control system, the space shuttle avionics system, future system such as the space station, space – based defense system such as SDI, and large command and control systems. 2.1. REAL TIME SYSTEM – OPERATING SYSTEM: At the core of software real-time system is a realtime operating system. One of the main differences between real-time operating systems and generalpurpose operating systems is the ability to guarantee a worst-case latency. On a generalpurpose OS, an external interrupt could be put into a queue and then serviced later after the OS has finished its current Operation and any other interrupts in the queue. On the other hand, a real-time OS can halt its current process to handle an interrupt immediately. In essence, the real-time OS guarantees event response within a certain interval. To do this, the real-time OS assigns priorities to processes and interrupts. If a high priority interrupt occurs, the OS immediately halts its process and services the interrupt. 2.2. NEED OF REAL TIME SYSTEM: Timing correctness requirements in a real time system arise because of the physical impact of the controlling systems activities upon its environment. For example, if the computer controlling a robot does not command it to stop or turn on time, the robot might collide with another object on the factory floor possibly causing serious damage .in many real time systems even more consequences will result if timing as well as logical correctness properties of the system are not satisfied, e.g., consider nuclear power plants or air traffic control system fail. 2.3. BASIC FACILITIES OF RTOS:


Being fast is a necessary condition of a real time system, but it is not sufficient. It has to meet explicitly deadlines and being fast on the average does not guarantee that a deadline will be met. If a real time system can be shown to meet its deadlines then we say that it is predictable. Multitasking is required to develop a good real time application Pseudo parallelism “– to handle multiple external events occurring simultaneously. Rate monotonic scheduling (RMS) - is utilized to compute in advance the processor power required to handle the simultaneous events. Algorithms (scheduling mechanism) are needed to decide which task or thread will run at a given time. Function is to switch from one task or process to another (context switch). • Overhead – should be completed as quickly as possible. • Dispatch time should be independent of the number of threads in the ready list. • Ready list should be organized each time an element is added to the list. III. SCHEDULING: Scheduling is a fundamental operating system function. All computer resource are scheduled before use, CPU is the primary resource .its scheduling is central to operating-system design. 3.1. CPU SCHEDULING: CPU scheduling is a task of selecting a waiting process from the ready queue and allocating the CPU to it. The CPU is allocated to the selected process by the dispatcher.

Once the CPU has been allocated to process the process keeps CPU until it release the CPU either by terminating or by switching to the waiting state. Example: - Microsoft window 3.1, apple Macintosh. Dispatcher latency: the dispatcher is the module that gives control of CPU to the process selected by the short-term scheduler. The time it takes for the dispatcher to stop one process and start another running is known as dispatch latency. Scheduling criteria: Different CPU scheduling algorithms have different properties and may favor one class of processes over another. The characteristics used for comparison can make a substantial difference in determination of algorithm. The criteria include the following: CPU utilization: To keep the CPU as busy as possible. CPU utilization may range from 0-100%. In real system it should range from 40% (for lightly loaded system) to 90% (for heavily used system). Through put: one measure of work is the number of processes completed for time unit called through put. E.g. for long process – 1process per hour. For short process – 10 process per second. Turn around time: How long it takes to execute that process. The interval from the time sufficient of a process to the time of completion is a turn around time. Turn around time is the sum of period spend waiting to get into memory, waiting in ready queue, executing on CPU I/O. Waiting time: The CPU scheduling algorithm does not affect the amount of time during which a process execute nor does I/O. It affects only the amount of time that a process spends waiting in the ready queue. Waiting time is done sum of period spend waiting in the ready queue. Response time: The time from the submission of request until the first response is produced. This measure is called response time. The amount of time it takes to start responding but not the time that it takes to o/p that response. 3.2. SCHEDULING ALGORITHMS: CPU scheduling deals with the problems of deciding which of the processes in ready queue is to be allocated the CPU. 1. First come, first-severed scheduling 2. Shortest-job-first scheduling 3. Priority scheduling 4. Round-robin scheduling

• Preemptive scheduling:Under the following CPU scheduling can take place. 1. When a process switches from the running state to the waiting state (I/O request, or invocation of wait for the termination of one of the child processes). 2. When a process switches from the running state to the ready state (for e.g., when an interrupt occurs). 3. When a process switches from the waiting state to ready state (for e.g., completion of I/O). 4. When a process terminates. In circumstances, 1 and 4 are non-preemptive scheduling, 2 and 3 are preemptive scheduling. • Non-preemptive scheduling:-


5. Multilevel queue scheduling 6. Multilevel feedback queue scheduling 3.3. REAL –TIME SYSTEM SCHEDULING: Real-time control applications can be mapped onto a spectrum of performance. On one side, hard realtime systems are very deterministic and never miss an event. An example of a hard real-time system in an engine dynamometer. If an event were missed. The data collected or the road conditions simulated would be incorrect. On the other side of the spectrum, soft real-time systems do not require the same degree of determinism and occasionally miss events without malfunctioning. For example, missing a single data point in a temperature monitoring system does not impact the overall trend because the general trend of temperature changes slowly. Implementing soft real time functionality requires careful design of the scheduler and related aspects of the operating system. First, the system must have priority scheduling, and real time processes must have the highest priority. Second, the dispatch latency must be small the smaller the latency, the faster a real time process can execute once it is run able. The problem is that many operating systems, including most versions of UNIX, are forced to wait either for a system call to complete or for an I/O block to take place before doing a context switch. 3.4. TIMING CONSTRAINTS FOR TASKS: Timing constraints can be met based on the type of application used. A task is something that needs to be done. It is often implemented in a separate thread, but does not have to be. In other words, tasks are a set of process with data dependencies between them. Tasks can be classified depending on two factors: 1. by the predictability of their arrival. 2. By the consequences of they’re not being executed on time. Basing on the first factor: • Periodic- In case of periodic task, a period might mean ‘once per period T’ or ‘exactly T units apart’. An example of dynamically created tasks is a (periodic) task that monitors a particular flight; this comes into existence when the aircraft enters an air traffic control region and will cease to exist when the aircraft leaves the region.

constraint on both start and finish times. Periodic requirements can arise from dynamic events such as an object falling in front of a moving robot, or a human operator pushing a button on a console. Tasks, which are bounded inter arrival, are called sporadic tasks. Depending on second factor they are critical and non-critical tasks:

• Critical tasks:- Their timely execution is critical. Ex: - life support systems, stability control of an aircraft. Despite their critical nature, it is not always essential that every iteration be executed successfully and within a given deadline.
• Non-critical tasks: - They are not critical to the application. The tasks should be completed with in a given deadline; otherwise, they are not useful. IV. STRUCTURE OF REAL-TIME SYSTEM: The state of the controlled process and of the operating environment (e g: pressure, temperature, speed and altitude) is acquired by sensor, which provides inputs to controller, the real time computer. The data rate from each sensor depends on how quickly the measured parameters can change. The “trigger generator “is a representation of the mechanism use to trigger the execution of individual jobs. There is a fixed set of application tasks or job, the “job list” That is in fig

Job list


Controlled process


Trigger generator



• Aperiodic: An aperiodic task has a deadline by which it must finish or start, or it may have a




Fig: schematic block diagram of real time system The software for these tasks is preloaded into the computer. Many of the jobs are periodic. Jobs can also be initiated depending on the sate of controlled process or on the operating environment. Finally, jobs can be initiated on command from operated input panel. The output of the computer is fed to actuators and the displays. The actuators typically have a mechanical or hydraulic component, and so their time constants are quite high .as a result, the data rates to the actuators are quite low. The sensors and the actuators run at relatively low data rates. The computer itself must fast enough to execute the control algorithms. As a result the separates into three areas an outer low rate area consisting of sensors actuators displays, and input panels, middle or peripheral area and the central cluster of processors .The controlled process can go through distinct phases, quite frequently. V. CHARACTERIZING REAL TIME SYSTEMS Building a real time system can vary from a simple task to an extremely complex task where the state of the art is still lacking. The difficulty depends on the characteristics of a real time system along, at least, five dimensions given below:5.1. GRANULARITY OF THE DEADLINE AND LAXITY OF THE TASKS: If the time between when a task is activated (required to be executed) and when it must complete execution is short then the deadline is tight (i.e. the granularity of the deadline is small, deadline is close). Even large granularity deadlines can be tight, when the laxity (deadline minus computation time) is small. In general, the tighter the deadline the more difficult the design task. 5.2. STRICTNESS OF A DEADLINE: The strictness of the deadline refers to the value of executing a task after its deadline. For a hard real -time task there is no value to executing the task after the deadline has passed. A soft real-time task retains some diminished value after its deadline so it should still be executed. Very different techniques are usually used for hard and soft realtime tasks.

5.3. RELIABILITY: Many real-time systems operate under severe reliability requirements. That is, if certain tasks, called critical tasks, miss their deadline then a catastrophe may occur. The requirement for critical tasks should be that all of them always make their deadline (a 100% guarantee), subject to certain failure and workload assumptions. 5.4. SIZE OF SYSTEM AND DEGREE OF COORDINATION: Real-time systems vary considerable in size and complexity. In most current real-time systems the entire system is loaded in to the memory, or if there are well-defined phases, each phase is loaded just prior to the beginning of the phase. The ability to load entire systems in to memory and to limit task interactions simplifies many aspects of building and analyzing real-time systems. Increase in size and coordination gives rise to many new problems that must be addressed and complicates the notion of predictability. 5.5. ENVIRONMENT: The environment in which a real –time system is to operate plays an important role in the design of the system. The deterministic environments give rise to small, static real-time systems where all deadlines can be guaranteed a priori. The problem is that the approaches taken in relatively small, static systems do not scale to other environments, which are larger, much more complicated, and less controllable. A dynamic real-time system operating in a non-deterministic environment is required in many future applications. VI. ACHIEVING REAL-TIME PERFORMANCE: Achieving quantifiable real-time performance requires integrated solutions across many areas. We discuss some of those areas: Real-time operating systems are an integral part of real-time systems. Real-time operating systems stress predictability and include features to support real-time constraints. Three general categories of real-time system operating Systems exist: -Small, proprietary kernels -Real-time extensions to commercial timesharing operating systems such as UNIX and -Research kernels.


6.1. SMALL, FAST, PROPRIETARY KERNELS:They come in two varieties • Homegrown: - Specialized to the application. • Commercial offerings: - The cost of uniquely developing and maintaining the first type, as well as the increasing quality of the commercial offerings is significantly reducing. The practice of generating homegrown kernels. To reduce the runtime overheads incurred by the kernel and to make the system fast, the kernel has a fast context switch. Has a small size (with its associated minimal functionality). Minimum intervals during which interrupts are disabled. To deal with the timing requirements, the kernel provides bounded execution time for most primitives, maintains a real-time clock, and provides a priority scheduling mechanism. The kernels also perform multi-tasking and intertask communication and synchronization. Some researches believe that the current kernel features provide almost no support for solving the difficult timing problems and would rather need more sophisticated kernels that directly address timing and fault tolerance constraints. Recently there have been efforts to produce seamless real-time kernels that scale from the small, proprietary kernels to large kernels that support UNIX interfaces. 6.2. REAL –TIME EXTENSIONS TO COMMERCIAL OPERATING SYSTEMS:A second approach to real-time operating systems is the extension of commercial products, e.g., extending UNIX to RT-UNIX, OR POSIX to RTPOSIX, or MACH to RT-MACH. The real time version of commercial operating systems are generally slower and less predictable than the proprietary kernels, but have great functionality and better software development environment-very important considerations in many applications. In particular, POSIX P.1003.4 subcommittee is defining standards for real-time operating systems. Various problems exist when attempting to convert a non real-time operating system to a real-time version. For example, in UNIX interface problems exist in process scheduling due to the nice and set priority primitives and its round robin scheduling policy. These and some other problems can and have been solved to result in a real-time operating system that is used for both real-time and non-real processing. For example, they list over RT-UNIX

system calls that are not recommended to be used when running a real-time application. The trend to begin with a complexity new implementation of UNIX based on micro kernels may reduce or eliminate some of the above problems. For example MACH is heavily based on lazy evaluation .one example for this strategy is copy-on-write. Variable real-time features that were added to MACH include real-time threads, real-time synchronization primitives, and support for priority inheritance. Another fundamental problem with timesharing paradigm is that these operating systems want to remove control over resources from the application. So given all these problems for RT-UNIX or RT-MACH can be used in real-time applications where missing a deadline has no severe consequences. If deadlines must be guaranteed to be met these operating systems can still be used if the designers can hand craft a set of priorities that will always work. 6.3. RESEARCH OPERATING SYSTEMS: While many real-time applications will continue to be constructed with proprietary real-time kernels with extensions to commercial timesharing operating systems, some significant problems exist. In particular the proprietary kernels have difficulty when scaling to large applications, and the time sharing extensions emphasize speed rather than predictability. The Spring KERNEL contains realtime support for multiprocessors and distributed systems. Spring, like MARS presents anew paradigm for real-time operating systems, but unlike MARS it strives for a more flexible combination of of-line and on-line techniques. VII. APPLICATIONS OF REAL-TIME SYSTEMS: Achieving complex, real-time systems is non trivial and will require research break-through in many aspects of system design and implementation. The architecture and hardware must also be designed to support predictability and facilitate analysis. An insidious aspect of critical real-time systems, especially with respect to the real-time requirements, is the weakest link in the entire system can undermine careful design and analysis at other levels. Finally, two very new trends involve the development of real-time databases and real-time artificial intelligence. We discuss them in detail below:-


7.1. REAL-TIME DATABASES: A real-time database is a database system where (at least some) transactions have explicit timing constraints such as deadlines. Real-time database systems can be found, for instance, in program trading in stock market, radar tracking systems, battle management systems, and computer integrated manufacturing systems. Some of these systems are soft real-time systems. Most current real-time databases work deals with soft real-time systems. In this work, the need for an integrated approach that includes conflict resolution, deadlock resolution, buffer managements are identified. Many protocols base on locking, optimistic, and time stamped concurrency control have been developed and evaluated in test bed or simulation environments. In most case the optimistic approaches seem to work best. Most hard real-time database systems are main memory databases of small size, with predefined transactions, and hand crafted for efficient performance. The metrics for hard real-time databases are different than for soft real-time databases. In soft real-time database transactions have similar properties, but in addition have soft real-time constraints. Metrics include response time and a throughput, but also include percentage of transactions, which meet their deadlines, or a weighted value function, which reflects the value, imparted by a transaction completing on time. In a hard real-time database, transactions have serializability, atomicity, and permanence properties. While the notion of consistency is relevant here, traditional approaches involve achieving consistency, involving waits, rollbacks, and aborts are not directly applicable. While the hard real-time system should guarantee all critical transaction deadlines and strive to meet all other transaction deadlines, this is not always possible. Hence, metrics such as maximizing the value imparted by complete transactions and maximizing the percentage of transactions that complete by their deadline are primary metrics. Throughput and response times are secondary metrics if they are used at all. 7.2. REAL-TIME ARTIFICIAL INTELLIGENCE: Many complex real-time applications now require or will require knowledge–based online assistance operating in real-time. This necessitates a major change to some of the paradigms and

implementations previously used by AI researchers .For example, AI systems must be made to run much faster aloe preemption to reduce latency for responding to new stimuli, include deadlines and other timing constraints in search techniques. In addition to these changes within AI, real-time AI (RTAI) techniques must be interfaced with lower level real-time systems technology to produce a functioning, reliable and carefully analyzable system. Integrating RTAI and low level real-time systems is quite a challenge because these RTAI applications are operating in non-deterministic environments, there is missing or noisy information, objectives may change dynamically, partial solution are sometimes acceptable so that trade off between the quality of the solution and time need to derive it can be made. It is too easy to synthesize the general principles and ideas from these experiments, as sufficient evaluative data is not available. Competing software architectures for real-time AI include production rule architectures, blackboard architectures, and process trellis architecture. The process trellis architecture, used in the medical domain, is a highly static approach while the other two are much more dynamic. The trellis architecture has potential to provide static real-time guarantees for those applications characterized by enough time to completely compute results from a set of inputs arrive. This approach is suitable from for certain types if real-time AI monitoring systems, but its generality for complex real-time AI systems has not been demonstrated. VIII. CURRENT RESEARCH IN REAL-TIME OPERATING SYSTEMS: Identifying that new approaches are needed which challenge the basic assumptions made by timesharing operating systems and developing those new paradigms. Developing real-time synchronization primitives such as those that support priority inheritance, developing support for fault tolerance. Retaining significant strongly emphasizing predictability not only of the kernel but also providing good support for application level predictability. There are several research projects that tell about the scope and research that is ongoing. Some of them are MARS, SPRING, MARUTI, ARTS, CHAOS, HARTOS, DARK.MARS kernel offers support for controlling a distributed application based entirely on time events from the environment. The Maruti system


focuses on support for dynamic on-line guarantees that tasks make their deadlines and on fault tolerance. Maruti has been designed in a top down approach with a goal of demonstrating principles. As such, the actual implementation is high level and runs on top of UNIX. IX. CONCLUSIONS: The scientific research community many grand challenge problems whose solution requires high performance computing. This list includes scientific problems in earth and space sciences, vision and robotics etc. These are of course very important problems. One important grand challenge that is missing is the need for developing science and technology of real-time computing .So many large, complex future applications depend on real-time systems that is critical to focus efforts on its -development.

X. BIBLIOGRAPHY: [1] OPERATING SYSTEMS.--By Galvin. [2] REAL-TIME SYSTEMS.--By Jane W. S. Liu. [3] RTOS PROGRAMMING.--By I Kolnick. [4] http:\\ [5] http:\\ [6] http:\\


Sign up to vote on this title
UsefulNot useful