Software Implementation of Petri nets and Compilation of Rule-based

Software Implementation of Petri nets and Compilation of Rule-based Systems Robert Valette LAAS-CNRS, 7 Av. du Colonel Roche, 31077 TOULOUSE CEDEX, France e-mail [email protected] Babou Bako ESIE, Ecole Supérieure Inter-africaine de l’Electricité B.P. 311 Bingerville, République de Côte d’Ivoire Abstract: The aim of this paper is to discuss the issue of high-level Petri nets implementation. The specific class of high-level net considered is such that tokens are objects and transitions are rules with variables. They are a special case of Predicate/Transition nets. The implementation technique proposed here is an adaptation of the compilation technique developed for rule-based systems preserving the net structure. This technique is compared to the token-player algorithm, commonly used for centralized implementation as well as to a direct translation of the net into a rule-based system which is compiled afterwards. Keywords: Petri net Implementation, Comparison with rule-based approach, High-level Petri nets.

Contents 0

Introduction.

2

1

Compilation principles for rule-based systems. 1.1 Introduction. . . . . . . . . . . . . . . . . . . . . 1.2 Working memory. . . . . . . . . . . . . . . . . . 1.3 Production memory. . . . . . . . . . . . . . . . . 1.4 Remarks about the syntax. . . . . . . . . . . . . 1.5 Building the sorting network and processing in it. 1.6 Conclusion. . . . . . . . . . . . . . . . . . . . .

. . . . . .

3 3 3 4 6 6 9

Centralized software Petri net implementation. 2.1 Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Representing places and triggering places. . . . . . . . . . . . . . . . . . . . . .

10 10 10

2

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3

High-level Petri nets. 3.1 Petri nets with objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Token player for Petri nets with objects. . . . . . . . . . . . . . . . . . . . . . . 3.3 Translating the Petri net with objects into a production system. . . . . . . . . . .

12 12 13 13

4

Implementation of Petri nets with objects respecting the control. 4.1 Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Example and comparison of the compilation techniques. . . . 4.3 Comparison with the token player. . . . . . . . . . . . . . . . 4.3.1 Petri nets of the subclass “state machines”. . . . . . . 4.3.2 Petri nets with transitions having two input places. . . 4.3.3 Case of a transition with more than two input places. .

14 15 15 17 18 18 18

5

0

Conclusion.

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19

Introduction.

During these past years, various papers about Petri Net implementation have been published. It is an important practical issue which can be addressed in many ways according to the aimed application domains. Some papers have considered centralized and distributed implementations of reactive open systems, i.e. systems which have to interact in real-time with their environments. When the parallelism depicted by the Petri net describes the internal behavior of a task rather than the global behavior of a set of tasks, the implementation is centralized and based on the concept of token player [CO 86, VA 86]. When the Petri net represents a set of distributed communicating tasks, important issues are: how to decompose the net into tasks, how to implement them [CO 86, BR 86, BR 88]? Other papers are concerned with implementation which should be as highly parallel as possible [TA 87, HE 88, BU 89]. However they do not consider that the Petri net is the control structure of a complex system interacting with an environment. Even on a highly distributed structure such as a transputer data communications between the processes imply overhead times which might be preponderant. The aim of this paper is to discuss Petri Net implementation in the case of systems interacting in real-time with their environments and where data structures are associated with tokens and firing rules with transitions. The rule associated with a transition t can only be applied on data structures associated with tokens located in the input places of t. In this case, the parallelism described by the net expresses a control structure of a rule based system which has not necessarily to be translated into a parallel implementation. It depicts independence or causality relations rather than a fine grained parallelism. Our application domain is the implementation of the global coordination and monitoring level for Flexible Manufacturing Systems. Petri nets as well as rule based approaches are commonly used, either separately or simultaneously [MA 88, VA 88, FL 89]. Pure rule based approaches imply an implementation by means of compilation in order to respect real-time constraints. In section 2 the principles of such a compilation are presented, in section 3 the principles of a centralized implementation of Petri nets by means of a token player are discussed. In section 4

a class of high-level Petri nets - Petri nets with objects - is considered. In section 5 a new implementation combining the token player mechanism with rule compilation techniques is proposed.

1 1.1

Compilation principles for rule-based systems. Introduction.

A rule-based system (or production based system) [BR 85] consists of a working memory containing facts known to be true, a production memory containing rules which are compared with the elements of the working memory (do they match?) in order to deduce new facts and an inference engine to select one rule and a tuple of facts among all the applicable rules and the existing facts. This kind of pattern matching is extensively used in decision making systems. For instance, decision rules are commonly employed for scheduling the operations in a Flexible Manufacturing System and for supervising it. The major problem when real-time applications are involved is the combinatorial explosion during the operation of the inference engine. Checking at each cycle of the inference engine, every rules for every facts in order to construct what is called the conflict set (the set of all the applicable rules associated with the matching facts) is time-consuming and irrelevant. A compilation of the rules [FO 79] realizes an optimization in order to avoid checking more than once a given predicate during an inference cycle and also in order to avoid checking a given predicate for a given fact at each cycle when the fact has not been modified. Doing so we avoid iteration on all the working memory and on all the production memory. In fact the operation is incremental, considering at each cycle only the facts that have been modified and the rules concerned with these facts. In this section we first introduce the vocabulary and then the compilation principles as defined by Forgy [FO 82, PH 89]. The language OPS5 [BR 85] is based on these principles.

