Knowledge-based approach to Petri nets analysis

Knowledge-based approach to Petri nets analysis M Benmaiza and M R Elkaraksy

In this paper a knowledge-based experimental tool for Petri nets modelling and analysis is presented. The tool consists of a graphical editor, allowing the capture and editing of Petri net graphs, integrated with an expert system allowing an automated analysis of an edited Petri net graph. According to goals set by the user, the expert system performs the necessary reasoning about reachability and invariance properties of the analysed Petri net graph and displays inferred results to the user. The core of this expert system is based on rules capturing the general knowledge (i.e. expertise) about reachability and invariance of Petri nets. The definition of these rules forms an interesting and original part of the work. Prolog was used as the implementation language of the expert system. Keywords: Petri nets, invariants analysis, reachability tree analysis, expert system Modelling and analysis of parallel and concurrent systems using Petri nets has become a very wide domain for research and applications. Tools for Petri net graphs editing and analysis exist and are steadily more available~; examples of such tools are OVIDE 2 and P R O T E A N 3. These tools generally allow the user to perform graphical editing of Petri net graphs (capture of Petri net graphs, production of reachability trees and invariant calculation). The user has then to scan the produced invariants and reachability tree, determine the characteristics (reachability, liveness, boundedness, consistency, invariance and restartability) of his model and restart the process of editing/analysis if needed. Based on the fact that a certain expertise is needed in order to derive Petri net properties from invariants or reachability trees, an expert system based Petri net analysis seemed to us an interesting and promising approach for an automated Petri net analysis. This paper presents a knowledge-based integrated tool and takes an expert system approach to the College of Computer and Information Sciences, King Saud University, PO Box 51178-Riyadh 11543, Saudi Arabia Paper received 5 February 1990. Revised paper received 30 May 1991 144

automation of Petri nets analysis. The basic idea behind the approach is to let the expert system have as fact base the reachability tree and invariants of the Petri net graph under study and as ~nference rules, a set of rules based on Petri net theory, defning the fundamental properties of Petri nets. In other words, the expertise that a user must have to analyse the net is implemented as a set of rules in the expert system. Rule definition was an interesting and original task that was achieved in the implementation of the expert system. Although our work was aimed at developing a fully integrated tool for Petri net modelling and analysis4 consisting of (a) a fully automated graphical editor including reachability tree and invariants production and (b) an expert system fully automating the analysis of Petri net graphs, this paper focuses mainly on the presentation of the expert system part. The paper initially presents a general overview of the integrated tool and stresses the main characteristics of the graphical editor. There follows a brief introduction to the basic fundamentals in Petri net theory covering Petri net analysis. The major part of the paper details the expert system-based Petri net analysis and is concluded by a summary of the obtained results and an outline of future work and prospects. Basic knowledge of Petri nets as found in References 5, 6 and 7 is assumed (Appendix A gives a brief overview of Petri nets).

I N T E G R A T E D TOOL FOR PETRI NET ANALYSIS As shown in Figure 1, modules implementing is called the graphical (this module is called

the tool consists of two main graphical editing (this module editor) and Petri net analysis the expert system for model

analysis). The interface between the graphical editor and the expert system consists of two files containing reachability tree and invariants descriptions. The graphical editor consists of an Editing module, a Reachability Tree Builder module and an Invariants Calculation module. The Editing module deals with the graphical editing of a Petri net graph. Graphical editing implements typical functions of place creation/modifi-

0950-7051/91/030144-13 © 1991 Butterworth-Heinemann Ltd

Knowledge-Based Systems

GRAPHICAL

/

/

EDITOR

• I EdItIngM°dule

]

Incidence Matrices I Reachablllty-tree ____._~|& InvarlentsModules ---'---~ / Userinterface /

\

/

Invarlants Calculation

Reacheblllty-tree Builder

~

]

~

Reach.-trae

Invsrlants

Base

Jl

R~ch.-tree

Reasoning Module

•

/nvarla•ts Heasonlng Module

EXPERT

Figure 1.

SYSTEM

General structure of the integrated tool

cation/deletion, transition creation/modification/deletion and arcs creation/modification/deletion. Place creation specifies the place name and its initial marking. Transition creation specifies the transition name and its shape. Arc drawing is performed so that objects (places or transitions) are not crossed by arcs. This feature is important for the readability of the Petri net graph and required the design and implementation of a special arc drawing algorithm. Place or transition deletion involves the deletion of all the incoming or outgoing arcs to or from the deleted object to keep the consistency of the Petri net graph. Error checking is performed as to the existence/non-existence of objects or arcs being edited. Petri net graphs can be saved for later editing. The editing module, upon completion of a Petri net graph editing, saves the edited graph (if requested) and automatically creates the forward and backward incidence matrices of the corresponding Petri net graph in a file used at a later stage by the reachability tree builder module and the invariants calculation module. Figure 2 shows an example of an edited Petri net graph as appearing on the screen. The Reachability Tree Builder module takes as input the incidence matrices file produced by the graphical editor and produces a file containing the corresponding reachability tree description in terms of Prolog predicates. Figure 3 shows a reachability tree description of the Petri net graph given in Figure 2. 'state' predicates describe all the states of the reachability tree with their markings and their type: root ("R"), leaves ("T") or intermediates ( .... ). 'set-places' and 'set-trans' predicates define the set of places and transiffons of the Petri net graph. 'direct desc' predicates describe the descendent relationship between two states. For Vol 4 No 3 September 1991

