1. Introduction to Open Architecture for Real-Time Systems Dr
Introduction to Open Architecture for Real-Time Systems Dr. Doug Locke Vice 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: For Real-Time Systems
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 Architecture High Level Design
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
Alarm Clock
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
Set
Alarm Mgr
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
Set
TIME
TIME
SET_ALARM_TIME
Timekeeper
ENABLE_ALARM
Set
Alarm Mgr
AL TIME
DISABLE_ALARM
Enable
Disable
Shared Resource
On/OFF
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. What’s 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. What if the Purchase thread had a 20 minute deadline ?
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
Deployment
Final Test
System Test
Unit Test
Code
Low Level Design
High Level Design
Architecture
Requirements
Identify Performance Requirements
Select Architecture Known to Support Real-Time
Separate Performance Requirements Among Elements
Analysis & Simulation
Identify Synchronization Mechanisms
Ensure Correct Synchronization
Check Locks Named & Coded Correctly
Watch for Anomalies Under Load

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