This paper focuses on the field of dynamically reconfigurable distributed embedded control systems construction process and presents a substantial part of the methodology aimed at this application area which is based on formal models, namely some variants of Petri Nets. Initial system specification is represented by a set of Workflow Petri Nets transformed into decomposed multi-layered Reference Petri Nets model, that is used during the generation of interpretable target system components representation. The main objective of presented approach is the introduction of dynamic reconfigurability features into the target system implementation reflecting changes in system specification during its run-time. Reconfigurability is achieved by the system decomposition into smaller interpretable pieces of computation that are installed on and performed by the underlying infrastructure. Introduced approach brings several layers of reconfigurability through a set of specific translation rules applied in different layers and scenarios for pseudo-code generation and by the possibility of installing the resultant functional parts on system nodes using well-defined communication protocol. The heart of described architecture lies within the specification of hosting platform called Petri Nets Operating System (PNOS) that includes the Reference Petri Nets interpreter.
Control systems lie on the thin border between physical and information worlds. The process of control is usually described as a loop switching between reading data from sensors and triggering a number of actuators installed within the physical environment. Above all, the process should respect all user-defined rules. Control systems could be constructed as a set of programmable logic controllers with proprietary software installation, communicating with each other, thus forming distributed embedded control system. Our work considers a target platform for this type of systems implementation to be a set of minimalistic and low energy consumption hardware devices, e.g. ATmega, PIC, or ARM microcontrollers, equipped with wireless transmission modules. Such devices are often used in the area of Wireless Sensor Networks (WSN) systems.
Usually a hardware part of any system implementation starts with selection of proper set of devices and their installation within the physical environment, including sensors and actuators attachment. The software part of system implementation complements the hardware one with the construction of appropriate application software, that controls each system unit and represents the whole system functionality. Dynamic reconfigurability features are necessary for the ability of the system to adapt itself to changes in environment and also to provide its maintainer with a possibility to change the system behaviour, while it is in runtime, i.e. without the necessity of complete destruction and further reconstruction, or even restart. Our main goal is to describe the software part of the process, that respects our focus on formal specification and dynamic reconfigurability.
In this paper, we are going to describe some recent results of the research
in the field of dynamically reconfigurable distributed embedded control systems,
and basic ideas of our research that aims to introduce complete methodology
for control systems construction and administration, which uses formal and
human readable notation as a system functionality specification, and provides the
user of resulting system with the possibility to change its behaviour within the
runtime. Introduced solution to the dynamic reconfigurability problem follows
the model transformation and executable model paradigms - Workflow Petri
Nets[
Related work could be divided into the following areas - embedded and operating systems, software engineering methods applied to the area of embedded systems, the usage of higher-level or visual languages for embedded systems specification and implementation, the dynamical reconfigurability within embedded systems, reconfigurable control systems (e.g. FMSs), multi-agent approach to the reconfigurable embedded systems development, system partitioning, code generation, and reconfigurable hardware.
The usage of formal modelling control system with dynamic reconfigurability features is not a new idea. Research activities in this topic are primarily focused on direct or indirect approach. The direct approach offers specific functions or rules, allowing to modify system structure, whereas the indirect approach introduces mechanisms allowing to describe system reconfigurations. The main difference consists usually in the level of reconfigurability implemented. Direct methods use formalisms containing intrinsic features allowing to reconfigure the system. Indirect methods use specific kind of frameworks or architectures, that make possible to change the system structure.
In our field of research the first group consists of formalisms based usually
on some kind of Petri nets. Reconfigurable Petri Nets [
The second group handles reconfigurations using extra mechanisms.
Modelbased control design method, presented by Ohashi and Shin [
So far, we have investigated formalisms and approaches to the control
system development. They have one common property, they are missing complex
design and development methods analogous to software engineering concepts.
Of course, the methods and tools that are applied in ordinary software systems
are not as simply applicable to embedded systems. Nevertheless, we can be
inspired with software engineering approaches and adopt them to the embedded
control systems [
Presented approach is based on existing formalisms and architecture that are together used in the specific platform developed by our team. In relation to previously defined areas of software engineering for embedded control systems, we deal with Process, Platform, and Middleware areas in this paper. Process area focuses on work-flow modelling using Petri Nets, transformation of the workflow models into the Reference Nets, and definition of the levels of abstraction. Middleware area focuses on multi-layered architecture inspired by the MULAN architecture. Platform area introduces Petri Nets Operating System (PNOS) linked with Petri Net Virtual Machine (PNVM) that offer specific means for system reconfigurability. All mentioned elements will be described in details in next chapters. 3 3.1
Work-flow modelling is very popular for its aim to precisely define the
functionality requirements using intuitive and human-readable form, while offering
enough precision to be interpretable by machines. For its formal and verifiable
characteristics and large research background we adopted for the purposes of
our research Wil van der Aalst’s specification for system work-flow modelling,
so called Extended Workflow Petri Nets[
Reference Nets allows to construct the system hierarchically, in several layers of
abstraction. Each element of layer at any level of abstraction could be changed
by change in nets marking. Nets representing system functionality are migrating
over nets of other layers changing the system functionality. The multi-layered
nature of the system and responsibilities of particular levels of system
decomposition is described in more detail in our previous work[
The core characteristics of resulting system, its dynamic reconfigurability,
is based in our solution on the ability of Reference Petri Nets interpretable
representations to migrate among places of the system as tokens, similarly as in
reference Nets. The new or modified Petri Net, that represents the system partial
behaviour change could be sent over other Petri Nets to its destination place to
change the whole system functionality. In our solution, these Petri Nets parts
are maintained by the Petri Nets Operating System (PNOS) and interpreted
by the Petri Nets Virtual Machine (PNVM) engine[
The important net (lying above processes nets) interpreted in PNOS is so called Platform net. Platform net is responsible for the interpretation of commands which are read from buffered serial line, or Ethernet. These commands allow to install, instantiate, and uninstall other Petri Nets. The Platform also allows to pass messages to the other layers, which are responsible for applicationspecific functionality. Since we need reconfigurability in all levels, the installation and uninstallation of functionality is implemented in each level of resulting system. Next section describes the Reference nets formalism that is used as an intermediate language for the target implementation. 5
System development process is described in Fig. 1. It starts with the
specification of the whole system work-flow, in an hierarchical way. Work-flow model
is transformed to the Reference Nets layered architecture and might be
further simulated and debugged using the Renew Reference Nets tools [
There are two translation phases. The translation of the Workflow Petri Nets model into the Reference Petri Nets model and translation of the Reference Petri Nets model into its interpretable form. The first transformation phase takes into
Graph transformations
reference nets production
PNML SmallDEVS
Model of controlled
system Node
PNOS account the set of work-flow specifications described within the work-flow model of the system and produces target node representations. Such a representation should contain the basic PNOS I/O functionality, and the platform functionality, which means the ability of receiving nets specifications, nets instantiation, removing nets instances, removing nets specifications, etc. Using this functionality the node main processes should be installed. It usually consists of the description of sub-processes interactions and ordering. Then the main processes of each node are installed with translated sub-processes. The communication between resources is represented by transitions, that are not part of any other role and serve as a data transport part of the system. Particular data types should be described in the terms dictionary, that holds all the necessary information needed for nets translation, that is not included within the diagram. Regarding the work-flow model, also other specific rules for the communication protocol could be derived. 5.2
Let us introduce some basic definitions of formalisms used during the system development. As a basement the classical Petri nets definition describes the main rules of the specification formalism.
A Petri net is a triple P N = (P, T, F ) where: – P and T are disjoint finite sets of places and transitions, respectively and – F ⊆ (P ×T )∪(T ×P ) is a binary relation called the flow relation representing arcs of the net. – •x = y|yF x is called input set (preset) of the element x and – x• = y|xF y is called output set (postset) of the element x, where x ∈ P ∪ T .
Van der Aalst’s extensions to Petri Nets add two basic conditions to the nets construction. Our modelling approach is very similar, so we can use his definition, but for the further transformation of models we need some more rules to be added. First let us introduce the simple work-flow net definition.
(WorkFlow net) if and only if [
A Petri net P N = (P, T, F ) is a WF-net – P N has two special places: i ∈ P and o ∈ P . Place i is a source place: •i = ∅.
Place o is a sink place: o• = ∅. – If we add a transition t∗ to PN which connects place o with i (i.e. •t∗ = {o} and t∗• = {i}), then the resulting Petri net is strongly connected.
Some other simplification rules added by Aalst and Hofstede extended
workflow models to provide for better human-readability. Some special types of
transitions representing logical operators and some special operations for
manipulation with tokens were added. Transitions and places are considered to be tasks
and conditions. Each EWF-net consists of tasks (either composite or atomic)
and conditions which can be interpreted as places. Tasks in elementary form are
atomic units of work, and in compound form modularize an execution order of
a set of tasks. In contrast to Petri nets, it is possible to connect “transition-like
objects” like composite and atomic tasks directly to each other without using a
“place-like object” (i.e., conditions) in-between[
Definition 3 (Extended Workflow Net). An extended work-flow net
(EWFnet) is a tuple EW F = (C, i, o, T , F , S, name, split, join, rem, nof i) such
that [
Our approach follows the previous definitions and adds some more rules to enable the extended work-flow models with communication features to satisfy the developer ability to combine multiple work-flow specifications. Definition 4 (Extended Communicating Workflow Net). We call Extended Communicating Workflow net ECW F = (EW F ,I,O,F C ) a EWF net that has following properties: – I ∪ PEW F = ∅ ∧ O ∪ PEW F = ∅. – EW F is an extended work-flow net, – I is a set of ECW F input places, where ∀pI ∈ I : •pI = ∅ ∧ pI 6= i, – O is a set of ECW F output places, where ∀pO ∈ O : p•O = ∅ ∧ pO 6= o, – F C is a communication flow F C ⊆ (I × T ) ∪ (T × O),
To specify complete work-flow model a definition of Workflow Specification was introduced by Aalst and Hofstede. We adopted this definition and added some slight change to one of the rules.
tuple (Q, top, T ,map) such that:
S is a
n– Q is a set of ECWF-nets,
– top ∈ Q is the top level work-flow[
And also some special types of tasks representing composite and multiinstance tasks were added by Aalst and Hofstede.
Definition 6. Whenever we introduce a work-flow specification S = (Q, top,
T , map), we assume T A, T C , T SI , T MI , C to be defined as follows [
Final definition describes the Workflow System consisting of set of Extended Communicating Workflow Specifications and communication transitions.
= (Sb, T W S , F W S ), where:
W S – Sb is non-empty finite set of extended communicating work-flow specifications,
Target system representation for the first phase of system model
transformation is constructed as a set of Reference Nets based on Valk’s nets-within-nets
paradigm that is formalized as an Elementary Object System which consists of
elementary net systems (EN System) EN = (B,E,F ,C), which is defined as
finite set of places B, finite set of transitions E, disjoint from B, a flow relation
F ⊆ (B × E) ∪ (E × B) and an initial marking C ⊆ B [
Definition 8 (Elementary Object System). An elementary object system
is a n-tuple EOS = (SN, OdN , Rho, type, Mc) where [
Definition 9 (System Marking). The set Obj := {(ONi, mi)|1 ≤ i ≤ n, mi ∈ R(ONi)} is the set of objects of the elementary object system. An object-marking (O-marking) is a mapping Mc : P → 2Obj ∪ N such that Mc(p) ∩ Obj 6= ∅ ⇒ Mc(p) ∩ N = ∅ for all p ∈ P .
Next paragraphs are going to describe both transformation process phases. The first one is the transformation of the work-flow model into the operational nets-within-nets model, second one the transformation of the nets-within-nets model into its interpretable form, reflecting the target PNOS platform. 5.3
We decided to describe our methods on the sample home automation example.
The whole system functionality is described in the form of work-flow model in
our approach represented by the Workflow System depicted in Fig. 2. There are
following elements within the work-flow models - places, transitions, and logical
transitions[
tem is translated into multi-layered Reference Nets model. Each layer of the Reference Nets model is generated separately using different production rules. First part of the system, that should be generated from the original model is the top level Infrastructure layer net, that describes the communication among all nodes of the system and could be used as a sort of deployment diagram. Infrastructure layer is a basic layer of the Reference Nets model and serves for the validation purposes and also as a description of the distribution of target system structure. Basically the main purpose of Infrastructure layer lies in description of the system nodes and their communication.
Within the Infrastructure layer, each node is represented as a place in which the particular Platform layer net is located. If there is any communication between nodes, this communication is represented as a transition between corresponding nodes. For example model described in Fig. 2 should be translated into the Infrastructure net described in Fig. 4. This layer is produced by the following set of rules.
Let W S = (Sb, P W S , T W S , F W S ) be a Workflow System which has to be transformed and SN = (P I , T I , W I ) a system net representing the Infrastructure layer of the target elementary object system should be generated using Algorithm 1.
(∗ demonstrates infrastructure net construction ∗) 1. P I = T I = W I ← ∅ 2. for each work-flow specification produce place in the system net, ∀s ∈ Sb :
P I = P I ∪ {pname(s)} 3. for every set of the communication transitions with the same name, place one transition to the system net, ∀ξ(t) ∈ χ(T W S ) = [χ(TiW S )]i∈<1,...,n> : T I = T I ∪ {tname(ξ(t))}, where name(ξ(ti)) = name(ξ(tj ))(i 6= j) 4. connect all communication transitions to the corresponding places with double-sided arcs, ∀pI ∈ P I , ∀tI ∈ T I : piI ∈ •tiI ∧ piI ∈ tiI •, where tW S ∈ T W S : ∀piW S inCi : piW S ∈ •tW S ∨ piW S ∈ tW S • 5. annotate all arcs with arbitrary names 6. place inscriptions to the transitions that invoke the : output up-link in the source node and places the result to the : input up-link of all the target nodes
Each node of the system, placed logically within the Infrastructure net place is considered to run on some piece of hardware installed with the PNOS. Because PNOS also consists of the PNVM it is able to interpret Reference Nets translated into the PNBC pseudo-code. Basic layer of the system, that must be installed on all nodes of the system is Platform layer, that brings a set of basic metaoperations that enables the node with other Reference Nets manipulation means - like loading, unloading nets, passing values, etc. This layer is described in Fig. 5. After the Platform layer was installed on the basic PNOS and become interpreted by the PNVM kernel, it is possible to send to it some other nets to define or modify the node behaviour. Basic types of such nets are Processes and Sub-processes of the target system. Generating the Process layer The translation of Processes layer also has its own set of production rules. When translating the work-flow model, there is at least one process net generated for each Workflow Specification within the the system model. Main process net consists of the set of meta-operations, that enable the main process to receive and run new nets definitions, and to pass the received values to running subnets. Input place is used for receiving the data by : input up-link. Output place serves as an buffer for the : output up-link. Nets place then stores all sub-process nets. During the main process life-cycle, each sub-process net is taken from the nets place, it is started, or served with parameters and started. Started net is then put back to nets place, where it resides, until the result is produced. When the result is ready, the net is taken from the temporary place again, the output result is taken, and the net is then stored again back to the nets place, or it could be stopped. The result of the net is then propagated according to the logic specified in the main process net. The example of translating the garden node main process net is shown in Fig. 6.
All the process nets should be produced according to the following rules. Let Si = (Q, top, T , map) be a Workflow Specification to be transformed and ONi = (PiP , TiP , WiP ) a net of the Processes layer of the target system. For the translation following Algorithm 2 should be used.
(∗ demonstrates process nets construction ∗)
1. PiP = TiP = WiP ← ∅
2. add nets, input and output places, PiP = PiP ∪ {pnets, pin, pout}
3. add the platform meta-operations, TiP = TiP ∪ {tname, tpass, tcreate, tremove}
4. for each sub-process in swim-lane construct the first transition that takes the
subnet from the nets place and invokes the : start up-link and a transition
that triggers the : output up-link, ∀tSi ∈ T top : TiP = T P P
i ∪ {ti(start), ti(out)},
where •ti(start) = pnets = ti•(start) ∧ •ti(out) = pnets = ti•(out)
5. connect both transitions with synchronization place and corresponding arcs,
∀tC ∈ TiC , where ∃p ∈ P, t ∈ Ti ⊂ T \ S{Ti} : p ∈ tC• ∧ p ∈ t• : PiP =
PiP ∪ {piP }, where tiP(s•tart) = piP = •tiP(out)
6. add one more place for each output communication to store the results of
the sub-process, PiP = PiP ∪ {piP } : tiP(s•tart) = piP
7. if the output is to be sent to another node add the transition that constructs
the message and puts the resulting message into the output sink, TiP =
TiP ∪ {tiP } : •tiP = piP ∧ tiP • = pout
8. translate special transitions according to the rules defined by Aalst [
i ∪ cc 11. copy left transitions, ∀t ∈ T : TiP = T P P i ∪ tt Generating the Sub-process layer Within the house work-flow model, there is a measure sub-process used in meteo and house modules. This sub-process should be translated to the Sub-process layer using Algorithm 3.
(∗ demonstrates sub-process nets construction ∗) 1. fPoiPr a∪llccPsub-process places produce corresponding places, ∀c ∈ C : PiP = 2. for all sub-process transitions produce corresponding transitions, ∀t ∈ T :
TiP = TiP ∪ ttP
3. translate special transitions according to rules defined by Aalst [
Resulting sub-process net is described in Fig. 7. 5.4
Following part of the development process comprises of target system code generation. In our approach, each layer of the system should be compiled to target code independently. All generated levels communicate with each other using up-links and down-links.
Fig. 7. Measure Sub-process net
The only part of the system, which is implemented natively, is the PNOS
kernel, including PNVM [
The important feature of the system is its reconfigurability. It is based on
operations of the operating system that are designated for manipulations with
nets (in the form of PNBC) and their instances. Nets could be sent to a node as a
part of the command for its installation. The command is executed by Platform
net. Using other commands, the platform can instantiate a net, pass a command
to it, destroy a net instance and unload a net template - see Fig. 5. The PNOS
Platform functionality is described in more detail in [
The main operating principle of resulting system could be described on the tasks of system construction - installation, and its reconfiguration. The installation of the system starts with placing proper nodes to the target environment. Each node should be installed with the PNOS, PNVM and basic platform layer. The physical communication between nodes using different wired or wireless communication technologies should be established. In our running example the scenario should start with installing the processes for each Workflow Specification and then sending particular sub-processes nets to relevant nodes. meteo load measure-wind meteo create mw1 measure-wind meteo load measure-anemo meteo create ma1 measure-anemo ... meteo start meteo pass mw1 start meteo pass ma1 start ...
The other important part of system functionality is its reconfiguration. It should be performed on each defined level of the system architecture. Basically, the node firmware including the PNOS and PNVM could be reprogrammed and rebuilt and then sent over the air to the particular node. The Platform net could be modified and also sent to the particular node, but usually we do not expect this layer to be modified often. The next level of reconfiguration is the processes layer. All processes of the node could be changed and then passed to its platform to change the behaviour of the node. Finally all the sub-processes nets could be modified and sent to particular nodes processes that reinstall them within the nets place. The example of the reconfiguration process follows. meteo pass mw1 stop meteo destroy mw1 meteo unload measure-wind meteo load measure-wind meteo create mw1 measure-wind meteo pass mw1 start ...
There is a plan in future to add the pause and resume operations to the platform, to be able to pause any particular net instance, change its template and resume then. For that it is necessary to invent, how to represent the pausing and resuming conditions in Petri Nets, that is not part of this material.
We described the basics of model transformation and execution-based methodology of distributed embedded control system development. Among the main methods it uses Petri Nets models transformations and target system prototype code generation. Development process starts with the work-flow model of the system specification defined according to the rules of Van der Aalst’s Workflow Specifications. Work-flow model of the system describes the functionality from user’s or domain specialist’s point of view. Using our methods, the work-flow model is further transformed to the multi-layered architecture based set of Reference Petri Nets. Each layer of the system is then translated to the specific target representation called Petri Nets ByteCode (PNBC), which is interpreted by the Petri Nets Virtual Machine (PNVM), that is a part of the Petri Nets Operating System (PNOS), that is installed on all nodes of the system. Targeted dynamical system reconfigurability is achieved by the possibility of PNBC net templates and instances replacement with its new versions. After the replacement, PNVM interpretation engine starts to perform a new version of partial functionality of the system. That makes the dynamic reconfigurability possible.
This work has been supported by the European Regional Development Fund in the IT4Innovations Centre of Excellence project (CZ.1.05/1.1.00/02.0070), by BUT FIT grant FIT-11-1, and by the Ministry of Education, Youth and Sports under the contract MSM 0021630528.