Introduction to Open Architecture for RealTime Systems Dr' Doug Locke Vice President of Technology

1
Introduction to Open Architecture for Real-Time
SystemsDr. Doug LockeVice President of
Technology
2
Agenda

• What is Real-Time?
• What is Meant by Open?
• Software Life Cycle
• Architecture Issues in Real-Time
• Real-Time in the Software Life Cycle
• How to Get There

3
Real-Time

• There are three basic real-time performance
  models
• (Plus many variations)
• Hard Real-Time Must always meet time
  constraints
• Timing failure has significant consequences
• Soft Real-Time Must meet time constraints
• Timing failure has minor consequences
• Must not miss too often and/or miss by too much
• Non Real-Time Has no defined time constraints
• Timing failure is not defined

Non-
Soft
Hard
Real-Time
4
Levels of Real Time Performance

• Measured
• (quantitative indications) - may or may not be
  repeatable
• Repeatable Measured
• Measuring the temperature 3 days DOES NOT help
  tomorrow
• Statistically Predictable Architecture
• Statistical - average response and related
  standard deviation
• Analytically Guaranteed bounded latency
• Maximum duration between an event and its
  associated response
• Deterministic
• Knowledge of every state of a system over time

The above Goals Utilize different architectures,
tools, and infrastructure approaches!
5
Construction and Analysis Techniques

• Measured - ad hoc
• Repeatable
• Control over hidden daemons, interrupt handlers
• E.g. spoolers, garbage collectors, low - level
  message handlers
• Statistically Predictable
• Often used architectures Internal queuing,
  asynchronous messaging
• Analysis
• Simulation via use cases
• Queuing Theory
• Analytically Guaranteed Latency
• Often used Architectures - Shared Resources,
  Fixed Priority Scheduling, Real-Time O/S
  Kernels
• Analysis Rate Monotonic Analysis
• Deterministic
• Cyclic executives

Dynamic
Static
6
What is Meant by Open?

• Traditionally open systems implied that
• Every component implements only publicly defined
  standards created by open processes
• Some Problems
• Is TCP/IP Open? (Produced by the government)
• Is Linux Open? (Not compliant to POSIX or other
  standards)
• Is CORBA Open? (Produced by a consortium)
• Is Windows Open? (Owned by a single corporation)
• A Practical Definition
• An Open system is one whose infrastructure is
• Widely accepted,
• Responsive to user needs,
• Is unlikely to be changed capriciously,
• Is not exorbitantly expensive.

7
Open Architecture

• An Open Architecture is
• Implementable using an open infrastructure
• Developed using an open methodolgy
• Described by an open notation
• Predictably successful meeting requirements using
  open predictive techniques
• For Real-Time Systems
• An open architecture must be predictably capable
  of meeting application time constraints

8
Software Life Cycles
Requirements
Where the Performance Problems Originate
Architecture
High Level Design
Low Level Design
Code
Unit Test
System Test
Where the Performance Problems Become Visible
Final Test
Deployment
9
Architectural-Level Abstraction
TIME
SET_TIME
DISPLAY
TIME
SOUNDS
SET_ALARM_TIME
ENABLE_ALARM
DISABLE_ALARM
This FUNCTIONAL interface hides critical
information Concurrency not exposed until too
late!
10
Enhanced Alarm Clock 1- Concurrency
TIME
SET_TIME
Set
TIME
SET_ALARM_TIME
Timekeeper
ENABLE_ALARM
Alarm Mgr
Set
DISABLE_ALARM
Enable
Disable
Tick
Alarm Clock
11
Consequences of Concurrency

• Cooperation between the concurrent threads
• Sharing of the value for Time
• Sharing of alarm time and wakeup enabled state
• The semantics used to make the problem tractable
  presents SHARED RESOURCES as a basic architecture
  concept
• Different sharing policies (discussed later) have
  a MAJOR effect on performance timing

12
Enhanced Alarm Clock 2- Concurrency and Sharing
TIME
SET_TIME
TIME
Set
TIME
SET_ALARM_TIME
Timekeeper
ENABLE_ALARM
Alarm Mgr
Set
AL TIME
DISABLE_ALARM
Enable
Disable
On/OFF
SharedResource
Tick
Alarm Clock
13
Concurrent Elements Can Support Analyzability

• Concurrent Element Specifications must convey
• Creation Mechanism Static, Dynamic
• Initiation Timing - Periodic, Aperiodic,
  Statistical
• Algorithmic Behavior ( Logical Behavior Path
  Length)
• Pathological Outcomes ( Behavior Timing)
• Communication and Synchronization
• Cooperation Protocols Resources Used
• Context Sensitive Initiation Conditions ( Guards,
  Barriers)
• Synchronization Protocols

14
Whats Wrong Traditional Resource Management?

• Functional Approach to Family Needs
• Get Groceries
• Take Kids to Soccer
• Buy parts and fix leaky plumbing
• The Traditional Implementation Binding
• Mom will shop for the groceries and take the kids
  to soccer
• Dad will get the hardware and do the plumbing
  repair
• Shared Resource The Family Car
• Actions using the car are SEQUENCED because they
  share the car
• This affects performance
• Families may have multiple cars resource
  allocation based on performance concerns. This
  family has 2 cars (and two drivers)

15
What I Forgot to Tell You

• The Hardware store is adjacent to the market,
  both 5 minutes away
• The soccer field is 45 minutes away through
  traffic!
• From a performance-driven perspective, Mom should
  not do both the soccer task and the grocery task
  using the same car.
• Giving Dad the both the plumbing and the grocery
  jobs will reduce the load on the resources.

16
Sample Notation
Schedulable Resource
Logical Resource
Action
Trigger
Thread
What if the Purchase thread had a 20 minute
deadline ?
17
Performance Analysis

• Using
• Concurrency Model
• Interaction Model
• Worst-case Scenarios
• Timing Parameters- guesses (engineering
  judgment), measurements
• Construct one or more of
• Discrete Event Simulation
• Schedulability Analysis (Analysis)
• Throughput Estimate
• Maintain models throughout implementation
• Start with estimates
• Refine estimates as detailed design is undertaken
• Replace estimates with measurements when possible

18
Real-Time in the Software Life Cycle
Analysis Simulation
19
Summary

• When time constraints are important
• Identify them early
• Define concurrency to support time constraints
• Define interaction protocols
• Use open architectural patterns known to meet
  time constraints
• Do analysis or simulation as soon as concurrency
  is defined
• Make model using performance budgets
• Refine budgets throughout life cycle
• Works just like cost budget process
• Made at project inception
• Tracked throughout project
• When budget breaks, reallocate or add resources,
  or change schedule
• Available from TimeSys TimeWiz (Analysis
  Simulation) Architecture Training Classes