Real time operating-systems

A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM

requirements of the system and ensure
that the system performance is both
1. Introduction correct and timely. There are three
types of time constraints:

Timeliness is the single
most important aspect of a real -time  Hard: A late response is incor
rect and implies a system failure.
system. These systems respond to a
An example of such a system is
series of external inputs, which arrive of medical equipment monitoring
in an unpredictable fashion. The real- vital functions of a human body,
time systems process these inputs, take where a late response would be
appropriate decis ions and also generate considered as a failure.
output necessary to control the
peripherals connected to them. As  Soft: Timeliness requirements
defined by Donald Gillies "A real-time are defined by using an average
system is one in which the correctness respons e time. If a single
of the computations not only depends computation is late, it is not
upon the logical correctness of the usually significant, although
computation but also upon the time in repeated late computation can
result in system failures. An
which the result is produced. If the
example of such a system
timing constraints are not met, system includes airlines reservation
failure is said to have occurred." systems.

 Firm: This is a combination of
It is essential that the
both hard and soft t imeliness
timing constraints of the system are requirements. The computation
guaranteed to be met. Guaranteeing has a shorter soft requirement
timing behaviour requires that the and a longer hard requirement.
system be predictable. For example, a patient ventilator
must mechanically ventilate the
patient a certain amount in a
given time period. A few
The design of a real -time seconds' delay in the initiation of
system must specify the timing

SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 1


breath is allowed, but not more
than that.
Most real -time systems
interface with and control hardware
directly. The software for such systems
One need to distinguish is mostly custom -developed. Real
between on -line systems such as an -time Applications can be either
airline reservation system, which embedded applications or non
operates in real-time but with much less -embedded (desktop) applications. Real
severe timeliness constraints than, say, -time systems often do not have
a missile control system or a telephone standard peripherals associated with a
switch. An interactive system with desktop computer, namely the
better response time is not a real-time keyboard, mouse or conventional
system. These types of systems are display monitors. In most instances,
often referred to as soft real time real-time systems have a customized
systems. In a soft real -time system version of these devices.
(such as the airline reservation
system) late data is still good dat a.
However, for hard real -time systems, The following table
late data is bad data. In this paper we compares some of the key features of
concentrate on the hard and firm real- real -time software systems with other
time systems only. conventional software systems.



Feature Sequential Concurrent Real Time
Programming Programming Programming
Predetermined Multiple sequential Usually composed
order programs executing
Execution of concurrent
in parallel
programs

Numeric Independent of Generally Dependent on
Results program dependent on program execution
execution speed program execution speed
speed

Examples Accounting, UNIX operating Air flight controller
payroll system



1.1 Real-time Programs:
The Computational Model

A simple real -time
program can be defined as a program P
that receives an event from a sensor
every T units of time and in the worst
case, an event requires C units of
computation time.

Assume that the processing
of each event must always be completed
before the arrival of the next event (i.e.,
when there is no buffering). Let the
deadline for completing the
computation be D. If D < C, the
deadline cannot be met. If T < D, the
program must still process each event in
a time O/ T, if no events are to be lost.
Thus the deadline is effectively
bounded by T and we need to handle
those cases where C O/ D O/T.



as well as DMA cycle stealing are
often problematic when
2. Design issue of Real determining process execution
Time Systems timing [4].

 An operating system must have a
Real-time systems are predictable behavior in all
defined as those systems in which the situations. Often the common-
correctness of the system depends not purpose operating systems, like
only on the logical result of UNIX, are too large and complex,
computation, but also on the time at and they have too much
which the results are produced [17]. A unpredictability. Thus, a special
common misconception is to consider, microkernel operating systems
that real-time computing is equivalent to like the Chorus microkernel [9]
fast computing. In traditional non-real- have been designed for real-time
time computer systems, the performance purposes.
goal is throughput: as many tasks should
be processed as possible in given time
Also traditional
period. Real-time systems have a
programming concepts and languages
different goal to meet: as many tasks as
are often not good for real-time
possible should be executed so, that they
programming. No language construct
will complete and produce results before
should take arbitrary long to execute,
their time limit expires. In other words,
and all synchronization, communication,
the behavior of real-time system must be
or device accessing should be
predictable [16] in all situations.
expressible through time-bounded
constructs [19]. However, despite all
these real-time requirements could be
To achieve predictability, solved, a human factor - the real-time
all components of the real-time system programmer - can always cause
must be time bounded. A predictability unpredictability to the system. To assist
of the system depends on many different the programming process, numerous
aspects. methods have been produced for real-
time system design, specification,
verification, and debugging [5].
 The computer hardware must not
