A MULTIUSER TOOL FOR GRAPHICAL SIMULATION OF PETRI

GAPS { A MULTIUSER TOOL FOR GRAPHICAL SIMULATION OF PETRI NETS Andreas Oberweis, Volker Sanger, Wolfgang Weitz Institut AIFB Universitat Karlsruhe D-76128 Karlsruhe Germany E-Mail: f oberweis j saenger j weitz [email protected]

ABSTRACT In this paper we present Gaps, a tool for the graphical design and simulation of Petri nets. Gaps provides a multiuser environment with a graphical net editor and animation of the Petri net simulation. Furthermore Gaps allows an easy integration of problem speci c visualization components. The possibility of adding external visualization and interaction clients supports the system developer in the rst place but this concept is also well suited to provide a basis for discussions with persons unfamiliar with the Petri net formalism.

1 INTRODUCTION

In the last few years, dynamic modelling techniques have become more and more important in the area of information system development (Sol et al. 1992). INCOME/STAR is an integrated CASE environment for the cooperative development of large distributed software systems. It integrates semantic data modelling and Petri net based behaviour modelling. Both sub-models are strongly related to each other because the activities speci ed in the behaviour model operate on the objects speci ed in the (static) data model. The development process is controlled by the ProMISE (Scherrer et al. 1994) process model. Whereas (Mochel et al. 1993) gives a general overview about the simulation component of INCOME/STAR, this paper focuses on aspects of simulation in a multiuser environment to support the cooperative design of large Petri net models. In INCOME/STAR the dynamic behaviour of the

system to be developed is modelled with high-level Petri Nets which allow an integrated speci cation of data ob-

jects and operations performed on these objects. While being a well-founded formalism for modelling dynamic system behaviour, Petri nets also have a natural graphical representation. In this way they oer a good basis for communicating the (intermediary) results of the design process to the customer.

2 MODELLING WITH Pr/T NETS: BASIC CONCEPTS

In the course of time, several variants of Petri Nets have been developed. One of these are the so-called Predicate/Transition-Nets (Pr/T-Nets) (Genrich et al. 1981). In those nets, places (predicates) are interpreted as data stores and represent relation schemes in rst normal form. A net marking represents a global system state. It assigns to each place a relation of the respective type. A transition represents a class of operations on the relations in the adjacent places. When a transition occurs, certain tuples are removed from its input places and certain tuples are inserted into its output places. A logical expression may be assigned to a transition to specify certain conditions on the tuples to be inserted and removed. The arcs are inscribed with tuples of variables having the arity of the adjacent place. The variables may be used in inscription of the adjacent transition. In the graphical representation of a Petri net, places are symbolized by circles while transitions are drawn as rectangles, inscribed with the corresponding condition. The circles and rectangles are connected by di-

rected arcs. The example depicted in Fig.1 shows the Pr/T net model for a simple lift system. The variable \n " means \new oor", the number of a oor the lift is requested to go to, while \c " stands for \current

oor", the number of the oor where the lift currently is. The scheme descriptions for the places are quite obvious for this simple example and therefore have been omitted. move_up

nfl > cfl

moving_up



call_lift nfl ε {1,...,8}



request

stop_down

lift_waiting



stop_up



nfl < cfl



moving_down

move_down

Figure 1: A simple Pr/T net To use high-level Petri nets as the formalism for behaviour modelling in INCOME/STAR has turned out to be a good choice because 



on the one hand, the well-de ned formal semantics of Petri nets allows the application of dierent analysis methods, such as discovering deadlocks or \dead code", i.e. operations that will never be executed, etc. on the other hand, they form an executable speci cation of the target system. By using the Petri net simulator presented in this paper, the developer obtains a impression of the system behaviour. In this way the simulation of the Petri net model can also be used as a basis for discussion with the customer.

Petri nets provide a graphical speci cation language for describing the target system's behaviour. With appropriate tool support this means that the software developer draws the system speci cation rather than writing it in some textual speci cation language. Given some experience on the developer's side, this results in higher eciency of the design process as well as better documented and thus easier maintainable systems.

3 REQUIREMENTS FOR SOFTWARE SUPPORT

A common drawback of most of today's graphical Petri net simulation tools is that usually they restrict themselves to providing an animated view of the transition occurrences in the graphical representation of the Petri net itself, i.e. by visualizing the ow of information along the arcs of the net. Since the Petri net only provides a conceptual model of the target system's behaviour, this means that only an abstract sequence of state transitions which model the system's behaviour is visualized, but not the system's behaviour as such. For modelling a control system for an automatic assembly line or just a single robot the corresponding Petri net may consist of hundreds of places and transitions. Visualizing a simulation run of such a large system on the level of the graphical speci cation of the Petri net will not be particularly useful because with increasing complexity of the net it becomes more and more dicult for the developer to imagine how a certain system state, speci ed by a given Petri net marking, translates to \reality". So what is needed is an open simulation environment integrating arbitrary visualization modules which can provide a problem oriented display of the current system state, independent of the visualization of the Petri net itself which models the system's behaviour. When dealing with large systems, often more than one developer will be involved in the design process of the corresponding Petri net model. Therefore the used tools should include appropriate multiuser support:   

Access control for the Petri net models to avoid inconsistencies when multiple developers try to apply changes to the net at the same time. A possibility to visualize the simulation run on an arbitrary number of workstations. The developers should be enabled to in uence the simulation run decentralized, i.e. from their own workstations.

4 GAPS

4.1 GAPS System Architecture Gaps (Graphical Animated Petri net Simulator) is a

tool which implements the ideas mentioned above. For the construction of the Gaps user interface in general the object-oriented programming language Smalltalk

was chosen because of its good prototyping capabilities and excellent graphics support. The Pr/T net simulator component is implemented in Prolog. These two systems are coupled via a TCP/IP network connection. In this way the simulator and (possibly multiple instances of) the editor can run on dierent machines (see Fig.2). editor 1

simulator Prolog simulator kernel

editor 2 TransNET

vis. client

former.

4.2 Example Session

After starting Gaps, the user creates a new net or loads an already existing one (if the corresponding part of the net is already locked by another developer, only read access is granted). New transitions, places and arcs may be inserted by simply selecting the icon of the chosen object with the mouse and placing it somewhere in the editor window (see Fig.3). Names and inscriptions of the objects can be changed by using context sensitive pop-up-menus. During the design process, the editor performs a number of consistency checks (e.g. \the arc inscriptions must be compatible with the scheme de nitions of the adjacent place" or \all variables in transition inscriptions must occur in the inscription of at least one adjacent arc").

Figure 2: Gaps system architecture The simulator expects the Petri net to be given as a set of Prolog rules. A direct coupling between the simulator and the Smalltalk front-end would require the latter perform this translation before sending the net to the simulator. This is unsatisfying since it breaks the conceptual separation between these two subsystems because it brings in implementation details of the simulator to the graphical front-end. Our solution to this problem is to add a mediating component, TransNET, between these two. TransNET works as a bidirectional lter which translates a Petri net description, given in our problem oriented language NETDL (net description language), into the corresponding Prolog rule set. The answers from the simulator are also transformed accordingly. External clients of the simulator (including the graphical front-end/editor) communicate with the simulator exclusively in NET-DL. In this way, it is possible to replace the Prolog based core component of the simulator without having to change the rest of the system. For the syntax of NET-DL we chose a notation similar to that of the far-spread SQL data description language. Since we use an SQL based database systems in the INCOME/STAR environment, this facilitates our eorts to integrate the modelling of static and dynamic information. Furthermore, it is planned to provide an SQL-DML subset for querying or updating the marking of a given place. In the following text by simulator we mean the system consisting of the (Prolog-) simulator together with TransNET as the only way to access the

Figure 3: Gaps editor window After the design process of the net is (at least partially) completed, a simulation run can be prepared. First the developer(s) provide(s) an initial marking of the net. To do so, tuples are inserted into arbitrary places simply by clicking on the respective symbol and entering attribute values. One of the net designers may then start the simulation by clicking on the corresponding icon of the Gaps main window, thereby becoming the \master" of this simulation run. The net and the initial marking are converted to NET-DL constructs and then transferred to the simulator. Here the received data is translated to Prolog, written into the Prolog database and additional data structures to facilitate the later execution of the net are generated. Initially, the simulator sends a list of all enabled transitions back to the Smalltalk front-end. Now the \master" is presented with this list and may choose one of the following

simulation modes:

1. stepwise: The user selects one (or more) of the dis-

played enabled transitions. The result of the selection is transmitted to the simulator where the ring of the transition(s) is performed. The resulting new list of enabled transitions is again sent back to the front-end. 2. n step sequence: n simulation steps (see above) are executed automatically. 3. automatically: as (2), except that the simulation continues as long as enabled transitions exist. 4. automatically until condition : as (3), but the simulation is stopped as soon as condition holds. condition may be the ring of a certain transition or the changing of the number of tuples in a given place. In the case of (2), (3) and (4), the selection of the transition to be red is done either randomly assuming a uniform distribution or (more generally) by an arbitrary user-de ned function on the set of enabled transitions. The sequence of transition occurrences can be logged into a database for later evaluation and analysis. This data can also be used to \re-play" previous simulation runs. Furthermore there exists an interface to the INCOME/STAR's global data dictionary which facilitates a system wide sharing of the Petri nets.

Figure 4: Gaps \stepwise" simulation The \master" of a particular simulation run may permit other developers to join in from their workstations, either passively by letting them only watch the progress of the simulation process, or actively by granting

them the right to in uence the process, e.g. by taking over the ring decision for one or more transitions.

4.3 Visualization

Beyond this, our simulator provides a well de ned interface to the outside world. External visualization applications can register with the simulator by sending it messages and asking for noti cation whenever one of the following events takes place:    

the simulation starts (initialization) a given transition res the contents of a given place changes the simulation ends

The coupling of the simulation system with its external visualization clients is again done over a network connection using the universally available TCP/IP protocol. This enables the clients even to run on machines dierent from the one the simulator runs on, for example a PC or some workstation with special graphical capabilities. When the simulation starts, the simulator sends to each client a startup message with the initial markings of all places this client registered for. This gives the client the possibility to initialize itself. During simulation, the client is only noti ed of the events it registered for and reacts to such messages by updating its display accordingly. In this way clients can be written which concentrate on the visualization of only a part of the modelled system, or display a more abstract view of the system state by aggregating information in a diagram, e.g. a histogram. On the other hand client programs may be written to provide a very concrete impression of how the current simulated system state looks in reality, for instance by providing an animated view of a robot \at work" when executing the Petri net speci cation of the robot control program. Thanks to the availability of support software to build graphical user interfaces (GUI builder) it is quite easy to implement such clients. On the other hand, control over a certain set of transitions may be delegated to external clients either. When a client has been registered as manager for a certain transition, the client is consulted whenever the transition is activated whether and { if so { with which set of input tuples the transition should re. Similar to the graphical visualization clients, it is also possible to

create graphical clients which present the user with an abstract view of the ring decision for the underlying transition. Such functionality may of course also be embedded into the so far purely passive visualization clients. Clients which on the one hand present the user with some view of the Petri net and on the other allow him or her to take control of some or all transitions in the net are called interactive clients. This concept goes so far that the Gaps editor itself eectively acts as an interactive client during a simulation run. The possibility of multiple clients registering as managers for the same transition may be restricted by the master of the simulation process. A very important problem in this context is the arbitration process between con icting ring decisions, especially when the ring decision for at least two of the transitions concerned is split among dierent clients/users. Solutions might be pursuing a rst come rst served strategy or assigning priorities to the clients.

5 INTEGRATION OF THE CUSTOMER

An easy-to-understand visualization of the simulated process (or just interesting parts of it) is especially well suited for demonstrating the Petri net model to customers and other persons not familiar to Petri nets. In this context a (possibly very much simpli ed) graphical visualization of the modelled system or a part of it is sucient to give an idea of how the system will work when nally implemented. In this way misunderstandings and open questions between customer and developer can be resolved at an early stage. Let us reconsider the lift-example presented above. With the concept of interactive clients, we could extend a { so far purely passive { visualizing client which shows the eects of the simulated lift control by adding a lift button for each oor. The buttons may be clicked on with a mouse, which may for example result in the ring of a \lift request" transition and the release of a corresponding tuple into the net.

6 CONCLUSION

The simulation of high-level Petri nets in a multiuser environment is a central building block of INCOME/STAR. It supports the cooperative design of large Petri nets and enables the developers to do extensive testing on their work together.

The simulation architecture facilitates the visualization of complex systems modelled with Petri nets in an easy way. The separation of Petri net simulator on the one hand and visualization client(s) on the other provides to a certain extent stability against changes of the underlying net. Visualization clients may be created to visualize the behaviour of the simulated target system by abstracting from the concrete Petri net as the behaviour model of this system, thus making even complex models visually comprehensible, which is also useful as a basis for discussion with a technically inexperienced customer. For some applications Pr/T nets do not suce because the objects to be modelled have a complex internal structure, e.g. they have set-valued attributes. For such applications NR/T nets (Oberweis et al. 1993) were introduced as a new type of high level Petri nets. These allow to model concurrent as well as exclusive access to structured complex objects. The extension of the simulator towards those nets is subject to ongoing implementation eorts.

REFERENCES (Genrich et al. 1981) Genrich, H.J.; Lautenbach, K., \System Modelling with High-Level Petri Nets", In Theoretical Computer Science 13 , 1981 (Mochel et al. 1993) Mochel, Th.; Oberweis, A.; and Sanger, V., \INCOME/STAR: The Petri Net Simulation Concepts", In Systems Analysis Modelling Simulation (SAMS) 1993, Vol. 13, Gordon and Breach Science Publ., New York 1993. (Oberweis et al. 1993) Oberweis, A.; Sander; P., and Stucky, W., \Petri net based modelling of procedures in complex object database applications", In D. Cooke (ed.), Proceedings IEEE Seventeenth Annual International Computer Software and Applications Conference COMPSAC 93 , Pho-

enix/Arizona, Nov. 1993. (Scherrer et al. 1994) Scherrer, S.; Oberweis, A.; and Stucky, W., \ProMISE { a Process Model for Information System Evolution", In Proc. Third Maghrebian Conference on Software Engineering and Arti cial Intelligence , Rabat, Morocco, April

1994. (Sol et al. 1992) Sol, H.G. and Crosslin, R.L. (eds.), Dynamic Modelling of Information Systems II , Elsevier, North Holland 1992