View
213
Download
0
Category
Preview:
Citation preview
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
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, ¶m); 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
Recommended