CS 425625 Software Engineering RealTime Software Design Based

CS 425/625 Software Engineering Real-Time Software Design Based on Chapter 15 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed. , Addison-Wesley, 2006 and on the Ch 15 Power. Point presentation available at the book’s web-site October 29, 2007 1

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

Introduction. … 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 Embedded Systems [www. wikipedia. com]: An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, sometimes with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. 3

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

. . Introduction. . n Three types of processes: u Sensor management u Computational u Actuator management n 5 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.

. . . Introduction. n 6 General model of an RTS [Fig. 15. 1, SE-8]

. …Introduction n 7 Sensor/actuator processes [Fig. 15. 2, SE-8]

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

. RTS: A Characterization. …. n “Development of most software focuses on how to n 9 handle a normal situation, but real-time, criticalapplication development also focuses on how to handle the abnormal situation” [Everett 95] RTS “must operate under more severe constraints than ‘normal’ software yet perform reliably for long periods of time” [Douglass 99]

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

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

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

…. . RTS: A Characterization. n Requirements for RTS (cont’d): u Communication Ø and synchronization Synchronous and asynchronous communication mechanisms should be designed 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 Ø 13

. …. . RTS: A Characterization n Requirements for RTS (cont’d): u Non Ø time-constrained activities Worst case scenarios cannot be easily evaluated u Computations & data modeling In process control systems computations can be complex Ø In RT databases data must have temporal validity Ø u Reuse RTS are poor candidates for reuse (are too specialized) Ø However, OO design may provide solutions Ø 14

RTS Design… n n n 15 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: u Better performance, but u Longer development time, and u Less suitable to change

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

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

…RTS Design n RT programming: 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 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 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) 18

RT Operating Systems. . . n n RTOS: specialized operating system for RTS Main responsibilities: Process management u Resource allocation (processor, memory) u n n 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 u Clock level, for periodic processes u n 19 Typical components: real-time clock, interrupt handler, scheduler, resource manager, dispatcher

. RT Executives. . n 20 Typical structure of an RTOS [Fig. 15. 4, SE-8]

. . RTOS. n Process management: u Coordination of the system’s set of concurrent processes u Periodic processes run at pre-set intervals of time u Process period: time between executions u Process deadline: the time by which the process must be complete 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 21

. . . RTOS n RTOS actions to start a process [Fig. 15. 5, SE-8] n Scheduling strategies: u u n 22 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 lowerpriority process Scheduling algorithms, examples: round-robin, shortest deadline first, rate monotonic

Generic RTS Architectures. . …. n Typical classes of RTS (each with a characteristic architecture): u 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 u Data acquisition systems [DAS] collect data from sensors for later processing and analysis 23

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

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

. . Generic RTS Architectures. . 26

. . . Generic RTS Architectures… n 27 The architecture of the intruder alarm system [Fig. 15. 8, SE-8]

…. Generic RTS Architectures. . n 28 Architecture of a temperature control system [Fig. 15. 10, SE-8]

…. . Generic RTS Architectures. n Generic DAS architecture [Fig. 15. 11, SE-8] 29

…. . Generic RTS Architectures. n A neutron flux data acquisition system [Fig. 15. 12, SE-8] 30

……Generic RTS Architectures n A ring buffer for data acquisition [Fig. 15. 13, SE-8] 31

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