**3. Novel approach to formal verification of logic controller specification**

Control Interpreted Petri Net is first written as an abstract rule-based logical model. Then, basing on that model two other models are built – a verifiable model for the NuSMV model checker (described in details in section 3.2, together with requirements list definition expressed in temporal logic) and a synthesizable model in VHDL (for reconfigurable logic controllers, discussed in section 4). Thanks to proposed methodology, synthesized model is formally verified before the implementation and the two models are fully consistent with each other.

#### **3.1. Rule-based logical model of a Control Interpreted Petri Net**

Proposed rule-based logical model used for synthesis and verification purposes is an intermediate format describing desired behaviour of designed logic controller [13, 14]. Model includes variables definition and their initial values, rules describing net functionality, changes of logic controller output and input signal values.

Proposed logical model reflects the behaviour of Moore digital automaton with inputs register (optionally) and outputs register (Figure 3). Combinational circuit (*CC*) controls system behaviour and operates on internal system states.

**Figure 3.** Moore digital automaton with inputs and outputs register

Formally, rule-based logical model can be defined as a seven-tuple:

$$\text{LM} = \{ \mathbf{P}, \mathbf{X}, \mathbf{Y}, \mathbf{S}, \mathbf{T}, \mathbf{O}, \mathbf{I} \}\tag{2}$$

Control Interpreted Petri Nets – Model Checking and Synthesis 181

Logic controller schema with input and output signals (Table 1) is presented in Figure 5. A Control Interpreted Petri Net for drink production process is presented in Figure 6. It has

Initially, both tanks are empty and process can be started. After pressing the *x1* button, drink production process starts. Valves *y10* and *y11* are opened and target containers are loaded on the carriage (*y3*). Filling tanks process (active signals *y1* and *y2*) is a concurrent process. When a tank is already full (signalized by sensor *x5* or *x7* respectively), the appropriate valve for filling tank is closed. Meanwhile, loaded containers and transported (*y12*) to a proper location (sensor *x13*). When the ingredients are ready, it is signalized by sensors *x2*, *x3* and *x4*. Then, ingredients from both tanks are dropped into the main tank (signals *y5* and *y6*), where they are mixed (signal *y4*). Emptying of small tanks is signalized by sensors *x6* and *x8*. When the drink is well mixed, it is indicated by sensor *x9*. Then, ready drink is filled into containers (*y7*, *y8*). When containers filling process ends (sensors *x10*,

A Control Interpreted Petri Net is written formally using temporal logic [15]. Logic representation well corresponds to net structure and behavior, and at the same time is easy

Logical model includes variables definition and their initial values. The following elements of Control Interpreted Petri Net are interpreted as model variables: places, input and output signals. Logical model involves also set of rules, which describe how defined variables change over time. Set of rules influences the system behaviour. Each rule (transition) is presented in a separate row and starts with transition name (a label for particular rule).

*x11*), they are transported (signal *y9*) to their starting location (sensor *x12*).

20 local states and initial marking involves two places – *P1* and *P14*.

**Figure 5.** Logic controller schema

to formally verify and to synthesize.

where:


As an example to demonstrate proposed solution a sample control process was chosen, described by means of Control Interpreted Petri Nets, then formally verified for behavioral properties and synthesized. Control process example was taken from. It was verified using CTL temporal logic and the NuSMV model checker in 2.5.2 version [19].

A simple embedded system for drink production is considered (Figure 4).

**Figure 4.** Real model of process for drink production

Logic controller schema with input and output signals (Table 1) is presented in Figure 5. A Control Interpreted Petri Net for drink production process is presented in Figure 6. It has 20 local states and initial marking involves two places – *P1* and *P14*.

**Figure 5.** Logic controller schema

180 Petri Nets – Manufacturing and Computer Science

verification simplification).

**Figure 4.** Real model of process for drink production

where:

controller),

controller),

Formally, rule-based logical model can be defined as a seven-tuple:





CTL temporal logic and the NuSMV model checker in 2.5.2 version [19].

