Transcription
Real-time Software Design Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 1
Objectives To explain the concept of a real-time systemand why these systems are usuallyimplemented as concurrent processesTo describe a design process for real-timesystemsTo explain the role of a real-time operatingsystemTo introduce generic process architecturesfor monitoring and control and dataacquisition systems Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 2
Topics covered System designReal-time operating systemsMonitoring and control systemsData acquisition systems Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 3
Real-time systems Systems which monitor and control theirenvironment.Inevitably associated with hardware devices Sensors: Collect data from the systemenvironment;Actuators: Change (in some way) the system'senvironment;Time is critical. Real-time systems MUSTrespond within specified times. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 4
Definition A real-time system is a software system wherethe correct functioning of the system depends onthe results produced by the system and the timeat which these results are produced.A soft real-time system is a system whoseoperation is degraded if results are not producedaccording to the specified timing requirements.A hard real-time system is a system whoseoperation is incorrect if results are not producedaccording to the timing specification. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 5
Stimulus/Response Systems Given a stimulus, the system must produce aresponse within a specified time.Periodic stimuli. Stimuli which occur atpredictable time intervals For example, a temperature sensor may be polled 10times per second.Aperiodic stimuli. Stimuli which occur atunpredictable times For example, a system power failure may trigger aninterrupt which must be processed by the system. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 6
Architectural considerations Because of the need to respond to timing demandsmade by different stimuli/responses, the systemarchitecture must allow for fast switching betweenstimulus handlers.Timing demands of different stimuli are different so asimple sequential loop is not usually adequate.Real-time systems are therefore usually designed ascooperating processes with a real-time executivecontrolling these processes. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 7
A real-time system model Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 8
Sensor/actuator processes Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 9
System elements Sensor control processes Data processor Collect information from sensors. May bufferinformation collected in response to a sensorstimulus.Carries out processing of collected informationand computes the system response.Actuator control processes Generates control signals for the actuators. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 10
Real-time programming Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 11
Real-time programming Hard-real time systems may have toprogrammed in assembly language toensure that deadlines are met.Languages such as C allow efficientprograms to be written but do not haveconstructs to support concurrency or sharedresource management. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 12
Java as a real-time language Java supports lightweight concurrency (threads andsynchronized methods) and can be used for somesoft real-time systems.Java 2.0 is not suitable for hard RT programming butreal-time versions of Java are now available thataddress problems such as Not possible to specify thread execution time;Different timing in different virtual machines;Uncontrollable garbage collection;Not possible to discover queue sizes for sharedresources;Not possible to access system hardware;Not possible to do space or timing analysis. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 13
System design Design both the hardware and the softwareassociated with system. Partition functions toeither hardware or software.Design decisions should be made on thebasis on non-functional systemrequirements.Hardware delivers better performance butpotentially longer development and lessscope for change. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 14
R-T systems design process Identify the stimuli to be processed and therequired responses to these stimuli.For each stimulus and response, identify thetiming constraints.Aggregate the stimulus and responseprocessing into concurrent processes. Aprocess may be associated with each classof stimulus and response. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 15
R-T systems design process Design algorithms to process each class ofstimulus and response. These must meet thegiven timing requirements.Design a scheduling system which willensure that processes are started in time tomeet their deadlines.Integrate using a real-time operating system. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 16
Timing constraints May require extensive simulation andexperiment to ensure that these are met bythe system.May mean that certain design strategiessuch as object-oriented design cannot beused because of the additional overheadinvolved.May mean that low-level programminglanguage features have to be used forperformance reasons. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 17
Real-time system modelling The effect of a stimulus in a real-time system maytrigger a transition from one state to another.Finite state machines can be used for modellingreal-time systems.However, FSM models lack structure. Even simplesystems can have a complex model.The UML includes notations for defining statemachine modelsSee Chapter 8 for further examples of state machinemodels. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 18
Petrol pump state model Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 19
Real-time operating systems Real-time operating systems are specialisedoperating systems which manage the processes inthe RTS.Responsible for process management andresource (processor and memory) allocation.May be based on a standard kernel whichis used unchanged or modified for a particularapplication.Do not normally include facilities such as filemanagement. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1514Slide 20
Operating system components Real-time clock Interrupt handler Chooses the next process to be run.Resource manager Manages aperiodic requests for service.Scheduler Provides information for process scheduling.Allocates memory and processor resources.Dispatcher Starts process execution. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 21
Non-stop system components Configuration manager Responsible for the dynamic reconfiguration of the systemsoftware and hardware. Hardware modules may bereplaced and software upgraded without stopping thesystems.Fault manager Responsible for detecting software and hardware faultsandtaking appropriate actions (e.g. switching to backup disks)to ensure that the system continues in operation. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 22
Real-time OS components Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 23
Process priority The processing of some types of stimuli mustsometimes take priority.Interrupt level priority. Highest priority which isallocated to processes requiring a very fastresponse.Clock level priority. Allocated to periodicprocesses.Within these, further levels of priority may beassigned. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 24
Interrupt servicing Control is transferred automatically to apre-determined memory location.This location contains an instruction to jump toan interrupt service routine.Further interrupts are disabled, the interruptserviced and control returned to the interruptedprocess.Interrupt service routines MUST be short,simple and fast. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 25
Periodic process servicing In most real-time systems, there will be severalclasses of periodic process, each with differentperiods (the time between executions),execution times and deadlines (the time bywhich processing must be completed).The real-time clock ticks periodically and eachtick causes an interrupt which schedules theprocess manager for periodic processes.The process manager selects a process whichis ready for execution. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 26
Process management Concerned with managing the set ofconcurrent processes.Periodic processes are executed at prespecified time intervals.The RTOS uses the real-time clock todetermine when to execute a process takinginto account: Process period - time between executions.Process deadline - the time by whichprocessing must be complete. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 27
RTE process management Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 28
Process switching The scheduler chooses the next process tobe executed by the processor. This dependson a scheduling strategy which may take theprocess priority into account.The resource manager allocates memoryand a processor for the process to beexecuted.The dispatcher takes the process from readylist, loads it onto a processor and startsexecution. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 29
Scheduling strategies Non pre-emptive scheduling Pre-emptive scheduling Once a process has been scheduled for execution, it runsto completion or until it is blocked for some reason (e.g.waiting for I/O).The execution of an executing processes may be stoppedif a higher priority process requires service.Scheduling algorithms Round-robin;Rate monotonic;Shortest deadline first. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 30
Monitoring and control systems Important class of real-time systems.Continuously check sensors and take actionsdepending on sensor values.Monitoring systems examine sensors andreport their results.Control systems take sensor values andcontrol hardware actuators. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 31
Generic architecture Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 32
Burglar alarm system A system is required to monitor sensors ondoors and windows to detect the presence ofintruders in a building.When a sensor indicates a break-in, thesystem switches on lights around the areaand calls police automatically.The system should include provision foroperation without a mains power supply. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 33
Burglar alarm system Sensors Movement detectors, window sensors, door sensors;50 window sensors, 30 door sensors and 200 movementdetectors;Voltage drop sensor.Actions When an intruder is detected, police are calledautomatically;Lights are switched on in rooms with active sensors;An audible alarm is switched on;The system switches automatically to backup power whena voltage drop is detected. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 34
The R-T system design process Identify stimuli and associated responses.Define the timing constraints associated witheach stimulus and response.Allocate system functions to concurrentprocesses.Design algorithms for stimulus processing andresponse generation.Design a scheduling system which ensures thatprocesses will always be scheduled to meettheir deadlines. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 35
Stimuli to be processed Power failure Generated aperiodically by a circuit monitor.When received, the system must switch tobackup power within 50 ms.Intruder alarm Stimulus generated by system sensors.Response is to call the police, switch on buildinglights and the audible alarm. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 36
Timing requirementsStimulus/ResponsePower fail interruptDoor alarmWindow alarmMovement detectorAudible alarmLights switchCommunicationsVoice synthesiser Ian Sommerville 2004Timing requirementsThe switch to backup power must be completedwithin a deadline of 50 ms.Each door alarm should be polled twice persecond.Each window alarm should be polled twice persecond.Each movement detector should be polled twiceper second.The audible alarm should be switched on within1/2 second of an alarm being raised by a sensor.The lights should be switched on within 1/2second of an alarm being raised by a sensor.The call to the police should be started within 2seconds of an alarm being raised by a sensor.A synthesised message should be availablewithin 4 seconds of an alarm being raised by asensor.Software Engineering, 7th edition. Chapter 15Slide 37
Burglar alarm system processes Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 38
Building monitor process 1class BuildingMonitor extends Thread {BuildingSensor win, door, move ;Sirensiren new Siren () ;Lightslights new Lights () ;Synthesizer synthesizer new Synthesizer () ;DoorSensors doors new DoorSensors (30) ;WindowSensorswindows new WindowSensors (50) ;MovementSensors movements new MovementSensors (200) ;PowerMonitor pm new PowerMonitor () ;BuildingMonitor(){// initialise all the sensors and start the processessiren.start () ; lights.start () ;synthesizer.start () ; windows.start () ;doors.start () ; movements.start () ; pm.start () ;} Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 39
Building monitor process 2public 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 intruderif (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 ;}} Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 40
Building monitor process 3lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;} // run} //BuildingMonitor Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 41
Control systems A burglar alarm system is primarily amonitoring system. It collects data fromsensors but no real-time actuator control.Control systems are similar but, in responseto sensor values, the system sends controlsignals to actuators.An example of a monitoring and controlsystem is a system that monitorstemperature and switches heaters on andoff. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 42
A temperature control system Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 43
Data acquisition systems Collect data from sensors for subsequentprocessing and analysis.Data collection processes and processingprocesses may have different periods anddeadlines.Data collection may be faster than processinge.g. collecting information about an explosion.Circular or ring buffers are a mechanism forsmoothing speed differences. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 44
Data acquisition architecture Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 45
Reactor data collection A system collects data from a set of sensorsmonitoring the neutron flux from a nuclearreactor.Flux data is placed in a ring buffer for laterprocessing.The ring buffer is itself implemented as aconcurrent process so that the collection andprocessing processes may be synchronized. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 46
Reactor flux monitoring Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 47
A ring buffer Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 48
Mutual exclusion Producer processes collect data and add it tothe buffer. Consumer processes take datafrom the buffer and make elements available.Producer and consumer processes must bemutually excluded from accessing the sameelement.The buffer must stop producer processesadding information to a full buffer andconsumer processes trying to takeinformation from an empty buffer. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 49
Ring buffer implementation 1class CircularBuffer{int bufsize ;SensorRecord [] store ;int numberOfEntries 0 ;int front 0, back 0 ;CircularBuffer (int n) {bufsize n ;store new SensorRecord [bufsize] ;} // CircularBuffer Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 50
Ring buffer implementation 2synchronized void put (SensorRecord rec )throws InterruptedException{if ( numberOfEntries bufsize)wait () ;store [back] new SensorRecord (rec.sensorId, rec.sensback back 1 ;if (back bufsize)back 0 ;numberOfEntries numberOfEntries 1 ;notify () ;} // put Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 51
Ring buffer implementation 3synchronized 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 Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 52
Key points Real-time system correctness depends not juston what the system does but also on how fast itreacts.A general RT system model involves associatingprocesses with sensors and actuators.Real-time systems architectures are usuallydesigned as a number of concurrent processes. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 53
Key points Real-time operating systems are responsibleforprocess and resource management.Monitoring and control systems poll sensorsand send control signal to actuators.Data acquisition systems are usuallyorganised according to a producer consumermodel. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15Slide 54
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 15 Slide 2 Objectives To explain the concept of a real-time system and why these systems are usually implemented as concurrent processes To describe a design process for real-time systems To explain the role of a real-time operating system To int
