Shared variables among multiple instances of FSMs

Shared variables among multiple instances of FSMs

Post by charles.d. » Sat, 22 Apr 2006 05:22:08


his is a multi-part message in MIME format.


----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: XXXX@XXXXX.COM
Hi Ptolemy hackers,



Here's the first post, likely of many to come. We are new Ptolemy users
here, although

personally I've followed the project for several years (but never got
around to diving in!).



We're trying to figure out a way to use Ptolemy as a general purpose M&S
tool, and a

modeling strategy for things like usage of resources. A scenario could
be something

like the self-checkout systems at supermarkets - typically there are 4
or so stations

available. When all are in use, customers wait in line until one becomes
available.



We might model each customer's behavior with a state machine, but then
we need a

"global variable" for the number of available stations, which would be
incremented and

decremented by the (concurrent) instances of customers. A (waiting)
customer can

then transition to e.g. a "checkout" state when this variable > 0 and
decrement it on

the way.



I've always had the impression that Ptolemy has a lot of depth, and now,
getting into the

details for real, that is an understatement! We are trying to get up to
speed on how things

work, so as we don't know the theory yet, there could be problems with
this approach, but

we want to try something out, even if it just helps us understand the
dynamics.



We have a simple model with which we're trying to get a grasp on some
basics.



At the top of the model, we have a MultipleInstanceComposite with a
"MIC_out" port to a

Display. Also, there is a "stationsAvailable" parameter, assigned value
4.



Inside the MIC is a ContinuousClock connected to the "trigger" port of a
ModalModel;

the MM has output ports "stations" and "bagging", going to MIC_out.



Currently the only output actions are to write some test strings to the
MM's output ports.



Issues we're having:

1. Can't seem to figure out how to get the concurrent FSMs to be
able to see the top
level parameter (again, could be a bad idea, just trying it for now...)
2. Using DEDirector, I got a complaint that something with a
HSDirector can only
be used in a CTDomain; don't know what HSDirector is, but I switched to
CT
3. No output on Display...



We are continuing in the manuals, but wanted perhaps to get a bit of a
reality check...



Thanks in advance for any input / tips / warnings / etc...



Chuck Lutz

Lockheed Martin

Systems of Systems - Modeling and Operations Analysis

BMC4I Modeling and Simulation

Moorestown, NJ

(856)638-7234 (office)

XXXX@XXXXX.COM



"Everyone spoke of an information overload, but what there

was in fact was a non-information overload."

- Richard Saul Wurman




<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
spa
 
 
 

Shared variables among multiple instances of FSMs

Post by eal » Sat, 22 Apr 2006 10:21:00

Dear Chuck:

