1 Department of Informatics and Mathematical Modeling, Technical University of Denmark2 Computer Science and Engineering, Department of Informatics and Mathematical Modeling, Technical University of Denmark3 Software Engineering, Department of Informatics and Mathematical Modeling, Technical University of Denmark4 Department of Applied Mathematics and Computer Science, Technical University of Denmark
The Petri Net Markup Language (PNML) is an XML based interchange format for all kinds of Petri nets, which was published as International Standard ISO/IEC 15909-2 in February 2011. Technically, ISO/IEC 15909-2 is defining an interchange format for three different kinds of high-level Petri nets and a simple version of Place/Transition systems only. But, one of the objectives of PNML was to provide a means for exchanging any kind of Petri net [10, 29, 1]. To this end, the concept of a Petri Net Type Definition (PNTD) was introduced, which is subject of a newly issued standardisation project: ISO/IEC 15909-3. There are many tools supporting one form of PNML or the other, and, in particular, there is the PNML Framework , which helps tool developers to ease the implementation of PNML by providing a framework and an API for loading and saving Petri net documents in PNML. This framework is based on the Eclipse Modeling Framework (EMF)  and has its focus on the underlying meta-models of Petri nets. The PNML Framework, however, is not generic in the following sense: Whenever a new Petri net type is created, the code for the complete tool needs to be regenerated. Moreover, the PNML Framework does not come with a graphical editor for Petri nets. The ePNK overcomes these limitations: It provides an extensionpoint, so that new Petri net types can be plugged in to the existing tool without touching the code of the ePNK. For defining a new Petri net type, the developer, basically, needs to give a class diagram (actually an Ecore diagram) defining the concepts of the new Petri net type, along with a mapping of these concepts to XML syntax. This type can then be plugged into the ePNK, and the graphical editor of the ePNK will be able to edit nets of this new type with all its features. Likewise, the ePNK allows to plug in new functionality for analysis and verification of Petri nets or any other kind of application for Petri nets. Actually, this was the idea when we started the development of the Petri Net Kernel (PNK) about 15 years ago [17, 12, 20]. At that time, however, we had to implement all of the IDE functionality of such a tool ourselves. Today, we can make use of the Eclipse platform , which helps us focusing on the Petri net specific parts; we get all the functionality of a nice IDE, basically, for free. This is why we named the tool ePNK: it can be considered to be an Eclipse-based Petri Net Kernel. But, it is just the spirit and their idea that the PNK and the ePNK have in common; technically, there is not a single line of code from the PNK in the ePNK, and the ePNK is not compatible with the PNK. What is more, we use the nice features of EMF, GMF, and Xtext for developing the ePNK in a model-based way. In this way, the complete development process of the ePNK is a case study in model-based software engineering using EMF and related technologies. This, actually, was the driving force behind this project. The evaluation and the lessons learned during this project, however, will be reported at an other occasion and to a different audience. This manual focuses on how to use the ePNK as an end user, and shows how a developer can use the extension mechanisms of the ePNK for providing new Petri net types along with their XML syntax, and how to add new functionality to the ePNK. A first version of this manual has been published in February 2011 as IMM-Technical Report-2011-03 already, which referred to version 0.9.1 of the ePNK. The current version of this document refers to version 1.0.0 of the ePNK, which was released in October 2012.