Run-Time Models for Measurement & Control Systems and Their Support in Ptolemy II Jie Liu EECS, UC Berkeley 9/13/2000 Agilent Technologies Research Intern Report

Outline Overview and Classification of Run-Time Models for MC systems Run-time models in Ptolemy II – Synchronous Dataflow – Finite State Machine – Real-Time Processes – Time-Synced Discrete Event Composing run-time models Demos new

Measurement and Control Systems are Distributed, Real-Time, & Reactive Distributed – Sensor nodes – Computational nodes – Actuator nodes – Communication system Reactive – React to its environment at the speed of the environment Real-Time – Directly Interact with Physical World – Constrains on response delays

Run-Time Software in Computational Nodes Aggregation of interacting software components A model of run-time software defines: – What the components are – How they execute – How they exchange messages Models provide properties that can be used to reason about safety, liveness, performance, and scalability. AB C

Messages in MC Systems Message Source – Internal – External Acquisition Style – Push – Pull Message Semantics – Event: Every event matters. – State: Only the newest state matters.

Event-Triggered and Time-Triggered Architectures What triggers a reaction? – Event Unpredictable Interrupts Easy to distribute – Time Predictable Polled Hard to distribute # of events/second system load ETA TTA H. Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications

Scheduling in Real-Time Systems Static Scheduling – Fixed order of execution (non-prioritized) – Predictable response time – Urgent events may be delayed Dynamic Scheduling – Prioritized execution Static priority v.s. dynamic priority – Preemptive or Non-preemptive

Run-Time Models in Ptolemy II modelmessage semantics triggerschedule preemptive timed SDFeventtimestatic-no FSMeventtime/ event dynamicno RTPstatetime/ event dynamicyesno TSDEevent dynamicnoyes

Synchronous Dataflow (SDF) modelmessage semantics triggerschedule preemptive timed SDFeventtimestatic-no FSMeventtime/ event dynamicno RTPstateeventdynamicyesno TSDEeventtime/ event dynamicnoyes

Synchronous Dataflow Analysis: Match well with time-triggered approach Not so expressive Hard to handle emergent events BD C A Components: Functional blocks Communication: FIFO queue Requirement: Fixed consumption and production rate Execution: Static scheduled (AAACBBD) safetyliveness bounded memory response time 

Finite State Machine (FSM) modelmessage semantics triggerschedule preemptive timed SDFeventtimestatic-no FSMeventtime/ event dynamicno RTPstateeventdynamicyesno TSDEeventtime/ event dynamicnoyes

Finite State Machine A C B guard/action Components: states Communication: transitions Requirement: finite states, atomic transitions Execution: events trigger transitions Analysis: Match well with both ET and TT architectures Not so expressive Sequential safetyliveness bounded memory response time  some

Real-Time Processes (RTP) modelmessage semantics triggerschedule preemptive timed SDFeventtimestatic-no FSMeventtime/ event dynamicno RTPstateeventdynamicyesno TSDEeventtime/ event dynamicnoyes

Real-Time Processes BD CA Components: processes Communication: state semantics Requirement: static priorities blocking read Execution: preemptive, event driven Analysis: Match well with ET architectures Easy for handling urgent events Nondeterministic, Not predictable. safetyliveness bounded memory response time  some

Time-Synced Discrete Event (TSDE) modelmessage semantics triggerschedule preemptive timed SDFeventtimestatic-no FSMeventtime/ event dynamicno RTPstateeventdynamicyesno TSDEeventtime/ event dynamicnoyes

Discrete Event (DE) Global notion of model time Components: functional blocks react to input events Communication: event = (time_tag, data_token) Require: Components are causal Execution: Event-driven execution Global event queue, sorting events in their chronological order B CA

Faster-Than-Real-Time Computation Not all events have real-world counter parts – Map between model time and real time only when necessary If we have: – Global notion of the “real” time (time-sync protocol) – Time-stamped sensor data – “Time-bomb” feature We benefit: – Tolerance to communication and computation jitters – Easiness of distributing and scaling up – Possibility of distributed synchronized operations Sensor Computer x x Actuator

Causality Subtlety Event in the past! Sensor Computer xx Actuator xxx x x Conditions to resolve the causality subtlety – Synchronous/Reactive assumption – Predictable inputs assumption – Side-effect-free assumption – Rollbackable computation assumption

Time-Synced Discrete Event Analysis Match with ET and TT architectures Directly reason about time Need infrastructure support Have causality subtlety safetyliveness bounded memory response time  some

Example: Discrete Event Control N + NCAP Excite the beam using zero-crossing events Time-stamped event triggering Time-Synced sensor, computation, and actuator

Example: Control Law Time-stamped sensor data Estimate the peak time. Control magnitude by setting time bombs Adaptive to change of physical dynamics Tolerate communication and computation latency sensor actuator up edge down edge control law /2 ’/2 ’

Composing Multiple Models controller b c a mode d controller actuator smoother actuator sensor d

Example: A Data Acquisition & Analysis System N + A B NCAP Time-triggered and event-triggered sequential operations Time-synced sensor data acquisition Composition of timed and untimed models

Example: Top-level sequential operations Settling Data Acquisition Analysis ready complete finish

Example: Settling Mode SDF – untimed model Streamed-data as fast as it can Best-effort computation Event detection sensor1 sensor2 |max-min|<d && ready SDF

Example: Acquisition Mode TimeSyncDE Synchronized data acq Faster-than-real-time computation Time-bombed reader and writer ReadBurst1 ReadBurst2 D1 D2 D3TimeBomb GlobalTime suffix complete TSDE

Example: Analysis Mode SDF Implicitly timed Equidistance-sampled data signal processing log1 log2 FFT scope 512 SDF ramp =? finish 1

Conclusion There are a variety of run-time software models Real-time software  prioritized preemptive multitask. Time-Synced Architecture opens new opportunities Choosing models are application dependent Usually need to compose more than one model Ptolemy II is a laboratory for exploring the models and composition

Acknowledgement Agilent Systems and Solutions Lab Stan JeffersonSteve Greenbaum John EidsonRandy Coverstone Stan WoodsHans Sitte Jeff BurchBruce Hamilton Jerry Liu Ptolemy Group THANK YOU!