![](bg2.png)
2. A code generator tool (named PnGenerator) that is
able to generate ANSI C code (and is easily extend-
able to other languages) for net execution. The gen-
erated code is amenable to be executed in hardware
with limited resources. Besides, the same gener-
ated code can be used to simulation and verification
purposes.
A high-level view of the environment, explained
along this section, is presented in Fig. 1.
Typically, the user interacts with the PnEditor. The
editor allows the user to generate Petri net models
based on a previously read Petri net type definition
(PNTD). This is a XML file defining the Petri net type
to be used. More specifically, it defines the set of tex-
tual annotations than can be associated to each net el-
ement. The editor configures itself based on the read
PNTD: only the net elements defined in the PNTD are
made available in the graphical editing commands.
The editor is also able to generate a non-
hierarchical specification from a hierarchical model
being edited. We call this version, the flat model. This
means that we view the hierarchical model as a graph-
ical convenience. On one hand, this has the advan-
tages of a modular specification, namely readability,
modularity, and reusability. On the other hand, the
reduction to a flat model guarantees that the gener-
ated Petri net can easily remain closer to well-studied
Petri nets for which numerous verification possibili-
ties exist (e.g. elementary net systems (Rozenberg,
1987), free-choice nets (Desel and Esparza, 1995),
and Place/Transition nets (Desel and Reisig, 1998)).
The PnGenerator reads flat net specifications and
generates ANSI C code capable of executing the
model (the executable model). It can also generate
interface code that is linked to the executable code.
This allows the use of the same executable code also
for simulation and analysis tasks.
The simulation is, typically, carried out by the in-
teraction of the PnEditor and PnGenerator tools:
1. the PnEditor sends (by file) upon user request, an
initial flat Petri net;
2. the PnGenerator identifies the possible next steps
and returns that information to the PnEditor in the
form of several possible evolutions for the given flat
net.
3. the user chooses one of the possible execution steps
4. the PnEditor asks the PnGenerator to executes the
specified step
5. the PnGenerator returns the modified model ele-
ments to the PnEditor
6. the PnEditor updates the model
on XML and is part of the ongoing effort for a High-level
Petri net ISO standard (Petri nets Standard, 2004).
Additionally, given a flat model, the PnGenerator is
able to generate automatic simulations (without user
intervention) logging them in text files.
Finally, given a flat model, the PnGenerator is also
able to generate the respective state graph and to use
it for analysis purposes, namely, deadlock detection
and reachability analysis.
The environment architecture also makes evident a
clear independence between modelling and code gen-
eration tasks. The creation of graphical models and
the definition of Petri net types can, thus, easily evolve
independently from the code generation and simula-
tion tasks. This makes the environment more open as
it will allow both tools to be used outside of the initial
foreseen close cooperation: other tools can totally, or
partially, replace or complement, the existent ones.
2.1 The PnEditor
The PnEditor is a typical Petri net graphical editor
with three main additional characteristics: (1) the use
of the emergent standard for Petri net model inter-
change; (2) the support for model modification op-
erations; (3) the interaction with the PnGenerator for
simulation and verification tasks. Additionally, the
PnEditor is able to generate non-hierarchical (flat)
models from hierarchical ones.
The PnEditor relies on the Eclipse open source
project (Eclipse, 2004) mainly due to the availabil-
ity of a suitable framework, named Graphical Editing
Framework (GEF), for the development of graphical
editors (GEF, 2004).
The PnEditor also allows the specification of net
modifications through the use of textual expressions.
These textual expressions correspond to a simple al-
gebra around a set of operations on net instances,
places, and transitions. Net instances are elements of
net vectors. Given a net model N , a net vector of net
models N is a list of n instances of N nets, denoted
N[1 . . . n] where each net instance is denoted N [n].
All net components of a net instance N[i] have their
denotations suffixed by N [i]. For example, place p
1
in a net instance S[2], becomes S[2].p
1
. This allows
a convenient way to refer to several distinct node in-
stances of a given net (Gomes et al., 2002; Gomes and
Barros, 2003; Barros and Gomes, 2004a).
The net instances and the respective places and
transitions, can be modified by a small set of oper-
ations defined elsewhere (Barros and Gomes, 2004a),
namely net addition and net subtraction. The net
modification operations can be applied at any time
some model modification is needed. Yet, net addition
can also be used in a structured way as the underly-
ing support for the hierarchical structuring of the net
model (Gomes and Barros, 2003) and for a particular
type of transition fusion, named synchronous group,
useful for object-oriented design (Barros and Gomes,
FROM PETRI NETS TO EXECUTABLE SYSTEMS: AN ENVIRONMENT FOR CODE GENERATION AND
ANALYSIS
465