Real Time Systems (15EC743)

Module 5 Real time systems(15EC743) Design of RTS

MODULE – 5
Design of RTS – General Introduction: Introduction, Specification Document, Preliminary Design,
Single-Program Approach, Foreground/Background System.
RTS Development Methodologies: Introduction, Yourdon Methodology, Ward and Mellor
Method, Hately and Pirbhai Method.

DESIGN OF RTS

5.1 GENERAL INTRODUCTION

The approach to the design of real-time computer systems is no different in outline from
that required for any computer-based system or indeed most engineering systems. The work can be
divided into two main sections:
• The planning phase; and
• The development phase.

It is concerned with interpreting use requirements to produce a detailed specification of the system
to be developed and an outline plan of the resources - people, time, equipment, costs - required to
carry out the development. At this stage preliminary decisions regarding the division of functions
between hardware and software will be made. A preliminary assessment of the type of computer
structure - a single central computer, a hierarchical system, or a distributed system - will also be
made. The outcome of this stage is a specification or requirements document. (The terminology
used in books on software engineering can be confusing; some refer to a specification requirement
document as well as to specification document and requirements document. It clearer and simpler
to consider that documents produced by the user or customer describe requirements, and
documents produced by the supplier or designer give the specifications.) It cannot be emphasized
too strongly that the specification document for both the hardware and software which results from
this phase must be complete, detailed and unambiguous. General experience has shown that a large
proportion of errors which appear in the final system can be traced back to unclear, ambiguous or
fault) specification documents. There is always a strong temptation to say 'It can be decided later';
MITMysore | Dept of Electronics and Communication Engineering
deciding it later can result in the need to change parts of the system which have already been

Dept. of ECE, GSSSIETW, Mysuru Page 95

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
designed. Such changes are costly and frequently lead to the introduction of errors. This shows the
distribution of errors and cost of rectifying them (the figures are taken from DeMarco, 1978). The
detailed design is usually broken down into two stages:
 Decomposition into modules; and
 Module internal design.
For real-time systems additional heuristics are required, one of which is to divide modules into the
following categories:
• Real-time, hard constraint;
• Real-time, soft constraint; and
• Interactive.
The arguments given in Chapter 1 regarding the verification and validation of different types of
program suggest a rule that aims to minimize the amount of software that falls into the hard
constraint category since this type is the most difficult to design and test.

5.2 SPECIFICATION DOCUMENTATION

To provide an example for the design procedures being described we shall consider a system
comprising several of the hot-air blowers described. It is assumed that the planning phase has been
completed and a specification document has been prepared. A PID controller with a sampling
interval of 40ms is to be used. The sampling interval may be changed, but will not be less than
40ms. The controller parameters are to be expressed to the user in standard analog form that is
proportional gain, integral action time and derivative action time. The set point is to be entered
from the keyboard. The controller parameters are to be variable and are to be entered from the
keyboard.

5.3 PRELIMINARY DESIGN

5.3.1 Hardware design:
There are many different possibilities for the hardware structure. Obvious arrangements are:
1. Single computer with multi-channel ADC and DAC boards.
2. Separate general purpose computers on each unit.
Separate computer-based microcontrollers on each unit linked to a single general. Purpose
MITMysore | Dept of Electronics and Communication Engineering
computer
Each of these configurations needs to be analyzed and evaluated. Some points to consider are:
Dept. of ECE, GSSSIETW, Mysuru Page 96
 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
Option 1: given that the specification calls for the system to be able to run with a sample interval
for the control loop of 40 ms, can this be met with 12units sharing a single processor?

Option 2: is putting a processor that includes a display and keyboard on each unit an expensive
solution? Will communication between processors be required? (Almost certainly the answer to
this is yes; operators and managers will not want to have to use separate displays and keyboards.)

Option 3: what sort of communication linkage should be used? A shared high speed bus? A local-
area network? Where should the microcontrollers be located? At each blower unit or together in a
central location? Each option needs careful analysis and evaluation in terms of cost and
performance. The analysis must include consideration of development costs, performance
operating and maintenance costs. It should also include consideration of reliability and safety. To
provide a basis for consideration of the widest range of approaches to software design we will
assume that option 1 above is chosen.

