RealTime Design CS 3302 Lecture 16

1
Real-Time DesignCS 3302Lecture 16

• David Smith
• dmsmith_at_cc.gatech.edu

2
Course Overview
Week 2 Concept
Weeks 3-4 Requirements
Weeks 5-6 Design
Weeks 7-8 Code
Process Management Analysis Planning
Scheduling Tracking Risk Management SW Design
Week 9 Test
Week 10 Slack Time
OO Concepts OO Design
Measurement Testing Design for Real-Time
Requirements Review
Software Quality Software Re-Use
Design Review
Modeling Summary
Demo
3
What does Real-Time Mean?

• FAST ENOUGH!

4
Outline

• Module External Interfaces
• User Interface Design
• Interface Design Models
• Task Analysis
• Design Issues
• Design Evaluation
• Real-Time Systems
• System Considerations
• System Components
• Analysis and Simulation
• Real-Time Design

5
Module External Interfaces

• Passage of data outside the Context Diagram
• Usually specified in the calling arguments or
  data structure definitions
• Good languages enforce these agreements AT
  COMPILE TIME
• You want to avoid writing extra code to do
  RUN-TIME CHECKING
• Interface coordination becomes very difficult if
• Each side of the interface is written by a
  different team / organization / company,
• There is no agreement on common data types, and
• Management does not have the intestinal fortitude
  to enforce syntax level agreements

6
Interface Design Models

• Frustration and anxiety are part of daily life
  for many users of computerized information
  systems. They struggle to learn command language
  or menu selection systems that are supposed to
  help them to do their job. Some people
  encounter such serious cases of computer shock,
  terminal terror, or network neurosis that they
  avoid using computerized systems.
• Ben Shneiderman, 1987

7
User Tasks
System Architecture Design
Find a Module
Data Dictionary
Menu Selection
Mouse Click
Hot Key
8
The Cognitive Problem
Model One persons view of the nature or
architecture of an entity.

• There are four different models which must be
  forced to agree for a successful user interface
  design
• the software designer creates a design model -
  how the system entrails are supposed to work
• the human factors analyst has a user model - the
  profile of the user for whom the system is
  intended
• the documentation establishes a users model -
  that persons perception of what the system is
  and does
• the software developers produce the system image
  whose behavior reflects what the system really is.

9
Task Analysis

• It is the job of the software design to make sure
  that the user spends
• as little time as possible thinking about the
  software,
• as much time as possible thinking about his
  problem.
• System requirements indicate what the system
  should do.
• The user model specifies
• what the user wants to do
• how the user can best accomplish that
• Task analysis is performed to reduce these broad
  goals to a series of steps fine enough to define
  the functionality of the software which
  implements them.

10
Interface Design Process

• 1. Establish the goals and intentions for the
  task
• 2. Map each goal to a sequence of specific
  actions
• 3. Specify the action sequence as it will be
  executed at the interface level
• 4. Represent the user action sequence as the
  transitions in a state transition diagram.
• 5. For each state, design the look of the
  interface before each user action to guide him to
  the right action
• e.g Windows 95 lt---
• 6. Define ALL legal actions from that state to
  another
• 7. Disable all other possible actions
• physically and graphically

11
Design Issues

• System response time
• duration (can be too short -gt double actions) and
  
• variability
• User help facilities
• usually, organized to say what system features
  do
• users want to know how do I do..
• Error information handling
• describe the problem in laymans terms
• recommend corrective action
• indicate possible consequences
• Command labeling
• relate to users objectives, not system jargon

12
Design Evaluation Process
preliminary design
build prototype 1
build prototype n
modify design
user evaluation
study design implications
13
Design Evaluation Criteria
14
Real-Time Systems

• System Considerations
• Integration and Performance
• Interrupt Handling
• Real-Time Data Bases
• Real-Time Operating Systems
• Real-Time Languages
• Task Synchronization and Communication

15
System Considerations

• At the system level, the first challenge is
  properly allocating functionality between
  hardware and software components
• temptation to move too much to software because
  it is easy to change
• should special-purpose hardware be used for
  complex computations? SGI graphics engine
• are the characteristics of an off-the-shelf
  operating system sufficient? excessive?
• Time performance requirements are allocated
  between system components as a response time
  budget.

16
Characteristics of Real-Time Software

• Design is resource constrained. Can sometimes
  trade off
• CPU cycles - ultimate measure of performance
• Memory - arrays and indexing
• Preprocessing data - organizing for rapid access
• Actual time constrained code is usually a small
  percentage of the total,
• usually quite complex.
• Frequently are unattended or work too fast for
  human error intervention
• special attention must be paid to detecting and
  alleviating error conditions.

17
Integration and Performance

• Two separate system performance issues are
  frequently confused synchronous and
  asynchronous operation.
• Synchronous operations regularly process messages
  at a given rate, and must complete the operation
  before the next message
• Asynchronous operations must respond to isolated
  events within a given time frame.
• Many system designs mix the two, greatly
  complicating the problem.
• Synchronous tasks must not only do their job, but
  must also leave enough processing resources in
  case an asynchronous event occurs
• Some poor designs process asynchronous data
  synchronously to ensure response time

18
Interrupt Handling

• Sequence of events
• External trigger
• Save context of interrupted program
• Switch context to interrupt service program
• Transfer control to interrupt processor
• Complete interrupt processing
• Restore context

What happens if the interrupted program is in the
middle of changing a data structure and the
interrupting program changes the structure?
19
Distributed Data Bases

• Choice with no good answer
• Example Airline reservations
• Distribute the data how to maintain
  consistency?
• periodic locking and change transfers
• consistency checks (background or foreground)
• exclusive writer protocols
• Centralized data how to maintain performance?
• Cost of communications
• General problem effort expended off-peak to
  improve instantaneous response

20
Real-Time Data Bases

• Design optimized for rapid access
• Multiple indices
• Complicates the structural integrity problem
• Usually, use locks to serialize access to
  structure change

• Wait protocol choices
• spin
• delay and retry
• wait for acknowledge

Set lock
change data structure
Clear lock
21
Real-Time Operating Systems

• Designed for efficient, predictable handling of
• asynchronous requests
• task synchronization (next chart)
• May be custom designed, or real-time extensions
  to standard OS (Unix)
• Incorporate task priorities
• Avoid program swapping
• Concurrent processing (Multi-tasking) is
  generally not efficient if the tasks are small
• Measures of effectiveness
• context switching time
• interrupt latency
• Note it is as important for these to be
  predictable as it is for them to be fast!

22
Real-Time Languages

• Any language can be a real-time language
• most require library function calls to implement
  real-time behavior
• a few (Ada, Jovial) build the features into the
  compiler
• not a big win unless implemented efficiently
• places further constraints on the operating
  system
• Necessary capabilities
• Set up and terminate parallel processes
  (priorities)
• Task synchronization (semaphores)
• Task communication (messaging, mailboxes)

23
Task Synchronization and Communication
parent process
set up tasks
child 2
child 1
do something
do something else
send data
wait for data
signal
finish up
both finished?
signal