Using PIPE and Woflan (and the Petri Net Linear Form)

This page is intended to help you install and use the Platform Independent Petri Net Editor (PIPE), an open source Java&XSLT based Petri net editor and analyzer created by MSc students at the Imperial College of London.

Download the latest version from the SourceForge site for PIPE (Australians can directly use this downloading mirror site in Sydney). Then unzip the file. This will create a directory named "Pipe". In this directory, the file "readme.txt" will tell you how to run the tool (Mac users can just double click on "bin/RunGui.class"). The documentation is in "bin/Docs/index.htm" (or Resources/Docs/index.htm) and is also accessible via the rightmost menu button in the tool. In the Drawing mode (i.e. the initial mode), the Select mode/button also permits node dragging. There is no Copy/Paste nor Undo functions.

To re-use Petri net examples, use the menu option "File - Example nets" (or "File - Open" and select a file in the directory "Resources/Example nets"). Animations can be done be directed and step-by-step or, for a real "animation", a given number of transitions can be randomly fired.
Use the "Save" or "Save As" buttons regularly when you have begun creating or updating a Petri net because a bug might prevent you to save after some sequences of modifications.
Petri nets are saved in the XML Petri net standard (PNML). The home page of PIPE states that "PIPE adheres to the latest PNML" but currently PIPE does not seem to permit the drawing of hierarchical nets (embedded nets) nor the storage/organization of Petri nets into modules.
As with all softwares but especially prototype softwares like PIPE, save your work regularly (e.g. everytime you enter a new transition) and also use different file names from time to time (e.g. because sometimes, PIPE refuses to save and display a "Null pointer" error message; the 'Save' function might also not work for big Petri nets while the 'Save as' function keep working). To be safe, if PIPE gives you an error message when you enter something (transition, place or arc), do NOT go ahead and save but stop and reload the last version and re-enter you last modifications; otherwise, you might save a corrupted version and have problems later (e.g. when loading that corrupted version).
It is also not a good idea to put spaces into the file names when you save: spaces are commonly used as separators between "tokens" in information technology, so for many treatments, catering for spaces within file names often makes things more difficult or ugly for the programmer and the end user.

PNML is a textual notation but is hardly readable (see the files in the directory "Resources/Example nets"). A more concise and readable textual notation is handy because graphical forms (i) require a tool to be entered or visualized, (ii) are time-consuming to enter, (iii) need to be transformed into images before exchanging them via email or including them into documents, (iv) take a lot of space on a screen and hence are difficult to compare visually, (v) cannot be handled via text management tools, e.g. their parts cannot be searched and copy/pasted in a text editor or a Web browser. Because I have not found such concise and readable textual notation, I invented one, named it PNLF (for "Petri Net Linear Form") and used it below and in other documents (hence, do not expect PIPE or other tools to read this notation in the near future; it is just a support for communication between you and me, e.g. if you have troubles with the softwares).
Note: The Conceptual Graph Linear Form -- with which I have worked for many years (if you are curious, see for example this document about translations between various logical notations) -- was my inspiration for the syntax of PNLF but the semantics of PNLF is quite different from the semantics of CGLF. PNLF has now been used by some other persons/organizations.

