CH 13

Realtime Software Design
● Designing embedded software
systems whose behaviour is
subject to timing constraints
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 1

Objectives
● To explain the concept of a realtime system and
why these systems are usually implemented as
concurrent processes
● To describe a design process for realtime
systems
● To explain the role of a realtime executive
● To introduce generic architectures for monitoring
and control and data acquisition systems

Topics covered
● Systems design
● Realtime executives
● Monitoring and control systems
● Data acquisition systems

Realtime systems
● Systems which monitor and control their
environment
● Inevitably associated with hardware devices
• Sensors: Collect data from the system environment
• Actuators: Change (in some way) the system's
environment
● Time is critical. Realtime systems MUST
respond within specified times

Definition
● A realtime system is a software system where the
correct functioning of the system depends on the
results produced by the system and the time at which
these results are produced
● A ‘soft’ realtime system is a system whose operation
is degraded if results are not produced according to
the specified timing requirements
● A ‘hard’ realtime system is a system whose operation
is incorrect if results are not produced according to
the timing specification
Stimulus/Response Systems
● Given a stimulus, the system must produce a
response within a specified time
● Periodic stimuli. Stimuli which occur at
predictable time intervals
• For example, a temperature sensor may be polled 10 times
per second
● Aperiodic stimuli. Stimuli which occur at
unpredictable times
• For example, a system power failure may trigger an
interrupt which must be processed by the system

Architectural considerations
● Because of the need to respond to timing
demands made by different stimuli/responses, the
system architecture must allow for fast switching
between stimulus handlers
● Timing demands of different stimuli are different
so a simple sequential loop is not usually
adequate
● Realtime systems are usually designed as
cooperating processes with a realtime executive
controlling these processes
S
ensorS ensorS ensoR
realtim
S
eensorS ensorS ensor
cont
ro s y m
A realtime system model
A
ctuaorA ctuaorA
©Ian Sommerville 2000
ctuaorA ctuaor
Software Engineering, 6th edition. Chapter 13 Slide 8
System elements
● Sensors control processes
• Collect information from sensors. May buffer information
collected in response to a sensor stimulus
● Data processor
• Carries out processing of collected information and computes
the system response
● Actuator control
• Generates control signals for the actuator

S
eS
n
sensooS
rrtim
u
l
s A
c
t
u
ao
r
R
e
s
p
on
s
e
D
a
t A
c
t
u
ao
r
cotl procesor onl
Sensor/actuator processes

System design
● Design both the hardware and the software
associated with system. Partition functions to
either hardware or software
● Design decisions should be made on the basis on
nonfunctional system requirements
● Hardware delivers better performance but
potentially longer development and less scope for
change

Hardware and software design
E
srrteeaq
b
lqP
iu
suarrteieh my
sm
tonntesm
S o
freqS
tudoierfstew
aw
rim e
n
tganres reH H a rd
quaired w
a
esw
m re
n
tiganres
RT systems design process
● Identify the stimuli to be processed and the
required responses to these stimuli
● For each stimulus and response, identify the
timing constraints
● Aggregate the stimulus and response processing
into concurrent processes. A process may be
associated with each class of stimulus and
response

RT systems design process
● Design algorithms to process each class of
stimulus and response. These must meet the given
timing requirements
● Design a scheduling system which will ensure
that processes are started in time to meet their
deadlines
● Integrate using a realtime executive or operating
system

Timing constraints
● May require extensive simulation and experiment
to ensure that these are met by the system
● May mean that certain design strategies such as
objectoriented design cannot be used because of
the additional overhead involved
● May mean that lowlevel programming language
features have to be used for performance reasons

State machine modelling
● The effect of a stimulus in a realtime system may
trigger a transition from one state to another.
● Finite state machines can be used for modelling
realtime systems.
● However, FSM models lack structure. Even
simple systems can have a complex model.
● The UML includes notations for defining state
machine models
● See also Chapter 7.

F u
lpow
e
r d
F
u
o
:
= l
s 6e
p
t
0o
we
r
T
im
e
r
W
iH a
tadlof: dm
n
s
p g
l
a
y N
u
mb
e
r
Microwave oven state machine
pow
er d e pH
o wa lf
ep
rF
u
o
wl
e
r
T
id
o
m
e
r:
x S
i e
g t
si
n m
u te b
r
cD
o
r
l
s
e
d O
p
e
r
a
t
d
o
:

