1 / 32 CS 425/625 Software Engineering Real-Time Software Design Based on Chapter 15 of the textbook [SE-7] Ian Sommerville, Software Engineering, 7 th Ed., Addison-Wesley, 2004 and on the Ch15 PowerPoint presentation available at the book’s web-site October 17, 2005
CS 425/625 Software Engineering Real-Time Software Design. Based on Chapter 15 of the textbook [SE-7] Ian Sommerville, Software Engineering, 7 th Ed., Addison-Wesley, 2004 and on the Ch15 PowerPoint presentation available at the book’s web-site October 17, 2005. Outline. Introduction - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1 / 32
CS 425/625 Software Engineering
Real-Time Software Design
Based on Chapter 15 of the textbook [SE-7] Ian Sommerville,Software Engineering, 7th Ed., Addison-Wesley, 2004 and on theCh15 PowerPoint presentation available at the book’s web-site
October 17, 2005
2 / 32
Outline
Introduction Real-Time Systems (RTS): A Characterization RTS Design RT Operating Systems Generic RTS architectures:
Monitoring and Control Systems Data Acquisition Systems
3 / 32
Introduction.…
Real-Time Systems: systems whose correct operation depends not only on the correctness of the results produced but also on the time at which these results are produced
Embedded Systems [www.webopedia.com]: An embedded system is “a specialized computer system that is part of a larger system or machine. Typically, an embedded system is housed on a single microprocessor board with the programs stored in ROM. Virtually all appliances that have digital interfaces (e.g., watches, microwaves, VCRs, cars) utilize embedded systems […]”
Usually, embedded systems are RTS
4 / 32
.Introduction...
RTS receive stimuli (both external and internal) and provide responses to these stimuli
Stimuli: Periodic: occur at preset intervals of time (e.g.,
every 20 ms) Aperiodic: have irregular occurrences
The sensor-system-actuator model of RTS: sensors provide inputs (stimuli), computational units elaborate responses, and actuators convey outputs (responses)
5 / 32
..Introduction..
Three types of processes: Sensor management Computational Actuator management
Since many stimuli need immediate treatment software handlers are needed. Handlers can run concurrently, hence RTS are usually designed as a set of concurrent processes.
This section of the presentation is based on [Dascalu01] “A real-time system must respond to externally generated
stimuli within a finite, specifiable time delay” [Everett95] An RTS differs from a “regular” (non-RTS) system in at
least the following aspects [Stankovic88]: Have deadlines attached to some or all tasks Faults in the system may lead to catastrophic
consequences Must have the ability to deal with exceptions Must be fast, predictable reliable, adaptive
9 / 32
.RTS: A Characterization.….
“Development of most software focuses on how to handle a normal situation, but real-time, critical-application development also focuses on how to handle the abnormal situation” [Everett95]
RTS “must operate under more severe constraints than ‘normal’ software yet perform reliably for long periods of time” [Douglass99]
10 / 32
..RTS: A Characterization….
A classification of RTS:
Utility
Timeth (hard deadline)
(a) Hard RTS
Utility
th (hard)Time
ts (soft)
(b) Firm RTS
Utility (c) Soft RTS
Timets (soft deadline)
11 / 32
…RTS: A Characterization…
Requirements for RTS: Timeliness
Reaction to stimuli “on time” (deadlines must be met) Relative and absolute timing constraints
Reliability Many errors have roots in incorrect specification Formal techniques needed for safety-critical systems
Intensive dynamics Models to describe behavior are necessary (based on
finite state machines)
12 / 32
….RTS: A Characterization..
Requirements for RTS (cont’d): Exception handling
Priorities should be assigned to stimuli/events Mechanisms for handling interrupts need be developed
Concurrency Parallel tasks are inherent in RTS The environment is also “concurrent” in nature
Distribution & resource allocation Distribution is not necessarily a characteristic of RTS,
but should be taken into consideration in larger applications
13 / 32
…..RTS: A Characterization.
Requirements for RTS (cont’d): Communication and synchronization
Synchronous and asynchronous communication mechanisms should be designed
Size In larger applications, there are numerous processes
and threads Size is associated with continuous change Decomposition in smaller units is needed, as are
mechanisms for modeling hierarchical structures
14 / 32
.…..RTS: A Characterization
Requirements for RTS (cont’d): Non time-constrained activities
Worst case scenarios cannot be easily evaluated Computations & data modeling
In process control systems computations can be complex
In RT databases data must have temporal validity Reuse
RTS are poor candidates for reuse (are too specialized) However, OO design may provide solutions
15 / 32
RTS Design…
Both the hardware and the software of the system must be designed and system functions allocated to either hardware or software
RTS design process should result in a system model that can be implemented in either software or hardware
Special-purpose hardware: Better performance, but Longer development time, and Less suitable to change
16 / 32
.RTS Design..
An RTS design process focuses on events (stimuli) rather than on objects or functions
Suggested RTS design process: Identify stimuli and associated responses Identify timing constraints on stimuli and responses Choose an execution platform for the system:
hardware & RTOS Aggregate stimulus and response processing
activities in several concurrent processes Design computational algorithms for each
stimulus/response association Design the scheduling software
17 / 32
..RTS Design.
RTS modeling relies on the use of state machines [e.g., Fig. 8.5. and 8.7, Somm00]
Timing constraints: May require extensive simulation and experimentation May preclude the use of an object-oriented
development approach (because of the overhead involved at run-time)
May require, for performance reasons, programming in assembly languages or system-level languages such as C
18 / 32
…RTS Design
RT programming: System-level languages (e.g., C) allow elaboration of
efficient code but the burden to express concurrency and to manage shared resources is on the programmer
Specially designed languages with good synchronization mechanisms such as Ada still have a number of limitations (e.g., lack of exceptions when deadlines are not met, strict FIFO policy for task queues)
Java has several facilities for lightweight RT programming (threads, synchronized methods) but also a number of limitations (e.g., garbage collector not controllable, JVM has various implementations)
19 / 32
RT Operating Systems...
RTOS: specialized operating system for RTS Main responsibilities:
Process management Resource allocation (processor, memory)
They may not include regular OS facilities such as file management
Manage at least two priority levels: Interrupt level, for processes that need fast response Clock level, for periodic processes
Detector statusSensor statusSensor statusRoom numberAlert messageRoom numberRoom number
28 / 32
….Generic RTS Architectures.. Architecture of a temperature control system [Fig. 15.10, SE-7]
ThermostatprocessSensorprocess
Furnacecontrol processHeater controlprocess
500Hz500Hz
Thermostat process500HzSensorvalues
Switch commandRoom number
29 / 32
…..Generic RTS Architectures. Generic DAS architecture [Fig. 15.11, SE-7]
DisplayProcessdataSensor databufferSensorprocessSensoridentifier andvalueSensors (each data flow is a sensor value)Sensoridentifier andvalueProcessdataSensor databufferSensorprocessSensoridentifier andvalueSensoridentifier andvalue
s1s2s3s4s5s6
30 / 32
…..Generic RTS Architectures. A neutron flux data acquisition system [Fig. 15.12, SE-7]