1.2

Working memory.

Let us present in detail the working memory elements. Entity class: The entities of the working memory are typed. Classes are defined and each entity is an instance of a class. For example, in a Flexible Manufacturing Systems the various machine tools may be typed and for example it is possible to define a class M ILL. The machine mach5 is then an instance of the class M ILL. In the same way, the part pa3 is an instance of the class P ART . Attributes: When defining a class, a collection of attributes (or properties) is attached to it. The name of the entity can be considered as its first attribute. Each attribute is defined by an identifier and the type of the values which can be assigned to it. For example, an instance of M ILL may have attached to it, the list of the operations it can perform by means of an attribute called operations. If mach5 can perform the operations op1, op2 and op3, then it will be written: mach5.operations = {op1, op2, op3}

this attribute takes its values in the set of the parts of the set of all operations which are possible in the manufacturing shop P({opi }). An instance of M ILL can also have a state taking the values f ree or busy: mach5.state = f ree and a part have an attribute op describing the next operation to be performed on it: pa3.op = op1. Working Memory Element: An entity with all its attributes and their values is called a working memory element. The working memory consists of the collection of all the working memory elements. For example we have the following working memory element (the identifier and the class is given first, then the list of the attributes with their values follows): (

mach5 is of class M ILL

1.3

∧ mach5.operations = {op1, op2, op3} ∧ mach5.state = f ree

(1)

Production memory.

Let us now describe the structure of the rules forming the production memory. Feature: A feature is an elementary predicate used in a rule precondition in order to perform a test on a working memory element. It involves only one attribute and compares it to a constant or to a variable. When checking the feature, all the entities of a given class are considered; for each one the value true or false is returned. Inter-features and intra-features: Two kinds of variables may appear in a feature. Entity variables have to be substituted by entities of a given class during the test whereas attribute value variables have to be substituted by constants which are legal values for the corresponding attributes. For example we may have the following features: "

x is of class M ILL ∧ op2 ∈ x.operations "

"

(2)

y is of class P ART ∧ y.op == op2

(3)

x is of class M ILL ∧ φ ∈ x.operations

(4)

where the variables x and y are entity variables whereas φ is an attribute value variable. The feature (3) compares the attribute op of the entity variable y of class P ART to a constant. The feature (2) compares the attribute operations of the attribute value variable x, which is a list of operations to the constant element op2 (does op2 belong to the attribute operations of the mill x?). On the other way, the feature (4) compares the attribute operations to a value which is not known yet, and which is represented by the attribute value variable φ.

A feature which does not contain any attribute value variable is called an intra-feature whereas the other ones are named inter-feature. The role of an intra-feature is to filter, among the entities of a specific class, those verifying a condition (the feature) independently from the other entities likely to be substituted to other entity variables in the rule precondition. The role of an inter-feature is to be associated with another inter-feature, involving another class od entities by means of another entity variable, but concerning the same attribute value variable. These two associated inter-features are used to filter pairs of entities verifying a specific relation: there exists a possible substitution of the attribute value variable such that the two inter-features are true simultaneously. This will be detailed in the sequel. One of the basic principle of rule-based system compilation is to split the pattern-matching operation into two steps, firstly, all the entities are filtered independently by checking the intrafeatures, secondly, the tuples of entities are built and filtered with respect to the inter-features. Pattern: A pattern is a list of features concerning a unique entity class. When a pattern is used in a test for a given entity, the value true is returned iff the value true has been returned for each of its features for this entity. In fact, a feature allows to perform an elementary test whereas a pattern allows a sequence of elementary tests on a given working memory element. We assume that no attribute value variable appear more than once in a pattern. As all the features within a given pattern involve a unique entity class, it seems natural to test the entity class only once. An example of pattern allowing to select free machines capable of performing a yet unspecified operation φ is: ( ∧ φ ∈ x.operations x is of class M ILL (5) ∧ x.state == f ree the entity class test is followed by a list of features having to be all verified. Precondition: The precondition of a rule consists of a set of patterns concerning one or various classes of entity. A precondition is true if all the patterns are true, with the restriction that an attribute value variable has to be substituted by a unique value in the whole precondition. For example the precondition allowing the choice of a free mill performing the operation φ which is exactly the operation to be performed on a part is the following one:      

pattern 1 : x is of class M ILL

(

∧ φ ∈ x.operations ∧ x.state == f ree

pattern 2 : y is of class P ART

(

∧ y.op == φ ∧ ...

(6)

It may be pointed out that the attribute value variable φ appears in each one of the two patterns forming the precondition. It corresponds therefore to only one value after the substitutions of x by a mill and y by a part (the operation to be performed). This is an example of two corresponding inter-features. Postcondition: The postcondition describes the modifications to be performed on the entities which have been substituted for the entity variables in the precondition of the rule. These modifications consist of a set of assignments to the attributes. The syntax is similar to that of the precondition the patterns being replaced by the assignments.

For example when a mill is chosen to perform an operation (application of the rule defined above) its state becomes busy which is expressed by the following postcondition:  

1.4

x is of class M ILL

n

∧ x.state := busy

y is of class P ART

n

∧ ... assignments concerning the part ...

(7)

Remarks about the syntax.

It must first be pointed out that the exact OPS5 syntax has not been respected, particularly the entity variables are implicit in OPS5. We have explicited them for the sake of clarity and because they are explicited in Predicate/Transition nets [GE 86]. Our notation is supposed to be more legible in the Petri net community. Some similarities exist between the concept of entity in OPS5 and the concept of object in object-oriented approaches. The concept of entity classes with their attributes is similar to that of object classes and their associated properties. The first difference is that inheritance does not exist in OPS5. Actually, it is possible to extend it and define a hierarchy of entity classes and only dynamic (during runtime) inheritance remains impossible. The second difference is that unlike methods which are defined within the object classes, rules are defined globally and can involve various entity classes. Actually, only the patterns are associated with a class of entity. An object oriented approach applied to production systems would therefore define an object class as an entity class associated with all the patterns and the assignments involving it.

1.5

Building the sorting network and processing in it.

As mentioned above, compilation principles have been introduced by Forgy and the RETE algorithm [FO 79], and many similar compiling techniques have been developed afterwards [PH 89]. These techniques are based on the use of sorting networks, frequently tree-structured, which maintain associated with each pattern its matching working memory elements. In the sequel we present shortly the outlines of RETE sorting-network and its utilization [FO 82]. Sorting network architecture: A test tree is associated with all the patterns globally, and a join tree is associated with each rule (actually to each precondition). The root of the test tree is its input, each working memory element which has just been modified by the application of a rule is entered in it and propagated in direction to its leaves (or rather a pointer to the element is entered and propagated). The test tree has a branch per pattern. The root of a join tree is a pointer to the associated rule. The working memory element pointers coming out of the test tree leaves are entered in the leaves of the join trees and propagated in direction to their roots, building up tuples of pointers at each node. Each join tree produces the list of the tuples of working memory elements with which the associated rule can be applied. Detailing the test tree: As mentioned above, the root is where pointers to modified working memory elements are introduced. The tree has a branch per pattern. The pointer is duplicated and sent to all the successor nodes of the root. These nodes correspond to the first test performed i.e. that of the entity class. When the class of the corresponding entity is the required one, a duplication of the pointer is performed, once again, when there is more than one pattern concerning this class. The remaining part of the branches consists of a sequence of nodes, one per intra-element

Input node

MILL

PART

parts verifying the pattern 2

(state = free)

mills verifying the pattern 1

Figure 1: Example of test tree. feature contained in the pattern. When the pointer reaches a node, the corresponding feature is tested. If the value true is returned, the pointer is propagated to the successor node. If the value false is returned the pointer is destroyed. The pointers reaching a leaf of the test tree are such that the corresponding working memory element verifies the whole pattern associated with the leaf. As mentioned above, inter-features are not taken into account in the test tree, they are used in the second step of the pattern-matching i.i. in the join tree. Let us consider Figure 1, it is the part of the test tree corresponding to the precondition (6). This precondition is made up of two patterns, so this part of the test tree has two branches and two leaves. The first leaf corresponds to the mills whose state is free, the other one to all the parts. It can be noticed that the inter-features are not taken into account. The first nodes correspond to the test of the entity class: is the element a mill or a part? Then the branch concerning the mills contains the feature concerning their attribute state. It can be remarked that the pointers are propagated through the test tree without any memorizing. When the test of a feature is false, the pointer is destroyed. Actually this is only true if the feature do not explicitly involve time; otherwise the pointer has to be kept asleep until the date for which the feature becomes true. If the system modeled by the rules directly interacts with sensors, the features involving sensors values (which may vary at any time) are taken out of the precondition and tested last when the rule is to be applied. Detailing the join tree: Its purpose is to test the groups of inter-features involving a given attribute value variable within a precondition, building so the tuples of working memory elements verifying the precondition of the associated rule. This is done by means of a binary tree, i.e. the first two inter-features are considered, then the resulting tuples of pointers to working memory elements are considered with a third inter-feature



!!!m

!p !

list of tuples of mills and parts verifying the precondition of the rule R

R

Figure 2: Example of a join tree. and so on. Then the second pattern is considered, first joining the preceding result to its first inter-feature and so on. Therefore, a node of a join tree has two inputs one corresponding to the preceding result and the other one to the next feature. Operating on a join tree involves generating tuples of entity pointers at each node. The input of the node corresponding to the preceding result contains all the tuples of entity pointers verifying the patterns checked till this point (they are stored until they are consumed and modified by the application of a rule). The other input of the node contains all the pointers verifying the next pattern to be considered. The node generates all the tuples formed from the preceding ones concatenated to new pointers and propagates copies of these pointer tuples to the successor node which verifies the corresponding inter-feature (those for which the attribute value variable is substituted by the same value). It must be pointed out that in the join trees, list of tuples of pointers are kept in the input of the nodes. An other important fact is that the operation is done incrementally after each modification of a working memory element. The root node of a join tree corresponds to the rule and its input contains all the tuples of entity pointers allowing the rule to be applied. Let us now consider the join tree in Figure 2. The tree has two nodes represented by boxes, φ and R. The input of the nodes are drawn as rectangles. The node φ has two inputs. The first one (φm) contains the list of pointers verifying the pattern 1 of precondition (6). The input (φp) contains those verifying the pattern 2 of the same precondition. This node generates all the pair of pointers corresponding to parts and to machines which are idle. Among them, it selects those which are such that the operation to be performed on the part (value of the attribute value variable φ) is an element of the list of possible operations for the mill. The selected pairs are sent to the node R but copies of the pointers are kept in its input.



p

m

tools verifying the pattern 3

!! m,p tuples of mills and parts verifying patterns 1 and 2

t

!" m,p,t

tuples of mills, parts and tools verifying the precondition of the rule R

R

Figure 3: A join tree with 3 nodes. Example of a 3-node join tree: Let us now consider the following rule precondition:            

pattern 1 : x is of class M ILL

(

∧ φ1 ∈ x.operations ∧ x.state == f ree


(

∧ y.op == φ1 ∧ y.kind of op == φ2

pattern 3 : z is of class T OOL

(

(8)

∧ z.kind of op == φ2 ∧ ...

As the precondition involves three different classes the join tree consists of three nodes as represented in figure 3. Applying a rule: In order to apply a rule, it is necessary to choose a tuple of working memory elements matching its precondition (see the root of the associated join tree). All the pointers to the working memory elements used for applying the rule are taken from the lists associated with the inputs of the join tree nodes (all the join trees and not only the join tree associated with the rule). The working memory elements are modified as specified in the rule postcondition. Finally pointers to them are inserted in the test tree root.

1.6

Conclusion.

The major required computer time is off-line in order to build the test tree, the join trees and to initially propagate all the known working memory elements. On-line, between two rule applications, only the modified elements have to be propagated. The major time is spent in the join trees,

when enumerating the new tuples of pointers which can be built with the pointers of the modified elements being propagated. The operation of the system is incremental. Finally it is clear that permanently a list of the rules to can be applied with the associated tuples of working memory elements is available. When the compiled rule-based system interacts with its environment this list can be used in two different manners. When the system is directly connected to sensors whose values are cyclically updated, the list of the applicable rules is searched in order to detect the rules which can effectively be applied in this real-time context (features implying sensors are not considered in the test tree). The other manner concerns systems receiving and sending messages. Normally, the system is in a steady state and the applicable rules correspond to all the messages which can be received eventually. At the reception of a message, the corresponding rule is applied. In the two cases after the application of a rule, some other internal rules may be applied before reaching a new steady state.

2 2.1

Centralized software Petri net implementation. Principles.

The principles for a centralized software Petri net implementation have been clearly presented in [CO 86]. In this section we only discuss some specific issues and compare the token player algorithm with an inference engine based on the compilation described above. First of all, exactly in the same way as above, the software implementation of a Petri net design by means of a token player has a cyclical operation. Actually, two cycles of operations exist. The inmost one corresponds to the firing of a transition, it is similar to the application of a rule. The other one corresponds to a sequence of transition firings between two steady states, i.e. between the reception of two messages or between two updates of the sensor values. In order to avoid checking all the transitions of the net during each one of the inmost cycle various optimizations of the token player algorithm have been proposed. One is based on a partition of the places into two sets: representing places and synchronization places [CO 86]. The other one is based on the concept of triggering places [VA 86]. In the two cases, the idea is to quickly select a subset of transitions likely to be enabled. This subset contains all the enabled transitions but may contain also transitions which are not enabled. The selection criterion is that one of the input places (the representing place or the triggering one) of these transitions has to contain a token at least. The similarities between Petri nets and rule-based systems are now well established [ZI 78, MU 88, PE 89, FL 89]. Transitions may be considered as rules and consequently, building a list of representing places (or of triggering places) is very similar to the fact of constructing a list of rules which may be applied in the RETE approach. The difference is that in the RETE approach all the rules are actually applicable whereas in the token player approach the transitions are only likely to be enabled.

2.2

Representing places and triggering places.

Let us now, briefly compare these two approaches in order to allow a more precise comparison with the RETE mechanism. The fact that the places have to be partitioned into representing places and synchronization ones restricts the possible choices of a representing place for a given transition. When a place has

a p2

h1 p1 h2

p3

b

p5

e

p4

c

d

p6

p7

f

g

Figure 4: Triggering and representing places. been chosen as representing one for one of its output transitions it has to be taken as representing place for all of them. Moreover the partition is not always possible and sometimes, implicit places have to be added to the net (for more details see [CO 86]). On the contrary the choice of the triggering place of transition is totally free among its input places and is independent of the choices concerning any other transition, Consequently, it is possible to choose a place known to be frequently marked last, avoiding so useless tests about transitions. Let us consider the net in Figure 4. The representing place of transition b has to be p1 and consequently it will be that of c. On the contrary, although the triggering place of b is p1, that of c may be p3 which is better because from the structure of the net it can be deduced that p3 will always be marked after p1. So during all the operation cycles such that p1 contains a token and p3 remains empty, transition c will be examined uselessly. This idea of always choosing the place marked last as the triggering place of a transition can even be systematically implemented with an auto-adaptative approach [BA 87]. The triggering place is dynamically changed each time a transition is considered as a candidate for firing and cannot be fired because one of its input place is empty. This latter is immediately chosen as the new triggering place. It may be pointed out that the triggering place approach is a tentative to obtain a list of transitions likely to be fired as small as possible and so to be closer to the RETE mechanism. However useless test are not avoided totally. On the other hand, the advantage of the representing place is that firing a transition t do not alter the remaining list of the transitions likely to be fired (new transitions may be added in a new list but none of the old ones have to be suppressed - only the transitions sharing the same representing place as t are deleted with t). A breadth first search may be implemented (as for the RETE approach) whereas with triggering places, a new list of transitions likely to be fired has to be built again and this leads to a depth first search (places that

have just been marked are put at the beginning of the list). Considering the example in Figure 4 again and if the marking is {p1, p3, p4}, after firing b the representing approach will consider transition d because p4 remains a representing place marked. On the opposite, with the triggering place approach, after firing b a new list of marked triggering places has to be built and transition e will be considered first. As a conclusion, it may be noted that none of these approaches is totally incremental at the level of the inmost operation cycle (firing a transition).

3

High-level Petri nets.

Although it has been shown above that the token player is not totally incremental and requires useless tests during the runtime in the inmost operation cycle, the overhead time introduced is small because the tests are very elementary (does a place contain a token?). Anyhow, an ordinary Petri net corresponds to a propositional logic rule system whose compilation principles are different from those of the RETE approach [PH 89]. Let us consider now high-level nets. In [CO 86] an extension of a token player for colored Petri nets has been presented and in [VA 88] one for a class of Predicate-Transition nets has been proposed. In the two cases a list of transitions likely to be fired for a given set of colors or for a given set of variable substitutions is built from a given set of marked places. In the sequel we shall consider only one class of high level nets, Petri nets with objects. Let us introduce them briefly.

3.1

Petri nets with objects.

Petri nets with objects can be considered as a special kind of Predicate-Transition nets [GE 86] in which the variables attached to the arcs are substituted by objects rather than by constants [SI 85]. Tokens are considered as instances or tuples of instances of object classes defined as a list of attributes. A transition describes a rule concerning the object states. The objects have to be located in its input places and if this rule is applied for a tuple of objects, they are moved from the input places to the output ones. To each transition, an attribute rule is attached in order to describe the part of the precondition and action involving the object attributes. If an attribute state is associated with each object and used to point to the place containing it, the transition associated with the attribute rule is then similar to a rule as defined in section 2.3.. Let us consider the Petri net in Figure 5 assuming that the attribute rule attached to c is:  

pattern 1 :

n

φ ∈ x.operations

pattern 2 :

n

y.op == φ

(9)

Then the transition c with this rule is equivalent to a rule having the following precondition: pattern 1 :   x is of class M ILL

(

∧ φ ∈ x.operations ∧ x.state == p1


(

∧ y.op == φ ∧ y.state == p3

   

(10)

Therefore, it is clear that the objects of the Petri net with objects correspond to the working memory elements in RETE, the variables attached to the arcs are equivalent to the entity variables.

p1

p3

b

c

p4 d

Figure 5: Petri net with objects.

3.2

Token player for Petri nets with objects.

The token player principles can be adapted to the case of the Petri nets with objects ([VA 88]). Actually, a transition t in order to be fired has to be enabled first in the underlying Petri net (the ordinary net obtained by deleting the variables attached to the arcs) and then a substitution of the variables by objects has to be possible in the attribute rule associated with t. Consequently, the list of the transitions likely to be fired may be very different from the list of the transitions which can actually be fired. The fact that the token player is not incremental is now a major drawback. The overhead time is all the more important since the enumeration and the selection of the tuples of objects is the most time consuming operation. This technique is only tractable in specific cases where this enumeration can be avoided (when the rules associated with the transitions are simple priority rules see [VA 88]). However, it is important to point out that this implementation is direct and keeps the net structure. This is an aid for debugging and maintaining the system. It also allows the use of various decomposition techniques applied on the net structure [CO 86, TA 89] in order to solve distribution issues for an implementation on a distributed system.

3.3

Translating the Petri net with objects into a production system.

It is clear (see (9) and (10)) that a Petri net with objects, as defined above, may be translated easily into a production system with an OPS5 syntax and then compiled into a RETE sorting network [BA 86]. Doing so, a purely incremental operation is implemented. For example, the net in Figure 5 may be compiled into the sorting tree in Figure 6. By chaining the roots of the join trees (one per transition) a list of all the actually enabled transitions is obtained, and with each transition is associated the list of the tuples of objects which can be substituted for the variables attached to its input arcs. In the input of the other nodes of the join trees we have intermediate lists. For example, the input φm of node φ contains all the mills which are in place p1, and φp contains all the parts in place p3. When a new part, say pa3, is moved into place p3, it is inserted into φp and only the pairs of a mill with pa3 are enumerated and those such that the two attribute value variables φ have the same value are propagated to the input of the node c. This illustrates the incremental operation. The operation is similar when it is a mill which is put into place p1. It must be underlined that the transition c is reached in a totally symmetrical way, either from

Figure 6: Sorting network after translation and compilation. place p1 or from place p3. On the contrary, the token players always particularize one of the input places (the representing or the triggering one). This symmetrical and fully incremental operation is possible only because not just only one list is memorized between two inmost operation cycles but a set of lists, one for each input of each join tree node. In [CO 86] it is pointed out that the token player operation is place driven. After a RETE compilation the operation is token driven and this is the main difference.

4

Implementation of Petri nets with objects respecting the control.

In the example presented above (Figure 5 and Figure 6) the sorting network has the same structure as the net. The inputs of the node corresponding to the transition c contains exactly the same objects as the places p1 and p3. This is absolutely untrue in the general case. As the features corresponding to the location of the objects in the places are represented in the same way as the other ones, there is no reason to deal with them differently. The control structure represented by the net is lost. The aim of this section is to show that it is possible to use the RETE approach in such a way that this control structure is kept and that this can be considered as an optimization of the compilation in many cases (precisely when the information produced by the control structure is rich). Doing so, the advantages of the token player approach and those of the compilation technique are pluralized.

4.1

Principles.

Two major modifications are introduced. The first idea is to split the test tree into one tree per place of the Petri net with objects. The state tests become implicit because all the working memory elements introduced in a test tree verify the specific intra-feature corresponding to it necessarily. The other intra-features involved in the precondition of one of the output transitions of a place are tested in the branches of the corresponding test tree, respecting the pattern structure (one branch per pattern). The second idea is to consider the tokens of the Petri net with objects as the working memory elements, even if these tokens are tuples of object instances. In fact, these tokens represent tuples of objects verifying relations which remain true as long as they are located in the place. They can only globally be substituted for variables; the tuple may only be split during a transition firing (in its postcondition). As a consequence, when a tuple of variables is attached to a transition, it is considered as a unique entity variable.

4.2

Example and comparison of the compilation techniques.

Let us consider the Petri net in Figure 7. It depicts a sequence of operations to be performed on parts by two kinds of machines, mills and lathes. Places p5 and p6 represent the free mills and free lathes respectively. The places p1 and p3 describe the input buffers of the machine pools i.e. the parts waiting for an operation. Transition b and d describe the decision processes in order to choose a part and a machine for a given operation. Transitions c and e represent the end of the operations. We note Ctx the pattern corresponding to the attribute rule attached to transition t and concerning the entity variable < x >. We also note Ctxy the join node corresponding to a variable φ involved simultaneously in an inter-feature of Ctx and in one of Cty . The compilation of the net respecting the control structure is in Figure 8 whereas a compilation after translation in a production system without control is in Figure 9. In this last case we have chosen the worst possible case i.e. when the features corresponding to state tests are taken into account at the end of the patterns. The small rectangles represent the inputs of the join nodes and not the join nodes themselves. The simplification introduced by a compilation preserving the control appears at the first glance. Actually the use of control [GA 89] or of relations existing between the entities [PH 89] is presently under investigation among the “production system community” in order to achieve compilation optimization. Predicate/Transitions nets and Petri nets with objects offer control and dynamic relations altogether. Let us now compare the two sorting networks obtained in detail. In the standard sorting network, all the objects are introduced in one input and all the patterns are considered. When the control states are tested last, the other features are tested until a false condition is encountered. For example for the parts, Cbx , Ccx , Cdx and Cex may be systematically tested. On the contrary, in a sorting network respecting the control, there is one input per place. When a place contains only objects (or tuples) of the same class, which is a standard modeling principle, neither the class test nor the state test are required. Patterns such as Cbx and Cdx are in different test trees and are never considered simultaneously. This points out the importance of the control. Let us now consider transitions c and e. In the standard sorting network they are not different from transitions b or d; they involve two entity classes (parts and machines) and a join node is required to check if the machine y (or z) considered for the tuple is indeed the machine operating

a X of class PART Y of class MILL Z of class LATHE Cbx , Cby : b intra-element sequences

p1

C

b

p2 c

bxy

: b inter-element

p5

p3 d

p4

p6

e

p7

Figure 7: A sequence of machine utilization.

p1

p5

Cbx

Cby

p2

p3

Ccxy

Cdx

Cbxy

b input of p2

p4

p6

Cexz

Cdz

Cdxz

c input of p3 and p5

e

d input of p4

input of p6 and p7

Figure 8: Compilation respecting the control structure.

ROOT LATHE PART

C

p1

Ccx

bx

p2

C

dx

C

MILL

C

ex

p5

p4

p3

C

by

Cbxy

Ccxy

Cdxz

b

c

d

C

cy

dz

p6

p2

C

ez

p4

Cexz e

Figure 9: RETE compilation of the Petri net. the part x. In the sorting network preserving the control the situation is totally different. The tuples formed by a machine and a part are not split, the are entered in the test tree as a unique working memory element. The patterns Ccxy and Cexz are a concatenation of Ccx and Ccy and of Cex and Cez respectively. No join node is required. This optimization is important because it avoids a useless tuple enumeration and an important overhead time.

4.3

Comparison with the token player.

When the rule-based compilation respects the control of the net - i.e. follows the principles of section 5.1 - the obtained implementation can be considered as a specific token player. In fact, the operation cycle of the inference engine (the processing cycle in the sorting network) works in the same way as the token player: 1. it builds the list of the enabled transitions, 2. it chooses a transition and a tuple of tokens enabling it, 3. it fires the transition and begins the cycle again. The sorting network (one test tree per place and one join tree per transition) is just a different way of storing the information concerning the Petri net structure and its current marking. We now discuss the following issue: what is the increase of complexity resulting from this approach? It is important to note that the only information stored in the sorting network between two inference cycles consists of the lists located in the input of the nodes of the join trees. Let us now detail these lists, in some specific cases.

4.3.1

Petri nets of the subclass “state machines”.

Each transition has a unique input place. Each Join tree consists of a unique node, and only one input of this node (that corresponding to the place) is utilized. See transition b and place p1 in figures 5 and 6. This input contains the list of the tokens of the input place which can be used to fire the transition. Consequently, the only information stored is the list of the enabled transitions with the tokens enabling them. This implementation is identical to that proposed in [CH 80]. It is also very similar to the ones based on representing or triggering places (as there is a unique input place, this place is at the same time a representing and a triggering one). In fact, in these approaches the tokens are listed in the places, associated with a pointer to their output transitions. The only difference lies in the conflict resolution. Commonly, the conflicts are solved by the rules attached to the transitions (do the token attributes match the inter or intra features of the rule?) and it is better to store the tokens in association with the transitions which can actually be fired with them rather than with the places. 4.3.2

Petri nets with transitions having two input places.

When a transition has two input places, its join tree has two nodes. See transition c and places p1 and p3 in figures 5 and 6. The first node implements the elaboration of the 2-uples of tokens and the pattern matching (inter-features). Its input nodes store the tokens of the input places which verify the intra-features. Only one of the inputs of the second node is used, it stores the list of the 2-uples enabling the corresponding transition (and verifying the precondition of the rule). Consequently, in this approach, the list of the enabled transitions is stored together with the marking of the net. The required amount of memory is therefore greater than in the approaches based on the representing or triggering places. On the other hand, the advantages of these two approaches are combined. Only transitions having their two input places with tokens are considered (this corresponds to an optimal strategy with dynamic triggering places). When the conflicts are solved by the rules, it is not necessary to build a new list of enabled transitions after each transition firing (this is the main advantage of the use of representing places). 4.3.3

Case of a transition with more than two input places.

In the example in figure 10 we see that the first node joins the two first input places p1 and p2, the second one joins them with place p3 and the third one (the root) is attached to the transition a. The inputs A and B of node φ1 store the markings of places p1 and p2 respectively. The input D of node φ2 stores the marking of p3. The input E of node a stores the list of the 3-uples of tokens enabling transition a. In relation to the preceding case, just one list is added: the input C of node φ2 , which contains the 2-uples of tokens in places p1 and p2 verifying the precondition of the rule. This supplementary list allows an operation which keeps the advantages of the traditional optimization methods for the token player. Transition a is only considered when its three input places at least contain a token (optimal dynamic triggering place). The list of the enabled transitions has not to be recalculated after each transition firing (representing place). In the general case, the join tree of a transition with n input places has n nodes and “n − 2” lists are added. The complexity increase is linear. Let us recall that the benefit is the avoidance of a cyclical enumeration of n-uples of tokens, which is exponential.

p1

p2

A

B

!1

p3

p1

p2

p3

D

C

!2

a

E

a

Figure 10: An example of a transition with 3 input places.

5

Conclusion.

We have shown that the token player approach and its optimizations strive to achieve incremental operation. A data structure is organized off-line in order to efficiently compute a new list of enabled transitions after a transition firing by modifying the former one rather than by completely recomputing it. The current solutions are a good compromise between the complexity of the data structure and the required efficiency in the case of ordinary Petri nets. When high-level nets are considered, when data are attached to the tokens and when the choice of the tokens used to fire a transition is complex, techniques derived from rule-based compilation are required. When they are applied directly, the control structure described by the Petri net is lost and this implies a loss of efficiency. Taking advantage of the similarity between the token player algorithm and the RETE techniques we have proposed a compilation preserving the net structure in order to combine the advantages of the two approaches. This last solution is the most efficient when the Petri net have a large number of places and a large number of tokens equally distributed among them. It is also very efficient when large tuples of objects appear, describing dynamic relations which are created and destroyed during the operation of the system.

Acknowledgements: The authors aknowledge the three anonymous referees for their comments. The work has mainly been done during the stay of Babou Bako at LAAS-CNRS.

References [BA 86] R. Bauman, T. A. Turano: Production based language simulation of Petri nets, Simulation Vol47, n5, p.191-198 (Nov. 1986). [BA 87] D.S. Barbalho: Conception et mise en œuvre de la fonction coordination pour une commande distribue’e d’atelier, The‘se de Doctorat de l’Universite’ Paul Sabatier, Toulouse, (De’cembre 1987). [BR 85] L.Brownston and al: Programming Expert Systems in OPS5: An Introduction to RuleBased Programming. Adisson-Wesley, (1985). [BR 86] G. Bruno, G. Marchetto: Process-translatable Petri nets for the rapid prototyping of process control systems: IEEE Trans. Software Eng., Vol SE-12, No 2, February, pp. 346357 (1986). [BR 88] M. Baldassari, G. Bruno: PROTOB: Object-Oriented Graphical modelling and Programming based on Prot Nets, 9th European Workshop on Applications anf Theory of Petri Nets Venice, June 22-24, p.333-342 (1988). [BU 89] B. Bütler, R. Esser, R. Mattmann: A distributed simulator for High Order Petri Nets, 10th International Conference on Application anf Theory of Petri Nets Bonn, June, p.2234 (1989). [CH 80] D. Chocron, E. Cerni: A Petri net based industrial sequencer. IEEE International Conference and Exhibition on Industrial Control and Instrumentation, pp.18-22 (March 1980). [CO 86] J.M. Colom, M. Silva, J.L. Villarroel: On software implementation of Petri nets and colored Petri nets using high-level concurrent languages. 7th European Workshop on Application and Theory of Petri nets Oxford, July, pp.207-241 (1986). [FL 89] H. Fleischack, A. Weber: Rule-based programming, Predicate/transition nets and the modeling of office procedures and flexible manufacturing systems. 10th International Conference on Application and Theory of Petri Nets. Bonn, (June 1989). [FO 79] C. Forgy: On an efficient implementation of production systems, Ph.D Thesis, CarnegieMellon University, (1979). [FO 82] C. Forgy: RETE: a fast algorithm for many pattern/many object pattern match problem. Artificial Intelligence, 19:17-37, (1982). [GA 89] H. Garnousset, J.M. Farines, E. Cantú, Efficient Tools for Analysis and Implementation of Manufacturing Systems Modelled by Petri nets with Objects: A production Rules Compilation-based Approach, IECON’89 Fifteenth Annual Conference of the IEEE Industrial Electronics Society, Philadelphia, (Nov. 1989). [GE 86] H. J. Genrich Predicate/Transition nets, Lecture Notes in Computer Science 254 Springer Verlag p. 207-247 (1986). [HE 88] A. Heinrich, W. Ameling: Multiprocessor System Architecture for the execution of Higher Petri nets, 9th European Workshop on Applications anf Theory of Petri Nets Venice, June 22-24, p.321-332 (1988).

[MA 88] J. Mart´ınez, P.R. Muro, M. Silva, S.F. Smith, J.L. Villarroel: Merging artificial intelligence techniques and Petri nets for real-time scheduling and control of production systems. 12th IMACS World Congress on Scientific Computation. Paris, July, Vol 3, pp. 528-531 (1988). [MU 88] T. Murata, D. Zhang: A Predicate-Transition net model for parallel interpretation of logic programs, IEEE Transaction on Software Engineering, Vol. 14, No. 1, (April 1988). [PE 89] G. Peterka, T. Murata: Proof procedure and answer extraction in Petri net model of logic programs, IEEE Transaction on Software Engineering, Vol. 15, No. 2, (February 1989). [PH 89] H. Philippe: Algorithmes pour la compilation de bases de connaissances en logiques propositionnelle et du premier ordre - les syste‘mes KHEOPS et CLOPS, The‘se de Doctorat de l’Universite’ Paul Sabatier, Toulouse, (Mai 1989). [SI 85] C. Sibertin-Blanc: High-level Petri nets with data structures, 6th European Workshop on Application and Theory of Petri nets, Helsinki, Finland, (June 1985). [TA 89] J. Tankoano, J.C. Derniame, Structured Design of Distributed Systems using Interpreted Petri Nets, 10th International Conference on Application anf Theory of Petri Nets Bonn, June, p.329-347 (1989). [TA 87] D. Taubner: On the Implementation of Petri Nets, 8th European Workshop on Applications anf Theory of Petri Nets Zaragoza 1987 and Lecture Notes in Computer Science 340 Springer Verlag p. 418-439 (1988). [VA 86] R. Valette: Nets in production systems, Lecture Notes in Computer Science 255 Springer Verlag p. 191-217 (1986). [VA 88] R. Valette, J. Cardoso, H. Atabakhche, M. Courvoisier, T. Lemaire: Petri nets and production rules for decision levels in FMS control. 12th IMACS World Congress on Scientific Computation. Paris, Juillet, pp.522-524 (1988). [ZI 78] Zisman, M.D.: Use of production systems for modelling asynchronous concurrent processes, in Pattern Directed Inference systems D.A. Watterman and F. Hayes-Roth (Eds.), Academic Press, London, p.53-68 (1978).