This paper deals with the embedded systems construction process based on the system specification modeled as a set of Petri nets. Modeling of the system starts with Workflow Petri Nets specification describing the main modules and processes within the system. Workflow model is then transformed to the multilayered Reference Nets structure, that is finally used for the code generation of the target system. The main goal of our approach is to provide for dynamic reconfigurability of the system deployment according to the changes within its specification. Dynamic reconfigurability means the possibility of system changes within its runtime. This is achieved by the decomposition of the whole functionality of the system to small interpretable pieces of computation. This approach also introduces several layers of reconfigurability using different translation rules operating on each layer. The heart of the system lies within the reference nets hosting platform called Petri Nets Operating System (PNOS) that includes the Petri Nets Virtual Machine (PNVM) that performs the very Reference Nets interpretation.
Control systems are important border technology lying between the physical and information world. The whole control process is described as a control loop that consists of reading data from sensors and triggers a number of actuators installed within the physical environment controlled by the system. Most of the control systems are constructed using a set of programmable logic controllers with appropriate suitable software installation. At a higher level of abstraction, programmable logic controller and its software installation could be seen as an embedded system. In this paper the considered target platform for system installation is set of minimalistic and low energy consumption hardware devices, e.g. Atmel microcontrollers equipped with wireless transmission modules that are often used within Wireless Sensor Networks (WSN).
A control system implementation could be divided into the hardware and software part. The hardware part starts with selection of the proper set of modules and its installation within the physical environment, including the sensors and actuators attachment. When there are multiple controllers, the hardware part must also take into account the communication among them. The software part then follows with the programming and installation of each control unit with appropriate application that controls hardware. The main purpose of this paper is to describe the software part of this construction process with the focus on dynamic reconfigurability of the resulting system using executable models and model continuity approach. The reconfigurability is necessary for the ability of the system to adapt itself to changes in environment and also to enable the system maintainer with the possibility to change the system behavior without the necessity of its complete destruction and reconstruction.
Because there is strong demand on proper coverage of the system complexity
at the beginning of the construction process, there is a need for suitable
description tools that preserve the user requirements semantics. During the system
lifetime there are also strong demands on its dynamic reconfiguration according
to the new requirements and also according to the changes within the physical
environment. The dynamic system specification change and following
reconfiguration requirements are not easy to satisfy. Within this paper we introduce
our solution of the described problem using the Workflow Petri Nets model
[
Next two sections describe used formalisms and the reconfigurable system architecture. The following section describes the whole system development process using a running example, and the last section contains the evaluation and conclusion. 2 2.1
Will van der Aalst defined the way to construct workflow models using Petri
Nets[
Reference Nets allow to construct a system hierarchically, in several levels. Such
an idea is a basis of the MULAN (MultiAgent Nets) architecture developed by
Cabac et al.[
The main part of the the system is installed over the hardware as a PNOS kernel with platform net, that are both able to host other nets. Each platform then hosts some number of main processes nets that hosts subprocesses. The whole communication is performed by sending messages using serial link. There is also theoretical possibility for subprocesses to contain other subprocesses etc. But presented example does not cover this.
The PNOS contains PNVM (Petri Net Virtual Machine) which interprets Petri Nets that are installed in the system in the form of a bytecode called Petri Nets ByteCode (PNBC). PNOS also provides the installed processes with the access to inputs and outputs of the underlying hardware that are connected
Subprocesses application bussiness logic
app. business logic, Processes install/remove subprocesses,
send/receive messages and commands
Plat+form iifnnotsrewtaraallrc/drteimomneowsvseiathgaepHspWltiocaaantpidopnc.oppmrroomcceeussnssiceeasst,,ion PNOS kernel irneffrearsetnrcuectnuerets, iinntethrperseytastteiomn of all
Hardware icnotmermpruentaictaiotinonofinthfreaswtrhuocletusryes-tepmhysical
to sensors and actuators, and also with the serial communication port that is
connected to the wired or wireless communication module (e.g. ZigBee)[
The main net (first process) interpreted in PNOS is so called platform net. Platform net is responsible for interpretation of commands which are read from buffered serial line. 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 application-specific functionality. Since we need reconfigurability in all levels, the installation and uninstallation functionality is implemented in each level. 4
The whole process of system development is described in Figure 2. It starts with
the specification of the main system workflow and its subprocesses. Resulting
workflow model is then transformed to the layered architecture and might be
further debugged using the Renew reference nets tool [
More detailed description of the whole PNOS architecture and functionality
could be found in [
As a running example, we use a subset of a home automation system. The home automation is partly based on the optimization of the energy consumption from multiple sources. There are diverse primary sources of the energy, but within 207
Graph transformations
reference nets production
PNML
Model of controlled
system Node PNOS
PNML
Work ow model
initial system speci cation XSLT
PNML + Renew modeling and debugging inscription Compiler
PNBC/HEX
code translation rules XSLT generation
Node PNOS
Model of infrastructure
PNBC messages
Infrastructure Microprocessor messages External Components
UART I/O
ZigBee Ethernet ...
Native Code +
PNBC
our example we concern on the photothermic solar energy panels used for warm
water and heating circuits energy supply. The home automation problem used
as an example is described in more detail in [
Home automation process could be described as an workflow model using the Workflow Petri Nets described previously. Next section shows the workflow model and its description. 4.2
Within this section, the workflow model of the part of house automation system
- the photothermic solar panel and hot water storage tank - is described, using
the Workflow Petri Nets defined by Van der Aalst[
send Water Tank Module
data receive measure adapt
In Figure 4 the measure subprocess was modeled also using the Workflow Petri Nets. It consists of two tasks - reading the data and converting it to the temperature value. Reading the data means getting the voltage from the input and the conversion means the necessary calculations to produce the human readable results.
Measure Subprocess
read delay
convert
The other subprocess shown on Figure 5 consists of the task of temperatures reading and comparing them to use the result for the adequate reaction of the automation system. If there is higher temperature on the solar panel than within the water tank, corresponding circular pump is started to move the hot water form panel to the tank.
In this way the system specification is basically defined. But there are some other prerequisites, e.g. we need to know about the technical aspects of reading and writing the input/output data. This information should be obtained from the customer and must be included as a part of the PNOS system. At this moment, these rules are stored in a proprietary format alongside the nets specifications, Adapt Subprocess solar temperature tank temperature adapt but in future we plan to add them as a next layer of the system called drivers. The following section describes the derived four level reference nets architecture, which is produced from described workflow model. The process of conversion of workflow model into the multilayered Reference Nets system is done using some coarsely defined rules, but in future it should be based on formally defined translation rules. 4.3
The multilayered system architecture derivation starts with the subprocess nets. In Figure 6 there is the measure subprocess reference net derived from the measure subprocess. This net is constructed adding the initial and final uplinks and places. These uplinks serve as a starting and finishing transitions called from the main process of the module. There are also primitive system functions calls, that operate directly with the underlying operating system. Resulting value token is prepared and sent using uplink : output(). All the subprocess protocol nets are named using the name place and corresponding uplink.
The solar panel main process described in Figure 7 is derived from the solar panel swimline in the workflow model. It consists of the place, where all the subprocess nets are stored and according to their names are called in particular order. Synchronization place is added between the subprocess protocol nets calls matching the solar panel main process swimline place. The name of the protocol net is derived from the name of the workflow subprocess, and it is not necessary to be human readable.
The measurement subprocess protocol net has already been described, so the last net that remains is the settings adaptation subprocess protocol net. It is described in Figure 8 and communicates with the operating system calling the proper signals according to the decisions made in transitions.
The water tank main process reflects the main process in the workflow model. It calls all the subnets and performs the synchronization of subprocesses using two temperature places, that are then synchronized within the adapt subprocess. It is described in Figure 9.
Above the last net, called infrastructure, there is a part of the underlying operating system called the platform net that describes the main required functions of the operating system needed by the application processes installed on it. The platform net is shown in Figure 10.
Finally the infrastructure layer, that is derived from the main workflow process description, is shown in Figure 11. In our example, it is very simple. Each swimline represents one place, where the module for hosting the platform, main process and protocols will be placed. The communication between the two subprocesses seated in different swimlines is represented here as an communication transition, that should internally call the final transition of the send task, that means the : output() downlink and the initial transition of the receive task, that means the : input() downlink. Those transitions are part of the platform layer and are propagated to the subprocesses nets. 4.4
Generally, in our approach, each layer of the system can be compiled to target code independently. There are two possibilities: first - the target code can be the native code of the controller processor, and second - target code is a bytecode that is interpreted by some virtual machine. Regardless on the way the code is generated, all the abstraction levels communicate with each other using uplinks and downlinks. The difference is, that levels deployed as interpreted bytecode are more flexible and dynamically changeable than the compiled ones. It is because such a modification needs a heavy compiler and (possibly) over-the-air programming of the node, that consumes a lot of energy. On the other hand it is possible to send the bytecode to the node as data. It thus allows for very high level of dynamic reconfigurability in the system runtime. E.g. new version of the measure subprocess is produced, then the corresponding Reference Net is derived and proper bytecode is generated. Finally the new version of the measure net is sent to the relevant node, and installed by its platform net.
We currently use the virtual machine and bytecode for all Petri Nets-based
code. The only part which is implemented natively, is the PNOS kernel,
including PNVM [
The bytecode contains symbols definitions and places definitions, allowed by a code for each uplink (U), initialization (I), and each transition (T). Each transition description consists of preconditions (P), guard (G), action (A) and postconditions (O), in a form of instructions for the PNVM. Each data element is a tuple consisting of a type and a value. Variables are declared as a part of transition code and identified by indexes. When the code of the net template is loaded to code memory of the PNVM, it is indexed in order to allow PNVM to quickly access particular parts of the code, especially places declarations, the uplinks and the transitions code. When the net template is instantiated, a specific part of runtime memory is allocated according to number of places. At the same time, the net transitions are scheduled for execution. Execution of a transition consists of reading its bytecode and attempting to satisfy all preconditions, downlinks and guards using recursive backtracking algorithm.
In guards and actions of transitions it is possible to call primitive operations of the underlying PNOS. Those operations are available in the Reference Nets inscription language as PNOS.operation, e.g., PNOS.readPort("solar1") reads data from virtual port named solar1, PNOS.writePort("pump1",100) writes value to the virtual port named pump1, PNOS.h(m) gets first space-separated substring from string m, and PNOS.t(m) returns the rest of the string m without the first substring.
Those primitive operations are directly mapped to the corresponding bytecode. We use a subset of the Reference Nets inscription language here. It works only on integers and strings as values with corresponding set of basic operations.
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 Figure 10. The
PNOS Platform functionality is described in more detail in [
PNOS-based nodes can be simulated in SmallDEVS environment [
For the testing purposes we use the Arduino and Raspberry Pi hardware platforms with XBee modules for wireless communication. The Arduino is enabled with the ATmega328P chip that introduces some important restrictions to the implementation. The main one is the 2kB SRAM memory that makes extensive use of direct Petri Nets interpretation very difficult. There is a strong limitation for the number of nets and also for the complexity of problems solved. For that purposes we consider now for further testing of the system to use the Raspberry Pi platform, that offer much more memory for the interpretation purposes. The energy consumption of the ARM could be reduced by underclocking, that is part of our future work plans.
PNVM/PNOS prototype has been implemented in Smalltalk. The implementation resembles the way how it will be implemented in pure C language in order to make final implementation easy. Up to now, we do not have C implementation ready, because we are still doing minor improvements to the reference Smalltalk version. Nevertheless, the automated generation of C version of PNVM/PNOS is planned for very near future.
With the hardware limitations in mind, we have tested the PNVM/PNOS prototype with a model containing the platform net and other three simple nets (9 transitions in all nets), that are loaded and instantiated successively. The code of nets occupies 718 B, 679 B, 147 B, and 115 B, what is 1659 B of total used memory for code. The simulation generates 4 net instances, containing 14 places. The number of tokens is up to 31, and needs 1547 B of object memory. The history of memory occupation is shown in Figure 12. Peaks in the graph corresponds to receiving a net via serial line and its loading to code memory.
To investigate the time consumption of the simulation, we measured the time needed for each step execution. It comprises evaluation of all transitions in all 2000 ] 1500 B [ e z i ys 1000 r o m e M 500 0
Code Memory Object Memory 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Step Number ten instances. The simulation was executed for 50 times to get average step duration.
The history of simulation steps durations is shown in Figure 13. We can see, that the duration increases depending on number of instances because the number of transitions is increasing. Peeks in the graph correspond with net loading, net instantiation, and uplink execution. These experiments has been done on contemporary desktop computer. On Raspberry Pi the step duration is about 100 times higher, because of slower CPU and slower access to the memory. Nevertheless, we suppose that C version of the PNVM/PNOS for Raspberry Pi will run reasonably faster which will make Arduino and Raspberry Pi platforms well usable for Petri nets-specified control systems. 6
The use of high-level languages, especially Petri Nets, allows to build and
maintain control systems in a quite fast and intuitive way. There are many approaches
to relate high-level languages with embedded devices or microcontrollers. One
kind of that approaches is applicable in systems with not very limited resources.
For example, Java can be used as a high-level language and works on
architecture which can be successfully used in embedded systems [
Step 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Step Number or are not applicable for systems with limited resources. The approach presented in this paper allows not only for design of systems with limted resources, but also for systems implementation using a high-level language, particularly the Nets-within-Nets formalism, allowing for the dynamic reconfigurability. 7
In this paper, we described the process of system construction based on Petri Nets-based models transformations and target prototype code generation. This process starts with the workflow model defined according to the Van der Aalst’s WF-Nets that describe the functionality of the system from the customers point of view. This model is then transformed to the multilayered architecture based on Reference Nets formalism. Each layer of the architecture is then translated to the specific target representation. The main part of the system is translated to the Petri Nets ByteCode (PNBC), that is interpreted by the Petri Nets Virtual Machine (PNVM) that is part of the Petri Nets Operating System (PNOS) which forms the remaining part of the system.
The whole system reconfigurability is based on the possibility of PNBC net replacement with the new version where the interpretation after reinstalling starts to perform the new version of the process. In the current version, the reconfigurability is considered to work on the granularity of processes and subprocesses. In further research, we plan to focus on more fine grained reconfiguration, including the platform primitive operations, and also on the processes migration.
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.