v
e
ni
o
n
eC
a
nc
e
l
H a
l o:=
fs3e t0pow
erD Dpoe n rcDlo
r
s
edE
n
a
d
o
:

d
'
RS
b
l
e
d
i
s
p
at
a
r
y
' S
y
s
t
f
a
ue
m
l W
a
d
o
:
i
t
n
g
d
s
p
l
a
m
ey
ido:'W
s dabp
ltinedgy'
Realtime programming
● Hardreal time systems may have to programmed
in assembly language to ensure that deadlines are
met
● Languages such as C allow efficient programs to
be written but do not have constructs to support
concurrency or shared resource management
● Ada as a language designed to support realtime
systems design so includes a general purpose
concurrency mechanism

Java as a realtime language
● Java supports lightweight concurrency (threads
and synchonized methods) and can be used for
some soft realtime systems
● Java 2.0 is not suitable for hard RT programming
or programming where precise control of timing
is required
• Not possible to specify thread execution time
• Uncontrollable garbage collection
• Not possible to discover queue sizes for shared resources
• Variable virtual machine implementation
• Not possible to do space or timing analysis

Realtime executives
● Realtime executives are specialised operating
systems which manage the processes in the RTS
● Responsible for process management and
resource (processor and memory) allocation
● May be based on a standard RTE kernel which
is used unchanged or modified for a particular
application
● Does not include facilities such as file
management
14
Executive components
● Realtime clock
• Provides information for process scheduling.
● Interrupt handler
• Manages aperiodic requests for service.
● Scheduler
• Chooses the next process to be run.
● Resource manager
• Allocates memory and processor resources.
● Despatcher
• Starts process execution.

Nonstop system components
● Configuration manager
• Responsible for the dynamic reconfiguration of the system
software and hardware. Hardware modules may be replaced and
software upgraded without stopping the systems
● Fault manager
• Responsible for detecting software and hardware faults and
taking appropriate actions (e.g. switching to backup disks) to
ensure that the system continues in operation

R
ecalotikm eP S
c
h
e
i
n
f
o
r
m
S
c
hd
u
l
i
n
a
t
o
e
d
u
l
eg
r I
nt
e
r
u
pt
r
o
c
e
s
q
u
i
r
e
s
o
m
nu
r
c
e
t
s ha
d
l
er
P
raw
o
cReeiu
satrdnyg prR
R
e
s
o
m
a
n
e
a
d
y
o
c
s
eu
r
c
e
gR
e
r
sl
a
s
e
o
u
r
cd A
r
Pv
a
i
l
b
e
s
o
u
r
c
t
r
o
c
e
se
o
r
list E D
pa
t
c
h
e x
eprocutsingl
i
t
Realtime executive components
Process priority
● The processing of some types of stimuli must
sometimes take priority
● Interrupt level priority. Highest priority which is
allocated to processes requiring a very fast
response
● Clock level priority. Allocated to periodic
processes
● Within these, further levels of priority may be
assigned

Interrupt servicing
● Control is transferred automatically to a
predetermined memory location
● This location contains an instruction to jump to
an interrupt service routine
● Further interrupts are disabled, the interrupt
serviced and control returned to the interrupted
process
● Interrupt service routines MUST be short,
simple and fast

Periodic process servicing
● In most realtime systems, there will be several
classes of periodic process, each with different
periods (the time between executions),
execution times and deadlines (the time by
which processing must be completed)
● The realtime clock ticks periodically and each
tick causes an interrupt which schedules the
process manager for periodic processes
● The process manager selects a process which
is ready for execution
Process management
● Concerned with managing the set of concurrent
processes
● Periodic processes are executed at prespecified
time intervals
● The executive uses the realtime clock to
determine when to execute a process
● Process period time between executions
● Process deadline the time by which processing
must be complete

S
c
C
h
o he
sd
u
fr exp l
e
rcuo r Re
s
o
ctins A urc e m anger
oryS
land aptrocesm tv D e
s
p
ari lax a
u tch
ibe pron er
cesoarn
RTE process management

Process switching
● The scheduler chooses the next process to be
executed by the processor. This depends on a
scheduling strategy which may take the process
priority into account
● The resource manager allocates memory and a
processor for the process to be executed
● The despatcher takes the process from ready list,
loads it onto a processor and starts execution

