REAL-TIME One form of a special-purpose operating system is
real time system. Real time systems are defined as
OPERATING
SYSTEMS
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:
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 real-
time operating system. One of the main differences
between real-time operating systems and general-
purpose operating systems is the ability to
guarantee a worst-case latency. On a general-
purpose 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:
1

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.
• 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:-
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
2
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 real-
time 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.
• Aperiodic: An aperiodic task has a deadline by
which it must finish or start, or it may have a
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 clock
Controlled
Sensors
process
Trigger
generator
Actuators Execution
Display operation
3
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 real-
time 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.
4
 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 run-
time 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 inter-
task 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 RT-
POSIX, 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 real-
time 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:-
5
 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
6
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:\\www.hcs.bu.edu
[5] http:\\www.cs.bu.edu
[6] http:\\beta.ece.vcsb.edu