Agilent Technologies Research Intern Report RunTime Models for

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

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

Measurement and Control Systems are Distributed, Real-Time, & Reactive l Distributed – – l Reactive – l Sensor nodes Computational nodes Actuator nodes Communication system 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 l Aggregation of interacting software components A B C l A model of run-time software defines: – – – l 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.

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

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

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

Run-Time Models in Ptolemy II model schedule preemptive message semantics trigger timed SDF event time static - no FSM event time/ event dynamic no no RTP state dynamic yes no TSDE event time/ event dynamic no yes

Synchronous Dataflow (SDF) model schedule preemptive message semantics trigger timed SDF event time static - no FSM event time/ event dynamic no no RTP state event dynamic yes no TSDE event time/ event dynamic no yes

Synchronous Dataflow B A l l Analysis: 1 1 1 3 2 C 2 2 2 D l. Components: Functional blocks l. Communication: FIFO queue l. Requirement: Fixed consumption and production rate l. Execution: Static scheduled (AAACBBD) safety liveness bounded memory response time Match well with time-triggered approach Not so expressive Hard to handle emergent events

Finite State Machine (FSM) message semantics trigger schedule preemptive timed SDF event time static - no FSM event time/ event dynamic no no RTP state event dynamic yes no TSDE event time/ event dynamic no yes model

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

Real-Time Processes (RTP) message semantics trigger schedule preemptive timed SDF event time static - no FSM event time/ event dynamic no no RTP state event dynamic yes no TSDE event time/ event dynamic no yes model

Real-Time Processes B A l l Analysis: l. Components: processes l. Communication: state semantics l. Requirement: static priorities blocking read l. Execution: preemptive, event driven D C safety liveness bounded memory response time some Match well with ET architectures Easy for handling urgent events Nondeterministic, Not predictable.

Time-Synced Discrete Event (TSDE) message semantics trigger schedule preemptive timed SDF event time static - no FSM event time/ event dynamic no no RTP state event dynamic yes no TSDE event time/ event dynamic no yes model

Discrete Event (DE) A C B l l l 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

Faster-Than-Real-Time Computation l Not all events have real-world counter parts – Map between model time and real time only when necessary x l If we have: – – – l x Sensor Actuator Computer 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

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

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

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

Example: Control Law l up edge l down edge l l l 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 ’ /2 sensor ’/2 actuator

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

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

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

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

Example: Acquisition Mode l l Time. Sync. DE Synchronized data acq Faster-than-real-time computation Time-bombed reader and writer Global. Time Read. Burst 1 suffix Read. Burst 2 D 1 D 2 D 3 TSDE Time. Bomb complete

Example: Analysis Mode l l SDF Implicitly timed Equidistance-sampled data signal processing log 1 log 2 512 64 1 FFT ramp scope 512 64 FFT SDF =? 512 finish

Conclusion l There a variety of run-time software models Real-time software prioritized preemptive multitask. l l 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 l Agilent Systems and Solutions Lab Stan Jefferson John Eidson Stan Woods Jeff Burch Jerry Liu l Steve Greenbaum Randy Coverstone Hans Sitte Bruce Hamilton Ptolemy Group THANK YOU!