1 / 19

Towards a High-Level Petri Net Type Definition

Towards a High-Level Petri Net Type Definition. Michael Westergaard Department of Computer Science University of Aarhus Denmark. Difficulties. Labels are not just non-negative integers, but can range over an arbitrary domain – is “1`2++4`7” the same as “<2>+4*<7>”?

aurelia-evans
Download Presentation

Towards a High-Level Petri Net Type Definition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards aHigh-Level Petri Net Type Definition Michael Westergaard Department of Computer Science University of Aarhus Denmark

  2. Difficulties • Labels are not just non-negative integers, but can range over an arbitrary domain – is “1`2++4`7” the same as “<2>+4*<7>”? • High-level Petri nets (HLPN) often support elaborate composition mechanisms, which have to be dealt with – should we extend PNML to support hierarchical nets?

  3. Outline • Labels • Composition Constructs • Hierarchical Petri Nets • Fusion • Implementation Status

  4. Labels • We have identified the following labelsfor high-level Petri nets: • (Names,) • Declarations (of types and variables), • Place types, • Initial markings, • Arc inscriptions, and • Transition guards. • To support interchange, we have defined structures for: • Identifiers (for names, declarations, and place markings), • Types (for type declarations), • Multi-sets (for initial markings and arc inscriptions), and • Expressions.

  5. Labels • Take as example a net witha place named A withdomain INTand initialmarking one token withvalue 2 and four tokenswith value 7 • We notice • Two (three) new labels, thedomain, the initial marking (and the name) • The initial marking is rather complex, and several reasonable concrete syntaxes can express it, e.g. • CPN Tools: 1`2++4`7 • CPN-AMI: <2> + 4*<7>

  6. Labels – Solution 1:Store as Concrete Syntax Example • We would store the initial marking as follows(using the concrete syntax of CPN Tools):<initialMarking> <text>1`2++4`7</text></initialMarking> Advantage • Very simple approach; high-level labels are a direct generalization of low-level labels Disadvantage • Different tools use different syntaxes to express the same • CPN Tools: 1`2++4`7, or • CPN-AMI: <2> + 4*<7>. and this makes interchange difficult

  7. Labels – Solution 2:Store as Abstract Syntax Tree Example • We would store the initial marking as follows:<initialMarking> <multiset> <valuecardinality=”1”><text>2</text></value> <valuecardinality=”4”><text>7</text></value> </multiset></initialMarking> Advantage • Eliminates differences in concrete syntax Disadvantages • Difficult to make simple editors that do not completely parse and check inscriptions • Cumbersome to add new features, as a new AST node has to be defined

  8. Labels – Solution 3:Mix Abstract and Concrete Syntax Example • We would allowing the initial marking to bestored as either:<initialMarking> <text>1`2++4`7</text></initialMarking>or<initialMarking> <multiset> <valuecardinality=”1”><text>2</text></value> <valuecardinality=”4”><text>7</text></value> </multiset></initialMarking> Advantages • Tools can save as much or as little using abstract syntax as desired – trade-off between interchangeability and simplicity • New features can easily be incorporated by using concrete syntax until an appropriate AST node is defined

  9. Labels – Solution 3:Mix Abstract and Concrete Syntax Added benefits • Allows an incremental transition to theinterchange format, as tool implementers can choose to save only some (parts of) labels as ASTs • Allows the format to be used as primary storageformat, as incorrect (and therefore unparsable) inscriptions can be saved using concrete syntax

  10. Composition Constructs • A number of composition constructsexist for high-level Petri nets: • Hierarchical nets • Fusion places • Synchronous channels • etc. • Composition mechanisms can be represented by adding new labels or special nodes • Example: Fusion places can be implemented by adding a label fusionGroup, which indicates to what fusion group the place belongs

  11. Composition Constructs • If we implement the compositionconstructs by a translation toModular PNML, they will be availableto a wider range of tools • Tools only need to support Modular PNML, and we need not clutter the standard with more or less useful improvements • Modular PNML can be mechanically flattened to Basic PNML, so support for Modular PNML is not essential • Expressed like this, the composition mechanisms are no longer tied to high-level Petri nets

  12. A Fusion Places:Canonical Member Page: Producer Select one member and convert it to a normal place Select one member and convert it to a normal place Make all other members point to the selected place Select one member and convert it to a normal place Make all other members point to the selected place • If a tool does not know about fusion places, how do we easily remove the place B from the fusion group? • What happens if we have more than one instance of the Consumer-page? Page: Consumer

  13. A Page: Storage 1`2++4`7 Storage INT B Fusion Places:Create a New Global Place • Deletion is now easy: just do it • It is easy to add a place to or remove a place from the group: just update the pointer • Multiple instances just amount to multiple pointers, which is fine Page: Producer Create a new page with a new place Create a new page with a new place Make all the members point to it Create a new page with a new place Make all the members point to it Create a new page with a new place Make all the members point to it Page: Consumer

  14. Module: Counted transmit A B Counted transmit A B Hierarchical Petri Nets Convert the sub-page to a module Convert the sub-page to a module Move all port-places to the interface Convert the sub-page to a module Move all port-places to the interface Convert the substitution-transition to an instance of the module Convert the sub-page to a module Move all port-places to the interface Convert the substitution-transition to an instance of the module Page: Produce/Consume Page: Counted transmit

  15. Implementation Status • A preliminary PNTD for high-level Petrinets is written • A transformation from PT-nets to the proposed format has been written • A transformation from the current storage-format of CPN Tools to the proposed format has been written • A tool for composition of high-level Petri nets stored using the proposed format is written All is available from http://www.daimi.au.dk/~mw/local/pnml/. (the address is also in the paper)

  16. Conclusion • We have shown 3 different ways to represent labels: • using concrete syntax only, • using abstract syntax only, and • using a mixture of concrete and abstract syntax. • We have argued that the 3rd way is the best, as it is more flexible and allows interchange between tools not sharing concrete syntax • We have seen reasonable ways to translate common composition mechanisms to Modular PNML equivalents, in particular: • Hierarchical Petri nets and • Fusion Places.

  17. Difficulties Revisited • Labels are not just non-negative integers, but can range over an arbitrary domain – is “1`2++4`7” the same as “<2>+4*<7>”? Yes, store them as abstract syntax. • High-level Petri nets (HLPN) often support elaborate composition mechanisms, which have to be dealt with – should we extend PNML to support hierarchical nets? No, convert them to use Modular PNML.

  18. Future Work • Definition of AST nodes for more functions in expressions, such as • arithmetical operators • string operations • Division of expressions into reasonable chunks (suitable for e.g. well-formed nets and general coloured Petri nets)

  19. Labels – Solution 3:Mix Abstract and Concrete Syntax Not a clear-cut separation • E. Kindler proposes in the April 2004proposal for ISO/IEC 15909-2 a similarapproach to the representation labels • Kindlers proposal requires that a label is stored either using concrete syntax or using abstract syntax • Our proposal allows<declaration> <type> <name>PRIME</name> <type><text>prime</text></type> </type></declaration>which clearly is a type-declaration even though the type “prime” is not standardized • Thus not having a clear-cut separation of abstract and concrete syntax makes it easy to simulate new AST nodes

More Related