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

*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 counterexamples are generated which allow to localize error source.

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 which can be divided into subsystems.

Logical model derived from Control Interpreted Petri Net is transformed into format of the NuSMV model checker according to some strictly specified rules [13, 14]:


Logical model into NuSMV model description translation is done automatically using implemented software application.

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 active when appropriate places include token (Figure 12).

```
next(p1) := case 
 p1 & x1 & !x4 : FALSE; 
 p20 & x12 : TRUE; 
 TRUE : p1; 
esac; 
next(p2) := case 
 p2 & x5 : FALSE; 
 p1 & x1 & !x4 : TRUE; 
 TRUE : p2; 
esac; 
...
```
Control Interpreted Petri Nets – Model Checking and Synthesis 187

The requirements list should include as much desired properties as possible, as only they will be checked. It is often written basing on an informal specification. In the best practices, it is specified by customer (in textual form) or by engineers not involved in design process

Using CTL temporal logic the requirements list for considered case study was defined (properties are listed in Figure 13 and described in details in Table 2). All specified requirements are satisfied in the corresponding model description. Some properties concern Petri net structure itself (properties 1 – 20). It is checked, whether particular places are reachable. Next properties describe output signals, which cannot be active at the same time (properties 21 – 23). The last part of properties regards the correlation of input and output

> CTLSPEC EF p1; --1 ... ... CTLSPEC EF p20; --20 CTLSPEC AG !(y5 & y10); --21 CTLSPEC AG !(y6 & y11); --22 CTLSPEC AG !(y9 & y12); --23 CTLSPEC AG (x5 -> AF !y10); --24 CTLSPEC AG (x7 -> AF !y11); --25 CTLSPEC AG (x13 -> AF !y12); --26 CTLSPEC AG (x12 -> AF !y9); --27

(in more or less formalized way).

**Figure 13.** Requirements list

**Property Description**

*...* ...

*24* 

*25* 

*1* It is possible to reach the *p1* place

*20* It is possible to reach the *p20* place

becomes inactive

**Table 2.** Requirements list description

tank) becomes inactive

*21* The *y5* and *y10* output signals can never be active at the same time *22* The *y6* and *y11* output signals can never be active at the same time *23* The *y9* and *y12* output signals can never be active at the same time

> Always, when the *x5* input signal is active (maximal fluid level in the first tank), finally the *y10* output signal (controlling valve for filling the first tank)