introduce unpredictable delays
into program execution. For
example, caching and swapping



Typically, a real-time 1. Absolute consistency
system consists of controlling system between the state of the environment
and a controlled system. The controlled and the controlling system. The
system can be viewed as the controlling system's view from the
environment with which the computer environment must be temporally
interacts. The typical real-time system consistent, it must not be too old.
gather information from the various
sensors, process information and
produce results. The environment for 2. Relative consistency
real-time system may be highly in among the data used to derive other
deterministic. Events may have data. Sometimes, the data items depend
unpredictable starting time, duration and on each other. If a real-time system uses
frequency. However, real-time system all dependent values, they must be
must react to all of these events within temporally consistent to each other.
prespecific time and produce adequate
reaction.
There are several
possibilities to maintain temporal
To guarantee, that a real- consistency. The state of the
time system has always a correct view environment is often scanned in
of its environment, a consistency must periodical basis and an image of the
be maintained between them. The environment is maintained in the
consistency is time-based. The controlling system. A timestamp
controlling system must scan its methodology is often used to figure out
environment fast enough to keep track validity of the system's image of the
changes in the system. The adequate environment.
fastness depends on application. For
example, sensing a temperature needs
often slower tempo than sensing a
A typical real-time system
moving object.
consists of several tasks, which must be
executed in simultaneous manner. Each
task has a value which is gained to the
The need to maintain system if a computations finishes in
consistency between the environment specific time. Each task has a deadline,
and the controlling system leads to the which indicates a time limit, when a
notion of temporal consistency. result of the computing
Temporal consistency has two
components [12]:



becomes useless, ie. gains sight of the scanning device. If the
zero or negative value to the system. object is not recognized, it can be
Furthermore, a task may have some rejected or rescanned later. Thus, an
value after the deadline has been operation loses its value after a certain
expired. time period, but no harm will occur due
to failure. A typical example of soft
deadline is a combined operation
The deadlines have been sequence. The whole sequence has a
divided into three types: hard, soft and firm deadline, but if some of the
firm deadlines. The hard deadline components of the sequence miss their
means, that a task may cause very high deadlines, the overall sequence might
negative value to the system, if the still be able to make its deadline.
computation is not completed before
deadline. Opposite to this, in a soft
deadline, a computation has the As a summary, the timing
decreasing value after the deadline, and requirements for real-time systems can
the value may become zero at later time. be expressed as following constraints to
In the middle of these extremes, a firm the processing [5]:
deadline is defined: a task loses its value
after deadline, but no negative
consequence will occur. Figure 1 plots 1. Response time, deadline:
the value versus time behavior for the system must respond to the
different deadline types. A real-time environment within a specified time
system must guarantee, that all hard after input (or stimuli) is recognized.
deadlines and as many as possible of
other deadlines are met.
2. Validity of data: in some
cases, the validity of the input or output
Examples of deadline types is a function of time. That is, some
are quite intuitive. A typical example of stimulus and the corresponding response
hard deadline can be found from the become obsolete with time, and the time
system controlling the nuclear power interval for which data is valid must be
plant: adding coolant to the reactor must accounted in processing requirements.
be done before temperature gets too
high. A typical example for firm
deadline can be found from the industry
3. Periodic execution: in
automation. A real-time system attempts
many control systems, sensors collect
to recognize a moving object. An object
data at predetermined time intervals.
can be scanned only, when it is in the



real-time behavior is often essential
when designing a safety critical system.
4. Coordinating inputs and
outputs: in some applications, input data
from various sensors must be
synchronized. Otherwise, decisions
would be made based on inconsistent
information.

