1 / 29

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

This report provides an overview and classification of run-time models for measurement and control systems, specifically focusing on the Synchronous Dataflow, Finite State Machine, Real-Time Processes, and Time-Synced Discrete Event models in Ptolemy II. It also discusses the composition of these models and their support in distributed, real-time, and reactive systems.

pberkowitz
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related