example, direct desc(["Tl"],"sl,"s0") reads: we move from sO to sl after firing the transition T1. The respective markings of nodes sO and sl are defined by the corresponding 'state' predicates (the order of the places is the one given by 'set-places' predicate). From Figure 3, we notice that what is actually produced by the Reachability Tree Builder module is an unfolded graph, i.e. a tree. The Invariant Calculation module allows us to calculate the minimal set of invariants (place and transition invariants) corresponding to the edited Petri net graph. The algorithm used to implement invariant calculation is based on a linear algebra approach and is an adaptation of the algorithm presented in Reference 8. The output of this module is a file containing the calculated invariants represented also as Prolog predicates. Figure 4 shows the invariants corresponding to the Petri net graph of Figure 2 in the format as produced by the Invariants Calculation module. 'set_places' and 'set__ trans' have the same meaning as previously. 'invp' describes a place invariant and 'invt' a transition invariant. For example invp[(1,1,1,1,1,1,1)] represents place invariant Ei=l,7~(Pi)=l, given that the initial marking is 1 for p~ and 0 for all other places; and invt[1,1,1,1,0,1,0,0,0,0,0)] corresponds to a transition invariant showing a firing cycle involving the transitions tl,t2,t3,t4 and t6. The expert system is mainly composed of two modules performing reasoning about Petri net graphs properties: the Reachability Tree Reasoning module and Invariance Reasoning module. Reachability Tree reasoning comprises basically the deriving of reachability, liveness, boundedness, safeness and restartability properties of a given Petri net graph while invariant reasoning deals with consistency and invariance of a Petri net graph from which not only liveness and boundedness of a model can be derived but also semantic properties (such as mutual exclusion). In this section, we have given a general overview of the developed tool focusing mainly on the graphical editor; the expert system part is described later in the paper. More details about the graphical editor and the expert system can be found in Reference 4. Basic Petri net theory necessary to understand inference rules definition is introduced in the following section. P E T R I NET ANALYSIS Petri net analysis consists of deriving the basic properties of a Petri net graph such as the one shown in Figure 2. They generally give a good idea about the behaviour of the modelled system. Two approaches exist in Petri net analysis: behavioural analysis based on the reachability tree of the analysed Petri net and structural analysis based on the invariants of the analysed Petri net. Based on the exhaustive enumeration of the set of all reachable markings, behavioural analysis is seen as a fine-grain analysis capable of addressing properties of individual places or transitions. On the other hand, invariant analysis depending only on the structure on a given Petri net, addresses more global properties linked to a Petri net as a whole and as such is seen as a coarsegrain analysis. The two approaches appear to be cam145

Figure 2.

Graphkal editor screen representation of a Petri net graph. PO! is the only marked place (one token)

plementary to each other and for this reason we took the decision to implement both of them.

Basic properties of Petri nets In what follows, basic properties of Petri nets relevant to inference rules definition will be given. Notations and definitions follow5. For completeness, a brief overview on Petri nets is given in Appendix A. Given an initial marking #o, let us consider a marked Petri net C=(P,T,I,O,po), its graph (G,/~0 and the set of reachable markings R(G,#o). N is the set of nonnegative integers.

Boundedness A place Pi 6 P is k-bounded iff V/~ ~ R(G,~),/z(p~)
Liveness A transition tiET is live in (G,po), if V/~ ~ R ( G , ~ ) , 2 a e T* such that 6(/~,crti) is defined (i.e. 6(/.t,o ti)=//' ). A Petri net is live if all its transitions are live.

Restartability A Petri net is restartable iff V/~ e R ( G , ~ ) , 3 o e T* such that 6(/u,ty)=~.

Invariance Invariance properties of a Petri net are properties expressing relations between places (place invariance) and relations between transitions (transition invariance) that are dependent only on the structure of the Petri net graph; i.e. these relations are true independently of any marking the Petri net could be in. From invariance properties of a Petri net, restartability, boundedness and liveness can a!so be asserted to some extent; other properties that deal with the semantics of 146

the model represented by the Petri net can be also derived. However, in our implementation we did not take into consideration derivation of semantic properties. Later, we give the important results concerning the invariance properties that were used to define some of the expert system inference rules. Place and transition invariance are defined next. C designates a Petri net incidence matrix as defined in Appendix A.

Place invariance A place invariant is a row vector q9 solution of the matrix equation q~.C = 0. Place Pi of the Petri net is represented by the element tp[i]. Assuming a Petri net with four places, an example of a place invariant could be qg=(1,1,0,0) corresponding to the invariant relation/~(p0+/~(p2)=k, where k is a constant representing the sum of the initial markings of p~ and P2- If, in addition, k= 1, then the above relation expresses mutual exclusion between places p~ and P2 and at the same time, their boundedness.

Transition invariance A transition invariant is a column vector q~ solution of the matrix equation C.qoT=0. The vector q~T contains one element per transition. (q5r is the transpose of qJ.) Transition invariants express the existence of transition firing cycles. An example of such an invariant could be q0T = (1,1,0,0,1,0,0,0,1) corresponding to the firing cycle tlt2t5t5t9 involving transitions tl,t2,t5 and t9. In this cycle transition t5 fires twice.

Reachability tree analysis A reachability tree is a graphical representation of the direct reachable relation 6(/&,t) for all markings belonging to the set of reachable markings R ( G , ~ ) . Usually a reachability tree is represented graphically as Knowledge-Based Systems

state ("s0" , [ I , 0 , 0 , 0 , 0 , 0 , 0 ] , " R " ) state ("sl" , [ 0 , i , 0 , 0 , 0 , 0 , 0 ] , " ") ") state ("s3" , [ 0 , 0 , i , 0 , 0 , 0 , 0 ] , " state ("s4" ,[o,o,o,z,o,o,o],,, ,,) ") state ("s5" , [ 0 , 0 , 0 , 0 , i , 0 , 0 ] , " state ("s7" , [0, i, 0 , 0 , 0 , 0 , 0 ] , "T") state ("s8" , [ I , 0 , 0 , 0 , 0 , 0 , 0 ] , " T " ) state("s6", [ 0 , 0 , 0 , 0 , 0 , i , 0 ] , " ") state("s9", [0,0,1,0,0,0,0],"T") state("sl0", [ 0 , 0 , 0 , 0 , 0 , 0 , I ] , " ") state("sll", [0,0,0,0,0,1,0],"T") state("s2", [ 0 , 0 , 0 , 0 , i , 0 , 0 ] , " ") state("sl2", [ 0 , i , 0 , 0 , 0 , 0 , 0 ] , " ") state("sl4", [ 0 , 0 , I , 0 , 0 , 0 , 0 ] , " ") state("slS", [ 0 , 0 , 0 , i , 0 , 0 , 0 ] , " ") state("sl6", [0,0,0,0,1,0,0],"T") state("sl7", [ 0 , 0 , 0 , 0 , 0 , i , 0 ] , " ") state("slS", [0,0,1,0,0,0,0],"T") state("sl9", [0,0,0,0,0,0,I]," ") state("s20", [0,0,0,0,0,1,0],"T") state("sl3", [I,0,0,0,0,0,0],"T") direct d e s c ( [ " T l " ] , " s l " , " s 0 " ) direct_-desc ( ["T2"] , "s3", "sl") direct d e s c ( [ " T 3 " ] , " s 4 " , " s 3 " ) direct--desc ( ["T4" ] , "s5", "s4") d i r e c t ~ d e s c ( [ "T5" ] , "s7", "s5") d i r e c t _ d e s c ( [ "T6" ], "s8", "s5") direct d e s c ( [ " T 7 " ] , " s 6 " , " s 4 " ) direct d e s c ( [ " T 8 " ] , " s 9 " , " s 6 " ) d i r e c t ~ d e s c ( ["T9"] , "sl0", "s6") d i r e c t _ d e s c ( ["TI0" ] , "sli", "sl0") d i r e c t _ d e s c ( [ "TI I" ] , "s2", "sO") d i r e c t _ d e s c ( [ "T5" ] , "s12", "s2") direct d e s c ( [ " T 2 " ] , " s l 4 " , " s l 2 " ) d i r e c t - d e s c ( [ "T3" ] , "s15',, "s14") d i r e c t - d e s c ( ["T4" ] , "s16", "s15") direct_-desc ( ["T7" ] , "s17", "s15") direct d e s c ( [ " T 8 " ] , " s l 8 " , " s l 7 " ) d i r e c t _ d e s c ( ["T9" ] , "s19", "s17") direct d e s c ( [ " T l 0 " ] , " s 2 0 " , " s l 9 " ) direct d e s c ( [ " T 6 " ] , " s l 3 " , " s 2 " ) set_places( ["Pl", "P2", "P3", "P4", "P5" , "P6", "P7"] ) set

__

Figure 3. module

trans(["Tl"

t

"T2"

t

"T3"

t

"T4"

l

"T5"

l

"T6"

t

"T7"

l

"T8"

l

"Tg"

l

"TI0"

f

"TII"])

Reachability-tree description in terms of Prolog predicates as produced by the Reachability-tree Builder

set places(["PI","P2","P3","P4","P5","P6","P7..]) set_trans ( ["TI" , "T2" , "T3" , "T4" , "T5", "T6" , "T7" , "T8" , "T9" , "TI0" , "Tll" ]) invp( [ i, i, I, i, I, i, I] ) invt ( [ 0, 0, 0, 0, 0, i, 0, 0, 0, 0, i]) invt ( [ 0, 0, i, 0, 0, 0, I, i, 0, 0, 0]) invt ( [ 0, i, i, i, I, 0, 0, 0, 0, 0, 0]) invt( [ i, i, I, i,. 0, i, 0, 0, 0, 0, 0] ) invt([ 0, 0, 0, 0, 0, 0, 0, 0, i, I, 0]) init ( [ "TI", "T!I" ] ) Figure 4. Invariants description in terms of Prolog predicates as produced by the Invariant Calculation module Vol 4 No 3 September 1991

147

shown in Figure 5. Nodes represent markings and arcs are labelled by fired transitions. Reachability, boundedness, liveness and restartability can, in general, be determined from the reachability tree. Determining boundedness is straightforward. Reachability between any two markings can be recursively established (or disproved) using the direct reachable function 6(/~,t). However liveness and restartability are not so obvious to check. In our work we had to develop an original technique based on the existence of firing cycles in a given reachability tree in order to assert liveness and restartability properties. Because of the importance of the concept of cycles to the liveness and restartability rules, the following paragraphs give definitions and properties related to cycles in a reachability tree. In these paragraphs, reference is made to the reachability tree given in Figure 5. Other details of the analysis are given later in the paper. The algorithm used to build the reachability tree is based on an algorithm given in Reference 5 and is fully detailed in Reference 4. R •.. •. - "" . . . . . . . . . . . . . .

$2

/

$13

•~ S12

Properties of reachability trees PI: A reachability tree is an unfolded teachability graph. All different paths, starting from the root node and terminating at a terminal node give all possible transitions firing sequences. P2: Because a reachability tree is an unfolded teachability graph, different distinct nodes along different paths from the root node may have identical markings• P3: The existence of identical markings on the same path from the root node implies the existence of firing cycles in the reachability tree. Repeated markings correspond to terminal nodes by construction of the reachability tree. P4: Terminal nodes are given types depending on whether their markings are identical to the marking of the root node ('LR' type), to a nonterminal node different from the root node ('LC' type) or to none of the nodes ('LT' type). 'LR' type nodes imply the existence of firing cycles through the root node, 'LC' type nodes imply the existence of internal firing cycles and 'LT' nodes indicate deadlock states.

S0

"L~.. •

• .qgl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

~

•

/~

/ff/f

•(.,j8" *~°"..................... """""-...... '.

• t2

•

$4

........ :~ ......... L

..... . ...... 1 , - • S14 •

t3

t4

/

•

S6

f

"" k '.• ',~•

/ /

:

• ,

•S

!

\

~8

\

[9 t9

Q $9

"~

5

\

"r

s15

• / /'

t10

$1 6

/i

• ~ ' ................

• •' / "/"

t8

i :,

,,.

/

i..... : ............... •

,"0

148

~ S8

1"

, T

$11

•

S18

r

Q

S19

I tl0

./'

$20

.'

"•.......................-'°'*

Figure 5.

S7

R : root node T : terminal node Sx : node Sx ti : fired transition

Reachability tree for the Petri net of Figure 2 Knowledge-Based Systems

Definitions and propositions Let us denote S the set of all nodes of a given reachability tree, s~ the name of a node belonging to S and So its root node. #(si) denotes the marking represented by node s~. Definition 1: A cycled-to node is a non-terminal node with a marking identical to an 'LC' or 'LR' type terminal node. Definition 2: Define the sets of nodes SLC and Scr as: SLc= {si•Sltype(s~)='LC'} Scr--{s~•S - {So}Isi is a cycled-to node} Definition 3: An internal cycle C i in a reachability tree is defined by the node pair (Sa, Sb), such that: (1) sa • SLC, Sb • Scr, /'L(Sa)=#(Sb) and (2) 3 o • T* such that 6(#(Sa),O)=#(Sb) In the cycle C~, all nodes are reachable from each other. The set of internal cycles of a given reachability tree is denoted PS.

Definition 4: An internal cycle C i is reachable from another internal cycle Cj (not through the root node), denoted C i ~ Ci, if V Sk • Sq, Vs~ • So, 3 o • T*[6(#(Sk),O)=#(S0 where Sc~ and Scj represent respectively the set of nodes in the cycles Ci and Cj. Proposition 1: Given two internal cycles C~ and Cj and their respective sets of nodes Sa and Sci, if Sc~NScj :/: (Ci and Cj intersect) then Ci--~ Cj and Cj --~ Ci (noted C~ ~ C,). The proof of this proposition is straightforward. Definition 5: Two internal cycles Ci and Cj are said to be reducible if they are intersecting. Proposition 2: The cycle reachability relation ~ is transitive i.e. if Ci ~ Cj and Cj <--->Ck then C~ ~ Ck. The proof of this proposition is based on cycles intersection (proposition 1) and is straightforward. Definition 6: A set of internal cycles C={Ck},ke[1,n] is a reducible set if V Ci, Cj • C,i:~j, C~ ~ C r Proposition 3: The cycle reachability relation *-->is an equivalence relation.

Proof: The relation is reflexive and symmetric by proposition 1 and transitive by proposition 2. So, by proposition 3, a reducible set of internal cycles C is an equivalence class noted [Ci], where C~ • C. Ci can be any of the cycles belonging to C and is used as the representative of the equivalence class.

Definition 7: A reduced set of internal cycles PS~d C_ PS is defined as the set of the representatives of all equivalence classes of internal cycles defined on a given reachability tree. PS~d possesses therefore the following properties: (1) V C, V Cm • PS~od,14=m, C~ and Cm are not reachable from each other, and Vol 4 No 3 September 1991

(2) for (PS - P S r e a ) ~ , V Ci • (PS - PSrea), 3 Ck • PS~dlCi ~ Ck. Definition 8: The set of reduced cycled-to nodes, SrCd, for a given reachability tree is defined as:

Sred={SklCi=(Sz, Sk) • PSr~d} Definition 9: An internal cycle C~ for a given reachability tree is said to be a trap cycle iff it is the only element of an equivalence class of internal cycles and V sx • Sa, Sx does not reach an 'LR' type node. Definition 9 can be extended to a trap equivalence class of internal cycles reachable from each other. Definition 10: An equivalence class of internal cycles reachable from each other C--[Ci] for a given reachability tree is said to be a trap equivalence class if V Ck • C, V Sx • Sck, Sx does not reach an 'LR' type node. Proposition 4: If a reachability tree contains at least one trap cycle (one trap equivalence class of internal cycles) then the corresponding Petri net is not restartable.

Proof: By definition, a trap cycle Ct is equivalent to a deadlock node. This means that if any node belonging to such a cycle is reached then there is no way of returning to the initial marking. So the net cannot restart. The same reasoning applies also to trap equivalence classes.

Proposition 5: If a reachability tree contains at least two trap cycles (two trap equivalence classes of internal cycles) then the corresponding Petri net is neither live nor restartable.

Proof: The net in not restartable by proposition 4. For the non-liveness, let C~ and C2 be two trap cycles. Then by definition they are not reachable from each other. So the net is not live. The next proposition deals with Petri nets which are live but not restartable. Let Tct be the set of transitions labelling the arcs of the internal cycle C~.

Proposition 6: If a reachability tree contains a unique trap cycle Ct (trap equivalence class of internal cycles) directly reachable from So and Vt • T,t • Tc, then the corresponding net is live.

Proof: the uniqueness of the trap cycle and the direct reachability from So ensure that all the nodes of the reachability tree except So are reachable from each other. Because all the transitions of the net appear at least once in the cycle C, and can be repeated indefinitely, then all markings of R(G,#o) are reachable from each other and all transitions are live. This proves the liveness of the net.

Invariants analysis Invariant analysis is based on the theoretical results explained below. Let us define the support of an invariant I, support(l), to be the set of places or transitions such that 149

I(t,) or I(pi) is non null. General results are given below: al) If p e support of place invariant then p is bounded. a2) a place invariant I is said to be total iff V peP, p e support (I). A total transition invariant is defined in the same way. a3) If V peP, p e place invariant, the Petri net is bounded and in addition possesses a total place invariant. a4) If VteT, t e transition invariant, the Petri net possesses a total transition invariant. a5) Transition invariants define firing cycles in a Petri net. Their existence does not involve that they are firable from ~ . a6) A Petri net admitting a total place invariant is said to be invariant and a Petri net admitting a total transition invariant is said to be consistent. Other important results concerning invariance, consistency, liveness and boundedness of a Petri Net (summarized from Reference 9) are stated below: bl) Petri net nonconsistent or noninvariant ~ nonlive or unbounded b2) Petri net nonconsistent and bounded ~ net live b3) Petri net nonconsistent and live f f unbounded and nonrestartable b4) Petri net noninvariant and bounded ~ nonlive b5) Petri net noninvariant and live ~ unbounded.

net nonnet net net

Petri net analysis using an expert system approach Two approaches to the automation of Petri net analysis can be envisaged: a conventional procedural programming language approach or a knowledge-based approach. The second approach implying the implementation of an expert system which allows a great deal of flexibility, can give advice, explain its reasoning and justify its findings 1°-13, seemed to us the most natural, appropriate and attractive one. Once the decision is taken to design the Petri net analyser using the knowledge-based approach, the natural question arises of what software should be used to develop the analyser. The choice is between using an expert system shell together with the accompanying development tools, or an AI programming language such as Prolog. In our case, for the first prototype of the tool, it was decided to develop the expert system to analyse Petri net graphs as a Prolog program; the whole graphical editor and accompanying analyser is intended for educational purposes, to be implemented on a PC, to model and analyse simple Petri nets (extended Petri nets such as Timed or Coloured Petri nets are not considered in this paper). The most important aspect in automating the analysis resides, of course, in defining the basic inference rules based on Petri net theory and heuristic reasoning using a reachability tree and invariants. 150

EXPERT SYSTEM-BASED A N A L Y S E R Reasoning with the reachability tree As seen in Figure 1, reasoning for Petri net properties based on the teachability tree is performed by an expert system module: the Reachability Tree Reasoning module. The knowledge base of this module is loaded with facts (expressed as Prolog predicates) extracted from a reachability tree by the Reachability Tree Builder module. An example of facts built by the Reachability Tree Builder module, for the Petri net graph shown in Figure 2 and its reachability tree given pictorially in Figure 5, is shown in Figure 3 (the meaning of predicates is described earlier in this paper). This form of reachability tree is convenient since it can be used straightforwardly by the expert system.

Overall working process of the expert system During its initialization phase, the expert system scans and marks all terminal nodes as being of one of the following types: terminal node with no descendants ('LT' type), cycle node to the root node ('LR' type), or a cycle node to one of the reachability tree internal nodes ('LC' type). This initialization phase is very important in determining the firing cycles of the analysed Petri net (please see above for definitions of cycles). After this preparatory work, the expert system engages itself in one consultation session during which the user interacts with the expert system by inquiring about properties of his Petri net. The normal working process of the expert system is then to respond to user queries about given Petri net properties by reasoning against its fact base using built-in inference rules. Properties to check are set as goals for the expert system to assert: liveness, restartability, deadlockfreedom (linked to liveness), reachability and boundedness. In what follows and for space limitation reasons, the reasoning process for only some properties of a Petri net graph will be demonstrated. Reasoning for reachability When the user sets the goal 'reachable(/6,)', where & is a marking to be checked if it is reachable from the initial state so with marking Po, the expert system reasoning process makes use of the following two inference rules: Rule 1: state Sx with marking/~, is directly reachable from the initial state So with marking/~, IF sx is a direct descendent of so The premise for this rule may be asserted by checking the existence of the predicate direct desc(ti,"Sx","So"), where t i E T Rule 2: state sx with marking/~ is reachable from the initial So with marking/Zo IF there exists a firing sequence o leading from the initial state So to sx Knowledge-Based Systems

The premise for this rule can recursively be deduced from the fact base of direct desc predicates. Note that there may be more than one possible firing sequence leading from ~ to 14. The reachability tree shows all possible firing sequences because of the way it is constructed (unfolded reachability graph). The basic simplified Prolog clauses invoked to check if state named Sy is reachable from the initial marking ~ are: reach(N1, "sO"): direct-desc(Tx, N1, "sO"), append-trans(Tx). reach(N1, "sO"): direct-desc(Ty, N1, N2), append-trans(Ty), reach(N2, "sO"). The recursive clause 'reach' in essence backtracks the reachability tree starting from the state named Sy and tries to reach the root node. While backtracking, transitions along the path are accumulated using the clause 'append-trans' building a firing sequence o. If this goal succeeds, the expert system concludes that the state indicated is reachable from the initial marking "So" and the firing sequence o is displayed. Reasoning for deadlock Deadlock-freedom checking is simple and straightforward. When the goal 'deadlock' is given, the expert system reasoning is based on the following inference rule: Rule 3: Petri net is deadlocked IF there exists any reachable deadlock state. The premise for this rule can be asserted by checking the fact base for the existence of any terminal state of type 'LT'. Reasoning for restartability As previously explained, during its initialization phase, the expert system discovers and stores in its database the following facts: • The set of internal cycled-to nodes (not including the root node) Scr. • The sets of internal cycles (set of pairs (cycle node, cycled-to node)) PS. For example, for the Petri net of Figure 1, the resulting reachability tree is given in Figure 5 and the set Scr would be: {s2, s14, s17, sl, s3, s6), and the set PS would be: {[s16, s2], [s18, s14], [s20, s17], [s7, sl], [sll, s6], [s9, s3]}. When the goal 'proper' is given, the expert system builds PSrea and Sred. Referring to Figure 5, the reduced cycle sets are those nodes that are cycled-to from nodes sl and s2; the expert system builds Srod and creates the predicate red-cycle-set ([sl, s2]). In the implementation, the representative cycle of an equivalence class of cycles is taken as the outermost inclusive cycle with its Vol 4 No 3 September 1991

head being the upmost of the nodes of the cycles belonging to this equivalence class. This explains why we obtained the set {sl, s2} as a reduced set of internal cycles. Reasoning for restartability is based on the following inference rules: Rule 4: Petri net is restartable IF there are no deadlock states reachable AND there are no internal cycles AND there is at least one reachable state that cycles back to the initial state. Rule 5: Petri net is restartable IF there are no reachable deadlock states AND there are no trap cycles (or trap equivalence class) AND for each existing internal cycle (or equivalence class), there exists a firing sequence from that cycle to the initial state. In terms of firing cycles and referring to definitions given earlier, these rules would have been expressed as: Petri net is restartable if there are (a) no internal cycles ('LC' type nodes) and no deadlock nodes ('LT' type) and at least one 'LR' type node or

(b) no trap cycles (trap equivalence classes of internal cycles) and no deadlock nodes and there are internal cycles ('LC' type nodes) and 3 Sy of type 'LR'[ V sx e Srcd, sx ___qSy. For example, for the reachability tree of Figure 5, sl can reach s8 and s2 can reach s13 and there are no deadlock states, hence the expert system concludes that the Petri net considered is restartable. Reasoning for liveness In essence, for a net to be live (see definition of liveness given earlier), it should be possible to reach any state from any other state (not necessarily going through Po) through a possible firing sequence, and all transitions of the net are firable from any marking belonging to the set of reachable markings R(G,g0). Notice that when the net is unbounded, it is difficult to prove its liveness since markings can be collapsed together. Our approach in that case is to inform the user that valid conclusions cannot be reached and advise him to solve the problem of unboundedness before proceeding further. Before giving the inference rules for liveness, let us recall that Tci is the set of transitions of the internal cycle Ci. We define Tc = y (Tci), V C i E PS as the set of all transitions in all pdssible internal cycles for a given reachability tree. The expert system reasons for liveness as depicted in Figure 6 and the reasoning process makes use of the following inference rules: 151

deadlock [ ~.

Note that the liveness property is reasoned in terms of deadlock and restartability properties. The analysis is based on discovering and analysing internal cycles in case the Petri net is non-restartable but live. For a Petri net, the forming of the set T,. is achieved using the following clauses:

yes

no

~-~. = > non-live T

bounded

~

yes

Advice; we can't conclude since P Net is unbounded Go an6-remedy unboundedness

T restartable

J

noJ

yes

internal distinct cycles

Vt 6 T , t ~ T c

I false

true

"~.~ = > live

one cycle

= > non-live

=

\

>

T non-live

\\ one cycle; one sub-root node Sr

(Let Tc be the set of all firable trans, in the cycle C) Sr is direct-desc of SO ?

Let S tr~v- Sr ti E;Tc ?

=

>

live

=

=

>

accumulate-Tc:direct-desc([Tx],-,-), append-Tc(Tx), fail. accumulate-Tc:TRUE append-Tc(Tx):set-accum-t(y), asserta(set-accum-t([Tx I Y]), retract(set-accum-t(y)).

>

non.live

non-live

Figure 6. Reasoning logic diagram for liveness Rule 6:

advise 'cannot decide on liveness' IF Petri net is unbounded. Rule 7:

Petri net is live IF Petri net is restartable AND every transition in the net belongs to the set Tc.

where 'set-accum-t(B)' is a predicate in the expert system database and B is the accumulated set of all firable transitions in the net. Initially, B is set to empty. Likewise, Tc~ is accumulated using a similar approach. To show how the expert system is actually implemented, a complete and representative example of that part of the Prolog program implementing reasoning for liveness is given in Appendix B. Reasoning with invariants

The Invariant Analysis module of the expert system works as follows: initially, the fact base is loaded with facts in the form of predicates: place and transition invariants, places definition (set-places predicate), transitions definition (set-tram predicate), and the set of firable transitions from the initial marking (init predicate). The invariants expressed as Prolog predicates, as produced by the graphical editor, for the Petri net graph given in Figure 2 are shown in Figure 4. The following inference rules (based on the results stated above) are embedded in the expert system. Definition rules Rule 9:

Petri net is bounded and invariant IF every place in the Petri net belongs to a place invariant. Rule 10:

Rule 8:

Petri net is live IF Petri net is non-restartable AND there are no reachable deadlock states AND there exists one trap cycle only (or trap equivalence class) directly reachable from the initial state. More formally, liveness inference rules are expressed as follows: Petri net is live if (a) it is restartable and Vt~T, teTc,

Petri net is consistent IF every transition in the Petri net belongs to a transition invariant. Concluding rules Rule 11:

Petri net is nonlive or unbounded IF it is non-consistent OR non-invariant.

or

(b) it is not restartable and there are no deadlocks and there exists only one trap cycle C, (or trap equivalence class) directly reachable from/~), i.e. 3 t~ cT I s(, t~ ) C, and t i E T c t . 152

Rule 12: Petri net is nonlive IF it is nonconsistent AND it is bounded.

Knowledge-Based Systems

T(rno) =empty

I (use Rg)

ye~. . . .

=> ~

~o

/

\ C (use RIO)

C (use RIO)

each other. Complementarity of the two approaches is also related to their intrinsic characteristics: derivation of semantic properties of a Petri net can only be performed using invariant analysis and checking state reachability at large is the resort of reachability tree analysis. Derivation of semantic properties and general state reachability are not implemented as such in the tool. However, for some semantic properties (like mutual exclusion) and general state reachability, only minor extensions to the tool are required. C O N C L U S I O N S AND F U T U R E P R O S P E C T S

=> B

= > BL

(R9)

(R9+R12)

Advice:-L or B (R1) ifB =>-L (R14)

Advice: if B =>-L (R12)

ilL => B (R15)

if L = > B'R (R13)

Figure 7. Decision tree for the reasoning with the invariants. I: invariant; C: consistent; L: live; B: bounded; R: restartable; (Rk): Rule k; R stands for 'non-S'

Rule 13: Petri net is unbounded and nonrestartable IF it is non-consistent AND it is live.

Rule 14: Petri net is non-live IF it is non-invariant AND it is bounded.

Rule 15: Petri net is unbounded IF it is non-invariant AND it is live. The reasoning process based on the above rules is carried out according to the decision tree given in Figure 7. For the Petri net shown in Figure 2 and considering its invariants given in Figure 4, the expert system would have concluded that it is invariant, bounded and consistent. Notice that these are the only conclusions to which we can arrive according to proved invariants theory. This obviously shows the limitations of invariants analysis.

Using the expert system: reachability tree or invariant analysis? After the discussion on the basic fundamentals of the automated teachability tree and invariant analysis and explanations about their implementations, a point of interest concerns when to use reachability tree analysis and when to use invariant analysis. Invariant analysis can give a quick snapshot on the general properties of an analysed net while reachability tree analysis allows a deeper understanding of the behaviour of a Petri net. For this reason, a good strategy in using the tool consists of starting by invariant analysis and if there is a need, proceeding to teachability tree analysis. In this way, we can see the two approaches as complementing Vol 4 No 3 September 1991

An integrated tool for Petri net editing and analysis has been presented. The tool consists of a graphical editor and an expert system for automating the analysis of Petri nets based on teachability tree and invariants techniques. The most innovative part of our work is the introduction of a knowledge-based approach to Petri net analysis. The expert system is implemented using Prolog with a static explanation facility being offered. The tool is intended to be an educational tool and to run on PCs with graphics support. We have shown how the necessary facts needed for Petri nets analysis can be captured and presented as Prolog predicates. Knowledge in the form of inference rules for the analysis of uninterpreted Petri nets is based on proved Petri net theory and graph cycles properties. These inference rules mimic an expert's way of analysis by examining a teachability tree or invariants for a given Petri net. Knowledge, in general, may consist of facts, concepts, theories, procedures and relationships. In our case, as mentioned above, knowledge for the analysis of uninterpreted Petri nets is presented only in the form of inference rules based on proved theories; there was no room for an expert's rules of judgement. However, a natural extension to the present work is to analyse Petri net graphs for a specific application domain. Knowledge, in this case, would include rules of judgement on how to interpret Petri net characteristics such as boundedness, liveness etc. as reflected on the modelled system for a particular domain of application. Here, a unified knowledge-based approach for analysis may become obvious. The authors are currently involved in research work aiming at augmenting the developed tool to add more power to it. We realized, while modelling and analysing systems using Petri nets, that one of the most difficult steps in the whole process is to arrive at the model itself. It would be interesting to provide an intelligent user interface that accepts the user specification of the system to be analysed in a high level language and synthesize a Petri net model corresponding to the system. The intelligent interface obviously requires heuristic knowledge about the specific expertise needed in Petri nets synthesis. Work in this direction is currently being investigated. The knowledge domain we took into consideration is specific and is applied to the synthesis of Petri net graphs for communication protocols. The specification language used is the ISO ESTELLE TM. The design approach adopted is again knowledge-based. Preliminary results to that goal may be found in Reference 15. 153

ACKNOWLEDGEMENTS This work was supported by the Research Centre of the College of Computer and Information Sciences at King Saud University, Saudi Arabia as Research Project No. RP14/406-407. REFERENCES 1 Feldbrugge, F and Jensen, K 'Petri net tool overview 1986' Lecture Notes in Computer Science Springer Verlag, New York (1987) 2 Le Mer, E 'OVIDE: A software package for verifying and validating Petri nets, software for computer control' Proceedings of the 3rd IFAC/IFIP Symposium Madrid Pergamon Press, Oxford (1983) pp. 255-260 3 Billington, J, Wheeler, G R and Wilbur-Ham, M C, 'PROTEAN: A high-level Petri net tool for the specification and verification of communication protocols' IEEE-TOSE Vol 14 No 3 (March 1988) pp 301-316 4 E! Karaksy, M R and Benmaiza, M 'Design and implementation of an interactive graphical tool for parallel systems modeling and analysis based on Petri nets' Research Report RP14/406-407, College of Computer & Information Sciences, King Saud University, Saudi Arabia (1989) 5 Peterson, J L Petri Net Theory and the Modeling of Systems Prentice Hall (1981) 6 Peterson, J L 'Petri Nets' Computing Survey Vol 9 No 3 (1977) pp 223-252 7 Murata, T 'Petri nets: properties, analysis and applications' Proceedings of the IEEE Vol 77 No 4 (April 1989) pp 541-580 8 Alaiwan, H and Toudic, J P 'Finding semi-flows, locks and traps in Petri nets' TSI 1-85, pp 103-112 9 Chevaziel-Pradin, B Un Outil Graphique Interactif

pour La Verification des Systemes a evolution parallele decrits par Resaux de Petri D. E. Thesis, P. Sabatier University, France (December 1979) 10 Rich, Elaine Artificial Intelligence McGraw-Hill (1983) 11 Yazdani, Masoud (ed.) Artificial Intelligence: Principles and Applications Chapman and Hall (1986) 12 Waterman, Donald A A Guide to Expert Systems Addison-Wesley (1986) 13 Klabr, Philip and Waterman, Donald A (eds.)

Expert Systems Techniques, Tools, and Applications Addison-Wesley (1986) 14 ISO TC 7/SC 21/WG 1-FDT,Subgroup B 'Estelle. A formal description technique based on an extended state transition model' (September 1986) 15 Benmaiza, M and El Karaksy, M R 'An expert system based user intelligent interface to synthesize Petri net models for communication protocols' Pro-

ceedings of the 12th National Computer Conference Riyadh, Saudi Arabia (October 1990) pp 579-596 BIBLIOGRAPHY Garavaglia, Susan PROLOG Programming Techniques and Applications Harper & Row (1987) Townsend, Carl Mastering Expert Systems With Turbo 154

Prolog Howard W. Sams & Co. (A division of Macmillan, Inc.)(1987) APPENDIX A Basic definitions and properties of Petri nets We use notations, definitions and properties of Petri nets as given in Reference 5. Definition of a Petri net A Petri Net is a 4-tuple C=(P,T,I,O) where: - P = set of places {Pl,P2,...,Pn}, IPI =n, - T = set of transitions {tl,t2 . . . . . . . tm} , I T [ = m , - P= is a multiset (or bag) over the set of places P, - I: T--> P= is the input function. I(t) defines the bag of input places to the transition t, - O:T--~ P= is the output function. O(t) defines the bag of output places to the transition t. Petri net graph Petri nets are usually conveniently represented as bipartite graphs in which circles represent places and bars represent transitions. Input (I) and output (O) functions are represented as labelled arcs from places to transitions or from transitions to places. This graphical representation of a Petri net is called a Petri net graph. Labels or arcs are nonnegative integers representing the multiplicity (i.e. the number of occurrences of a place in a bag) of a given place in the input or output bag of a transition. Multiplicity of place p is noted #(p,I(ti)) or #(p,O(ti)). Petri net marking Let N be the set of non-negative integers. The marking of a place in a Petri net is defined as the function /~:P --~ N associating a number of tokens to a given place. Every place has a marking. The marking of a Petri net is therefore represented as an n-dimensional row vector/&=(/&l,~2,...,/~,,),/6, e N" ([P[=n). /~,i=~k(Pi) N is the individual marking of place Pi. Notice that /6, is only one of the possible markings of the Petri net. A distinguished marking ~ represents the initial marking of all places. A marked Petri net is noted C=(P,T,I,O,#) and its corresponding marked graph is noted (G,g). Marking of a Petri net graph is represented as solid dots (called tokens) within the places. Transition enabling, transition firing A transition tj is enabled in a marking/6, if for all places p~ ~ P, ~ ( p i ) > #(pi,I(tj)). An enabled transition may fire. Firing of a transition removes tokens from its input places and deposits tokens into its output places. When several transitions are enabled, the choice of the transition to fire is nondeterministic. Next marking function The dynamic behaviour of a Petri net is defined in terms of the set of possible markings, a current marking (or state) and the next marking function. The next marking function defines the transition of a Petri net Knowledge-Based Systems

from its current marking to a new marking after the firing of one transition. Next marking function is therefore defined as: 6:Nn X T ---> N" F o r a n e n a b l e d t r a n s i t i o n t,/~ a n d # ' ~ N", w e c a n w r i t e di(/~,t)=#' w h e r e # ' is t h e m a r k i n g r e a c h e d f r o m # a f t e r firing t h e t r a n s i t i o n t. If T* is t h e set o f all t r a n s i t i o n s e q u e n c e s f o r m e d o v e r t h e set o f t r a n s i t i o n T a n d o ~ T * , 6 c a n b e g e n e r a l i z e d as f o l l o w s : 6(/u, cr tj) = 6(6(/t/, o),tj)

Marking reachability for a Petri net If 6 ( # , t j ) = / z ' , t h e m a r k i n g /£ is said to b e d i r e c t l y r e a c h a b l e f r o m t h e m a r k i n g /z. M a r k i n g r e a c h a b i l i t y c a n b e g e n e r a l i z e d in t h e c a s e 6 ( / ~ , o ) = # ' w h e r e o e T*.

Set of reachable markings For a marked Petri net (G,#k), R(G,/-tk) is defined as the set of all markings directly or indirectly reachable from/z k. R(G,#o) is the set of all markings reachable from the initial marking ~ . Matrix representation of Petri nets and fundamental equation of a Petri net Incidence matrices are known to be matrix representations of graphs. Petri net graphs can be represented using backward and forward incidence matrices which are m x n matrices with each row representing one transition and each column representing one place. The forward incidence matrix, noted C + represents the output function O while the backward matrix, noted C- represents the input function I. Provided that a Petri net does not contain self-loops, a Petri net graph can be represented by the incidence matrix C = C + - C-. A n interesting consequence of this matrix representation of a Petri net is the ability to write an equation expressing the marking reachability for a Petri net given its incidence matrix and a firing sequence of transitions o ~ T*. This equation is known as the fundamental equation of a Petri net and is expressed as:

U' =/~ + f(o).C where f(a) is an m-columns firing vector such that f(a)[i] = number of times transition ti ~ T has fired in the sequence ~r. APPENDIX B /* goal 'liveness' checks for liveness */ liveness:-livenessl. livenessl:- /* checks restartability and sets appropriately flag (flagproper) */ init_proper, restartable, livez. init proper:restart(flagproper(_)), asserta(flagproper(0)). livez:-/* case deadlock state(s) */ flagdl(Y),Y = 1, write("...No P_Net is NON_LIVE, deadlock(s)..."),nl.

V o l 4 N o 3 S e p t e m b e r 1991

livez:-/*case deadlock free but unbounded */ flagdl(Y), Y=0, flagbound(Z),Z= 1, write("...PNet is deadlock_free but unbounded."),ni, write("...We cannot reach valid conclusion as for liveness."),nl, write("...Advice to go and remedy unboundedness."),nl. livez:-/* case deadlock_free and bounded */ flagdl(Y), Y=0, flagbound(Z), Z=0, live1. live1:-/* case deadlock free and non_restartable */ flagproper(Z), Z=0, dist_cycles, live2. live1:-/* case deadlock_free and restartable */ flagproper(Z), Z= 1, check live_t, flaglivet(F), F= 1, write("...Yes P_Net is LIVE, since it is restartable and"), write("all transitions are firable..."),nl. livel:-/* case deadlock free, restartable but some transitions are not firable */ flagproper(Z), Z= 1, flaglivet(F), F=0, write("...No P_Net is N O N L I V E , since it is restartable"), write("but not all transitions are firable..."),nl. live2:-/* case of one internal cycle (or one equivalence cycle */ number cycles(N), N= 1, live3. live2: /* case of more than one internal cycle (or equivalence cycle)*/ number cycles(N), N > 1, write("...No P_Net is NON_LIVE, since it is n o n restartable"), writeCand there are trap cycle(s)"),nl, write(" (or trap equivalence cycle(s))"),nl. live3:- /* case of one cycle (or equivalence cycle) that can be reached directly from root */ red_cycle_set([Xl_]), direct desc(_,Y,"s0"), X=Y, checkxx,live4. live3:- /* case one cycle (or equivalence cycle but cannot be reached directly from root */ write("...No P_Net is NON_LIVE, since it is n o n restartable"), writeCand there is one reduced internal cycle not directly"), write("reachable from root state..."),nl. live4:-/* one cycle, directly reachable from root and all transitions are firable in the cycle */ flagfire_all(N), N= 1, write("...Yes P n e t is LIVE, since it is non_restartable"), write("and has one reduced internal cycle directly"), writeCreachable from initial state and all transitions are firable..."),nl. live4:- /* one cycle, directly reachable from root but not all transitions are firable in that cycle */ flagfire all(N), N=0, direct desc([Tl_],_,"s0"), write("...No P_Net is NON_LIVE, since it is non_ restartable"), write("and has one reduced internal cycle directly"), write("reachable from initial state through firing trans..."), write(T), write("...which is not included in the cycle..."),nl. check live t:-/* to check that all transitions in the net are firable and set flag 'flaglivet'appropriately */ accum_live_t, set_trans(X), set accum_t(Y), member_ t_live(X,Y), retract(flaglivet(_)), asserta (flaglivet(1)). accum live t:direct desc([Tx] . . . . ), append t live(Tx), fail. accum live t:-2=2.

since

there

is

append_t_live(Tx):set_accum_t(Y), asserta(set_accum_t([TxlY])),retract(set_accum_t(y)).

155

member_t_live(l],_). member t live([Head[Tail] ,Y):member_t(Head,Y),membert_live(TaiI,Y). member t(x,[xl_l). member_t(X,[_lTaill):member_t(X,Tail). dist cycles:-/* to check if we have more than one internal cycle (or equivalence cycle) */ red_cycleset(X), retract (number_cycles(_)), asserta(number cycles(O)), call num(X). calLnum([l). call_num([_lTl):number cycles(N), M=N+ 1,

156

asserta(number cycles(M)), retract(number cycles(N)), call hum(T). checkxx:-/* to check that all transitions in thc cycle arc lirable */ direct desc(A ,B ,"sO"), retract(set accum t(_)), asserta(set accum t([])), retract(direct desc( . . . . "sO")), accum live t, asserta(direct descA,B ,"sO")), checkxx 1. checkxxl:-/* to set flag indicating fire all */ direct desc([Ti I_],_,"s0"), set_accum_t(Y), member_t(Ti,Y), retract(flagfire_all(_)), asserta(flagfire all(l)). checkxx 1:retract(flagfire all(_)), asserta(flagfire_all(0)).

Knowledge-Based Systems