A simple embedded system for drink production is considered (Figure 4).




As an example to demonstrate proposed solution a sample control process was chosen, described by means of Control Interpreted Petri Nets, then formally verified for behavioral properties and synthesized. Control process example was taken from. It was verified using

LM = {P, X, Y, S, T, O, I} (2)

Initially, both tanks are empty and process can be started. After pressing the *x1* button, drink production process starts. Valves *y10* and *y11* are opened and target containers are loaded on the carriage (*y3*). Filling tanks process (active signals *y1* and *y2*) is a concurrent process. When a tank is already full (signalized by sensor *x5* or *x7* respectively), the appropriate valve for filling tank is closed. Meanwhile, loaded containers and transported (*y12*) to a proper location (sensor *x13*). When the ingredients are ready, it is signalized by sensors *x2*, *x3* and *x4*. Then, ingredients from both tanks are dropped into the main tank (signals *y5* and *y6*), where they are mixed (signal *y4*). Emptying of small tanks is signalized by sensors *x6* and *x8*. When the drink is well mixed, it is indicated by sensor *x9*. Then, ready drink is filled into containers (*y7*, *y8*). When containers filling process ends (sensors *x10*, *x11*), they are transported (signal *y9*) to their starting location (sensor *x12*).

A Control Interpreted Petri Net is written formally using temporal logic [15]. Logic representation well corresponds to net structure and behavior, and at the same time is easy to formally verify and to synthesize.

Logical model includes variables definition and their initial values. The following elements of Control Interpreted Petri Net are interpreted as model variables: places, input and output signals. Logical model involves also set of rules, which describe how defined variables change over time. Set of rules influences the system behaviour. Each rule (transition) is presented in a separate row and starts with transition name (a label for particular rule).


Control Interpreted Petri Nets – Model Checking and Synthesis 183

**Figure 6.** Control Interpreted Petri Net

**Table 1.** Logic controller input and output signals

A rule consists of two separated parts. The first part contains conditions for transition firing, namely names of active places and input signals (if required) needed to fire the transition. If the condition involves more than one variable, variables are usually connected with a logical operator *and* (written as &). It is also possible to connect the variables with logical operator *or* (written as |), what can be used by transition activation with one of many input signals. Similar as by initial values of variables, a variable can take the *TRUE* value (active place / input signal) or the *FALSE* value (inactive input signal). The second part describes marking changing of Petri net places. Usage of a temporal logic operator *X* indicates that marking changing will take place in the next system state. Analogously to previous possible variable values, after transition firing some places can become active (transition output places) or inactive (transition input places, names of these variables are preceded by an exclamation mark). Proposed solution is focused on transitions. Here, transition input places, firing conditions (corresponding to appropriate combinations of input signals) and transition output places are taken into account.

**Figure 6.** Control Interpreted Petri Net

182 Petri Nets – Manufacturing and Computer Science

**Table 1.** Logic controller input and output signals

output places are taken into account.

Inputs

Outputs

Signal Description

*x1* Signal to start the process

*x4* Containers preparation is finished *x5* Maximal fluid level in the first tank *x6* Minimal fluid level in the first tank *x7* Maximal fluid level in the second tank *x8* Minimal fluid level in the second tank *x9* Drink preparation is finished *x10* Filling of the first container is finished *x11* Filling of the second container is finished *x12* The carriage is in its starting location (the right side) *x13* The carriage is in its target location (the left side)

*y1* Preparation of the first ingredient *y2* Preparation of the second ingredient

A rule consists of two separated parts. The first part contains conditions for transition firing, namely names of active places and input signals (if required) needed to fire the transition. If the condition involves more than one variable, variables are usually connected with a logical operator *and* (written as &). It is also possible to connect the variables with logical operator *or* (written as |), what can be used by transition activation with one of many input signals. Similar as by initial values of variables, a variable can take the *TRUE* value (active place / input signal) or the *FALSE* value (inactive input signal). The second part describes marking changing of Petri net places. Usage of a temporal logic operator *X* indicates that marking changing will take place in the next system state. Analogously to previous possible variable values, after transition firing some places can become active (transition output places) or inactive (transition input places, names of these variables are preceded by an exclamation mark). Proposed solution is focused on transitions. Here, transition input places, firing conditions (corresponding to appropriate combinations of input signals) and transition