An example of real-time 3. Scheduling
system is simplified unmanned vehicle
system (SUVS) [20]. The SUVS
controls a vehicle with no assistance To support timeliness in a
from a human driver. It periodically real-time system, a special real-time task
receives data from sensors such as the scheduling methods have been
speedometer, temperature sensor, and introduced. Traditional real-time
direction sensor. It controls the vehicle research has been concerned to uni
by generating appropriate signals to processor scheduling. As a complexity
actuators, such as the accelerator, brake and scale of real-time system grows, the
and steering wheel. processing power of real-time system is
increased by adding new processors or
by distribution. These issues introduce
Decisions are made based several new concepts to scheduling
on the current inputs from the sensors research, numerous schemes have been
and the current status of the road and the introduced for multiprocessor and
vehicle. Decisions must be made within distributed scheduling. In this section,
a specified time. The events can occur we discuss two main principles for real-
very unexpectedly. Let's think about a time scheduling, a scheduling paradigm
scenario, where an obstacle suddenly and a priority inversion problem.
falls into the road. The braking and
steering decisions must be done within a
short time period to avoid crashing. 3.1 Scheduling paradigms
These decisions must also be
synchronized and the status of the road
and other traffic must be taken into
account. Thus, most of tasks in SUVS The simplest real-time
have a hard deadline. This is typical in scheduling method is not to schedule at
many safety critical systems [6, 7]. A all. This method sounds dummy, but in
many real-time systems, only one task



exists. A common example is a typical
programmable logic. Programmable
logics are widely used in the industry Depending on particular
automation. A programmable logic's system's behavior, the different
program is executed periodically. scheduling paradigms have been
During every execution, the program introduced [13]:
reads all inputs, makes simple
calculations and sets appropriate
outputs. Same program is executed at 1. Static table-driven
every time, and a state of the system approaches: These perform static
depends on internal variables set in the schedulability analysis and the resulting
previous runs. However, interrupts can schedule (table) is used at run time to
be used to catch asynchronous events, decide, when a task must begin
but an advanced processing must be execution. This is a highly predictable
made within standard run periods. approach, but it is very inflexible,
because a table must always be
reconstructed, when a new task is added
In more advanced real-time to the system. Due to predictability, this
systems, several simultaneous tasks can is often used when absolute hard
be executed. Every task may have deadlines are needed.
different timing constraints and they
may have a periodic or an aperiodic
execution behavior. The periodic 2. Static priority-driven
behavior mens, that a task must be pre-emptive approaches: These perform
executed within prespecific time static schedulability analysis, but unlike
intervals. When a task has an aperiodic in the previous approach, no explicit
behavior, it will execute, when an schedule is constructed. At run time,
external stimulus occurs. In a typical tasks are executed "highest priority
real-time systems, both type of tasks first". This is a quite commonly used
exists. However, all aperiodic tasks can approach in concrete real-time systems.
always be transformed to periodic. A
task structure of the system describes,
when the tasks can be started. Many 3. Dynamic planning-based
systems have a static task structure, approaches: Unlike the previous two
where tasks are installed during system approaches, feasibility is checked at run
startup and no new tasks can be started time. A dynamically arriving task is
afterwards. In dynamic task structure, accepted for execution only if it is found
tasks can be started and ended during feasible.
system uptime.



4. Dynamic best effort runnable. When the higher priority task
approaches: Here no feasibility checking becomes eligible, it is always started to
is done. The system tries to do its best to run. The task with a lower priority is
meet deadlines, but a task may be pre-empted, the task is released from a
aborted during its execution. processor in favor to higher priority
task.

Unfortunately the most
scheduling problems are NP-complete. A priority inversion
However, many good heuristic problem arises, when a lower priority
approaches have been presented. Thus, task has reserved a shared resource. If a
numerous algorithms have been higher priority task needs the same
introduced to support these scheduling resource, the resource cannot be
paradigms. Algorithms are either based acquired, because it is already reserved
on the single scheduling paradigm or by another task. This forces the higher
they can spread over several paradigms. priority task to block, which may lead to
These algorithms include least common the missing of its deadline. Also the
multiply (LCM) method, earliest deadlock situation is possible. Figure 2
deadline first (EDF) method, rate illustrates an execution sequence, where
monotonic (RM), and many others. A a priority inversion occurs. A task T3
survey of scheduling methods is found executes and reserves a resource. A
in [13]. higher priority task T1 pre-empts task
T3, but wants to allocate a resource
3.2 Priority inversion reserver by task T3. Then, task T2
problem becomes eligible and blocks task T3.
Because the task T3 cannot be executed,
In a multitasking the resource remains reserved
environment, the shared resources are suppressing task T1 to run. Thus, the
often used. The usage of these resources task T1 misses its deadline due to
must be protected with a well-known resource conflict.
methods, like semaphores and mutexes.
However, a priority inversion problem
[14] arises, if these methods are used in Several approaches have
real-time system with a pre-emptive been introduced to rectify the priority
priority-driven scheduling. In priority- inversion problem. The use of priority
driven scheduling, the eligible task with inversion protocols is one approach. The
a highest priority is always executed. basic idea of priority inversion protocols
The task is eligible, when it is not is that when a task blocks one or more
waiting for any event, so when it is higher priority tasks, it ignores its



