1 / 30

CS 425/625 Software Engineering

Real-Time Software Design

Based on Chapter 13 of the textbook [SOMM00] Ian Sommerville,Software Engineering, 6th Ed., Addison-Wesley, 2000 and on theCh4 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 / 30

Outline

Introduction Real-Time Systems (RTS): A Characterization RTS Design RT Executives Generic RTS architectures:

Monitoring Systems Control Systems Data Acquisition Systems

3 / 30

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 [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 […]”

Usually, embedded systems are RTS

4 / 30

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

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

...Introduction.

General model of an RTS [Fig. 13.1, Somm00]

Real-timecontrol system

ActuatorActuator ActuatorActuator

SensorSensorSensor SensorSensorSensor

7 / 30

.…Introduction

Sensor/actuator processes [Fig. 13.2, Somm0]

Dataprocessor

Actuatorcontrol

Actuator

Sensorcontrol

Sensor

Stimulus Response

8 / 30

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

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

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

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

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

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

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

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

.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 Aggregate stimulus and response processing

activities in several concurrent processes Design computational algorithms for each

stimulus/response association Design the scheduling software Integrate the system with an RT executive or OS

17 / 30

..RTS Design.

RTS modeling relies on the use of state machines [e.g., Fig. 7.5. and 7.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 / 30

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

RT Executives...

RT Executives: specialized (& smaller) operating systems for RTS

Main responsibilities: Process management Resource allocation (processor, memory)

Usually, they do not include other 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 / 30

.RT Executives.. Typical structure of an RT executive [Fig. 13.4, Somm00]

Process resourcerequirements

Scheduler

Schedulinginformation

Resourcemanager

Despatcher

Real-timeclock

Processesawaitingresources

Readylist

Interrupthandler

Availableresource

list

Processorlist

Executingprocess

Readyprocesses

Releasedresources

21 / 30

..RT Executives.

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

...RT Executives

RTE actions to start a process [Fig. 13.5, Somm00]

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

Resource manager

Allocate memoryand processor

Scheduler

Choose processfor execution

Despatcher

Start execution on anavailable processor

23 / 30

Generic RTS Architectures..….Generic RTS Architectures..….

Typical classes of RTS (each with a characteristic architecture): 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 collect data from sensors for later processing and analysis

24 / 30

.Generic RTS Architectures..…

A burglar 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.13.6, Somm00]

25 / 30

..Generic RTS Architectures....

26 / 30

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

Lighting controlprocess

Audible alarmprocess

Voice synthesizerprocess

Alarm systemprocess

Power switchprocess

Building monitorprocess

Communicationprocess

Door sensorprocess

Movementdetector process

Window sensorprocess

560Hz

60Hz400Hz 100Hz

Power failureinterrupt

Alarmsystem

Building monitor

Alarmsystem

Alarm system

Alarm system

Detector status Sensor status Sensor status

Room number

Alert message

Room number

Room number

27 / 30

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

Thermostatprocess

Sensorprocess

Furnacecontrol process

Heater controlprocess

500Hz

500Hz

Thermostat process500Hz

Sensorvalues

Switch commandRoom number

28 / 30

…..Generic RTS Architectures. A flux monitoring system [Fig. 13.10, Somm00]

DisplayProcess

dataSensor data

bufferSensorprocess

Sensoridentifier and

value

Processedflux level

Sensors (each data flow is a sensor value)

29 / 30

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

Consumerprocess

Producerprocess

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.