5.3.2 Software design:

Examining the specification shows that the software has to perform several different functions:
1. DDC for temperature control;
2. Operator display;
3. Operator input;
4. Provision of management information;
5. System start-up and shut-down; and
6. Clock/calendar function.

The various functions and type of time constraint are shown in Figure. The control module has a
hard constraint in that it must run every 40 ms. In practice this constraint may be relaxed a little to,
say, 40 ms ± 1 ms with an average value over 1 minute of, say, 40 ms ± 0.5 ms. In general the
sampling time can be specified as Ts ± es with an average value, over time T, of Ts ± ea. The
MITMysore | Dept of may
requirement Electronics and Communication
also be relaxed Engineering
to allow, for example, one sample in 100 to be missed. These
constraints will form part of the test specification. The clock/calendar module must run every 20
Dept. of ECE, GSSSIETW, Mysuru Page 97
 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
ms in order not to miss a clock pulse. The operator display, as specified, has a hard constraint in
that an update interval of 5 seconds is given. Common sense suggests that this is unnecessary and
an average time of 5 seconds should be adequate; however, a maximum time would also have to be
specified, say10 seconds.. These would have to be decided upon and agreed with the customer.
They should form part of the specification in the requirements document. The start-up module does
not have to operate in real time and hence can be considered as a standard interactive module. The
sub-problems will have to share a certain amount of information and how this is done and how the
next stages of the design proceed will depend upon the general approach to the implementation.

There are three possibilities:

• Single program;
• Foreground/background system; and
• Multi-tasking.

Figure 5.1: Basic software modules.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 98

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
5.4 SINGLE- PROGRAM APPROACH
Using the standard programming approach the modules shown in Figure are treated as
procedures or subroutines of a single main program. The flow chart of such a program is illustrated
in Figure. This structure is easy to program; however, it imposes the most severe of the time
constraints- the requirement that the clock/calendar module must run every 20 ms - on all of the
modules. For the system to work the clock/calendar module and anyone of the other modules must
complete their operations within 20 ms. If fl, fz, f3, f4 and fs are the maximum computation times
for the module's clock/calendar, control, operator display, operator input and management output
respectively, then a requirement for the system to work can be expressed as fl + max (tz, f3, f4, fs)
< 20 ms.

The single-program approach can be used for simple, small systems and it lead to a clear and
easily understandable design, with a minimum of both hardware and software. Such systems are
usually easy to test.. In the above example the management output requirement makes it unsuitable
for the single-program approach; if that requirement is removed the approach could be used. It
may, however, require the division of the display update module into three modules: display date
and time; display process values; and display controller parameters.

MITMysore | Dept of Electronics and Communication Engineering

Figure 5.2: Single Program Approach

Dept. of ECE, GSSSIETW, Mysuru Page 99

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
5.5 FOREGROUND/BACKGROUND SYSTEMS
These are obvious advantages - less module interaction, less tight time constraints if the
modules with hard time constraints can be separated from, and handled independently of, the
modules with soft time constraints or no time constraints. The modules with hard time constraints
are run in the so-called 'foreground' and the modules with soft constraints (or no constraints) are
run in the 'background'. The foreground modules, or 'tasks' as they are usually termed, have a
higher priority than the background tasks and a foreground task must be able to interrupts
background task. The partitioning into foreground and background usually requires the support of
a real-time operating system, for example the Digital Equipment Corporation's RT/11 system. It is
possible, however, to adapt many standard operating systems, for example MS-DOS, to give
simple foreground/background operation if the hardware supports interrupts.

The foreground task is written as an interrupt routine and the background task as a standard
program. If you use a PC you are in practice using a foreground/background system. The
application program that you are using (a word processor, a spreadsheet, graphics package or some
program which you have written yourself in a high-level language) is, if we use the terminology
given above, running in the background. In the foreground are several interrupt-driven routines -
the clock, the keyboard input, the disk controller - and possibly some memory-resident programs
which you have installed - a disk caching program or an extended memory manager. The
terminology foreground and background can be confusing; literature concerned with non-real-time
software uses foreground to refer to the application software and background to refer to interrupt
routines that are hidden from the user.

MITMysore | Dept of Electronics and Communication Engineering

