1. 1 / 30 CS 425/625 Software Engineering Real-Time Software Design Based on Chapter 13 of the textbook [SOMM00] Ian Sommerville, Software Engineering, 6 th Ed., Addison-Wesley, 2000 and on the Ch4 PowerPoint presentation available at the book’s web-site: www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html October 29, 2003

2. 2 / 30 Outline n n Introduction n n Real-Time Systems (RTS): A Characterization n n RTS Design n n RT Executives n n Generic RTS architectures: u u Monitoring Systems u u Control Systems u u Data Acquisition Systems

3. 3 / 30 Introduction.… n n 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 n n Embedded Systems [from 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 […]” n n Usually, embedded systems are RTS

4. 4 / 30.Introduction... n n RTS receive stimuli (both external and internal) and provide responses to these stimuli n n Stimuli: u u Periodic: occur at preset intervals of time (e.g., every 20 ms) u u Aperiodic: have irregular occurrences n n The sensor-system-actuator model of RTS: sensors provide inputs (stimuli), computational units elaborate responses, and actuators convey outputs (responses)

5. 5 / 30..Introduction.. n n Three types of processes: u u Sensor management u u Computational u u Actuator management n n 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. 6 / 30...Introduction. n n General model of an RTS [Fig. 13.1, Somm00]

7. 7 / 30.…Introduction n n Sensor/actuator processes [Fig. 13.2, Somm0]

8. 8 / 30 RTS: A Characterization…… n n This section of the presentation is based on [Dascalu01] n n “A real-time system must respond to externally generated stimuli within a finite, specifiable time delay” [Everett95] n n An RTS differs from a “regular” (non-RTS) system in at least the following aspects [Stankovic88]: u u Have deadlines attached to some or all tasks u u Faults in the system may lead to catastrophic consequences u u Must have the ability to deal with exceptions u u Must be fast, predictable reliable, adaptive

9. 9 / 30.RTS: A Characterization.…. n n “ 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] n n RTS “must operate under more severe constraints than ‘normal’ software yet perform reliably for long periods of time” [Douglass99]

10. 10 / 30..RTS: A Characterization…. n n A classification of RTS:

11. 11 / 30 …RTS: A Characterization… n n Requirements for RTS: u u Timeliness   Reaction to stimuli “on time” (deadlines must be met)   Relative and absolute timing constraints u u Reliability   Many errors have roots in incorrect specification   Formal techniques needed for safety-critical systems u u Intensive dynamics   Models to describe behavior are necessary (based on finite state machines)

12. 12 / 30 ….RTS: A Characterization.. n n Requirements for RTS (cont’d) : u u Exception handling   Priorities should be assigned to stimuli/events   Mechanisms for handling interrupts need be developed u u Concurrency   Parallel tasks are inherent in RTS   The environment is also “concurrent” in nature u u Distribution & resource allocation   Distribution is not necessarily a characteristic of RTS, but should be taken into consideration in larger applications

13. 13 / 30 …..RTS: A Characterization. n n Requirements for RTS (cont’d) : u u Communication and synchronization   Synchronous and asynchronous communication mechanisms should be designed u u 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. 14 / 30.…..RTS: A Characterization n n Requirements for RTS (cont’d) : u u Non time-constrained activities   Worst case scenarios cannot be easily evaluated u u Computations & data modeling   In process control systems computations can be complex   In RT databases data must have temporal validity u u Reuse   RTS are poor candidates for reuse (are too specialized)   However, OO design may provide solutions

15. 15 / 30 RTS Design… n n Both the hardware and the software of the system must be designed and system functions allocated to either hardware or software n n RTS design process should result in a system model that can be implemented in either software or hardware n n Special-purpose hardware: u u Better performance, but u u Longer development time, and u u Less suitable to change

16. 16 / 30.RTS Design.. n n An RTS design process focuses on events (stimuli) rather than on objects or functions n n Suggested RTS design process: u u Identify stimuli and associated responses u u Identify timing constraints on stimuli and responses u u Aggregate stimulus and response processing activities in several concurrent processes u u Design computational algorithms for each stimulus/response association u u Design the scheduling software u u Integrate the system with an RT executive or OS

17. 17 / 30..RTS Design. n n RTS modeling relies on the use of state machines [e.g., Fig. 7.5. and 7.7, Somm00] n n Timing constraints: u u May require extensive simulation and experimentation u u May preclude the use of an object-oriented development approach (because of the overhead involved at run-time) u u May require, for performance reasons, programming in assembly languages or system-level languages such as C

18. 18 / 30 …RTS Design n n RT programming: u u 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 u u 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) u u 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. 19 / 30 RT Executives... n n RT Executives: specialized (& smaller) operating systems for RTS n n Main responsibilities: u u Process management u u Resource allocation (processor, memory) n n Usually, they do not include other OS facilities such as file management n n Manage at least two priority levels: u u Interrupt level, for processes that need fast response u u Clock level, for periodic processes n n Typical components: real-time clock, interrupt handler, scheduler, resource manager, dispatcher

20. 20 / 30.RT Executives.. n n Typical structure of an RT executive [Fig. 13.4, Somm00]

21. 21 / 30..RT Executives. n n Process management: u u Coordination of the system’s set of concurrent processes u u Periodic processes run at pre-set intervals of time u u Process period: time between executions u u Process deadline: the time by which the process must be complete u u 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. 22 / 30...RT Executives n n RTE actions to start a process [Fig. 13.5, Somm00] n n Scheduling strategies: u u Non-preemptive: a process scheduled for execution runs until completion or until blocked (e.g., waiting for an input) u u Pre-emptive: a higher-priority process can take over a lower- priority process n n Scheduling algorithms, examples: round-robin, shortest deadline first, rate monotonic

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

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

25. 25 / 30..Generic RTS Architectures....

26. 26 / 30...Generic RTS Architectures… n n The architecture of the burglar alarm system [Fig. 13.7, Somm00]

27. 27 / 30 ….Generic RTS Architectures.. n n Architecture of a temperature control system [Fig. 13.9, Somm00]

28. 28 / 30 …..Generic RTS Architectures. n n A flux monitoring system [Fig. 13.10, Somm00]

29. 29 / 30 ……Generic RTS Architectures n A ring buffer for a data acquisition system [Fig. 13.11, Somm00]

30. 30 / 30 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.