Scheduling strategies
● Non preemptive scheduling
• Once a process has been scheduled for execution, it runs to
completion or until it is blocked for some reason (e.g. waiting
for I/O)
● Preemptive scheduling
• The execution of an executing processes may be stopped if a
higher priority process requires service
● Scheduling algorithms
• Roundrobin
• Rate monotonic
• Shortest deadline first

Monitoring and control systems
● Important class of realtime systems
● Continuously check sensors and take actions
depending on sensor values
● Monitoring systems examine sensors and
report their results
● Control systems take sensor values and control
hardware actuators

Burglar alarm system
● A system is required to monitor sensors on doors
and windows to detect the presence of intruders in
a building
● When a sensor indicates a breakin, the system
switches on lights around the area and calls police
automatically
● The system should include provision for
operation without a mains power supply

Burglar alarm system
● Sensors
• Movement detectors, window sensors, door sensors.
• 50 window sensors, 30 door sensors and 200 movement
detectors
• Voltage drop sensor
● Actions
• When an intruder is detected, police are called
automatically.
• Lights are switched on in rooms with active sensors.
• An audible alarm is switched on.
• The system switches automatically to backup power when a
voltage drop is detected.

The RT system design process
● Identify stimuli and associated responses
● Define the timing constraints associated with
each stimulus and response
● Allocate system functions to concurrent
processes
● Design algorithms for stimulus processing and
response generation
● Design a scheduling system which ensures that
processes will always be scheduled to meet
their deadlines
Stimuli to be processed
● Power failure
• Generated aperiodically by a circuit monitor. When
received, the system must switch to backup power within 50
ms
● Intruder alarm
• Stimulus generated by system sensors. Response is to call
the police, switch on building lights and the audible alarm

Timing requirements
Stimulus/Response Timing requirements
Power fail interrupt The switch to backup power must be completed
within a deadline of 50 ms.
Door alarm Each door alarm should be polled twice per
second.
Window alarm Each window alarm should be polled twice per
second.
Movement detector Each movement detector should be polled twice
per second.
Audible alarm The audible alarm should be switched on within
1/2 second of an alarm being raised by a sensor.
Lights switch The lights should be switched on within 1/2
second of an alarm being raised by a sensor.
Communications The call to the police should be started within 2
seconds of an alarm being raised by a sensor.
Voice synthesiser A synthesised message should be available
within 4 seconds of an alarm being raised by a
sensor.
40H zdetM ov e m
cr pocesD nt 6 0 Hz D op r s
ce n o r 1
0H
zW inpd row
c
sen o r
etco
r56 0stH
azusBSen
uild s o r
tprnogc ems
asonuistorA
S
e
l
a
r
mn
s
o
r

y
es
t
m
Ca
o u
m s
p rouni
e
sc
ation
P
oiw
netr faiplu
treP
o
wp eo r
cs w itc
h Bu
il
d n g
m on
i
t
Ao
lr
apr m oR

cs y o m
t
e
m n u
mb
e
r A le r t m es age
A
lsyatrem A
udpirbolce aslrmL A
s yl R
ato
r
e m
n
um b e r
ighptirnog ecsontrl V R
oA
l
a
m

n
ur
m

s
y
b
e
r tem
oicep sroyn
tchesizer
Process architecture
// See http://www.softwareengin.com/ for links to the complete Java code for this
// example
class BuildingMonitor extends Thread {
BuildingSensor win, door, move ;
Siren siren = new Siren () ;
Lights lights = new Lights () ;
Synthesizer synthesizer = new Synthesizer () ;
DoorSensors doors = new DoorSensors (30) ;
WindowSensors windows = new WindowSensors (50) ;
MovementSensors movements = new MovementSensors (200) ;
PowerMonitor pm = new PowerMonitor () ;
BuildingMonitor()
{
// initialise all the sensors and start the processes
siren.start () ; lights.start () ;
synthesizer.start () ; windows.start () ;
doors.start () ; movements.start () ; pm.start () ;
}
Building_monitor process 1
public void run ()
{
int room = 0 ;
while (true)
{
// poll the movement sensors at least twice per second (400 Hz)
move = movements.getVal () ;
// poll the window sensors at least twice/second (100 Hz)
win = windows.getVal () ;
// poll the door sensors at least twice per second (60 Hz)
door = doors.getVal () ;
if (move.sensorVal == 1 | door.sensorVal == 1 | win.sensorVal == 1)
{
// a sensor has indicated an intruder
if (move.sensorVal == 1) room = move.room ;
if (door.sensorVal == 1) room = door.room ;
if (win.sensorVal == 1 ) room = win.room ;
lights.on (room) ; siren.on () ; synthesizer.on (room) ;
break ;
}
}
lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;
windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;
} // run
} //BuildingMonitor
Building_monitor process 2
Control systems
● A burglar alarm system is primarily a monitoring
system. It collects data from sensors but no real
time actuator control
● Control systems are similar but, in response to
sensor values, the system sends control signals to
actuators
● An example of a monitoring and control system is
a system which monitors temperature and
switches heaters on and off

