Run-Time Models for Measurement & Control Systems and Their Support in Ptolemy II

1. 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

2. 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 new

3. Measurement and Control Systems areDistributed,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

4. A B C 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.

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

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

7. 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

8. Run-Time Models in Ptolemy II

9. Synchronous Dataflow (SDF)

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

11. Finite State Machine (FSM)

12. Finite State Machine • Components: states • Communication: transitions • Requirement: finite states, atomic transitions • Execution: events trigger transitions guard/action A B C • Analysis: • Match well with both ET and TT architectures • Not so expressive • Sequential

13. Real-Time Processes (RTP)

14. Real-Time Processes • Components: processes • Communication: state semantics • Requirement: static priorities blocking read • Execution: preemptive, event driven B D A C • Analysis: • Match well with ET architectures • Easy for handling urgent events • Nondeterministic, Not predictable.

15. Time-Synced Discrete Event (TSDE)

16. Discrete Event (DE) • Global notion of modeltime • 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 A C B

17. 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 Actuator x Computer x

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

19. Time-Synced Discrete Event • Analysis • Match with ET and TT architectures • Directly reason about time • Need infrastructure support • Have causality subtlety

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

21. 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 up edge down edge  ’ sensor control law /2 ’/2 actuator

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

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

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

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

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

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

28. 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

29. Acknowledgement • Agilent Systems and Solutions Lab Stan Jefferson Steve Greenbaum John Eidson Randy Coverstone Stan Woods Hans Sitte Jeff Burch Bruce Hamilton Jerry Liu • Ptolemy Group THANK YOU!