Combining DataFlows and Petri Nets for CyberPhysical Systems Specification
 5 Citations
 1.1k Downloads
Abstract
This paper proposes a new modeling formalism for the specification of cyberphysical systems, combining the functionality offered by Petri nets and synchronous data flows. Petri nets have been traditionally used to model the behavior of reactive systems, whose state evolves depending on the interaction with external events. On the opposite, dataflow formalisms have been used predominantly to describe datadriven systems that produce output data through mathematical transformations applied to input signals. The proposed formalism covers both kinds of problems, offering support for the design of mixed systems containing linear control and signal processing operations along with event driven elements. Model composition using multiple components communicating through input and output signals and events, enable the implementation of distributed cyberphysical systems. The new formalism and the respective execution semantics are presented, with special attention to the bidirectional interaction between Petri net elements and dataflow nodes.
Keywords
Cyberphysical systems Embedded systems Petri nets Dataflow1 Introduction
Cyberphysical systems assume a growing importance in all fields of the modern world, with many applications that include industrial machines, home appliances, entertainment systems and gadgets. The fast dissemination of the Internet and the wide availability of inexpensive networking technology, brought Internet connectivity to the recent generations of embedded devices, contributing to the birth of the Internet of Things. This evolution enabled the development of new applications and services, including access to automatic payment systems, connection to social media platforms and solutions based on distributed networks of remote devices, like smart grids, city traffic control systems, invehicle systems and wireless sensor networks.
These advances opened a gap for novel development solutions adapted to the new design challenges. Model based development formalisms, from which Petri nets can be highlighted, promise to answer these questions: offering high level design concepts that hide the low level platform details, contribute to accelerate development time, minimize the probability of coding errors and reduce timetomarket.
From the existing Petri net [1] based tools, the IOPT tools framework [2] and the underlying Petri net class [3] have been designed for embedded system controller development. However, the IOPT tools currently do not offer component based model composition and lack support for complex data manipulation operations. The formalism proposed in this paper was specified to address both problems: provide support for model composition and introduce a complementary formalism to deal with data driven problems. These extensions simplify the modeling of mixed linear/eventdriven controllers and systems that make extensive use of mathematical data operations. Model composition bring advantages to the modeling of complex systems, support component reuse and allow the creation of component libraries.
2 Relationship to CyberPhysical Systems
This paper proposes a new development formalism designed to support the development of embedded systems and cyberphysical systems. The proposed formalism supports model composition using components. The external interface of the components is defined by input and output signals and events.
The formalism supports both centralized and distributed implementations, where each component can be located on remote Internet locations. A complete Cyberphysical system may be specified as a single model composed by multiple components and the components may be executed at different locations. A communication protocol for remote control, monitoring and debug of embedded controllers [12, 13] satisfies the requirements to support the component interactions.
3 Related Work
The formalism proposed in this paper is the result of previous work around the IOPT tools framework [2] and the IOPT Petri net class [3]. Other Petri net based tools that support the modeling of embedded systems have been proposed by different authors, from which the NCES [4], SNS [5], SIPN [6] and CPN [7] should be mentioned.
However, the traditional Petri net based formalisms have primarily focused on the reactive part of the controllers and do not offer good support to solve datadriven problems. Petri net classes have usually relied on text based mathematical expressions that are enabled when specific places are marked or transitions fire. In some classes these expressions may call procedures written using standard programming languages, as Java and StandardML. In contrast, this paper proposes a hybrid formalism that employs Petri nets and dataflows. Petri nets provide good modeling capabilities to design reactive controllers. Dataflows offer advantages to solve data driven problems, including digital signal processing, linear control of systems and support systems that require many data transformation operations.
Some Petri net based dialects, as the NCES [4] and SNS [5], support model composition based on components communicating through signals and events. One of the main applications of this capability is the study of the interaction between controllers and controlled systems (called plants). However, the plant models often require intensive data processing and are not adequately modeled using Petri nets. The new formalism offers both model composition and data processing capabilities and is well adapted to model the plants and the controllers.
Other formalisms, as the synchronous data flows [8, 9], IEC61499 [10] and Matlab Simulink [11] offer support for data driven problems, but are not centered on Petri nets and do not benefit from all the available Petri net modelchecking tools.
4 Graphical Representation
A DSPnet model (Dataflow, Signals and Petri nets), is a directed graph composed by five types of nodes: Petri net places, Petri net transitions, input/output signals, inputs/output events and dataflow operations. The nodes may connected using two types of arcs: normalarcs and readarcs. Normal arcs correspond to the traditional Petri net arcs. Read arcs are used to transmit data between graph nodes and may be used to connect signals, dataflow operations and Petri net nodes.
Dataflow nodes, called operations, employ mathematical expressions to calculate new values. Each operation has a set of input and output anchors that may be connected to other nodes using read arcs. Each output anchor holds one expression, used to compute the corresponding value. Input anchors are used as operands in the mathematical expressions. Each anchor has an associated name and datatype. Computation time is considered instantaneous, with no propagation delays, implementing a synchronous dataflow behavior. As a consequence, signal loops, where the output of an operation is directly or indirectly feedback to an input, are forbidden. When a signal loop is desired, expressions may employ a delay operator «[−n]», to refer the value of the feedback input from previous execution steps. In the example on Fig. 1, the Cnt operation employs the delay operator to read the previous value of the Counter output signal («Counter[−1]»).
Input and output signals and events are used to define the external interface of the model and establish the communication with the external world. Input signals may be connected to sensors or user interface items like buttons and switches. Output signals may be connected to LEDs, powerelectronics, relays or mechanical actuators. When used as components in distributed cyberphysical systems, the input and output signals and events may be used to communicate with other subsystems. Each signal has an associated datatype. Available datatypes are Boolean, integer ranges and fixedpoint ranges.
Events represent instantaneous actions that may (or not) happen on any execution step. Input events are triggered by external sources, but internal or output events may be triggered by the firing of transitions or as the result of dataflow computations. For example, a dataflow operation may detect the crossing of a predefined threshold on an input signal and produce an event. In this case, the datatype associated with the operation output must be defined as an «event». Events may also be used as input for dataflow operations, treated as Boolean values inside expressions. In Fig. 1, the Up operation produces an event by detecting an up edge on the input signal Btn, and the Cnt operation interprets two events to implement and updown counter.
The Petri net places and transitions are used to specify the control logic of the cyberphysical systems, whose state evolves reacting to external events and changes in signals and dataflow elements. A maximal step execution semantics is employed, where all enabled transitions must always fire in the next execution step. Conflicts between transitions, when multiple enabled transitions compete for the same place tokens, are resolved using priorities.
Transition firing is inhibited using guards and events. A guard condition is defined by a read arc starting on a Boolean signal or dataflow operation, and the transition can only fire when the corresponding value holds true. Read arcs starting on events also prevent transition firing. In this case, the arcs may originate on external events, dataflow nodes producing events or another transition. When the arc originates on a transition, it is equivalent to a synchronous channel. In the same way, when a read arc starts on a place, it creates a guard condition that is equivalent to a test arc: transition firing depends of the place marking but no tokens are consumed and no conflicts with other transitions are raised.
Figure 1 presents several examples of guard conditions and transition input events. Arcs terminating on a transition, with a solid dot near the end, denote a guard condition and arcs ending with a diamond denote an event. Transitions TA1, TA2 and TB1 are conditioned by input events, while transitions TA2, TA4 and TB1 have guard conditions. In particular, transition TA4 has a test arc from place PA1 and transitions TA3 and TB1 are connected using a synchronous channel.
In the opposite direction, place marking and events generated by transition firing, may be used to influence the dataflow calculations. Read arcs starting on places read the number of place tokens. Read arcs starting on a transitions transmit events. In Fig. 1 the value of AnalogOut is calculated from place PA3, with value 10 when the place is marked and 5 otherwise. The value of the Counter output is defined by the Cnt operation. This operation implements an up/down counter controlled by events triggered by the TA2 and TA4 transitions.
Arcs may be visualized using two formats: in addition to the usual graphical representation, a symbolic format contributes to minimize clutter and improve readability. When this format is chosen, instead of drawing an arrow, the identifier of the source node is presented near the target node. Figure 1 includes two symbolic arcs. Both arcs start at the Counter output, ending at the Cnt and Err operations.
A typical approach to the design of complex systems, is the assembly of multiple components that implement individual subsystems. This way, the same component subsystems may be reused on multiple projects. Existing models might be used as components to create higher level solutions. Figure 2 displays the external interface of the model presented on Fig. 1. The interface has a set of anchors corresponding to the input and output signals and events defined in the original model, which may be directly used in other models using read arcs. Distributed implementations may place the components on different hardware platforms, or even on remote network locations. Centralized implementations may start with the assembly of a flat model containing the contents of all components.
5 Formal Definition
A DSPnet is a directed graph composed by three parts: an external interface composed by input and output signals and events, a state control part consisting of a lowlevel Petri net and a dataprocessing part composed by dataflow operations and internal signals.
Definition 1:
A system specified by a DSPnet is described as a tupple DSPnet = (P, T, S, E, O, A, R, m_{ 0, }s_{ 0 }, w, pt, ex, st, ot) satisfying the following requirements:
 (1)
