Modeling continuous-time sub-systems in Metropolis

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 dont necessarily affect the dynamics of
  the system

6
Formal 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
7
Formal 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
8
Formal 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
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
DT2M
M2DT
Medium
CT2M
M2CT
CT
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
DT2M
M2DT
Medium
M2CT
CT2M
CT
11
Examples Tank level control
Tank level
Controller
Control
Actuator
Sensor
Tank
12
Examples Bouncing ball
Position
Event observer
Acquisition
Event detection
Sensor
Ball
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