original priority assignment and Early systems consisted of a small
executes its critical section at the highest number of processors performing
priority level of all the tasks it blocks. statically determined set of duties.
After exiting its critical section, the task Future systems will be much larger,
returns its original priority. Figure 3 more widely distributed, and will be
illustrates, how a priority inversion expected to perform a constantly
problem presented in the figure 2 can be changing set of duties in dynamic
solved with a priority inheritance environments. This also sets more
protocol. Again, the task T3 executes requirements for future real-time
and reserves a resource, and a higher operating systems.
priority task T1 wants to allocate that
resource. As a result of priority
inheritance, the task T3 inherits priority Real-time operating
of T1 and executes its critical section in systems need to be significantly
that priority. Thus, the task T2 cannot different from those in traditional time-
pre-empt task T3 and the resource is sharing system architectures because
released after a critical section is they have to be able to handle the
finished. Now the task T1 can acquire added complexity of time constraints,
resource and it is completed to its flexible operations, predictability and
deadline. dependability.

4. Real-time operating
system
5. Real-time operating
system requirements and
Real-time operating basic abstractions
systems are an integral part of real-time
systems. Examples of these systems are
process control systems, flight control
systems and all other systems that In real-time systems,
require result of computation to be operating system plays a considerable
produced in certain time schedule. role. The most important task of it is to
Nowadays real-time computing schedule system execution (processes)
systems are applied to more dynamic and make sure that all requirements that
and complex missions, and their the system is meeting are filled. In this
timing constraints and characteristics chapter we will introduce some general
are becoming more difficult to manage. terms used in operating systems and
real-time systems:


5.1 General terms
Real-time operating One common denominator
systems require certain tasks to be in real-time systems seems to be that all
computed within strict time constraints. designers want their real-time systems
Time constraints define deadline, the to be predictable. Predictability
response time in which the computation means, that it should be possible to
has to be completed. There are three show, demonstrate, or prove that
different kinds of deadlines; hard, soft requirements are met subject to any
and firm. Hard deadline means that if assumptions made, for example,
the computation is not completed before concerning failures and workloads. In
deadline, it may cause a total system other words predictability is always
failure. Soft deadline means that subject to the underlying assumptions
computing has a decreasing value made.[2]
after the deadline but not a zero or
negative number. If firm deadline is
missed, the value of task is lost but For static real-time
no negative consequence is occurred. systems in deterministic, stable
environments we can easily predict the
overall system performance over large
Fault tolerance, the time frames as well as predict the
capability of a computer, subsystem performance of some individual task.
or program to withstand the effects of In more complicated, changing,
internal faults, is also a common nondeterministic environment , for
requirement for real-time operating example a future system of robots co-
systems. operating on Mars, it is far more
complicated task to predict in design
phase, how the system is actually going
to act in its real environment. In
Several real-time systems operating system level system must be
collect data from their environment at designed to be so simple, that it is
predetermined time intervals which possible to predict worst-case situations
requires periodic execution. in execution.

5.3 Temporal consistency

5.2 Predictability


The controlling system
must scan its environment fast
enough to maintain a correct view of
it. If that is taken care of, it can be
said that consistency is achieved
between real-time system and its
environment. This leads to notion of
temporal consistency [6], which has two
components;

 Absolute
consistency, which is
achieved between the
controlling system and
the state of the
environment if the systems
view of the environment is
temporally consistent.

 Relative
consistency, which is
achieved if data items
dependent of each other
in the system are
temporally consistent to
each other.

 Temporal
consistency is usually
maintained by periodically
scanning the environment
and maintain an image of
the environment in the
controlling system.



operating system are also usually
6. Real-time operating based on microkernel architecture and
must support these main functional areas
system structure [1]:

When systems have  process management and
become larger and unwieldy, they are synchronization
difficult to comprehend, develop and  memory management
maintain.  inter process communication
 I/O