P is a finite set of places
 (2)
T is a finite set of transitions
 (3)
S is a finite set of signals
 (4)
E is a finite set of events
 (5)
O is a finite set of dataflow nodes, called operations
 (6)
P ∪ T ∪ S ∪ E ∪ O = ϕ
 (7)
A is a finite set of normal Petri net arcs with A ⊆ (P × T) ∪ (T × P)
 (8)
R is finite set of read arcs with
\( \begin{aligned} R \, \subseteq & \, \left( {S \times S} \right) \, \cup \, \left( {S \times O} \right) \, \cup \, \left( {S \times T} \right) \, \cup \, \left( {O \times S} \right) \, \cup \, \left( {O \times O} \right) \, \cup \, \left( {O \times T} \right) \, \cup \\ & \left( {P \times T} \right) \, \cup \, \left( {O \times E} \right) \, \cup \, \left( {E \times O} \right) \, \cup \left( {E \times E} \right) \, \cup \, \left( {E \times T} \right) \, \cup \, \left( {T \times T} \right) \\ \end{aligned} \)
 (9)
\( \forall s \in S, \, \# \{ (x \times s)(x \times s) \in R\} \le 1\quad \left( {{\text{signals}}\,{\text{have}}\,{\text{no}}\,{\text{more}}\,{\text{than}}\,{\text{one}}\,{\text{input}}\,{\text{arc}}} \right) \)
 (10)
\( \forall e \in E, \, \# \{ (x \times e)(x \times e) \in R\} \le 1\quad \left( {{\text{events}}\,{\text{have}}\,{\text{no}}\,{\text{more}}\,{\text{than}}\,{\text{one}}\,{\text{input}}\,{\text{arc}}} \right) \)
 (11)
m_{ 0 } is the initial placemarking function with mapping m_{ 0 }: P → N_{ 0 }
 (12)
s_{ 0 } is the initial signal values partial function with mapping s_{ 0 }: S → {N_{ 0 },}
 (13)
w is the normalarcs weight function with mapping w: A → N_{ 0 }
 (14)
pt is the transition priority function with mapping pt: T → N_{ 0 }
 (15)
ex is a function applying operations to mathematical expressions (where all expression nonliteral operands are the source of the operation input arcs)
 (16)
ex : O → exp, where ∀nlop ∈ exp(O), nlop ∈ {x(x, O)∈R}
 (17)
st is a signal type function with mapping st: S → t, t ∈ {Boolean, Range}
 (18)
ot is an operation result type function with mapping ot: O → t, t ∈ {Boolean, Range, Event}.
The external interface of a system defined by a DSPnet is composed by a set of input signals, output signals, input events and output events that is a subset of the system signals and events.
Definition 2:
The external interface of system specified by a DSPnet is a tuple EIF = (IE, IS, OE, OS) satisfying the following requirement:
 (1)
IE ⊆ E
 (2)
IS ⊆ S
 (3)
OE ⊆ E
 (4)
OS ⊆ S
 (5)
IE ∩ IS ∩ OE ∩ OS = ϕ
 (6)
\( \forall s \in IS, \, \{ (x \times s)(x \times s) \in R\} = \phi \quad \quad \left( {{\text{input}}\,{\text{signals}}\,{\text{have}}\,{\text{no}}\,{\text{input}}\,{\text{driver}}\,{\text{arcs}}} \right) \)
 (7)
\( \forall e \in IE, \, \{ (x \times e)(x \times e) \in R\} = \phi \quad \quad \left( {{\text{input}}\,{\text{signals}}\,{\text{have}}\,{\text{no}}\,{\text{input}}\,{\text{driver}}\,{\text{arcs}}} \right) \).
A system defined by a DSPnet can be decomposed in two parts, the state control logic and the dataprocessing part:
Definition 3:
The state control logic part of a DSPnet is a low level Petri net defined by a tuple PN = (P, T, A, m_{ 0 }, w, tp, R^{−}) where:
 (1)
P is the DSPnet set of places
 (2)
T is the DSPnet set of transitions
 (3)
A is the DSPnet set of normal arcs
 (4)
m_{0} is the DSPnet initial marking mapping m_{0}: P → N_{0}
 (5)
w is the DSPnet arc weight mapping w: A → N_{0}
 (6)
tp is the DSPnet transition priority mapping: T → N_{0}
 (7)
R_{ P } is a subset of the DSPNet set of read arcs such as R_{ P } ⊆ R ∧ R^{−} ⊆ (P × T)∪(T × T)
(test arcs and synchronous channels).
Definition 4:
The data processing part of a DSPnet is a synchronous dataflow SDF = (O, S, E,\( R^{ + } \)_{,}s_{ 0, }ex, st, ot) where:
 (1)
O is the DSPnet set of dataflow operation nodes
 (2)
S is the DSPnet set of signals
 (3)
E is the DSPnet set of events
 (4)
R_{ D } is a subset of the DSPnet read arcs R_{ D } = R – R_{ P }
 (5)
s_{ 0 } is the DSPnet initial signal values partial function s_{ 0 }: S → {N_{ 0 }, −}
 (6)
ex is the DSPnet operation expressions function
 (7)
st is the DSPnet signal types function
 (8)
ot is the DSPnet operation results type function.

Literal operands: decimal values or hexadecimal values starting with the «0x» prefix

Variable operands corresponding to the graph nodes directly connected through input arcs

The arithmetic operators +, −, *, / and MOD, plus the unary operator −

The comparison operators =, <>, <, <=, > and >=

The logical operators AND, OR, XOR and the unary operator NOT

The « bit » operators and (&), or () and not (!) in addition to shift left («) and shift right (»),  Subexpressions inside parentheses (and)

The delay operator ([−n]) in association with variable operands, to refer past values from previous execution steps

The array index operator ([+ i]) associated with tables of constant values stored in operation nodes, to implement mathematical functions based on tables of values

The conditional operators WHEN and OTHERWISE to build if/case constructs.
In Fig. 1, the Cnt updown counter was implemented using the expression:
 (a)
The previous value of Counter plus 1 if the CntUp event happens
 (b)
The previous value of Counter minus 1 if CntDn happens
 (c)
The value remains unchanged when none of these events occur.
6 Execution Semantics
The execution semantics of the proposed modeling formalism inherits principles from both synchronous data flows [9] and low level Petri nets [1], in particular from the IOPT Petri net class [3].
The evolution of the system state is performed in quantum steps, called execution steps that typically occur at a certain frequency, with variable of fixed time intervals. Each execution step is considered instantaneous, but may be divided in a finite number of microsteps.
As presented in Definition 3, the state control logic part of a model consists on a low level Petri net. As a consequence, the main aspect defining the evolution of a Petri net are the firing rules associated with transitions: in order to fire, a transition must be simultaneously enabled and ready.
Definition 5:
A transition is enabled when all input places, connected through normal Petri net arcs, hold a number of tokens that is equal or more than the respective arc weights. For a transition t: ∀(p ∈ P  (p,t) ∈ A), m(p) > w(p,t).
Definition 6:
A transition guard condition is defined by a read arc ending in the transition, originating on a node containing a Boolean value or a range value, evaluated as true when different from zero.
Definition 7:
A transition input event is defined by a read arc ending in the transition, originating on an event, a transition or an operation producing a result of type event.
Definition 8:
A transition is ready when all guard conditions and input events are true
Definition 9:
Maximal step execution semantics  all transitions simultaneously enabled and ready are forced to fire on the next execution step.
Definition 10:
Conflict – Two or more transitions are in conflict when all of them are simultaneously enabled, but the number of tokens on the shared input places is not enough to fire all of them.
Definition 11:
Conflict resolution – Conflicts between transitions are solved using priorities. Priority criteria is composed by: (1) execution microstep, (2) transition priority and (3) transition unique identifier.
A read arc starting on a transition propagates events produced when the transition fires, called transition output events. These events can be forwarded to other transitions or used by dataflow operations. For example, a read arc directly connecting two transitions creates a synchronous channel, where the source transition can be viewed as a master and the target as a slave. Synchronous channels are typically used to synchronize transitions located inside different components. Systems with multiple components may contain large chains of masterslave transitions.
However, as both the master and slave transitions must fire on the same execution step (when enabled and ready), the execution semantics rules must ensure that the firing of the master transitions is evaluated before evaluating the slave transitions. Any dataflow operations that depend on events produced by the masters must also be calculated before evaluating the slave transitions. This problem lead to the concept of microsteps, that define a precise sequence of evaluation. All DSPnet nodes are associated with a microstep number, including transitions and dataflow operations.
Definition 12:
Microstep assignment:
 (1)
Nodes with no input read arcs are assigned to microstep 1.
 (2)
Nodes with input read arcs are assigned a microstep number corresponding to the maximum microstep associated with these input read arcs, according to the following rules:
 (a)
Read arcs used in inside mathematical expressions in association with the delay operator «[−n]», are assigned to microstep 1, as the expression uses values stored from previous executions steps.
 (b)
Read arcs starting on a transition, propagating transition output events, are assigned a microstep number equal to the transition microstep plus 1.
 (c)
Read arcs starting on nontransition nodes, are assigned the same microstep number as the source node.
 (a)
In the same way as transition dependencies lead to the concept of microsteps, the existence of dependencies between dataflow operations evaluated in the same microstep, require the definition of another sequencing mechanism to finetune the order of operations evaluation, called nanosteps.
Definition 13:
Nanostep assignment:
 (1)
Nodes with no input read arcs are assigned to nanostep 1.
 (2)
Nodes with input read arcs are assigned a nanostep number corresponding to 1 the maximum nanostep associated with these input read arcs, according to the following rules:
 (a)
Read arcs used in inside mathematical expressions in association with the delay operator «[−n]», are assigned to nanostep 1.
 (b)
Read arcs starting on nodes from past microsteps, including all places and transitions, are assigned nanostep 1.
 (c)
Read arcs starting on nodes from the same microstep, are assigned 1 plus the source node nanostep number.
 (a)
Lemma 1:
Any dataflow operation nodes sharing the same microstep and nanostep numbers can be evaluated by any execution order, or executed in parallel.
It is important to notice that microstep and nanostep numbers are just used to sort the operation/transition nodes and define a deterministic sequence of evaluation, but does not imply any clocking scheme for hardware or software implementations.
In order to be syntactically correct, the number of microsteps and nanosteps must be finite and a DSPnet cannot exhibit loops where nodes with higher micro/nano step numbers are used by nodes with lower numbers. This would contradict the rules on definitions 12 and 13, even if the loops occur across nodes located on different components. To avoid loops, the external interface of the components must include information about the dependencies between input and output signals and events. When models of the individual components are available, a flat model containing all the nodes from all components should be constructed and analyzed.
In conclusion, the following algorithm may be used to implement an execution step of a system described by a DSPnet:
7 Conclusion and Future Work
Relative to previous solutions, the new formalism offers many advantages to model datadriven systems that do not employ traditional statemachines, with advantages over purely Petri net centered based languages. As an example, Fig. 3 presents a simple data flow model of a video image generator model. This model may be easily translated to VHDL and implemented on a FPGA device, to generate a video image that presents two windows with rectangular buttons that lighten whenever several input signals are active. A Web based graphical editor for the proposed formalism is currently under development, and all the examples presented in this paper were designed using this tool. The editor implements an algorithm to calculate the microstep and nanostep number according to the definitions presented in this paper and displays the results. Future work includes the development of an entire tool framework, including a Web based simulator, modelchecking tools, automatic code generation tools for software (C) and hardware (VHDL) based platforms. An existing protocol to support distributed implementations and remote debug and monitoring over the internet [12, 13] will be ported to the new formalism.
References
 1.Reisig, W.: Petri Nets: An Introduction. Springer, New York (1985)CrossRefzbMATHGoogle Scholar
 2.Pereira, F., Moutinho, F., Gomes, L.: IOPTTools  towards cloud design automation of digital controllers with Petri nets. In: ICMC 2014 International Conference on Mechatronics and Control, Jinzhou, China, 3–5 July 2014Google Scholar
 3.Gomes, L., Moutinho, F., Pereira, F., Ribeiro, J., Costa, A., Barros, J.P.: Extending inputoutput placetransition Petri nets for distributed controller systems development. In: ICMC 2014  International Conference on Mechatronics and Control, Jinzhou, China, 3–5 July 2014, pp. 1099–1104 (2014)Google Scholar
 4.Hanisch, H.M., Lüder, A.: A signal extension for Petri nets and its use in controller design. Fundamenta Informaticae 41(4), 415–431 (2000)zbMATHGoogle Scholar
 5.Starke, P., Roch, S.: Analysing SignalNet Systems. HumboldtUniversiät at zu Berlin, Institut fur Informatik (2002)Google Scholar
 6.Frey, G.: Hierarchical design of logic controllers using signal interpreted Petri nets. In: Proceedings of the IFAC AHDS 2003, SaintMalo, France, vol. 12, pp. 401–406 (2003)Google Scholar
 7.Jensen, K., Kristensen, L.M.: Colored Petri nets: a graphical language for formal modeling and validation of concurrent systems. Commun. ACM 58(6), 61–70 (2015)CrossRefGoogle Scholar
 8.Lee, E.A., Messerschmitt, D.G.: Synchronous data flow. Proc. IEEE 75(9), 1235–1245 (1987). doi: 10.1109/PROC.1987.13876 CrossRefGoogle Scholar
 9.Colaço, J.L., Pagano, B., Pouzet, M.: A conservative extension of synchronous dataflow with state machines. In: Proceedings of the 5th ACM International Conference on Embedded Software, pp. 173–182. ACM (2005)Google Scholar
 10.Vyatkin, V.: Instrument Society of America. IEC 61499 function blocks for embedded and distributed control systems design (p. o3neida). ISAInstrumentation, Systems, and Automation Society (2007)Google Scholar
 11.Dabney, J.B., Harman, T.L.: Mastering Simulink. Pearson, Upper Saddle River (2004)Google Scholar
 12.Pereira, F., Gomes, L.: Minimalist architecture to generate embedded system web user interfaces. In: CamarinhaMatos, L.M., Tomic, S., Graça, P. (eds.) DoCEIS 2013. IFIP AICT, vol. 394, pp. 239–249. Springer, Heidelberg (2013)CrossRefGoogle Scholar
 13.Pereira, F.; Melo, A.; Gomes, L.: Remote operation of embedded controllers designed using IOPT Petrinets. In: 13th IEEE International Conference on Industrial Informatics; 22–24 July 2015, Cambridge, UK (2015)Google Scholar