CS 425/625 Software Engineering Real-Time Software Design

1
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 the
• Ch4 PowerPoint presentation available at the
  books web-site
• www.comp.lancs.ac.uk/computing/resources/IanS/SE6/
  Slides/index.html
• October 29, 2003

2
Outline

• Introduction
• Real-Time Systems (RTS) A Characterization
• RTS Design
• RT Executives
• Generic RTS architectures
• Monitoring Systems
• 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 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
.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. 13.1, Somm00

7
.Introduction

• Sensor/actuator processes Fig. 13.2, Somm0

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 (contd)
• 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 (contd)
• 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 (contd)
• 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
• 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
..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
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 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
.RT Executives..

• Typical structure of an RT executive Fig. 13.4,
  Somm00

21
..RT Executives.

• Process management
• Coordination of the systems 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
...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

23
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
.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
..Generic RTS Architectures....
26
...Generic RTS Architectures

• The architecture of the burglar alarm system
  Fig. 13.7, Somm00

27
.Generic RTS Architectures..

• Architecture of a temperature control system
  Fig. 13.9, Somm00

28
..Generic RTS Architectures.

• A flux monitoring system Fig. 13.10, Somm00

29
Generic RTS Architectures

• A ring buffer for a data acquisition system
  Fig. 13.11, Somm00

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., Softwares 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.