A recent trend in
operating system development consists
of structuring the operating system as
3.2 Structure of the
a modular set of system servers
CHORUS system
which sit on top of a minimal kernel,
microkernel, rather than using the
traditional monolithic kernel, in
which all functionality of the system Microkernel based
is provided. Figure 3.1 presents operating systems are like stripped down
monolithic kernel of the UNIX system timesharing operating systems with only
[7]. minimal functionality. In figure 3.2
microkernel of the CHORUS system is
presented [7].
3.1 Monolithic kernel of
the UNIX system
In real-time operating
systems microkernels are used to
achieve strict timing requirements. The
The idea in microkernel-
structure of system must be compact,
based operating systems are that
all unnecessary functionality must be
those functions which are needed
stripped down and execution time of a
universally, by every component of the
single task must be minimized. In real-
system, form the microkernel. Other
time operating systems reaction time
functionality is handled outside the
kernel and they can be specially
tailored for each application.
Notations close and open system are
also used for this purpose. Real-time



has to be short and the scheduling They can be divided into 3
algorithm to be executed must be fast categories :
and very simple.

 small proprietary kernels
6.1 Basic abstractions
Usually current real-time  real-time extensions to commercial
operating systems support following timesharing
basic abstractions with slight operating systems
differences between different systems:
Task : The basic unit of resource  research kernels.
allocation. This includes /actor address
space and access to the system
resources.
Thread : The basic unit of 7.1 Small Proprietary
execution. Usually executed in the Kernels
address space of a single task.
Port : A one-way communication
channel implemented as a message The small, proprietary
queue. kernels are often used for small
embedded systems when very fast and
highly predictable execution must be
Port set : A group of ports. Port guaranteed. The kernels are often
set has usually only one queue. stripped down and optimized to reduce
the run-time overhead caused by the
Message : Collection of data kernel. The usual characteristics of these
objects used in communicating between kernels are [13]:
threads.

 fast context switching.
7. Real Time Operating
System Types  small size and stripped-down
functionality.



 quick response to external applications, such as instrumentation,
interrupts. communication front ends, intelligent
peripherals, and process control. Since
the application are simple, it is relatively
 minimized intervals, easy to determine, that all timing
when interrupts are disabled. constraints are met. As complexity of
the system increases, it becomes more
and more difficult to map all timing,
 fixed or variable
computation time, resource, and value
sized partitions for memory
requirements to a single priority for each
management.
task. In these situations demonstrating
predictability becomes very difficult.
 ability to lock code Because of these reasons, some
and data into memory. researchers believe, that more
sophisticated kernels are needed to
address timing and fault tolerance
 special sequential constraints. Recently there are efforts to
files for data accessing. produce scalable kernels. The smallest
level of support is a microkernel, and the
support can be broaden by demands of
To deal with timing requirements, the
the application. An example of this type
kernel should provide a priority
of kernel is the Chorus microkernel [9],
scheduling mechanism and a bounded
which can be scaled from a simple
execution time for most primitives. For
embedded microkernel to a full
timing purposes, the kernel should
POSIX/UNIX support.
maintain a real-time clock

and provide special alarm and timeout 7.2 Real-time Extensions
services, as well as primitives for delay To Commercial
by a fixed amount of time. In general,
the kernel also performs multitasking Timesharing Operating
and intertask communication and Systems
synchronization via standard well-
known constructs such as mailboxes,
events, signals, and semaphores.
The second approach to the
Additionally, the kernel should support
real-time operating system is the
real-time queuing methods such as
extension of commercial products, like
delivering messages by a priority order.
extending UNIX to RT-UNIX, or
These kernels are suitable for small
POSIX to RT-POSIX. The real-time


versions for commercial operating 7.3 Research Kernels
systems are generally slower and less
predictable than proprietary kernels, but
they have a greater functionality and a
better software development The third category of real-
environments. time operating system is research
kernels. These kernels are used in
research purposes to develop and
demonstrate new features to the real-
However, there are various time operating systems. Trends in the
problems when attempting to convert a current research in real-time operating
non-real-time operating systems to a systems include developing real-time
real-time version [3]. For example, in process models, developing real-time
UNIX interface, problems exist in synchronization primitives, searching
process scheduling. These problems are solutions for timing analysis, developing
due to nature of the nice and set priority support for fault tolerance, investigating
primitives as well as round robin object-oriented approaches, providing
scheduling policy. Furthermore, timer support for multiprocessor as well as
facilities in unix are too coarse, memory distribution, and attempting to formally
management is too complex, and define a microkernel. There are
interprocess communication facilities do numerous research project addressing
not support fast and predictable these issues. A survey of these projects
communication. Also implementation is found in [13].
issues used in the UNIX operating
system restrict its

