CS 425/625 Software Engineering Real-Time Software Design

1. CS 425/625 Software EngineeringReal-Time Software Design Based on Chapter 15 of the textbook [SE-7] Ian Sommerville, Software Engineering, 7th Ed., Addison-Wesley, 2004 and on the Ch15 PowerPoint presentation available at the book’s web-site October 17, 2005

2. Outline • Introduction • Real-Time Systems (RTS): A Characterization • RTS Design • RT Operating Systems • Generic RTS architectures: • Monitoring and Control Systems • Data Acquisition Systems

3. 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. .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. ..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.

6. ...Introduction. • General model of an RTS [Fig. 15.1, SE-7]

7. .…Introduction • Sensor/actuator processes [Fig. 15.2, SE-7]

8. RTS: A Characterization…… • 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. .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. ..RTS: A Characterization…. • A classification of RTS:

11. …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. ….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. …..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. .…..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. 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. .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. ..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. …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. 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 • Typical components: real-time clock, interrupt handler, scheduler, resource manager, dispatcher

20. .RT Executives.. • Typical structure of an RTOS [Fig. 15.4, SE-7]

21. ..RTOS. • Process management: • Coordination of the system’s set of concurrent processes • Periodic processes run at pre-set intervals of time • Process period: time between executions • Process deadline: the time by which the process must be complete • The executive uses the real-time clock to determine when a process must execute; a real-time tick period is usually several milliseconds long

22. ...RTOS • RTOS actions to start a process [Fig. 15.5, SE-7] • Scheduling strategies: • Non-preemptive: a process scheduled for execution runs until completion or until blocked (e.g., waiting for an input) • Pre-emptive: a higher-priority process can take over a lower-priority process • Scheduling algorithms, examples: round-robin, shortest deadline first, rate monotonic

23. Generic RTS Architectures..…. • Typical classes of RTS (each with a characteristic architecture): • Monitoring and control systems [MCS]: • Monitoring systems examine sensors and report their results; may take action in exceptional cases • Control systems read sensors and continuously command actuators • Data acquisition systems[DAS] collect data from sensors for later processing and analysis

24. Generic RTS Architectures..…. Generic MCS architecture [Fig. 15.6, SE-7]

25. .Generic RTS Architectures..… • An intruder alarm system (monitoring system): • Monitors sensors on doors and windows to detect the presence of intruders in a building; also monitors movement sensors in rooms • When a sensor indicates a break-in, switches on lights around the area and calls police automatically • Powered by a main power supply but also has provisions for battery backup; includes a power circuit monitor • Timing requirements for the system are shown on the next page [Fig.15.7, SE-7]

26. ..Generic RTS Architectures....

27. ...Generic RTS Architectures… • The architecture of the intruder alarm system [Fig. 15.8, SE-7]

28. ….Generic RTS Architectures.. • Architecture of a temperature control system [Fig. 15.10, SE-7]

29. …..Generic RTS Architectures. • Generic DAS architecture [Fig. 15.11, SE-7]

30. …..Generic RTS Architectures. • A neutron flux data acquisition system [Fig. 15.12, SE-7]

31. ……Generic RTS Architectures • A ring buffer for data acquisition [Fig. 15.13, SE-7]

32. Additional References [Dascalu01] Dascalu, S., Combining Semi-forma and Formal Notations in Software Specification: An Approach to Modelling Time-Constrained Systems, PhD thesis, Dalhousie University, Halifax, NS, Canada, 2001. [Douglass99] Douglass, B.P., Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns, Addison-Wesley, 1999. [Everett95] Everett, W., and Honiden, S., “Reliability and Safety of Real-Time Systems,” IEEE Software, 12(3), May 1995, p. 12-16 [Gibbs94] Gibbs, W.W., “Software’s Chronic Crisis,” Scientific American, Sep. 1994, p. 86-95. [Stankovic88] Stankovic, J.A., and Ramamritham, K., Tutorial: Hard Real-Time Systems, IEEE Computer Society Press, 1988.