*y3* Loading containers *y4* Mixing ingredients *y5* Valve for emptying the first tank *y6* Valve for emptying the second tank *y7* Valve for filling the first container *y8* Valve for filling the second container *y9* Carriage movement to the right *y10* Valve for filling the first tank *y11* Valve for filling the second tank *y12* Carriage movement to the left

*x2* Ingredients preparation in the first tank is finished *x3* Ingredients preparation in the second tank is finished Transitions from net from Figure 6 are described as separate rules (Figure 7). Firing of each transition changes marking of its input and output places. For example, firing of the *t1* transition removes token from the *p1* place (expressed by *!p1*) and adds a token into three places staring three concurrent processes: *p2, p3* and *p4* (expressed by *p2 & p3 & p4*).

Control Interpreted Petri Nets – Model Checking and Synthesis 185

Input signals from the net in Figure 6 are assigned to places, where they are essential and may become active (Figure 9). In each other state, the signals remains by default inactive. For example, input signal *x5* can be activated, when Petri net marking involves the place *p2*.

p1 -> (!x1 | x1) & (!x4 | x4);

*Model checking* technique [7, 10] is one of formal verification methods among others like e.g. *theorem proving* or *equivalence checking* and is currently used in the industry in software and hardware production [12]. System model is compared with defined properties and an answer whether they are satisfied or not is given. In case of any detected errors, appropriate

Model checking process can be performed on the whole system or just on a part of it (socalled *partial verification*), what has an important meaning especially by complex systems

Logical model derived from Control Interpreted Petri Net is transformed into format of the

d. Defined variable take some initial values. Each variable takes any of two values (*TRUE*

e. Each place changes according to the rules defined in the transitions *T* and the function *ρ: T → 2X*; conditions of changes between places (token flow) occur in pairs (groups) –

Logical model into NuSMV model description translation is done automatically using

Similar like in logical model, model description for verification starts with variables definition, which correspond to places, input and output signals. Then, initial values are assigned to the variables. Rules describing net behaviour and token flow correspond to values changes of appropriate places (active/inactive marking of places, Figure 10). Input signals change their value only in expected situations (Figure 11). Output signals are in turn

f. Each output signal changes according to the rules defined in the function *λ: M → Y,* g. Each input signal changes randomly, but can take the expected values connected with

**Figure 9.** Input signals in logical model

which can be divided into subsystems.

implemented software application.

or *FALSE*),

a. Each place *p ϵ P* is a variable of Boolean type, b. Each input signal *x ϵ X* is a variable of Boolean type, c. Each output signal *y ϵ Y* is a variable of Boolean type,

in the previous place(s) and in the next place(s),

active when appropriate places include token (Figure 12).

Petri net places or change adequately to the situation.

**3.2. Model checking of rule-based logical model** 

...

counterexamples are generated which allow to localize error source.

p2 -> !x5 | x5; p3 -> !x7 | x7;

NuSMV model checker according to some strictly specified rules [13, 14]:

```
t1: p1 & x1 & !x4 -> X (!p1 & p2 & p3 & p4); 
t2: p2 & x5 -> X (!p2 & p5); 
t3: p3 & x7 -> X (!p3 & p6); 
...
```
**Figure 7.** Set of rules in logical model