use for real-time purposes. These issues
include intolerable overhead, non
preemptability of the kernel, and internal
FIFO queues. As a result, extending
commercial timesharing operating
system for real-time purposes is not a
feasible approach, especially when hard
deadlines are needed.



flexible real-time operating system,
including:

 Viewing the execution of a task as
8. Designing a reflective a random process where task
architecture for a real- could be blocked at arbitrary
points during its execution for an
time operating system indefinite time. In critical real-
time environments each task is
well defined and can be analyzed
There are several issues a priori
that has to be taken into account
when designing and building a real-time
operating system; meeting functional,  Assuming that little is known
fault tolerance and timing about the tasks a priori, so that
requirements are complex tasks. One little semantic information
method in building a complex and about them is utilized at run
flexible real-time system is to use the time. In real-time systems, the
notion of reflective architecture [5]. A software should be able to make
system based on reflective use of important semantics
architecture is one that reasons about information about the application
and reflects upon its own current tasks.
state and that of the environment to
determine the right course of action.  Attempt
Several current real-time systems ing to maximize throughput or
contain the same basic paradigms minimize average response time.
found in timesharing operating
systems. They are usually only
stripped down and optimized versions of These metrics are not
time-sharing operating systems. primary metrics for real-time systems.
Although they stress fast mechanisms System could have a good average
such as fast context switching and response time and still miss every
ability to respond to external deadline, resulting a useless system.
interrupts quickly, they retain some
main abstractions of timesharing
systems, which should be taken into In traditional systems
account when designing a complex and computation solves some application
problem such as sorting a file or filtering



important signals from radar returns. In other and to system
reflective system we can consider a modes.
system to have a
 Time requirements
(deadlines, periods
computational part and reflective part.
etc.)
Computational part acts like in the
traditional systems, but reflective part of
the system exposes the system state  Time profiles, such as the
and semantics of the application to worst-case execution times
decide what to do, for example in
filtering process to choose the most
appropriate filter.  Resource needs

 Precedence constraints
5.1 Design issues There
exists also several opposing factors,
that make the design even more  Communication
complex. The desire for predictability requirements
versus the need for flexibility to
handle non-deterministic environments,
failures and system architecture, the  Objectives or goals of the
need for efficient performance and low system
cost versus understandability etc.
Flexible real time system architecture  Consistency and integrity
cannot be based on handcraft constraints
solutions because of their complexity
and requirements. When building a
real-time system based on a reflective  Policies to guide system-
architecture means that first we must wide scheduling
identify reflective information
regarding the system. This information
includes:  Fault tolerance requirements

 Policies to guide tradeoff
 Importance of task, analyses
group of tasks and
how tasks'
importance relates to



 Performance monitoring possible to perform adaptive
information management of redundancy.