> Always, when the *x7* input signal is active (maximal fluid level in the second tank), finally the *y11* output signal (controlling valve for filling the second

> finally the *y12* output signal (carriage movement to the left) becomes inactive

finally the *y9* output signal (carriage movement to the right) becomes inactive

*<sup>26</sup>*Always, when the *x13* input signal is active (carriage location on the left),

*<sup>27</sup>*Always, when the *x12* input signal is active (carriage location on the right),

signals.

**Figure 10.** Rules in verifiable model (assignment of next values to places)

```
next(x1) := case 
 p1 : {FALSE, TRUE}; 
 TRUE : FALSE; 
esac; 
next(x2) := case 
 p5 : {FALSE, TRUE}; 
 TRUE : FALSE; 
esac; 
...
```
**Figure 11.** Assignment of next values to input signals in verifiable model

```
next(y1) := case 
 p5 : TRUE; 
 TRUE : FALSE; 
esac; 
next(y2) := case 
 p6 : TRUE; 
 TRUE : FALSE; 
esac; 
...
```
**Figure 12.** Assignment of next values to output signals in verifiable model

Model description is the first part needed for model checking. Additionally, it is necessary to specify some requirements, which are supposed (expected) to be true in defined model. Structural properties can also be checked on the Petri net level (and do not require model checking technique). However, the most important are here behavioural properties, which describe system functionality, impact of input signals and output signals activity.

Properties to be checked are defined using temporal logic [6, 15, 20] – either LTL (*Linear Temporal Logic*) or CTL (*Computation Tree Logic*). Properties describe safety requirements (*something bad will never happen*), as well as liveness requirements (*something good will eventually happen*). Safety and liveness requirements are the most frequently specified requirements to be verified.

The requirements list should include as much desired properties as possible, as only they will be checked. It is often written basing on an informal specification. In the best practices, it is specified by customer (in textual form) or by engineers not involved in design process (in more or less formalized way).

Using CTL temporal logic the requirements list for considered case study was defined (properties are listed in Figure 13 and described in details in Table 2). All specified requirements are satisfied in the corresponding model description. Some properties concern Petri net structure itself (properties 1 – 20). It is checked, whether particular places are reachable. Next properties describe output signals, which cannot be active at the same time (properties 21 – 23). The last part of properties regards the correlation of input and output signals.


**Figure 13.** Requirements list

186 Petri Nets – Manufacturing and Computer Science

**Figure 10.** Rules in verifiable model (assignment of next values to places)

next(x1) := case

next(p1) := case

next(p2) := case

 p1 & x1 & !x4 : FALSE; p20 & x12 : TRUE; TRUE : p1;

 p2 & x5 : FALSE; p1 & x1 & !x4 : TRUE; TRUE : p2;

TRUE : FALSE;

next(x2) := case

TRUE : FALSE;

p1 : {FALSE, TRUE};

p5 : {FALSE, TRUE};

**Figure 11.** Assignment of next values to input signals in verifiable model

esac;

esac;

esac;

esac; ...

esac; ...

esac; ...

next(y1) := case p5 : TRUE; TRUE : FALSE;

next(y2) := case p6 : TRUE; TRUE : FALSE;

**Figure 12.** Assignment of next values to output signals in verifiable model

requirements to be verified.

Model description is the first part needed for model checking. Additionally, it is necessary to specify some requirements, which are supposed (expected) to be true in defined model. Structural properties can also be checked on the Petri net level (and do not require model checking technique). However, the most important are here behavioural properties, which

Properties to be checked are defined using temporal logic [6, 15, 20] – either LTL (*Linear Temporal Logic*) or CTL (*Computation Tree Logic*). Properties describe safety requirements (*something bad will never happen*), as well as liveness requirements (*something good will eventually happen*). Safety and liveness requirements are the most frequently specified

describe system functionality, impact of input signals and output signals activity.


**Table 2.** Requirements list description

By introducing a subtle modification into Control Interpreted Petri Net, which regards initial marking removing from place *p14* (initial marking involves then only the *p1* place), the corresponding part of logical model and NuSMV model description is also changed. However, such a subtle change dramatically changes net behavior, and thereby designed logic controller behavior. Model checking of the same properties shows now another results. User receives multiple generated counterexamples indicating unsatisfied requirements. Places *p1* to *p12* are reachable, but it is not possible to reach active marking of further places. Next to last requirement is also not satisfied (*CTLSPEC AG (x13 -> AF !y12)*). Summarizing the report – an error occurs starting from transitions *t7* and t*13*, what confirms the fact, that it is indeed correlated with additional initial marking (and actually the lack of it) of Control Interpreted Petri Net.

Control Interpreted Petri Nets – Model Checking and Synthesis 189

digital circuits design allows for frequent verification (simulation, analysis) of developed system. Its main goal is to check, whether designed system works at all, but the circuit might be not optimized. Circuit optimization and minimization of resources usage are here out of

Logical model into VHDL model translation is done automatically using implemented software application. Generated VHDL file for considered drink production process is fully

Model for synthesis starts with input and output signals definition. Petri net places are defined as internal signals. By clock rising edge and active reset signal, some initial values are assigned to places, which correspond to initial marking of a Control Interpreted Petri

For places the one-hot encoding was used (called also *isomorphic places encoding*), which is the most accurate (and the simplest) representation of logical model, however it can cause bigger resources usage. For each place one flip-flop is generated, which label corresponds to particular place etiquette. Flip-flop sets the *1* value, if a place contains token, otherwise it holds the *0* value. Additionally, one-hot encoding is recommended by implementation in FPGA circuits, and even seen as the most effective method for states encoding [23], i.e. in FPGA circuits of Xilinx [21], especially for small automata. It is also possible to extend the

Places marking can change after transitions firing. Conditions connected with transitions correspond to values of input signals and active marking of particular places. If a condition is satisfied, Petri net transition is realized, and thereby its input and output places change

if p1 = '1' and x1 = '1' and x4 = '0' then

Output signals are active by active marking of appropriate places, what is denoted as shown

y1 <= p5; y2 <= p6; y3 <= p4;

...

Net. Additionally, by each clock rising edge places hold their heretofore marking.

scope, however they may be important in some fields [9, 18].

synthesizable.

work to any other encoding.

their marking (Figure 14).

in Figure 15.

**Figure 14.** The *t1* transition firing in VHDL model

end if;

 p1 <= '0'; p2 <= '1'; p3 <= '1'; p4 <= '1';

**Figure 15.** Outputs assignment in VHDL model

When model checking process does not indicate any errors, it is then possible and advisable to focus on synthesizable code. Basing on logical model, model in hardware description language VHDL is built. The model is fully synthesizable and may be then implemented in FPGA for a reconfigurable logic controller.
