Unit: 7: Design of RTS – General Introduction: Introduction, Specification Documentation, Preliminary design, Single-program approach, Foreground/background, Multi-tasking approach, Mutual exclusion, Monitors 6 Hours

Design of software – 3 approaches Single task Foreground/background; and Multi-tasking

IntroductionApproach to the design – of RT computer systems – is no different in outline – that required for any

computer-based system/most engineering systemsTwo main sections – designing of RTS

Planning phase Developing phase

Planning phaseFig. Shows the planning phase

Concerned with the interpreting user:- Requirements to produce a detailed specification of the system – to be to developed- Outline plan of the resources – people, time, equipment, costs – required to carryout the

development Preliminary decisions – regarding – division functions between hardware and software – will be made Preliminary assessment – of the type of computer structure – like, single central computer, a hierarchical

system, or a distributed system – will be made Specification document (Requirement document) – is the outcome of this stage Some refer – specification requirement document - as well as – specification document and requirements

document – it is simpler to consider that documents produced by the user or customer describe requirements, and documents produced by the supplier or designer given the specifications

Cannot be emphasized – too strongly – that the specification document – for both the H/W and S/W - in this phase – must be complete, detailed, and unambiguous

Large proportion of errors – which appear in the final system can be traced back to – unclear, ambiguous, or faulty specification documents