Implementation structures in the
When tasks' priorities are
operating system retain this
fixed, a fixed-priority scheduling
information and primitives
mechanism, provided by most real-
allow it to be dynamically
time kernels, works properly. Still
changed. When
many more complex systems require
implementing a real-time
dynamic priorities. Dynamic priorities
operating system based on
can be dynamically calculated for
reflective architecture, we
example with some weighted formula
need to use real-time
that combines different information
programming languages.
e.g. deadline and resource needs.
First we need a high-level
Systems with fixed priorities are not
programming language that
able to handle dynamic priorities
is capable of specifying
properly.
reflective information such
as timing requirements and In order to deal with
the need for guarantees with predictability versus flexibility, there is
respect to these requirements. a need for multilevel, multi-dimensional
An example of this is scheduling algorithms [5]. These
Spring-C, which is used in algorithms explicitly categorize the
Spring -system performance, including when there is
implementation [3]. In system degradation or unexpected
general, this language is C events. Algorithms are multi-
-based programming dimensional, because they have to
language with support for consider all resources needed by a
timing specifications and task, not just CPU time, and they
guarantee semantics. Then must consider precedence constraints
we need a language to and communication requirements.
support system description. They are multi-level algorithms,
That should provide means because tasks are categorized into four
to perform careful, detailed classes; critical (missing the deadline
and accurate timing analysis. causes a total system failure),
Third, we require notation essential (these tasks have hard
for specifying fault-tolerance deadlines, but the tasks are not critical),
requirements on a task-by- soft real-time (task value drop after
task basis, where it is deadline but not to zero or negative
number), and non-real-time (no



deadlines). When task arrives, This paper gives an
scheduling algorithm uses the reflective overview of the real-time system issues.
information about active tasks and The main concept in all real time
creates a full schedule for them and systems is predictability. The
predicts if some of them is going to miss predictability depends on numerous
their deadlines. If deadlines would be different aspects, hardware, operating
missed, error handling can occur before system, programming languages, and
that happens. program design and implementation
methods. The real-time system must also
have a temporally consistent view of the
environment it belongs to. The
consistency can be addressed as terms of
Many real-time systems absolute and relative consistency. The
require strict fault tolerance in order tasks in real-time systems may have
to operate in complex, highly variable arbitrary deadlines. The deadlines have
environment. A three-level framework been divided into three categories,
for defining fault tolerance depending on how the system is affected
requirements is presented. At the if a deadline is missed. These categories
highest level of the framework is the are hard, firm and soft deadlines.
overall design process. That includes
specification of the physical inputs and
outputs from and to the external world, To support timeliness and
first specification of the important predictability, the different scheduling
functional blocks in the system, the methods have been produced for
flow of data and interactions among uniprocessor systems as well as
them, a definition of timing multiprocessor and distributed systems.
requirements (periods, deadlines and Tasks in real-time systems can have
response times), identification of each periodic or aperiodic behavior, and
functions criticality, and specification several scheduling paradigms have been
of mode changes. At the second level of produced to support different system
the framework redundancy of the types. When resources need to be
system is managed. On third level allocated in real-time systems, a priority
of the framework is the actual inversion problem may arise. The
coding of the application modules priority inversion may cause the task to
themselves. These three levels must lose its deadline. Several priority
be consistent with each other. inheritance protocols have been
introduced to solve the priority inversion
9. Conclusion problem.



Real-time operating system Helsinki, Dept. of Computer Science,
is an integral part of real-time system. Helsinki, Finland
Real-time operating system offers tools
to guarantee predictability. The small,
proprietary kernels have been stripped [3] B. Furht, D. Grostick, D. Gloch, G.
out and optimized for real-time Rabbat, J. Parker, and M. Mc Roberts.
purposes. These kernels may be scalable Real-Time Unix Systems Design and
from simple embedded systems to Application Guide. Kluwer Academic
offering full POSIX/UNIX support. Publishers,
Also commercial timesharing operating
systems can be extended to meet the
real-time requirements, but these are not
[4] W. Halang. Implication on suitable
often applicable for real-time
multiprocessor structures and virtual
performance requirements. Also several
storage management when applying a
research kernels were introduced. These
feasible scheduling algorithm , in hard
kernels are used to develop and
real-time environments. Software
demonstrate new real-time system
Practice and Experience, 16(8):761-769.
features.
Real-time database is an
example case of real-time system. It [5] K. Kavi and S. Yang. Real-time
combines database and realtime system design methodologies: An
concepts. These concepts include introduction and a survey. Journal of
handling a database schema, efficient Systems and Software, 18(1):85-99
data management support,
transactionality, failure recovery
mechanisms, data temporality, and real- [6] Mathai Joseph, Real -time Systems:
time access to data. Specification, Verification and Analysis,
Prentice Hall International, London
References
[1] R. Abbott and H. Garcia-Molina.
Scheduling real-time transactions. ACM [7] Bran Selic, Turning Clockwise:
SIGMOD Record, 17(1):71-81 Using UML in the Real -Time Domain,
Communications of the ACM,
[2] P. Elovaara and K. Raatikainen.
Evaluation of concurrency control
algorithms for realtime databases. [8] K. Ramamritham and J. Stankovitc.
Report C-1996-52, University of Scheduling algorithms and operating



system support for real-time systems.
Proceedings of the IEEE, 82(1):55-67,.

[9] K. Ramamritham. Real-time
databases. Distributed and parallel
databases,.

[10] J. Bacon. Concurrent systems.
Addison-Wesley


Real time operating-systems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Real time operating-systems

Similar to Real time operating-systems (20)

Real time operating-systems