From: Claus Reinke To: designCPN@daimi.aau.dk Date: Thu, 21 Nov 1996 13:41:07 +0100 (MET) Subject: Communication with external processes As the discussion focuses on the interface between nets and the external world, I have changed the subject line. > Charles Lakos # Soren Christensen > 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. One advantage of the external port version is that it is simple to do the replacement: Just model the environment superpage and use the original net as a substitution transition either in this explicit superpage or in the implicit superpage of the real environment. This should be helpful both for analysis and for testing. > 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. Agreed. And if it should not be possible to analyse a subpage at least partially without knowing its embedding, this would only hint at a problem with the modularization based on substitution transitions, not at a problem with the external port idea. Both Charles and Soren mention that there may be more than one correct way to do the interfacing: > 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. Associating transition and place based interfaces with different styles of interactions seems reasonable, but I would rather not let the choice of the interaction model depend on the current implementation. It may very well be that case that one of the choices reflects the implementation more closely, but the abstract model should hide the implementation decision, providing a mapping from both abstract forms of interaction to whatever the current implementation uses. # It could be nice to have a general way of communication with exterior # processes, but I think there are more candidates for such an interface. # Especially the discussion of synchronous vs. asynchronous communication # becomes an issue. While it is true that there may be many candidates for the interface, it seems as if not all of them have found the same attention yet. I know that Soren has been working on synchronous communication inside nets, so currently the situation presents itself as follows (at least to me): communication | asynchronous synchronous --------------+-------------+------------------- internal | standard research topic external | ??? implemented This is rather disappointing as external ports seem to fit very naturally into the existing formalism. In particular, they could serve as an intermediate solution until there is an agreement on a better style of interfacing. They could be added and, if necessary, removed in a rather smooth transition: Adding them would not break existing models and if they should really need to be replaced by another concept later, it would only be necessary to actually specify the now imaginary superpage in terms of the new concept. Ultimately, it would be nice to have both asynchronous and synchronous communication facilities on both levels, so that the one most suitable for the problem in question could be used for modeling. -- Claus Reinke University of Kiel email: cr@informatik.uni-kiel.de Department of Computer Science http://www.informatik.uni-kiel.de/~cr/ Preusserstr. 1-9, 24105 Kiel --- [[ 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/ ]]