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 download - id: cb3b6-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


... interfaces (e.g., watches, microwaves, VCRs, cars) utilize embedded systems ... Monitors sensors on doors and windows to detect the presence of intruders in a ... – PowerPoint PPT presentation

Number of Views:24
Avg rating:3.0/5.0
Slides: 31
Provided by: sergium
Learn more at: http://www.cse.unr.edu


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 13 of the textbook SOMM00 Ian
  • 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/
  • October 29, 2003

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

  • 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. 13.1, Somm00

  • Sensor/actuator processes Fig. 13.2, Somm0

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

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

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

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

...RT Executives
  • RTE actions to start a process Fig. 13.5,
  • 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 systems examine sensors and report
    their results may take action in exceptional
  • Control systems read sensors and continuously
    command actuators
  • Data acquisition systems collect data from
    sensors for later processing and analysis

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

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

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

..Generic RTS Architectures.
  • A flux monitoring system Fig. 13.10, Somm00

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

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