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

Introduction
Approach to the design of RT computer systems is no different in outline that required for any computer-based system/most engineering systems Two main sections designing of RTS Planning phase Developing phase

Planning phase
Fig. 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 stage Inputs: high-level specifications Outputs: global data structures, and high-level software architecture Excessive liaison between H/W and S/W designers is needed Ex.: 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 stage Detailed 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:

its 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 data b. Operations on the object are performed by sending a message to the object requesting the operation c. Is an instance of a class d. Class defines a common structure that describes all members of the class e. 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 Interactive Amount 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 made Ex.: 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 operations Modern S/W development methodologies: Address the above problem Assumption: Proceeding step-by-step through specification, preliminary design, and detailed design is possible

Specification Document
Consider 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 document Hot-Air Blower Specification Version 3.1 Date 10 January 1992 Introduction System comprises a set of hot-air blowers arranged along a conveyor belt Several 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 used Sampling interval may be changed but will not be < 40 ms Controller parameters are to be expressed to the user in standard analog form i.e., proportional gain, integral action time, and derivative action time Set 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 input Operator 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.n 3. Integral action = nn.nn 4. Derivative action = nn.nn 5. Sampling interval = nn 6. Management information 7. Accept entries Select 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 information In selection of item 6 of the operator menu a management summary the previous 24 hours will be given

of the performance of the plant over

Summary : provides the following information: i. Average error in deg.C in 24 hour period ii. Average heat demand %FS in 24 hour period iii. For each 15 minute period: a. Average demanded temperature b. Average error c. 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 Design
2 Types: Hardware design and Software design

Hardware Design
There 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 evaluated Some 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 performance 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 S/W design, option 1, assumed to be chosen

 Software Design
Examining 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 module Constraint 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 approach

Fig. shows the standard programming approach modules ( which can be considered as the procedures or subroutines) of a single main program Fig. 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 modules For system to work clock/calendar module and any one of the other modules must complete their operations within 20 ms If t1, t2, t3, t4, and t5 are the maximum computation times for the modules 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 line Single program approach:

Can be used for simple, small systems It leads to a clear and easily understandable design with a minimum of H/W and S/W Usually easy to test As 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 used It 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 approach
Design and programming of large RTS will ease if FBA is extended into multiple partitions to allow the concept of many active tasks At 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 available In practice, with the some understanding of the computer system, it should not be difficult to implement the primitive instructions Underlying the implementation of primitive instructions will be an eventual reliance on the system H/W Ex.: In a common memory system some form of arbiter will exist to provide for mutual exclusion in accessing an individual memory location

Foreground/Background System
Advantages: 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 programs Partitioning into FBS usually requires support of a RTOS Ex.: DECs RT/11 system, MS-DOS - Supports FBS, if hardware supports interrupts

PC in usually FBS is used Application 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 background Interrupt-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 approach There 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 difficult Ex.: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 unsolved Assumption: 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 task Ex.: 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 task Foreground and background modules are still linked through the data structure as shown by Fig. The linkage occurs because they share data variables Ex.: 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 verified Ex.: 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 area Let the controller operates with p1=10, p2=5, and p3=6 Let new values for controller planned are p1=20, p2=2, p3=0.5 As 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 quickly

Let 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 controller Example 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