Strong temptation – to say – ‘It can be decided later’(i.e., deciding later can result in the need to change parts of the system – which have already been designed – such, changes are costly and frequently lead to the introduction of errors

Table : Distribution of errors and cost of correcting errors [DeMacro, 1978]

Development Phase

Preliminary design stage:

Aim: to decompose the system – into a set of specific sub-tasks – which can be considered separately. Also, referred to as – high-level design stageInputs: high-level specificationsOutputs: global data structures, and high-level software architectureExcessive liaison between H/W and S/W designers – is neededEx.: There will be a need to revise – the decisions on the type of the computer structure proposed and if, for ex.: a distributed system is to be used, to decide on the number of processors, communication systems (bandwidth, type), etc.,Control strategy – will need reviewing – including consideration of the control algorithm to be used. At the end – a review of both the H/W and S/W designs – should be carried out

Detailed design stageDetailed design 2 stages: Decomposition into modules and Module internal design

Stages of detailed design stages: H/W design and S/W design H/W design:First stage: Involves questions on the board structure of the system – Are separate boards going to be used for analog inputs and digital inputs or are all inputs going to be

concentrated on one board? can the processor and memory be located on one board? what type of bus structure should be used?

Second stage: Design of the boards Involves the design of the boards

S/W design:First stage: Involves identifying activities – which are related Heuristic rules: have been developed – to aid the designer – with decisions on division into modules

(Pressman, 1992) Various heuristics – are given differing – emphasis in the different design methodologies Brief descriptions of general methodologies:i. Functional decomposition:

- Top-down approach, which has been advocated by Wirth and others- Lead to module subdivision based on a separation into functions- Each module – performs a specific function-

ii. Information hiding: - Parnas, 1972a, b – had been with this- Strongly against – functional decomposition approach - Strongly against – module division based on hiding – as much as possible of the information – used by a

module within the module

iii. Object oriented:- it’s the division of the system – into entities which contain both data and the functions – that operate on the

data

- way of achieving – the aims set out by Parnas in his information hiding proposals

Main properties of Objects:a. Encapsulate data and operations that can be performed on that datab. Operations on the object are performed by sending a message to the object requesting the operationc. Is an instance of a classd. Class defines – a common structure that describes all members of the classe. Classes are organized hierarchically – and sub-classes, inherit all the features of the super-ordinate

class

Differences between functional and information hiding approaches:Approaches – above – do not give guidance – on how to decide on boundaries between function modules

or object modules

Commonly used heuristics – for guiding module subdivision: Coupling and cohesion:

Heuristics underlying for data-flow design methodologies:o Maximizing of module cohesion

o Minimizing of coupling between modules

Heuristics and methodologies: developed by o Constantine and Yourdon (1979)

o Myers (1978)

o Stevens et al. (1974)

Partition to minimize interfaces:

Heuristic was proposed by – DeMacro (1978) This heuristic can be combined with data-flow methods Suggests – the transformations indicated on the data-flow diagram – should be grouped so as to

minimize the number of interconnections between the modules

For RTS – additional heuristics are required: One of which is to divide modules – into the following categories: Real-time, hard constraint Real-time, soft constraint InteractiveAmount of software – hard constraint category of – to be to minimized, since this type is the most difficult to

design and test

Major differences in S/W design: Between RT and standard systems - occur in Preliminary design Decomposition into modules

Similarities in S/W design: Between RT and standard systems - occur in Module internal design Testing

From, above point: whole process of specification, design, and construction appears sequential – this is a simplistic view. In practice, top-level design decisions – frequently cannot be made until lower-level design decisions – have been madeEx.: We cannot decide, what type of computer is required (processing power, memory requirements) until either we have coded the software or we have made detailed estimates of the amount of code and the type of computation required.

A control algorithm which requires extensive arithmetic operations on real numbers results in a different computational load from one involving simple logic operationsModern S/W development methodologies: Address the above problemAssumption: Proceeding step-by-step through specification, preliminary design, and detailed design – is possible

Specification DocumentConsider a system – comprising several of the hot-air blowers

Assumption: Planning phase has been completed and a specification document has been prepared

Shortened version of the specification documentHot-Air Blower Specification

Version 3.1 Date 10 January 1992

IntroductionSystem comprises – a set of hot-air blowers – arranged along a conveyor beltSeveral different configurations – may be used with a minimum of 6 blowers and a maximum of 12

Plant interface Input from plant

o Outlet temperature: analog signal, range: 0-10 V, corresponding to 20 deg.C to 64 deg.C, linear

relationship Output to plant

o Heater control: analog signal, range 0 to -10 V, corresponding to full heat (0 V) to no heat (-10 V),

linear relationship

Control PID controller with the sampling interval – 40 ms is usedSampling interval – may be changed – but will not be < 40 msController parameters – are to be expressed to the user – in standard analog form – i.e., proportional gain, integral action time, and derivative action timeSet point is to be entered – from the keyboard

Operator communication Display

Operator display is as shown below: Set temperature : nn.n deg.C Date: dd/mm/yyyy Actual temperature : nn.n deg.C Time:hh/mm Error : nn.n deg.C Heater output : nn% FS Sampling Interval : nn ms

Controller settings Proportional gain : nn.n Integral gain : nn.nn s Derivative gain: nn.nn s Display values : will be updated every 5 s

Operator inputOperator can at any time – enter a new set point or new values for the control parameters. This is done by

pressing the ‘ESC’ key For response to ‘ESC’ key: a menu shown below will come – on the bottom of the display screen

1. Set temperature = nn.n 2. Proportinal gain = nn.n3. Integral action = nn.nn 4. Derivative action = nn.nn5. Sampling interval = nn 6. Management information

7. Accept entriesSelect menu number to change

For response – to the number entered – present value of the item selected will be deleted from the display. Cursor positioned ready – for the input of a new value

Process will be repeated until item 7 – accept entries – is selected at which time the bottom part of the display will be cleared and the new values shows in the top part of the display

5.0 Management informationIn selection of item 6 of the operator menu – a management summary of the performance of the plant over

the previous 24 hours will be given Summary : provides the following information:

i. Average error in deg.C in 24 hour periodii. Average heat demand %FS in 24 hour periodiii. For each 15 minute period:

a. Average demanded temperatureb. Average errorc. Average heat demand

iv. Date and time of output

6.0 General information There will be a requirement for a maximum of 12 control units Single display and entry keyboard – which can be switched between the units – is adequate

Preliminary Design2 Types: Hardware design and Software design

Hardware DesignThere are many different possibilities – for H/W structure

Obvious arguments: Single computer with multi-channel ADC and DAC boards Separate general purpose computers on each unit Separate computer-based microcontrollers on each unit linked to a single general purpose

computer

Each of these configurations – need to be analyzed and evaluatedSome points to consider are:

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 12 units 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 performanceAnalysis – must include consideration of development costs, performance operating and maintenance

costs. It should also include, consideration of reliability and safetyTo provide a basis for – consideration of the widest range of approaches to S/W design, option 1, assumed to be chosen

Software DesignExamining the specifications shown – S/W has to perform several different functions:

DDC for temperature control Operator display

Operator input Provision of management information System start-up and shut-downs, and Clock/calendar function

Fig. shows – various functions and type of time constraint

Control module: Has a hard constraint

It must run every 40 ms. In practice, these constraints – can be relaxed a little to, say, 40 ms +- 1ms with an average value over 1 minute of, say 40 ms +-0.5 ms

In general, sampling time can be specified as Ts+-es with an average value, over time Ts of Ts+-es. Requirement – may also be relaxed – to allow – for ex.: one sample in 100 to be missed These constraints – will form part of the test specification

Clock/calendar module:Must run for every 20 ms – in order not to miss a clock pulse

This constraint, can be changed into a soft constraint – is some additional H/W is provided in the form of a counter which can be read and reset by the this moduleConstraint could now be, say, an average response time of 1 s with a maximum interval between reading the counter of 5 s

Operator display module:Has the hard constraint

An update interval of 5 s is given

Common sense suggests that – this is unnecessary and an average time of 5 s should be adequate; however, a maximum time would also have to be specified, say 10 s

Operator input module and management information logs:Soft constraints – are adequate, would have to be decided upon and agreed with the customer - Should form part of the specification in the requirements document

Start-up module:Does not have to operate – in real time Can be considered – as a standard interactive module

There are several different – activities – which can be – divided into sub-problems - Sub-problems will have to share – certain amount of information - How above thing is done, and how the next stages of the design proceed will depend upon the general approach to the implementation

There are 3 possibilities: Single program Foreground/background system, and Multi-tasking

Single program approachFig. shows the standard programming approach – modules ( which can be considered as the procedures or

subroutines) of a single main programFig. shows the flowchart of such a program This structure is easy to program. It imposes the most severe of the time constraints

Ex.: the requirements that the clock/calendar module must run every 20 ms – on all of the modulesFor system to work – clock/calendar module and any one of the other modules must complete their

operations within 20 msIf t1, t2, t3, t4, and t5 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 t1 + max(t2, t3, t4, t5) < 20 ms

Note: Control module provides the control computations for each of the 12 units Values of t1, t2, t3, t4, and t5 must include the time taken to carry out the tests required and t1 must also

include the time taken to read the clock input lineSingle program approach:

Can be used for simple, small systemsIt leads to a clear and easily understandable design – with a minimum of H/W and S/W

Usually easy to testAs the size of the problem increases – there is a tendency at the detailed design stage – to split modules

not because they are functionally different but simply to enable them to complete within the required time interval

Above ex. in – management output requirement makes it unsuitable for the single-program approach; if that requirement is removed the approach could be usedIt may – require, however – the division of the display update module into 3 modules:

display date and time display process values display controller parameters

Multi-tasking approachDesign and programming of large RTS –will ease if – FBA is extended into multiple partitions – to allow the

concept of many active tasksAt preliminary design stage: each activity is considered as a separate task

Implication of this approach: each task may be carried out in parallel there is no assumption made at the preliminary design stage – as how many processors will be used

in the system

Implementation of a multi-tasking system – requires the ability to –

create separate tasks schedule running of the tasks, usually on a priority basis share data between tasks synchronize tasks with each other and with external events prevent tasks corrupting each other, and control the starting and stopping of tasks

Above actions – to perform - the facilities are provided by RTOS or a combination of RTOS, and a RT programming language

Examples with illustrate the problems that arise with multi-tasking and why RTS require special language and OS facilities

For simplicity, assumption: One CPU is used and that the use of this CPU is time shared between the tasks A number of primitive instructions exist

Primitive instructions: instructions which are part of a programming language or the operating system and their implementation and correctness is guaranteed by the system

User for concern is that – an accurate description of the syntax and semantics is made availableIn practice, with the some understanding of the computer system, it should not be difficult to implement the

primitive instructionsUnderlying the implementation – of primitive instructions – will be an eventual reliance on the system H/WEx.: In a common memory system some form of arbiter will exist to provide for mutual exclusion in accessing an individual memory location

Foreground/Background SystemAdvantages:

less module interaction less tight time constraints

if the modules with hard time constraints can be separated form, and handled independently of , the modules with soft time constraints or no time constraints

Foreground modules: modules with hard time constraints Are also called as ‘tasks’ Have the higher priority than background tasks Must be able to interrupt a background task Written as an interrupt routine

Ex.: interrupt-driven routines Background modules:

Modules with soft time or no time constraints Written as a standard program

Ex.: application programsPartitioning into FBS – usually requires support of a RTOSEx.: DECs RT/11 system, MS-DOS - Supports FBS, if hardware supports interrupts

PC – in usually FBS – is usedApplication programs – like, a word processor, a spreadsheet, graphics package, or some program which

been written by the user, in high-level language - are run in backgroundInterrupt-driven routines – like, clock, keyboard input, the disk controller, and possibly some memory-resident programs – run in background. Fig. shows the structure of the FBS approachThere is very clear separation between – foreground and background systems

Requirement for foreground part to work: t1+t2 < 20 ms

Requirement for background part to work: max (t3,t4,t5) < 10 s display module runs on average every 5 s, and operator input responds in < 10 s

Even though – time constrains been relaxed – measurements to e made in order to check the performance are more complicated than in the single-program case, so – evaluation of the performance of the system has been made more difficultEx.:Foreground/Background system using Modula-2

Since, low-level facilities of the language are directly used – so, problems of data sharing and mutual exclusion remain unsolvedAssumption: all the variables – required by the controller – are stored in common storage and hence, are accessible at any time to either the operator task or the control taskEx.: as above – control task, which is entered on an interrupt, can return only to a specific named task and hence there can be only one background taskForeground and background modules – are still linked through the data structure as shown by Fig.

The linkage occurs because – they share data variablesEx.: in the hot-air blower system, the control task, the display task, and the operator input task all require access to the controller parameters

In the single program (single tasking) – there was no difficulty in controlling access to the shared variable since, only one module(task) was active at any one time

But, in FBS, tasks may operate in parallel – i.e., one foreground and one background module – may be active at the same time

‘active’ – means not mean ‘running’, since, one CPU is being used, only one task can be run at any instant – but ‘active’ means – ‘both the foreground and background tasks may have the potential to run at the time same of’Ex.: taken above – variables can be shared between the control, display, and operator input modules – without any difficulty since, only one module writes to any given variable

Operator input module writes the controller parameters and set point variables.Clock/calendar module writes to the date and time variables

Control module writes to the plant data variables (error and output temperature)Input from the operator must be buffered and only transferred to the shared storage when it has been verifiedEx.: Buffering of parameter input data

To understand the reasons of buffering:Let us consider – what happens – when a new value was entered – it stores directly in the shared data areaLet the controller – operates with p1=10, p2=5, and p3=6Let new values for controller planned are p1=20, p2=2, p3=0.5As soon as the new value of p1 is entered the controller begins to operate with p1=20, p2=5, and p3=6

with – which is neither old values nor new values. This also, may not matter operator enter the data quicklyLet us consider the situation – what happens if, after entering p1, the telephone rings or the operator is

interrupted in some other way and consequently forgets to complete the entry? Then, the plant could be left running with a completely incorrect and possibly unstable controllerExample above is not strictly correct – and safe – since, an interrupt could occur between transferring x to p1, y to p2, in which case the incorrect controller would be used

For simple feedback controller – it may be of little effect – but, for it may cause serious effect, if the change were to a sequence of operations. Possibly dangerous consequences for it may lead – and also, for large systems – it may cause much problem

Transfer of data between foreground and background tasks: Sequence of lines: p1:= x; p2:= y; p3:= z; form the critical section – which should be an indivisible action. Simple way of doing this is: InhibitInterrupts; p1:= x; p2:= y; p3:= z; EnableInterrupts;

Undesirable _ for several separate modules – each ot have access to the basic H/W of the machine and each to be able to change the status of the interrupts

Modules concerned with the details of the computer H/W – are difficult to design, code and test, and have a higher error rate than the average module – limiting such, number of modules is a good practice

Transfer should be take place – ideally – at a time suitable for the controller module – which imposes that the operator module and the controller module should be synchronized or should rendezvous