Lectures Software Engineering - Chapter 13: Real-time Software Design

50 trang hoanguyen 3460

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 13: Real-time Software Design", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_13_real_time_software.ppt

Nội dung text: Lectures Software Engineering - Chapter 13: Real-time Software Design

Real-time Software Design l Designing embedded software systems whose behaviour is subject to timing constraints ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 1
Objectives l To explain the concept of a real-time system and why these systems are usually implemented as concurrent processes l To describe a design process for real-time systems l To explain the role of a real-time executive l To introduce generic architectures for monitoring and control and data acquisition systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 2
Topics covered l Systems design l Real-time executives l Monitoring and control systems l Data acquisition systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 3
Real-time systems l Systems which monitor and control their environment l Inevitably associated with hardware devices • Sensors: Collect data from the system environment • Actuators: Change (in some way) the system's environment l Time is critical. Real-time systems MUST respond within specified times ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 4
Definition l A real-time 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 l A ‘soft’ real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements l A ‘hard’ real-time system is a system whose operation is incorrect if results are not produced according to the timing specification ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 5
Stimulus/Response Systems l Given a stimulus, the system must produce a response within a specified time l Periodic stimuli. Stimuli which occur at predictable time intervals • For example, a temperature sensor may be polled 10 times per second l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 6
Architectural considerations l 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 l Timing demands of different stimuli are different so a simple sequential loop is not usually adequate l Real-time systems are usually designed as cooperating processes with a real-time executive controlling these processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 7
System elements l Sensors control processes • Collect information from sensors. May buffer information collected in response to a sensor stimulus l Data processor • Carries out processing of collected information and computes the system response l Actuator control • Generates control signals for the actuator ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 9
System design l Design both the hardware and the software associated with system. Partition functions to either hardware or software l Design decisions should be made on the basis on non-functional system requirements l Hardware delivers better performance but potentially longer development and less scope for change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 11
R-T systems design process l Identify the stimuli to be processed and the required responses to these stimuli l For each stimulus and response, identify the timing constraints l Aggregate the stimulus and response processing into concurrent processes. A process may be associated with each class of stimulus and response ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 13
R-T systems design process l Design algorithms to process each class of stimulus and response. These must meet the given timing requirements l Design a scheduling system which will ensure that processes are started in time to meet their deadlines l Integrate using a real-time executive or operating system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 14
Timing constraints l May require extensive simulation and experiment to ensure that these are met by the system l May mean that certain design strategies such as object-oriented design cannot be used because of the additional overhead involved l May mean that low-level programming language features have to be used for performance reasons ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 15
State machine modelling l The effect of a stimulus in a real-time system may trigger a transition from one state to another. l Finite state machines can be used for modelling real-time systems. l However, FSM models lack structure. Even simple systems can have a complex model. l The UML includes notations for defining state machine models l See also Chapter 7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 16
Real-time programming l Hard-real time systems may have to programmed in assembly language to ensure that deadlines are met l Languages such as C allow efficient programs to be written but do not have constructs to support concurrency or shared resource management l Ada as a language designed to support real-time systems design so includes a general purpose concurrency mechanism ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 18
Java as a real-time language l Java supports lightweight concurrency (threads and synchonized methods) and can be used for some soft real-time systems l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 19
Real-time executives l Real-time executives are specialised operating systems which manage the processes in the RTS l Responsible for process management and resource (processor and memory) allocation l May be based on a standard RTE kernel which is used unchanged or modified for a particular application l Does not include facilities such as file management 14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 20
Executive components l Real-time clock • Provides information for process scheduling. l Interrupt handler • Manages aperiodic requests for service. l Scheduler • Chooses the next process to be run. l Resource manager • Allocates memory and processor resources. l Despatcher • Starts process execution. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 21
Non-stop system components l 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 l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 22
Real-time executive components
Process priority l The processing of some types of stimuli must sometimes take priority l Interrupt level priority. Highest priority which is allocated to processes requiring a very fast response l Clock level priority. Allocated to periodic processes l Within these, further levels of priority may be assigned ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 24
Interrupt servicing l Control is transferred automatically to a pre-determined memory location l This location contains an instruction to jump to an interrupt service routine l Further interrupts are disabled, the interrupt serviced and control returned to the interrupted process l Interrupt service routines MUST be short, simple and fast ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 25
Periodic process servicing l In most real-time 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) l The real-time clock ticks periodically and each tick causes an interrupt which schedules the process manager for periodic processes l The process manager selects a process which is ready for execution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 26
Process management l Concerned with managing the set of concurrent processes l Periodic processes are executed at pre-specified time intervals l The executive uses the real-time clock to determine when to execute a process l Process period - time between executions l Process deadline - the time by which processing must be complete ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 27
Process switching l 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 l The resource manager allocates memory and a processor for the process to be executed l The despatcher takes the process from ready list, loads it onto a processor and starts execution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 29
Scheduling strategies l Non pre-emptive 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) l Pre-emptive scheduling • The execution of an executing processes may be stopped if a higher priority process requires service l Scheduling algorithms • Round-robin • Rate monotonic • Shortest deadline first ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 30
Monitoring and control systems l Important class of real-time systems l Continuously check sensors and take actions depending on sensor values l Monitoring systems examine sensors and report their results l Control systems take sensor values and control hardware actuators ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 31
Burglar alarm system l A system is required to monitor sensors on doors and windows to detect the presence of intruders in a building l When a sensor indicates a break-in, the system switches on lights around the area and calls police automatically l The system should include provision for operation without a mains power supply ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 32
Burglar alarm system l Sensors • Movement detectors, window sensors, door sensors. • 50 window sensors, 30 door sensors and 200 movement detectors • Voltage drop sensor l 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. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 33
The R-T system design process l Identify stimuli and associated responses l Define the timing constraints associated with each stimulus and response l Allocate system functions to concurrent processes l Design algorithms for stimulus processing and response generation l Design a scheduling system which ensures that processes will always be scheduled to meet their deadlines ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 34
Stimuli to be processed l Power failure • Generated aperiodically by a circuit monitor. When received, the system must switch to backup power within 50 ms l Intruder alarm • Stimulus generated by system sensors. Response is to call the police, switch on building lights and the audible alarm ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 35
Process architecture
Building_monitor process 1
Building_monitor process 2
Control systems l A burglar alarm system is primarily a monitoring system. It collects data from sensors but no real- time actuator control l Control systems are similar but, in response to sensor values, the system sends control signals to actuators l An example of a monitoring and control system is a system which monitors temperature and switches heaters on and off ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 40
Data acquisition systems l Collect data from sensors for subsequent processing and analysis. l Data collection processes and processing processes may have different periods and deadlines. l Data collection may be faster than processing e.g. collecting information about an explosion. l Circular or ring buffers are a mechanism for smoothing speed differences. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 42
Reactor data collection l A system collects data from a set of sensors monitoring the neutron flux from a nuclear reactor. l Flux data is placed in a ring buffer for later processing. l The ring buffer is itself implemented as a concurrent process so that the collection and processing processes may be synchronized. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 43
Mutual exclusion l Producer processes collect data and add it to the buffer. Consumer processes take data from the buffer and make elements available l Producer and consumer processes must be mutually excluded from accessing the same element. l The buffer must stop producer processes adding information to a full buffer and consumer processes trying to take information from an empty buffer. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 46
Java implementation of a ring buffer 1
Java implementation of a ring buffer 2
Key points l Real-time system correctness depends not just on what the system does but also on how fast it reacts l A general RT system model involves associating processes with sensors and actuators l Real-time systems architectures are usually designed as a number of concurrent processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 49
Key points l Real-time executives are responsible for process and resource management. l Monitoring and control systems poll sensors and send control signal to actuators l Data acquisition systems are usually organised according to a producer consumer model l Java has facilities for supporting concurrency but is not suitable for the development of time-critical systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13 Slide 50