Real time systems are required to compute and

deliver correct results within a specified period of

time acceptable to requirements of respective
application !!!
Real time systems may involve serious risk, in
the event of late results !!!

Specified response times/latencies for physical system

tasks/computing tasks
Event driven(asynchronous and
synchronous) and strict scheduling
Software(application and system s/w) tightly coupled with
hardware
Dedicated functionality of the custom computing system
Multi-tasking(processes/threads/tasking) of
Physical system/computing tasks
System intended to run continuously
Critical applications

'Fly by wire' for Aircraft

Medical monitoring and life-support equipment
Battle field targeting / laser guns /range finders
Automotive safety systems
Industrial control systems
Timing - nanoseconds/microseconds/milliseconds

How to get a feel of Realtime ???

The speed of light is
3 10 power of 8m/sec
Time taken =
distance/speed
If the item being surveyed
is only 50 m distant, the
time of ight will be
reduced to 325 ns !!!!!
For 40km, it is
130usecs !!!
.

A scenario could be to generate digital pulses to control

angular position of motor shafts :
- say, 2ms pulse will mean neutral position
- say, 1.5ms pulse will mean -45 degrees
- say, 2.5ms pulse will mean +45 degrees
- in certain cases, must be refreshed every
20 ms with an accuracy of 10s of
Microseconds
- Visualize several such motors being
Refreshed, periodically !!!
- may be used for Industrial or Robotic control

A scenario could be to respond to crash sensors of an

airbag safety subsystem of an automotive system - there
is no use of the result(s), if dead-lines are breached
would there be any use of
such results ??
What are the expected results ??
What about the timing requirements of such results ??

Automated chemical plant may need temperature control at 250

degrees centigrade, with a predetermined, strict time interval of 30
milliseconds !!!
In this case, the timing response must be with respect to real-time
clock mechanism of the automated chemical plant !!!
Sensors are involved and actuators are involved !!!
Custom computers are involved !!!
Custom operating system is involved !!!
Custom applications are involved !!!
There may be several such physical tasks/activities to managed
and several such real-time dead-lines/requirements !!!!

Real time systems can be small and large ?

Small say, networking equipment
Large say, Aircraft control system
Clear your misconceptions in a way,
embedded computing just means custom
computing may be small, but not always !!!!

Event/Interrupt driven, the next characteristic of real-time

systems is their involvement with events. These often
manifest themselves in terms of interrupt signals arising from
the arrival of data at an input port, or the ticking of a hardware
clock, or an error status alarm. Because real-time systems are
often closely coupled with special equipment (a situation that
is termed embedded) the programmer has also to gain a
reasonable understanding of the hardware if the project is to
be a thorough success.
Once again, however, the demarcation between traditional
data processing and real-time systems is not easy to draw
because event-driven GUI interfaces are so widely used
within all desktop applications.
However, context is the key to distinguishing the two
requirements !!!

Multi-tasking
Real-time systems are often expected to involve multi-tasking.
In this situation, several physical processes or tasks cooperate
to carry out the overall job. When considering this arrangement,
there should be a clear distinction drawn between the static
aggregation of groups of instructions into functions for
compilation, and the dynamic sequencing of tasks which takes
place at run-time.
For this, a full multi-tasking is not always necessary, but it can
be positively advantageous to programmers in simplifying their
work. It is also widely accepted that many computer systems
have become so complex that it has become necessary to
decompose them into components to help people to understand
and build them. In the traditional data processing.
These physical tasks may need to be mapped to computing
tasks and Implemented !!!

Critical code
Although not always the case, real-time systems can
involve serious risk. A failure to run correctly may result in
death or at least injury to the user and others.
Such applications are becoming more and more common, with
the aircraft and automobile industries converting their products
to y by wire processor technology. This removes from the
driver/pilot all direct, muscular control over the physical
mechanism, relying entirely on digital control systems to carry
out their commands.
The burden of developing real-time, life-critical software, with all the extra checking, documentation and
acceptance trials required, may raise the cost beyond normal
commercial projects, of similar code complexity, by a large
factor.
Most real-time applications are intended to run continuously, or
at least until the user turns o the power.

A real-time task can be realized as either a periodic (clockdriven) or an aperiodic/sporadic (event-driven) entity .
Real-time tasks typically communicate using an
asynchronous model, via shared data areas.
The use of concurrency raises a number of other design
issues: race-conditions mutual exclusion, deadlock, live-lock,
starvation and many more such problems.
How are these taken care ???

RTE/RTOS
VxWorks
VRTX
QNX
LynxOS
FreeRTOS
MicroC/OS
RTAI
XENOMAI
RTLINUX

Task Instances periodic or aperiodic/sporadic

A temperature or pressure or level sensing task is periodic !!!
Triggering an actuator task, when one of the sensed parameters
has crossed the threshold, is a good example for
aperiodic/sporadic !!!

A periodic task may need to started after 1000msecs of start of the

system and may have the following characteristics :
- period
- 50msecs
- processing time - 8 msecs
- r. dead-line
- 50 msecs
Most periodic tasks are static however, some sophisticated
systems may need additional periodic tasks, during run-time,
dynamically a good example, is air-traffic control !!!

This diagram is not exhaustive ??

If the tasking involves periodic scanning, it is convenient to use a

cyclic executive to host the application code.
Such a primitive scheduling facility oers little except regular, periodic
execution. Cyclic executive is the best example for a pure
co-operativescheduling !!!
If further run-time facilities such as memory management and
semaphore handling are required it is common to acquire a special
RTE/RTOS such as VXWorks or FreeRTOS. A very good example for
a fully preemptive system!!!
We are yet to study and work with such systems !!!
A full operating system such as Linux can oer all the facilities. We
have studied about the services offered by such a system and
familiar with the working of such a system
There are hybrid implementations, which provide well partitioned realtime and non-real time services !!! Xenomai is a good example for this
there are several others as well !!

Despite other features, the principal role of a real-time system is to

respond to asynchronous, predictable/unpredictable events in an
orderly and timely fashion. Often the application's requirements will
specify explicitly the maximum response latency times which are
acceptable.
Implied timing constraints which the system has to satisfy in order
to successfully interact with connected equipment. To achieve
this, real-time systems frequently rely on hardware interrupt signals
to evoke the necessary service routines. The executive software
will convert interrupt signals into software ags or software signals
so that processing can be more eectively scheduled, in an
appropriate sequence, with the mainline application code.

Thus, although some small amount of processing may take place

within the ISRs, this must be reduced to a minimum because the
ISRs are usually beyond the control of the scheduler, their relative
priorities being permanently xed by the hardware platform.
Some increase in latency, or acceptable loss of responsiveness, is
unavoidably incurred in order to retain control of the overall
scheduling.
How the interrupt service routines communicate with the main
tasks is another of the features that distinguishes well developed
real-time executives, from typical operating systems !!!

 Hardware/device initialization
Use of memory management H/W for intertask security/isolation
Loading task code into memory, RAM or Flash
Task initialization and management
Task scheduling
Real-time clock/timer maintenance
Critical resource protection
Intertask communication
Intertask synchronization
I/O and drivers management
Multiple interrupt servicing
deterministic memory management
+ additional, related features, if any !!!

Task Response times

Standard o/s

1100 ms

Desktop Linux

110 ms

RTE/RTOS

10s of microseconds

Real-time Linux
/Xenomai

10s of microseconds