Introduction to Open Architecture for Real-Time Systems Dr Introduction to Open Architecture for Real-Time Systems Dr. Doug Locke Vice President of Technology

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

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

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!

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

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.

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

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

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!

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

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

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

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

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)

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.

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 ?

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

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

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