Petri Net to Statechart

Bx Examples Repository

Title: PetriNetToStateChart

Version: 0.1

Type: Sketch


This example is inspired by the "The Petri-Nets to Statecharts Transformation Case" from the sixth Transformation Tool Contest (TTC) [1]. The first part of the original transformation maps a Petri-net to a flat statechart, while the second part creates a hierarchical structure for the state chart.
This case is converted to a bx example by regarding Petri-net as "views" (an abstraction) on hierarchical statecharts, i.e., the hierarchical structure is "lost" when transforming to Petri-nets. The primary complexity of the original case is thus out-of-scope here and still has to be performed as a post-processing step on flat statecharts.


A detailed description of the metamodels involved is provided in [1] (click on the DOI for diagrams). There are, however, no big surprises: A Petri-net consists of Places, Transitions and Arcs, while a statechart consists of connected States. The hierarchy in the statechart is formed by building AND and OR compound states based on some rules documented in detail in [1].


Places in the Petri-net correspond to basic (atomic) States in the statechart, Transitions correspond to so called HyperEdges (special States) in the statechart, and arcs (connecting Transitions and Places) correspond to links (connecting HyperEdges and basic States).
The main challenge here is elegantly ignoring the hierarchical structure in the statechart.

Consistency Restoration

Changes to the hierarchical structure of the statechart should have no effect on the corresponding Petri-net, whereas renaming basic states and reconnecting them should be reflected in the corresponding Places and Transitions/arcs.

Propagating renaming of Places in the Petri-net is also clear, but propagating all other changes in the Petri-net is a challenging to specify precisely as it is unclear what should happen to the hierarchical structure (completely losing it is still "consistent"!). This is probably another case where one requires a "least change" or "least surprise" principle to state precisely how consistency of the statechart should be restored.

Properties [optional section]

Variants [optional section]


References [optional section]

The original case description is provided in [1].


Anthony Anjorin



Artefacts [optional section]

A virtual machine hosted on Share is available with a workspace containing both (Ecore) metamodels, the concrete example used above, and a TGG formalizing the consistency relation as a set of rules:

1. Pieter Van Gorp, Louis M. Rose, Christian Krause (Eds.): Sixth Transformation Tool Contest (TTC 2013)
EPTCS 135, 2013, pp. 16–31, doi:10.4204/EPTCS.135.3
Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.