I would be happy to try to help out, but would probably need
to see the model to understand what it does (or doesn't do).
I suspect that you need a purely DE model, rather than a
hybrid CT/DE model, which might simplify things.

As for parameter scoping: Every parameter is visible
to everything below it in the hierarchy. It is not
advisable, however, to change values of a parameter
above you in the hierarchy (it may be possible, but
I would have to look up the syntax, and would prefer
not to, since it will cause trouble later). The
problem is that you may get unexpected nondeterminism
(where the result of an execution depends on arbitrary
decisions that the scheduler makes). Changing parameter
values below the ModalModel is fine... The semantics
here is clean and well-defined. You can do this
using transition actions on the ModalModel transitions.
If the parameter named y is inside a mode named x
then the transition action reads "y.x = new value".

Hope this helps. Feel free to send me (or the list)
a model to look at.

Edward


At 01:22 PM 4/20/2006, Lutz, Charles D wrote:

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
XXXX@XXXXX.COM , http://ptolemy.eecs.berkeley.edu/~eal



----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: XXXX@XXXXX.COM

 
 
 

Shared variables among multiple instances of FSMs

Post by charles.d. » Sun, 23 Apr 2006 07:06:19

his is a multi-part message in MIME format.



----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: XXXX@XXXXX.COM

hi Hackers,



Here is the second model, "OldMICversion1.xml". Thanks!



Chuck Lutz

Lockheed Martin

Systems of Systems - Modeling and Operations Analysis

BMC4I Modeling and Simulation

Moorestown, NJ

(856)638-7234 (office)

XXXX@XXXXX.COM



"Everyone spoke of an information overload, but what there

was in fact was a non-information overload."

- Richard Saul Wurman




<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>hi Hackers,</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Here is the second model, “OldMICversion1.xml”.
Thanks!</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>

<p class=MsoNormal><strong><b><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Chuck Lutz</span></font></b></strong></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Lockheed Martin</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Systems of Systems - Modeling and Operations Analysis</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>BMC4I Modeling and Simulation</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Moorestown</span></font><font size=2 face=Arial><span
style='font-size:10.0pt;font-family:Arial'>, </span></font><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>NJ</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>(856)638-7234 (office)</span></font>&
 
 
 

Shared variables among multiple instances of FSMs

Post by charles.d. » Tue, 25 Apr 2006 22:47:15

i Prof. Lee,

Thanks very much for the reply. I'm looking over the two models to
try to let it sink in... and diving into more docs to help as well.

I used to work for a Swedish s/w company, Telelogic, which "back in
the day" made SDL tools and are now a UML 2 vendor, so I definitely
have a certain FSM semantics "baggage" I'm bringing along here.

The idea that the FSM could fire > 1 transition at once (based on
the "trigger == 1" guard), let alone fire an infinite number in zero
time, is a notion I'd forgotten. Quite cool stuff indeed. I don't re-
call if that is how things work in Harel-like FSMs... haven't looked
at the theory in a while (yep, got your June '99 paper on my desk...)

I had sent two models in as many emails; unfortunately the first did
not make it through the size limit. I will tweak and resend that as it
touched on some other general concepts of how we are approaching our
work in Ptolemy.

I will have to go read up on the time advancement issue you discussed.
That's got me stumped a bit, but a look at the CT semantics should
help. I guess my asking it to animate the states for 1s per entry is
the only reason things seem to be moving along as I had intended.

Thanks!
Chuck Lutz

-----Original Message-----
From: Edward A. Lee [mailto: XXXX@XXXXX.COM ]
Sent: Saturday, April 22, 2006 12:37 AM
To: Lutz, Charles D
Cc: XXXX@XXXXX.COM
Subject: RE: Shared variables among multiple instances of FSMs


I think that what's going on in your model is that when the
output of the ContinuousClock goes to 1, the ModalModel
starts switching states without letting time advance any
further. This is the right behavior under CT semantics,
since the guard on both transitions is "trigger == 1", and
hence when the trigger input has value 1, both guards are
true. Your model specifies an infinite number of state
transitions in zero time.

In the attached model, I made the following changes:

- changed the outside director to DEDirector
- removed the inside director
- changed the ContinuousClock to Clock
- changed the directorClass parameter of the ModalModel
to ptolemy.domains.fsm.kernel.FSMDirector (note that this
would have been the default if you had first used the ModalModel
with DEDirector).
- set the synchronizeToRealTime parameter of the director to true.

I think you really want DE, not CT for this type of model.
CT is useful when you have continuous dynamics (given by ordinary
differential equations). It has much more subtle semantics that
cleanly support hybrid systems (mixing continuous dynamics with
discrete dynamics). Your model, in fact, is a hybrid system with
Zeno behavior. See:

http://ptolemy.eecs.berkeley.edu/publications/papers/05/OperationalSeman
tics/

DE is much simpler. In the attached model, each time the Clock
generates
an output, the ModalModel executes one transition. Replace the Clock
with PoissonClock and you get a much more interesting model with random
behavior...

Hope this helps.

Edward

At 03:06 PM 4/21/2006, Lutz, Charles D wrote:

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
XXXX@XXXXX.COM , http://ptolemy.eecs.berkeley.edu/~eal

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing