From: schristensen@daimi.aau.dk (Soren Christensen) To: designCPN@daimi.aau.dk Date: Wed, 20 Nov 1996 10:15:08 +0100 Subject: Re: Asynchronous i/o, initial state, port assignments Claus Reinke, Thanks for posting your suggestions! It is very nice to have a discussion on these topics in this forum. >This letter contains some proposals for extensions/modifications of >Design/CPN which arose from my practical experiences with the tool. > >I am sending it to the mailing list because it seems very likely that >others could make similar proposals based on the problems they >encountered. A discussion of such problems and proposals could help >to improve the tool and the formalism. Nevertheless, the section >'Proposals From Users` in the Design/CPN WWW pages is still empty... We will put your proposals in. >To the CPN group: there is a (small;-) chance that some of these >proposals may require only minor modifications of the implementation, >and I could really use all of them. What do you think about it? Below you will find my immediate comments. > >--------------- Proposals: > >1) Asynchronous input/output via external ports > 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. This is a major extension! And it will definitely not be done inside the near future. But of course it all depends on our resources - so if funding is provided it could be done. > Soren Christensen gave an example on how to achieve communication > with external processes with current means, assuming some limitations: > > > 1) the external process can be started as a sub-process. > > 2) the communication will be done using std_in/std_out of the sub-process. > ... > > In this way it is possible for the simulation to control an external > > process, the other way is much harder! > > The last remark shows up a real problem: Once you have modeled a real > system by a net, it seems natural to try and control the system by a > simulation run on the net model. However, this gets impracticable as > there seems to be no simple way to distribute sensor data from the > real system to the corresponding places in the net model. > > IMO, the reason for the problems is the way in which external > communication is (or rather: cannot be) integrated into the net > model. Communication happens by side-effecting > input/output-operations in code-regions and is thus synchronous with > the firing of some transitions. The enabling of these transitions, > however, cannot depend on any input-operation, which makes input > harder than output. > > In contrast to these input/output-operations, the standard model of > communication in Petri nets is asynchronous. In other words, it would > be much more natural to connect input/output to places instead of > transitions. > > The idea, at least, is very simple: introduce external port places. > > The whole CPN-net can be seen as a subnet of the runtime > environment. The environment superpage, which instantiates the > CPN-net as a substitution transition, is not modeled as a net, but > there needs to be a way to describe the external port assignments. > These could be defined in the global declaration node (probably > associating each external port with an i/o-stream or with a function > that does i/o). > > The simulation would have to check for input data on streams and for > output tokens on external ports. Input data would have to be > converted into tokens on external ports and output tokens into data for > output streams. Place capacities for external ports may be helpful, > but could be modeled by pairs of communication buffers as usual in > Petri nets. > >2) Initial state, side-effects and initial markings > > As of now, the code in the global declaration node is evaluated only > once (during the switch from the editor to the simulator). Similarly, > initial markings are not reevaluated if 'Initial State' is selected. > Of course, the manual states that side-effecting code is only allowed > in code regions, so this should not matter (and I am certainly not a > fan of side-effecting code;-). However, in lack of a better solution > and since ML depends on side-effects for i/o, it may be a good idea > to provide at least a 'hook' for users to include their own > initialization code into the state initialization (e.g., if there is > a function named 'init' in the global declaration node, it will be > called at switch time and whenever 'Initial State' is selected from > the menu). As the code of 'init' may have influence on the values of > the initial markings, they would need to be reevaluated instead of > simply being reinstantiated on every initialization. In the current version you can do this by adding a transition to initialise the markings. You can isolate this on a separate page - by means of place fusion's, and you can use a code segment to load the values from a text file. The input'ms functions which can be declared for colors are tailored for exactly this use. > This would also allow to load initial markings from a text file and > to modify this file prior to an initialization, or to have multiple > files with initial markings for one net. The existing 'Save State' > seems to copy the whole net and doesn't work with a textual > representation. > > External port assignments and the initialization of subprocesses > should go into 'init', too. > >3) Port assignments > > Last, but not least, please do anything to make port assignments > easier. Also, any tool support to ensure consistency of port > assignments during modifications of the net would be appreciated. As you indicate by the eclipse in the end of your list there are a lot of possibilities in this area. In Design/CPN 3.0 there are already some support: Working top-down, i.e., using the "move to subpage" command, makes the port-socket assignment totally automatic. And when you use the "substitution transition" command the port-socket assignment applies the following rules: 1) If there is a single element of a given port type (input / output / input-output) then the assignment is done. 2) If there is a unique match of names of a given port type, the assignments are done. It is often possible (convenient?) to use the above rules anyway. > - key shortcut for port assignments OK., we have a general problem that it is hard to find shortcuts, since we would like these to be the same for both the Mac and the UNIX platform. > - highlighting of not yet assigned sockets (ports?) Note that port/socket pairs having the same names are not shown in the hierarchy region of the substitution. Unassigned sockets are shown as ---> ???). There is no indication of unassigned ports. We can discuss this, but as far as I remember the argument for this decision was that it is not required to assign all ports. This is also reflected in the way initial markings of port/sockets work: if a port is assigned it initial marking will be taken form the socket, but if a port is not assigned it will have the initial marking specified for the port place. I.e., unassigned port places can have "default values" specified in the initial markings. > - copying a substitution transitions including its hierarchy region, > its socket places and its port assignments should be possible Port/socket assignments are not preserved by copy/cut/paste operations, but it is preserved by duplicate and move. Try these I think they will do what you want. > - when connecting a place to a substitution transition, immediately > ask for the port assignment (this should be optional, configurable > via interface options). > Allow to introduce a new port place here, if necessary. > - introducing a new port in the subnet should introduce new sockets > assigned to this port in all existing instances > ... If you have a simple suggestion which would effectively improve the solution we have - please let us know! I'm not at all sure the ones you suggest are the "right" ones.... Best regards, Soren Christensen --------------------------------------------------------------------- | Soren Christensen, Computer Science Department, Aarhus University | | Ny Munkegade 116, DK-8000 Aarhus C, DENMARK | | email: schristensen@daimi.aau.dk | phone: +45 89 42 32 65 | | telefax: +45 89 42 32 55 | phone at home: +45 86 93 63 26 | | WWW URL: | --------------------------------------------------------------------- --- [[ 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/ ]]