CS 425/625 Software Engineering Real-Time Software Design - PowerPoint PPT Presentation


PPT – CS 425/625 Software Engineering Real-Time Software Design PowerPoint presentation | free to view - id: d3b9c-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

CS 425/625 Software Engineering Real-Time Software Design


... part of a complete device including hardware and mechanical parts. ... RTS Design... Both the hardware and the software of the system must be designed and system ... – PowerPoint PPT presentation

Number of Views:284
Avg rating:3.0/5.0
Slides: 33
Provided by: sergium


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CS 425/625 Software Engineering Real-Time Software Design

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

  • Introduction
  • Real-Time Systems (RTS) A Characterization
  • RTS Design
  • RT Operating Systems
  • Generic RTS architectures
  • Monitoring and Control Systems
  • Data Acquisition Systems

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

  • 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

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

  • General model of an RTS Fig. 15.1, SE-8

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

RTS A Characterization
  • This section of the presentation is based on
  • 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
  • Must have the ability to deal with exceptions
  • Must be fast, predictable reliable, adaptive

.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

..RTS A Characterization.
  • A classification of RTS

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

.RTS A Characterization..
  • Requirements for RTS (contd)
  • Exception handling
  • Priorities should be assigned to stimuli/events
  • Mechanisms for handling interrupts need be
  • 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

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

...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
  • In RT databases data must have temporal validity
  • Reuse
  • RTS are poor candidates for reuse (are too
  • However, OO design may provide solutions

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

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

..RTS Design.
  • RTS modeling relies on the use of state machines
  • Timing constraints
  • May require extensive simulation and
  • 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

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

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
  • Clock level, for periodic processes
  • Typical components real-time clock, interrupt
    handler, scheduler, resource manager, dispatcher

.RT Executives..
  • Typical structure of an RTOS Fig. 15.4, SE-8

  • Process management
  • Coordination of the systems set of concurrent
  • Periodic processes run at pre-set intervals of
  • 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

  • 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

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
  • Control systems read sensors and continuously
    command actuators
  • Data acquisition systems DAS collect data from
    sensors for later processing and analysis

Generic RTS Architectures...
Generic MCS architecture Fig. 15.6, SE-7
.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
  • 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

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

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

..Generic RTS Architectures.
  • Generic DAS architecture Fig. 15.11, SE-8

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

Generic RTS Architectures
  • A ring buffer for data acquisition Fig. 15.13,

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.
  • Stankovic88 Stankovic, J.A., and Ramamritham,
    K., Tutorial Hard Real-Time Systems, IEEE
    Computer Society Press, 1988.
About PowerShow.com