Real time systems are required to compute and deliver correct results within a specified period oftime acceptable to requirements of respectiveapplication !!!

Real time systems may involve serious risk, in the event of late results !!!

Specified response times/latencies for physical systemtasks/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) ofPhysical 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 Real-time ???

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 flight 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 ofsuch 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 caninvolve 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 ‘fly 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 soft-ware, 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.ff

A real-time task can be realized as either a periodic (clock-driven) 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

VxWorksVRTX

QNXLynxOS

FreeRTOSMicroC/OS

RTAIXENOMAIRTLINUX

Task Instances – periodic or aperiodic/sporadicA 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 o ers little except regular, periodic ffexecution. 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 o er all the facilities. We ffhave 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 real-time 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 achievethis, real-time systems frequently rely on hardware interrupt signals to evoke the necessary service routines. The executive software will convert interrupt signals into software flags or software signals so that processing can be more e ectively scheduled, in an ffappropriate 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 fixed 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 1–100 ms

Desktop Linux 1–10 ms

RTE/RTOS 10s of microseconds

Real-time Linux/Xenomai 10s of microseconds