From: Charles Lakos <charles@cs.utas.edu.au>
To: markus.montigel@aut.alcatel.at
Date: Thu, 21 Nov 1996 14:02:25 +1100 (EST)
Subject: Re: Asynchronous i/o, initial state, port assignments

> Date: Wed, 20 Nov 96 11:52:47 +0100
> Subject: (dCPN) Re: Asynchronous i/o, initial state, port assignments
> 
> Claus Reinke made the a proposal concerning asynchronous I/O by introducing
> external port places.  I agree completely that it should be possible to
> feed a CPN with external sensor data for the same reasons Claus mentioned
> already.
> 
> However, the markings of these external port places are then changed by
> some "external force" which isn't modelled in the CPN itself.  IMO this
>  ...
> 
> In this way we could have an automatic run of a net where external
> processes determine which enabled transitions actually occur.  Such a
> testing facility seems to be quite convenient. (Otherwise transitions
> must always be selected by hand).
> 
> Markus Montigel
> Transport Automation Systems
> Alcatel Austria AG
> Scheydgasse 41
> A-1211 Vienna
> Austria
> 
> email:	Markus.Montigel@aut.alcatel.at
> Fax:    +43 1 277 22 173
> Tel:	+43 1 277 22 3476

In summary, Markus suggests:
1. It should be possible to feed a net with external sensor data
2. Doing so via a place affects the analysis of the net
3. It is better to have external processes affect the choice of which
   enabled transitions should occur.

I have some comments based on my own experience of interfacing Object
Petri nets to the outside world:

1. Whichever way you do it - via places or transitions - if the external
   data affects the behaviour of the net, then it will affect the 
   analysis.  The only alternative seems to be to model the external 
   environment and then replace it by the actual environment in the 
   "production" system.

2. This problem highlights for me the importance of being able to
   analyse the behaviour of "open" systems or, if you like, being able
   to perform modular analysis of nets.

3. The desirable form of interaction will be affected by the style of
   implementation of the net simulator.  If the determination of enabled
   transitions is done by polling or in some busy loop, then both place
   and transition interactions seem to be workable.  If, however, discrete
   event simulation techniques are used, i.e. the deposit of a token in
   a place alerts neighbouring transitions of the need to be (re)evaluated,
   then a place form of interaction seems to be preferable.

-- 
Charles Lakos.                               Charles.Lakos@cs.utas.edu.au
Computer Science Department,                 charles@cs.utas.edu.au
University of Tasmania,                      Phone:    +61 03 6226 2959
Sandy Bay, TAS, Australia.                   Fax:      +61 03 6226 2913

---
[[ Post messages and summary of replies:              designCPN@daimi.aau.dk ]]
[[ To (un)subscribe, send "help" to:                  Majordomo@daimi.aau.dk ]]
[[ The moderator's address:                     designCPN-owner@daimi.aau.dk ]]
[[ World Wide Web URL:              http://www.daimi.aau.dk/designCPN/email/ ]]