Title: Modeling continuous-time sub-systems in Metropolis
1Modeling continuous-time sub-systems in
Metropolis
EE249 project 12/3/02
Mentors Claudio Pinello Felice Balarin Yosinori
Watanabe Howard Wong-Ton
2Outline
- 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
3Introduction
- 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
4Timed and untimed MoCs
???
5Application 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 dont necessarily affect the dynamics of
the system
6Formal analysis of the interface (1)
1) Eliminating deadlocks X(w) gt X(r) ? T(w) gt
T(r) if CT has no instantaneous mapping X(w)
? X(r) ? T(w) ? T(r)
DT
w
r
w
r
CT
T1
- 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)
T3
T2
X
7Formal analysis of the interface (2)
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)
DT
w
r
w
r
CT
T1
T3
- 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)
T2
T2
X
8Formal analysis of the interface (3)
3) Eliminating the possibility of computing the
same trajectory many times X(r) ? X(r) ? T(r)
? T(r)
DT
w
r
w
r
CT
T1
- 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)
T3
T2
X
9Implementation 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
DT2M
M2DT
Medium
CT2M
M2CT
CT
10Implementation 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
DT2M
M2DT
Medium
M2CT
CT2M
CT
11Examples Tank level control
Tank level
Controller
Control
Actuator
Sensor
Tank
12Examples Bouncing ball
Position
Event observer
Acquisition
Event detection
Sensor
Ball
13Conclusions
- 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