520 likes | 856 Views
Hybrid Systems Concurrent Models of Computation. EEN 417 Fall 2013. HYBRID SYSTEMS. Discrete System (FSM). Continuous System. jump. Hybrid System. flow. Examples of Hybrid Systems The Hybrid Automaton Model properties of this kind of model. Topics in Today ’ s Lecture.
E N D
Hybrid SystemsConcurrent Models of Computation EEN 417 Fall 2013
Discrete System (FSM) Continuous System jump Hybrid System flow
Examples of Hybrid Systems The Hybrid Automaton Model properties of this kind of model Topics in Today’s Lecture
A Thermostat (happen instantaneously)
Dynamics of Thermostat x 82 80 70 68 t on off
Hybrid Automaton for Thermostat Is this automaton deterministic?
Digital controller of physical “plant” thermostat controller for power plant intelligent cruise control in cars aircraft auto pilot Phased operation of natural phenomena bouncing ball biological cell growth Multi-agent systems ground and air transportation systems interacting robots (e.g., RoboSoccer) Where do Hybrid Systems arise?
Another example Change in Temperature Example due to George Pappas, UPenn
Nuclear reactor example (contd.) Each time step, T, y1, and y2 change. Example due to George Pappas, UPenn
Hybrid Automaton for Bouncing Ball x – vertical distance from ground (position) v – velocity c – coefficient of restitution, 0 ·c· 1
Behavior of Bouncing Ball Automaton: Plot position x as a function of time t , where x starts at height xmax What kind of plot would you expect?
Simulation of Bouncing Ball Automaton in Ptolemy II / HyVisual
Zeno Behavior What is a Zeno machine?
Informally: The system makes an infinite number of jumps in finite time Zeno Behavior
Our model is a mathematical artifact Why does Zeno Behavior Arise?
Our model is a mathematical artifact Zeno behavior is mathematically possible, but it is infeasible in the real, physical world Points to some unrealistic assumption in the model Why does Zeno Behavior Arise?
Recall: Actor Model for State Machines • Expose inputs and outputs, enabling composition:
A system is a function that accepts an input signal and yields an output signal. The domain and range of the system function are sets of signals, which themselves are functions. Parameters may affect the definition of the function S. Recall: Actor Model of Continuous-Time Systems
Input is the net torque of the tail rotor and the top rotor. Output is the angular velocity around the y axis. Example: Actor model of the helicopter Parameters of the model are shown in the box. The input and output relation is given by the equation to the right.
Recall: Feedback Composition Angular velocity appears on both sides. The semantics (meaning) of the model is the solution to this equation.
A model of computation assigns semantics (meaning) to the syntax defined in the actor model. The MoC gives operational rules for executing a model. These rules determine when actors perform internal computation, update their internal state, and perform external communication. An MoC also defines the nature of communication between components (e.g., buffered I/O). Models of Computation (MoC)
Discrete-time helicopter model looks the same: Discrete-Time (DT) Actor Models
Time-Triggered Reactions of FSMs use a Discrete-Time MoC sigY sigG sigR sigR pedG pedR
A more reasonable model of a discrete helicopter controller would be a mixed-signal model: Here, the signals inside the blue area are continuous-time signals, and the ones outside are discrete-time signals. Mixed Signal Models
To jointly model discrete and continuous-time signals in the same MoC, use the notion of “absent” values Event-triggered composition of state machines uses a discrete-event MoC.
Imperative, Threads, Declarative physical models, Constraints, … Actors are not the only way to do things Modelica model of an industrial robot. Modelica uses Spice-like models where components have no inputs or outputs.
A preferable schedule would space invocations of A and B uniformly in time, as in: Uniformly Timed Schedule … minimum latency
Notice that in this schedule, the rate at which A and B can be invoked is limited by the execution time of C. Non-Concurrent Uniformly Timed Schedule … No jitter, but utilization is poor.
With preemption, the rate at which A and B can be invoked is limited only by total computation: Concurrent Uniformly Timed Schedule:Preemptive schedule … thread 1: high priority preemptions … thread 2: low priority
In steady-state, the execution follows a simple periodic pattern: Ignoring Initial Transients,Abstract to Periodic Tasks sampleTime = 8 sampleTime = 1 sampleTime = 1 This follows the principles of rate-monotonic scheduling (RMS). … thread 1: … thread 2:
If the execution of C runs longer than expected, data determinacy requires that thread 1 be delayed accordingly. This can be accomplished with semaphore synchronization. But there are alternatives: Throw an exception to indicate timing failure. “Anytime” computation: use incomplete results of C Requirement 1 for Determinacy: Periodicity interlock sampleTime: 8 … thread 1: sampleTime: 1 sampleTime: 1 … thread 2:
If the execution of C runs shorter than expected, data determinacy requires that thread 2 be delayed accordingly. That is, it must not start the next execution of C before the data is available. Requirement 1 for Determinacy: Periodicity sampleTime: 8 … thread 1: sampleTime: 1 sampleTime: 1 … thread 2: interlock
Note that semaphore synchronization is not required if actor B runs long because its thread has higher priority. Everything else is automatically delayed. Semaphore Synchronization Required Exactly Twice Per Major Period sampleTime: 8 … thread 1: sampleTime: 1 sampleTime: 1 … thread 2:
What about more complicated rate conversions (e.g. a task with sampleTime 2 feeding one with sampleTime 3)? How can these ideas be extended to non-periodic execution? Discussion Questions
Suppose that C requires 8 data values from A to execute. Suppose further that C takes much longer to execute than A or B. Then a schedule might look like this: Abstracted Version of the Spectrum Example 8 1 1 …
For next time Read Chapters 10, 11