Figure 5.3: Software module for foreground/background system.

Dept. of ECE, GSSSIETW, Mysuru Page 100

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
RTS DEVELOPMENT METHODOLOGIES

5.6 INTRODUCTION
The production of robust, reliable software of high quality for real-time computer control
applications is a difficult task which requires the application of engineering methods. During the
last ten years increasing emphasis has been placed on formalizing the specification, design and
construction of such software, and several methodologies are now extant. All of the methodologies
address the problem in three distinct phases. The production of a logical or abstract model - the
process of specification; the development of an implementation model for a virtual machine from
the logical model - the process of design; and the construction of software for the virtual machine
together with the implementation of the virtual machine on a physical system - the process of
implementation. These phases, although differently named, correspond to the phases of
development generally recognized in software engineering texts. Abstract model: the equivalent of
a requirements specification, it is the result of the requirements capture and analysis phase.
Implementation model: this is the equivalent of the system design; it is the product of the design
stages - architectural design and the detail design.

Although there is a logical progression from abstract model to implementation model to

implemented software, and although three separate and distinct artifacts abstract model,
implementation model, and deliverable system - are produced, the phases overlap in time. The
phases overlap because complex systems are best handled by a hierarchical approach:
determination of the detail of the lower levels in the hierarchy of the logical model must be based
on knowledge of higher - level design decisions, and similarly the lower-level design decisions
must be based on the higher- level implementation decisions. Another way of expressing this is to
say that the higher-level design decisions determine the requirements specification for the lower
levels in the system.

5.7 YOURDON METHODOLOGY

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 101

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS

Figure 5.4: Software modeling

The Yourdon methodology has been developed over many years. It is a structured methodology
based on using data-flow modeling techniques and junctional decomposition. It supports
development from the initial analysis stage through to implementation. Both Ward and Mellor
(1986) and Hatley and Pirbhai (1988) have introduced extensions to support the use of the
Yourdon approach for the development of real-time systems and the key ideas of their
methodologies are:
1. Subdivision of system into activities;
2. Hierarchical structure;
3. Separation of data and control flows;
MITMysore | Dept
4. of Electronics and
No early Communication
commitment Engineering
to a particular technology; and
5. Traceability between specification, design and implementation.

Dept. of ECE, GSSSIETW, Mysuru Page 102

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS

5.8 REQUIREMENT DEFINITION FOR DRYING OVEN

Components are dried by being passed through an oven. The components are placed on a
conveyor belt which conveys them slowly through the drying oven. The oven is heated by three
gas-fired burners placed at intervals along the oven. The temperature in each of the areas heated by
the burners is monitored and controlled. An operator console unit enables the operator to monitor
and control the operation of the unit. The system is presently controlled by a hard wired control
system. The requirement is to replace this hard wired control system with a computer-based
system. The new computer-based system is also to provide links with the management computer
over a communication link.

Figure 5.5: General arrangement of drying oven.

Input/output
The inputs come from a plant interface cubicle and from the operator. There will need to be inputs
obtained from the communication interface.
Plant Inputs
A thermocouple is provided in each heater area - the heater areas are pre-heat, drying, and cooling.
The inputs are available as voltages in the range 0 to 10 volts at pins 1 to 9 on socket j22 in the
interface cubicle.The conveyor speed is measured by a pulse counting system and is available on
pin 3 at socket j23 in the interface cubicle. It is referred to as con-speed. There are three
interlocked
MITMysore | Dept ofsafety guards on
Electronics andtheCommunication
conveyor systemEngineering
and these are in-guard, out-guard, and drop-
guard. Signals from these guards are provided on pins 4, 5, 6 of socket j23. These signals are set at

Dept. of ECE, GSSSIETW, Mysuru Page 103

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
logic HIGH to indicate that the guards are locked in place. A conveyor-halted signal is provided on
pin I of socket j23. This signal is logic HIGH when the conveyor is running.
Plant Outputs
Heater Control: each of the three heaters has a control unit. The input to the control unit is a
voltage in the range 0 to 10 volts which corresponds to no heat output to maximum heat output.
Conveyor Start-up: a signal convey-start is output to the conveyor motor control unit.
Guard Locks: asserting the guard-lock line, pin 8 on j10 , causes the guards to be locked in
position and turns on the red indicator light on the outside of the unit.

