CS 425/625 Software Engineering Real-Time Software Design

1
CS 425/625 Software Engineering Real-Time
Software Design

• Based on Chapter 15 of the textbook SE-8 Ian
  Sommerville,
• Software Engineering, 8th Ed., Addison-Wesley,
  2006 and on the
• Ch15 PowerPoint presentation available at the
  books web-site
• October 27, 2008

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

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-8

7
.Introduction

• Sensor/actuator processes Fig. 15.2, SE-8

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
• 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
• 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-8

21
..RTOS.

• 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
...RTOS

• RTOS actions to start a process Fig. 15.5, SE-8
• 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-8

26
..Generic RTS Architectures....
27
...Generic RTS Architectures

• The architecture of the intruder alarm system
  Fig. 15.8, SE-8

28
.Generic RTS Architectures..

• Architecture of a temperature control system
  Fig. 15.10, SE-8

29
..Generic RTS Architectures.

• Generic DAS architecture Fig. 15.11, SE-8

30
..Generic RTS Architectures.

• A neutron flux data acquisition system Fig.
  15.12, SE-8

31
Generic RTS Architectures

• A ring buffer for data acquisition Fig. 15.13,
  SE-8

32
Additional References

• Dascalu01 Dascalu, S., Combining Semi-formal
  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.