Woflan is a workflow verification tool. (If you have "administrator" privileges, it is automatically installed in the Windows system's "Programs and files" directory so you may not easily find it by browsing but you may execute it by entering the name "Woflan" in a "Run" command). Currently, four input formats can be used: those of Woflan (file extension: .tpn), Staffware (file extension: .xfr) and COSA Workflow (file extension: .scr). Unfortunately, the downloadable version of Woflan (i.e. 2.3) does not yet import from PNML (if an xml file is given as input, the translator xml2tpn is called but this translator is not present in the 2.3 version). A PNML to Woflan translator is available online. However, the PNML subset accepted by this translator is different from the PNML subset used by PIPE (the first subset is called EPNML, the second is an early version of PNML or PNK (Petri Net Kernel) which is also often used as reference). To bridge the two, I created an on-line converter from PIPE's PNML to Woflan's PNML which translates "value" tags into "text" tags, removes spaces within names of transitions/places, and removes various graphic-related elements. Click here if you want to access a Woflan's PNML checker. For details about PNML, click here or here.

The following exercises are from the prescribed textbook "Workflow Management: Models, Methods and Systems" (by Wil van der Aalst and Kees Max van Hee).

Table of Contents

Module 4 - exercise 2.1: German traffic light model

Below, a PNLF representation of the solution of this exercise (which is given p 310 of the book) is followed by the image of its modelling with PIPE. Compare the two representations.

In PNLF, a Petri net in the linear/textual form is composed of one of several statements separated by semi-colons (the last statement ends by a dot). Places are enclosed within parenthesis and transitions within square brackets. Each token is represented by "@". Coreference variables (e.g. *r and *ry below) are used for connecting various occurrences of a same place or transition. Commas are used for separating different branches of the graph.
Given the following graphical form (which is nearly identical to the one given in the book), the textual representation does not seem particularly helpful but you will see in a later document (disclosed Week 8) that the linear form is very helpful to present and comment the graphical representations of these models in the IBM WebSphere Business Integration Workbench. See also the last section of this document.

Also note that PIPE can only permit it user to represent implicit AND/OR splits, not explicit AND/OR splits. The page 59 of the book shows the mapping between the two forms (and page 56 explains why using an implicit OR split is sometimes adequate when using an explicit OR split is not). Thus, to represent an OR-split in PIPE, use a place and connect it to two (or more) transitions (the simulation in PIPE works, it just randomly selects one transition). To represent an AND-split, connect a transition to two (or more) places.

[red_yellow *ry]    //in PNLF, for readability reasons, all the outputs of 
                    // a node should rather be presented together;
  { <-(c1 *c1 @),   // some inputs may also be given
    ->(red *r @) { ->[*ry], ->[yellow_green *yg] },  //OR-split
    ->(yellow *y) { ->[*yg], ->[yellow_red *yr] } //OR-split
  }; //all the outputs of an OR-split should be presented together

[*yg] //in PNLF, when a variable is re-used, the node type is not given again;
      //different nodes can have a same type but a variable is unique to a node
  { //"<-(*r)," not represented here since already represented above
    ->(*y)->[*yr] { ->(*c1), ->(*r) },
    ->(green *g)->[green_yellow] { ->(*y), ->(c2)->[*yr] }
  }; //note how paths are explored/presented as soon as readability permits it
     // (the arcs from/to *yr could have been presented later but this would
     // have made the mental synthesis/checking of the graph more difficult)

Note the above layout with the transitions (the black rectangles) below one another. Such a "vertical layout" makes graphics simpler to understand and gives you plenty of space: it permits you not to use abbreviations for names (which is rarely a good idea), nor to overlap names (overlaps force the reader to guess the names, or if she can, move the nodes to read the names), nor to use too many arcs with several breakpoints (use direct/simple arcs whenever possible). You should develop your graphs vertically, NOT horizontally (and hence horizontal scrolling in PIPE is NOT to be used). An HTML file that includes (without size specifications) a PNG image of your graph (generated via PIPE's export feature) must be printable on a vertical A4 sheet of paper (landscape printing is forbidden).
Although places named c1, c2, ... are used in the PNLF representations above and below because these are the names used in the solutions in the book, YOU SHOULD NOT USE abbreviations such as c1, c2..., P1, P2, ..., T1, T2, ..., even with a legend (within an annotation) giving the full names of the places and transitions. Indeed, this makes the graphics and the results of the analysis EXTREMELY hard/long to understand and check (by people), and hence are also inappropriate to support communication between people (using such abbreviations is nearly as inappropriate as writing in a foreign language and giving a reference to a translation dictionary for this language). The book may use such abbreviations either because actual names do not really matter for certain exercices (any symbol will do), or because it has space constraints. In your case, intuitive names matter and you have space (e.g. by using modules and the above cited layout).

Module 4 - exercise 2.2: Project X

This model contains "implicit OR-splits" (p59 in the book): in the linear form, see the strings "){" (for the OR-split after "c6", the "yes" and "no" cases actually form an explicit representation).

(begin @)->[A *a]{->(c1)->[B *b]->(c4)->[F *f]->(end),
                  ->(c2)->[C *c]->(c5)->[*f],
                  ->(c3)->[D *d]->(c6){yes->[E *e]->(c7 *c7),
[*a]->(c8){ ->[*d], <-[*e],  ->[*b], <-[*b],  ->[*c], <-[*c],  ->[*f] }.

Module 4 - exercise 2.3: Railnet

(busy1 *b1 @)->[clear_track]->(free1)->[claim_track]->(claimed1)->[use_track]->(*b1).

The solution given in the book seems to miss an arc from the place "f4" to a transition "claim_track". I have added it here.

(busy1 @
 *b1){ <-[claim_track *ct2]<-(free2 *f2 @), ->[*ct2]->(c2)->[transfer *t12],
       ->[*t12]{ ->(free1 *f1), ->(busy2 *b2) };
(*b2){ <-[claim_track *ct3]<-(free3 *f3),   ->[*ct3]->(c3)->[transfer *t23],
       ->[*t23]{ ->(*f2), ->(busy3 *b3 @) };
(*b3){ <-[claim_track *ct4]<-(free4 *f4 @), ->[*ct4]->(c4)->[transfer *t34],
       ->[*t34]{ ->(*f3), ->(busy4 *b4) };
(*b4){ <-[claim_track *ct1]<-(*f1),         ->[*ct1]->(c1)->[transfer *t41],
       ->[*t41]{ ->(*f4), ->(*b1) }.

Additional information about PIPE and PNLF

Dr. Philippe A. MARTIN