Operator Inputs
The operator sends the following command inputs: Start, Stop, Reset, Re-start, and Pause. The
operator can also adjust the desired set point for each area of the dryer.
Operator Outputs
The operator VDU displays the temperature in each area, the conveyor belt speed, and the alarm
status. It should also display the current date and time and the last operator command issued.

5.9 WARD AND MELLOR METHOD

The outline of the Ward and Mellor method is shown in Figure. The starring point is to
build, from the analysis of the requirements, a software model representing the requiremel1ls in
terms of the abstract entities. This model is called the essential model. It is in two parts: an
environmental model which describes the relationship of the system being modeled with its
environment; and the behavioral model which describes the internal structure of the system. The
second stage the design stage - is to derive from the essential model an implementation model
which defines how the system is implemented on a particular technology and shows the allocation
of parts of the system to processors, the subdivision of activities allocated to each processor into
tasks, and the structure of the code for each task. The essential model represents what the system is
required to do; the implementation model shows how the system will do what has to be done. The
implementation model provides the design from which the implementers of the physical system
can work. Correct use of the method results in documentation that provides traceability from the
physical
MITMysore | Deptsystem to the abstract
of Electronics andspecification
Communicationmodel. Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 104

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS

Figure 5.6: Outline of abstract of modeling approach Ward and Mellor.

5.10 HATELY AND PIRBHAI METHOD

As might be expected the general approach of the Hatley and Pirbhai methodology is very close to
that of Ward and Mellor. There are some differences in terminology which are summarized in
Table below

MITMysore | Dept of Electronics and Communication Engineering

Table 5.1: Differences in terminology

Dept. of ECE, GSSSIETW, Mysuru Page 105

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
Separate diagrams are used for data and control;
• only one CSPEC can appear at any given CFD level; and
• all data f10ws and control f10ws are shown with single arrow heads;

Figure 5.7: Structure of requirement model.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 106

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS

Figure 5.8: Hately and Pirbhai notation.

5.11 COMMENTS ON THE YOURDON METHODOLOGY

Both methodologies - Ward and Mellor and Hatley and Pirbhai - are simple to learn and
have been widely used. They are founded on the well-established structured methods developed by
the| Yourdon
MITMysore Dept of organization
Electronicsand
andhence over the years Engineering
Communication a lot of experience in using the techniques has
been gained. For serious use on large scale systems they both require the support of CASE tools.

Dept. of ECE, GSSSIETW, Mysuru Page 107

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS
The labour involved in checking the models by hand is such that short cuts are likely to be taken
and mistakes are bound to occur. It can be argued that the methods are really only a set of
procedures for documenting a specification and a design and to some extent this is true.

The analysis procedures are minimal and adequate checking for consistency can be
performed only with the support of a CASE tool. However, the methodologies are still useful in
that the procedures they recommend provide a sensible way of preparing both a specification and a
design in that they encourage the development of hierarchical, modular structures. the two, the
Hatley and Pirbhai method is the more structured and formalized in its approach. Its diagrams are
less cluttered than those of the Ward and Mellor method and, once the separation is understood,
are easier to follow. Many CASE tools provide alternative displays which allow a choice of either
separate diagrams or a combined diagram with switching between the two forms. The weakness of
both methods lies in the allocation of processors and tasks. The suggestion that one allocates
activities to processors and then subdivides the activities into tasks allocated to each processor
appears at first sight a sensible way to proceed. However, when it is tried one soon realizes that the
information required to do this is not available.

MITMysore | Dept of Electronics and Communication Engineering

Dept. of ECE, GSSSIETW, Mysuru Page 108

 Real Time Systems (15EC743)
Module 5 Real time systems(15EC743) Design of RTS

Figure 5.9: The structure of architectural model.

Recommended book for reading:

nd
1. Real –Time Computer control –An Introduction, Stuart Bennet, 2 Edn. Pearson
Education 2005.

2. Real-Time Systems Design and Analysis, Phillip. A. Laplante, Second Edition, PHI,
MITMysore | Dept of Electronics and Communication Engineering
2005.

Dept. of ECE, GSSSIETW, Mysuru Page 109