Lecture 12:Real-time system design

Burns/Wellings ch 17 + ch 2

Realtime Systems SMD138

To put the topics of previous lectures into a contextTo show how how the overall design of a real-time system can be deduced from external factorsTo illustrate the purpose of real-time system design methodsTo give a translation of Burns/Wellings ch 17 into C/POSIX/QNX form

Goal

Our running example will be a pump control system for a mineThe responsibilities of the control system are:• To start and stop a water pump depending on water

level• To monitor whether the pump is working• To monitor and log various environmental values• To temporarily disable the pump if the methane

gas level is too high• To provide an operator interface to the system

A mine pump example

System diagram

Pump Controlcomputer

Log

Terminal

Water flowWaterhigh

Waterlow CO

levelCH4level

Airflow

1

2

3

4

Interrupt-generating sensors:• High and low water level switchesSensors that must be sampled:• Water and air flow sensors• Gas level sensors... plus operator input from the terminal keyboard

Available sensors

We have already seen the merits of letting the number of independent input sources determine an initial task structureFurthermore, the nature of an input source (sampled/interrupting) will suggest what kind of task that should be considered:• The sampling gas level and air/water flow sensors

must be handled by periodic tasks• The water level sensors can preferably be handled

by event-driven, sporadic tasksAnd we know periodic = driven by timer events...

Implied design

Having ideas about the sensor drivers is just a startHow do we come up with a design for the whole system?This question is what design models and methods try to addressExamples in the real-time domain:• UML models / ROPES design method• MASCOT3• HRT-HOOD (ch 17)• etc (see sect. 2.4)We will only sketch the general ideas behind all these, using the example from ch. 17 as an illustration

Overall design

Differentiate between • logical design (behavior if hardware is no constraint) • physical design (when physical resources like cpu

speed are taken into account)Based on object-oriented system decompositionPopular design methods tend to introduce a plethora of object variants with respect to concurrency• Active objects (periodic, sporadic, arbitrary, ...)• Passive objects (protected, unprotected, ...)We will be more principled, and treat all final objects according to the reactive concurrent object pattern

Real-time system design

5

6

7

8

Initially:• The system is one big unknown object with just a

main methodAgenda:• Repeatedly decompose each object into finer

constituent parts (also objects), with more refined interfaces

Result:• A system where every object can be directly

implemented in your programming language

Progress

Initial view – the big one-method object• What can be done to this object? It can be started,

that’s what the main method doesFirst-level decomposition – the functional requirements suggest four distinct subsystems:• pump controller subsystem• environment monitor subsystem• operator console subsystem• data logger subsystem

The mine control example

Graphically

Mine control system

main

Pump controller Environm. monitor

Operator console Data logger

checkSafe

notSafesafe

chec

kSafe

reqS

tatu

sse

tPum

p

alarm

logXX

waterHighwaterLowgetWaterFlow

key

print

getGasXXlevel

writeFile

setMotor

waterHigh, waterLow (pump controller) - sensor interrupt routinesnotSafe, safe (pump controller) – called by environment to indicate when it is safe to operate the pumpreqStatus, setPump (pump controller) – called by console in response to operator commandscheckSafe (environment monitor) – called by pump controller before starting motoralarm (console) – called by anybody to wants to bring the operator’s attention to some conditionlogXX (logger) – called by controller and environment subsystems when state changes

Methods

9

10

11

12

Controller decomposition

Pump controller

Motor controller

Water flow sensor

Water level sensor

highEventlowEvent

notSafesafe

reqStatussetPump

alarm

logWF

alarm logMotor

alarm

logWL

setM

otor

waterHighwaterLow

getWaterFlow

reqStatus

checkSafe

Monitor decomposition

Environment monitor

checkSafe

CH4 status

Air flow sensor

CH4 sensor

CO sensor

writealarm

logCH4

alarm

logAF

alarm

logCO

getCH4level

getAirFlowgetCOlevel

