1 Modeling continuous-time sub-systems in Metropolis Gabriel Eirea EE249 project 12/3/02 Mentors: Claudio Pinello Felice Balarin Yosinori Watanabe Howard Wong-Ton

2 Outline Introduction Application scenarios – Sampled-data systems – Hybrid systems – Event-driven systems Formal analysis of the interface Implementation in Metropolis meta-model Examples – Tank level control – Bouncing ball Conclusions

3 Introduction Metropolis: design environment for heterogeneous embedded systems In many applications (e.g., embedded control) it is useful to model the interaction with a physical process Modeling continuous-time sub-system enables simulation and analysis at an early stage in the design process Main challenge: interaction between timed and untimed MoCs

4 Timed and untimed MoCs ???

5 Application scenarios Sampled-data systems – read and write values at discrete time – typically write values to a zero-order hold – usually periodic Hybrid systems – dynamics change abruptly when state reaches certain values or when an external command is applied – discrete transitions are inherent to the dynamics of the system – modeled as FSM with ODEs assigned to each state Event-driven systems – events generated when state reaches certain values – events don’t necessarily affect the dynamics of the system

6 Formal analysis of the interface (1) events on the interface – w: write (DT  CT) – r: read (CT  DT) each event e has two tags – execution index X(e) – time tag T(e) DT CT wr 1)Eliminating deadlocks X(w) > X(r)  T(w) > T(r) if CT has no instantaneous mapping: X(w)  X(r)  T(w)  T(r) X wr T=1 T=2 T=3

7 Formal analysis of the interface (2) events on the interface – w: write (DT  CT) – r: read (CT  DT) each event e has two tags – execution index X(e) – time tag T(e) DT CT wr 2)Eliminating the need of unbounded queues at the inputs X(w’)  X(w)  T(w’)  T(w) X(r)  X(w)  T(r)  T(w) X wr T=1 T=2 T=3

8 Formal analysis of the interface (3) events on the interface – w: write (DT  CT) – r: read (CT  DT) each event e has two tags – execution index X(e) – time tag T(e) DT CT wr 3)Eliminating the possibility of computing the same trajectory many times X(r’)  X(r)  T(r’)  T(r) X wr T=1 T=2 T=3

9 Implementation in Metropolis meta-model If all the events on the interface are annotated with the GlobalTime quantity  1) + 2) + 3) are satisfied Four interfaces: – DT2M – M2DT – M2CT – CT2M Time is resolved at the medium CT integrates the ODE when a write or a read event occurs If CT detects an event, it is communicated to the medium DT CT Medium DT2M M2CT CT2M M2DT

10 Implementation in Metropolis meta-model interface DT2M extends Port { update void writeInput(double value); } interface M2CT extends Port { update boolean haveWriteReq(); update double getWriteTime(); update double receiveInput(); } interface CT2M extends Port { update boolean haveReadReq(); update double getReadTime(); update void issueOutput(double value, boolean event_detected, double time_event); } interface M2DT extends Port { update double readOutput(); update boolean eventDetected(); } DT CT Medium DT2M M2CTCT2M M2DT

11 Examples: Tank level control Tank level Control Controller Tank ActuatorSensor

12 Examples: Bouncing ball Position Event detection Acquisition Sensor Ball Event observer

13 Conclusions The events on the interface between the DT and CT sub-systems have to be ordered somehow ODE integration should be a task for the simulator, not the meta-model – extend meta-model to support the description of a CT sub-system using some notation for ODEs Examples shown can be used as a template to model a wide range of CT sub-systems Ongoing work: a more complex event-driven system