Places not mentioned in particular rule do not change marking after firing of the (considered) transition. It means that the particular rule does not change marking of not mentioned places. Rules correspond therefore to Petri net transitions firings, and ipso facto marking changing of places. Situations, when a transition cannot be realized are not considered, supposing that active places hold then their marking. Proposed approach is an inertial description oriented on transitions (based on publications [1]. In the paper [11], because of the presence of Mealy outputs (where output signals values depend on input signal values and current internal system state), additionally output signals connected with particular transition firing are taken into account, besides places and input signals.

Output signals are considered for successive Petri net places. If the activity of particular output signal is connected with more than one place, this signal occurs multiple times on the right side of an arrow, by different places. Proposed notation concerns Moore outputs, where output state depends only from internal state of the system.

Output signals from the net in Figure 6 are therefore assigned to places, in which they are active (Figure 8). For example, the *y10* output signal is active only by active marking of the *p2* place, and active marking of the *p10* place implies the activity of output signals *y4, y5* and *y6*. The other output signals, which are not present on the right side of particular rule (for particular places) remain default inactive. It is also possible to evidently indicate the activity or inactivity of output signal, as in [1], proposed solutions seems however to be intuitive and does not enforce additional information, which could negative influence its readability.

```
p2 -> y10; 
p3 -> y11; 
p4 -> y3; 
... 
p10 -> y4 & y5 & y6; 
...
```
**Figure 8.** Output signals in logical model

Input signals changes are also defined in logical model. However, the definition is only used by model checking process (model description preparation). In the HDL (*Hardware Description Language*) file, input signals are not concerned as they are inputs to the logic controller. Input signals coming from different objects, supervising system or system operator are considered analogously like output signals for successive Petri net places.

Input signals from the net in Figure 6 are assigned to places, where they are essential and may become active (Figure 9). In each other state, the signals remains by default inactive. For example, input signal *x5* can be activated, when Petri net marking involves the place *p2*.

```
p1 -> (!x1 | x1) & (!x4 | x4); 
p2 -> !x5 | x5; 
p3 -> !x7 | x7; 
...
```
**Figure 9.** Input signals in logical model

184 Petri Nets – Manufacturing and Computer Science

**Figure 7.** Set of rules in logical model

...

**Figure 8.** Output signals in logical model

Transitions from net from Figure 6 are described as separate rules (Figure 7). Firing of each transition changes marking of its input and output places. For example, firing of the *t1* transition removes token from the *p1* place (expressed by *!p1*) and adds a token into three

Places not mentioned in particular rule do not change marking after firing of the (considered) transition. It means that the particular rule does not change marking of not mentioned places. Rules correspond therefore to Petri net transitions firings, and ipso facto marking changing of places. Situations, when a transition cannot be realized are not considered, supposing that active places hold then their marking. Proposed approach is an inertial description oriented on transitions (based on publications [1]. In the paper [11], because of the presence of Mealy outputs (where output signals values depend on input signal values and current internal system state), additionally output signals connected with

Output signals are considered for successive Petri net places. If the activity of particular output signal is connected with more than one place, this signal occurs multiple times on the right side of an arrow, by different places. Proposed notation concerns Moore outputs,

Output signals from the net in Figure 6 are therefore assigned to places, in which they are active (Figure 8). For example, the *y10* output signal is active only by active marking of the *p2* place, and active marking of the *p10* place implies the activity of output signals *y4, y5* and *y6*. The other output signals, which are not present on the right side of particular rule (for particular places) remain default inactive. It is also possible to evidently indicate the activity or inactivity of output signal, as in [1], proposed solutions seems however to be intuitive and does not enforce additional information, which could negative influence its readability.

Input signals changes are also defined in logical model. However, the definition is only used by model checking process (model description preparation). In the HDL (*Hardware Description Language*) file, input signals are not concerned as they are inputs to the logic controller. Input signals coming from different objects, supervising system or system operator are considered analogously like output signals for successive Petri net places.

p10 -> y4 & y5 & y6;

p2 -> y10; p3 -> y11; p4 -> y3;

...

...

particular transition firing are taken into account, besides places and input signals.

where output state depends only from internal state of the system.

places staring three concurrent processes: *p2, p3* and *p4* (expressed by *p2 & p3 & p4*).

t2: p2 & x5 -> X (!p2 & p5); t3: p3 & x7 -> X (!p3 & p6);

t1: p1 & x1 & !x4 -> X (!p1 & p2 & p3 & p4);