void *motor_ctrl(void *arg) {int motor_status = OFF;int motor_condition = DISABLED;while (1) { int rcv_id = MsgReceive(motor_chan, &msg, sizeof(msg), NULL); switch (msg.tag) {

case REQ_STATUS: ... break; case MOTOR_NOTSAFE: ... break;

case MOTOR_SAFE: if (motor_status == ON) { setMotor (START); // out8(MOTOR_CTRL, START);

logger_logMotor(MOTOR_STARTED); } motor_condition = ENABLED; logger_logMotor(MOTOR_SAFE);

Coding the motor object 1

case MOTOR_SETPUMP: if (msg.value == ON) {

if (motor_status == OFF) if (motor_condition == DISABLED || ch4_checkStatus() != MOTOR_SAFE) console_alarm(PUMP_NOT_SAFE); else { setMotor(START); // out8(MOTOR_CTRL, START);

logger_logMotor(MOTOR_STARTED); } } else {

if (motor_status == ON) if (motor_condition == ENABLED) {

setMotor(STOP); // out8(MOTOR_CTRL, STOP); logger_logMotor(MOTOR_STOPPED);

} }

motor_status = msg.value; break;

Coding the motor object 2

13

14

15

16

int motor_setpump(int val) {struct Msg msg = {SETPUMP, val};MsgSend(motor_conn, &msg, sizeof(msg), NULL, 0);

}int motor_reqStatus() {

int status; struct Msg msg = {REG_STATUS, 0};MsgSend(motor_conn, &msg, sizeof(msg), &status, sizeof(status));return status;

}...

int motor_chan, motor_conn;

void motor_init() {pthread_t;motor_chan = ChannelCreate(0); /* gets priority inheritance by default */motor_conn = ConnectAttach(0, 0, motor_chan, 0, 0);pthread_create(&t, NULL, motor, NULL);

}

Coding the motor object 3

void *wflow(void *arg) { struct sigevent ev; timer_t tmr; struct itimerspec spec = {{1,0}, {1,0}}; int chan = ChannelCreate(0); int conn = ConnectAttach(0, 0, chan, 0, 0); int flow = 0; int current, last = OFF; SIGEV_PULSE_INIT(&ev, 10, conn, 0, 0) timer_create(CLOCK_REALTIME, &ev, &tmr); timer_settime(tmr, 0, &spec, NULL); out8(WFLOW_CTRL, ENABLE); while (1) { MsgReceivePulse(chan, NULL, 0, NULL);

...

Coding the water flow object 1

Coding the water flow object 2

.... current = motor_reqStatus(); flow = in8(WFLOW_STATUS) & ACTIVE_MASK; if ((current==ON && last==ON && !flow) || (current==OFF && last==OFF && flow)) { console_alarm(PUMP_FAULT);

} last = current; logger_logWFlow(flow);

}}

Coding the water flow object 3

void wflow_init() { struct sched_param param; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED); param.sched_priority = WFLOW_PRIO; pthread_attr_setschedparam(&attr, &param); pthread_create(&wflow_thread, &attr, wflow, NULL);}

17

18

19

20

Water level sensors:• Sensor events should trigger the pump on or off• Deadlines determine the actual maximum and

minimum water levels that may occur• Physics of the pump and the mine dimensions

suggest deadlines of 200 ms for the water level sensors• Further physical constraints imply a minimum

distance of 6 s between two water level events

Timing requirements

Water flow sensor• Actually reads accumulated water quantity• Water flow determined by comparing two

consecutive readings• Pump physics suggests placing readings one second

apart (less frequent, and possible alarms might be useless when pump is already burnt)• Required flow accuracy of 4% gives a deadline for

each reading of 40 ms

Timing requirements

Gas level sensors:• Based on a form of A/D conversion that must be

initiated before each reading• Conversion takes 40 ms• Mining legislation dictate that gas levels are

sampled 10 times a second (100 ms period)• Each period activity must take care of reading the

previous conversion as well as initiating a new one• That gives a deadline of 100-40 ms = 60 ms

Timing requirements

Extra requirement for the methane sensor:• When gas level reaches a critical level, the pump

motor must be switched off to avoid the risk for explosions• Again, physical factors like pump placement

determine the deadline – 200 ms in our example• However, consider the following scenario:

Timing requirements

worst case: T + T + D

sample sampleread read

TD

We only know thatreading will be donebefore the deadline,nothing more!

21

22

23

24

That is:• For the methane gas sensor task with period T and

deadline D we have that 2T+D < 200 ms• Setting T = 100 ms and D = 60 ms will not work• For this reason, we specify tighter parameters for

the methane task: T = 80 ms and D = 30 ms• Note that there is still room for a 40 ms

conversion time within each period

Timing requirements

Deadline-monotonic priorities

Task Type Period Deadline PriorityCH4 sensor periodic 80 30 10CO sensor periodic 100 60 8Air-flow sensor periodic 100 100 7Water-flow sensor periodic 1000 40 9Water-level sensor sporadic ≥6000 200 6CH4 status reactive - - inheritedMotor controller reactive - - inherited

Due to deadlines being separate from periods, the simple utilization-based test for fixed priorities cannot be usedAnother problem is the presence of a sporadic task, and blocking during synchronous message sendsHence, the more complex analyses from ch 13 that compute blocking-times (B) and response-times (R) must be performed (left out here)As input we assume the existence of worst-case execution times (C) for all tasks

Analysis

Deadlines are met!

Blocking times

Example of analysis result

Task Type T D C B R

CH4 sensor periodic 80 30 12 3 25

CO sensor periodic 100 60 10 3 47

Air-flow sensor periodic 100 100 10 3 57

Water-flow sensor periodic 1000 40 10 3 35

Water-level sensor sporadic 6000 200 20 3 79

25

26

27

28

Real-time system design is a complex issue; object-oriented design methods can helpThe extra dimensions of threads vs. objects must be handled appropriately; a systematic use of concurrent reactive objects avoids the tensionMost methods distinguish between objects that are either active (spontaneously executing, driven by timers or interrupts) or passive (only run when called by others)Our concurrent objects serve both purposesDecoupling between threads by means of non-parking communication methods is essential to analysability

Wrapping up

29