50H zpSe
n
s
o
r
r
c
50H zT S
e
v
an
s
o
r
l
u
A temperature control system
50H
zH S
R w
o it
mc
h

o
m
n
ua
n
b
e
rh
e
r
m
o
s
p
c
d
T
ht
a
e
r
m
os
t
a

pr
o
c
e
s
eaptr ceosntrol conF
u
rtol npacoes
Data acquisition systems
● Collect data from sensors for subsequent
processing and analysis.
● Data collection processes and processing
processes may have different periods and
deadlines.
● Data collection may be faster than processing
e.g. collecting information about an explosion.
● Circular or ring buffers are a mechanism for
smoothing speed differences.

Reactor data collection
● A system collects data from a set of sensors
monitoring the neutron flux from a nuclear
reactor.
● Flux data is placed in a ring buffer for later
processing.
● The ring buffer is itself implemented as a
concurrent process so that the collection and
processing processes may be synchronized.

S
ensor (each dpS
aretnc sfolorw
Reactor flux monitoring
diesnS
avt aflieunesaor dvaS
leun
ebsu)ofr edatP P
r
o
f
l
uc
e
s
d
x

l
v
rdoactesDl
isplay
P
rpoducser
A ring buffer
C
o n
sprcum
esr
Mutual exclusion
● Producer processes collect data and add it to
the buffer. Consumer processes take data from the
buffer and make elements available
● Producer and consumer processes must be
mutually excluded from accessing the same
element.
● The buffer must stop producer processes
adding information to a full buffer and consumer
processes trying to take information from an
empty buffer.
class CircularBuffer
{
int bufsize ;
SensorRecord [] store ;
int numberOfEntries = 0 ;
int front = 0, back = 0 ;
CircularBuffer (int n) {
bufsize = n ;
store = new SensorRecord [bufsize] ;
} // CircularBuffer
synchronized void put (SensorRecord rec ) throws InterruptedException
{
if ( numberOfEntries == bufsize)
wait () ;
store [back] = new SensorRecord (rec.sensorId, rec.sensorVal) ;
back = back + 1 ;
if (back == bufsize)
back = 0 ;
numberOfEntries = numberOfEntries + 1 ;
notify () ;
} // put
Java implementation of a ring buffer 1
synchronized SensorRecord get () throws InterruptedException
{
SensorRecord result = new SensorRecord (1, 1) ;
if (numberOfEntries == 0)
wait () ;
result = store [front] ;
front = front + 1 ;
if (front == bufsize)
front = 0 ;
numberOfEntries = numberOfEntries 1 ;
notify () ;
return result ;
} // get
} // CircularBuffer
Java implementation of a ring buffer 2
Key points
● Realtime system correctness depends not just
on what the system does but also on how fast it
reacts
● A general RT system model involves associating
processes with sensors and actuators
● Realtime systems architectures are usually
designed as a number of concurrent processes

Key points
● Realtime executives are responsible for
process and resource management.
● Monitoring and control systems poll sensors and
send control signal to actuators
● Data acquisition systems are usually organised
according to a producer consumer model
● Java has facilities for supporting concurrency but
is not suitable for the development of timecritical
systems

CH 13

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CH 13

Hochgeladen von

Copyright:

Verfügbare Formate

Real­time Software Design

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 1

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 2

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 3

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 6

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 9

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 10

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 11

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 13

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 14

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 15

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 16

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 18

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 19

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 21

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 22

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 24

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 25

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 27

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 28

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 29

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 30

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 31

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 32

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 33

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 35

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 40

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 42

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 43

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 49

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 50

Das könnte Ihnen auch gefallen

Realtime Software Design