Page 9 - DCAP608_REAL TIME SYSTEMS

Real Time Systems

Notes Thus, multi-tasking, although generally seen as an implementation strategy, can also offer an
intellectual tool to aid the designer.
Run-time scheduling: The separation of an activity into several distinct, semi-autonomous tasks
leads to the question of task sequencing. In traditional DP applications the sequence planning is
largely done by the programmer. Functions are called in the correct order and the activity is
completed. But for real-time systems this is only half the story. The major part of sequencing
takes place at run-time, and is accomplished by the operating system through the action of the
scheduler. It is as if the sequencing decisions have been deferred, it is a kind of ‘late sequencing’,
to draw a parallel with the established term ‘late binding’, used with regard to code linking. This
is perhaps the most interesting feature of real-time systems. The manner in which the various
activities are evoked in the correct order is quite different from that of a traditional DP system
which normally relies on the arrival of data records from an input file to sequence the functions,
and so it is predetermined and fixed.

Task Prepare a chart to show major parts of sequencing.
Unpredictability: Being event driven, real-time systems are at the mercy of unpredictable changes
in their environments. It is just not feasible to anticipate with 100 per cent certainty all the
permutations of situations which may arise. In my experience, the worst offenders are actually
the human users, who seem totally unable, or unwilling, to understand what the designer
intended. Any choice offered by a menu or sequence of YES/NO alternatives will soon reveal
unexpected outcomes during field trials. The exact ordering or sequencing of all the functions
which deals with these interactions has to be decided at run-time by the scheduler, giving much
more flexibility in response. Considerable effort is now put into extensive simulation testing in
order to trap as many of these bugs as possible, even before the designs are released.

Notes Life-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 ‘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 software, with all the extra checking, documentation and acceptance trials required,
may raise the cost beyond normal commercial projects, of similar code complexity, by an
astonishing factor of 30. Most real-time applications are intended to run continuously, or
at least until the user turns off the power. Telephone exchanges, for example, contain
millions of lines of real-time code, and are expected to run non-stop for 20 years.

The increasing use of embedded microprocessors within medical monitoring and life-
support equipment, such as radiological scanners and drug infusion pumps, makes
consideration of software reliability and systems integrity even more urgent. Some research
effort has been expended in devising a method to formally prove correct a computer
program, much in the same way that mathematicians deal with algebraic proofs. So far,
the products resulting from this work have not generated much commercial interest.

4 LOVELY PROFESSIONAL UNIVERSITY