1 / 18

DEMO CPN-tools

DEMO CPN-tools. Ronny Mans Eindhoven University of Technology, Faculty of Technology Management, Department of Information Systems, P.O.Box 513, NL-5600 MB, Eindhoven, The Netherlands. Outline. Introduction to CPN Tools Building a net Time, Hierarchy and Color Analysis Simulation

uri
Download Presentation

DEMO CPN-tools

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. DEMOCPN-tools Ronny Mans Eindhoven University of Technology, Faculty of Technology Management, Department of Information Systems, P.O.Box 513, NL-5600 MB, Eindhoven, The Netherlands.

  2. Outline • Introduction to CPN Tools • Building a net • Time, Hierarchy and Color • Analysis • Simulation • Single run, replications • Monitors • Net for DCT case

  3. Classical Petri net • Simple process model • Just three elements: places, transitions and arcs. • Graphical and mathematical description. • Formal semantics allows for analysis.

  4. Limitations of classical Petri nets • Inability to test for zero tokens in a place. • Models tend to become large. • Models cannot reflect temporal aspects • No support for structuring large models, cf. top-down and bottom-up design • High level Petri nets in CPN • Color • Time • Hierarchy

  5. CPN (Colored Petri nets) • CPN is the language developed by Kurt Jensen. • CPN supports the extensions with time, color and hierarchy. • CPN is based on standard ML. • CPN is supported by Design/CPN and CPN Tools. • For more information: http://www.daimi.au.dk/CPnets/

  6. Simulations • Simulations of CP-nets are run for many reasons: • Debugging • Analysis of system behavior (performance or functional) • Presentation of a model to project team • Communication with external programs • The usefulness of the simulations is heavily dependent on the flexibility and functionality of the simulator. • Access to simulation information • Stopping simulations

  7. Accessing simulation information • It is often useful to be able to exchange information between the CPN simulator and external processes or files. • Code segments can be added to transitions for: • Reading and writing in files • Calculating some performance measures • Sending and receiving information from external processes

  8. Controlling a simulation • Simulation stop criteria • Number of steps executed • Dependent on model time • Dependent on markings or transitions

  9. Common functionality • These controlling and accessing activities share a common pattern: If certain conditions are fulfilled, then do something. • If transition T occurs, then save information in a file. • If there are no tokens on place P, then stop the simulation. • If model time is greater than C, then calculate the average number of tokens on place P.

  10. Problems when simulating • Problems controlling and accessing simulation information: • Cannot access marking information. • Net structure may have to be changed to obtain desired functionality. • If multiple transitions need to be inspected, then code segments must be duplicated. • Code segments cannot be disabled. • Only low-level support, which is difficult to use.

  11. Monitors in CPN Tools monitor (verb) to watch, keep track of, or check, usually for a special purpose Merriam-Webster’s Collegiate Dictionary • A monitor is a mechanism that is used to observe, inspect, control or modify a simulation of a CP-net. • Important characteristics of monitors: • They can inspect the statesand eventsof a simulation, and take appropriate actions based on the observations. • There is an explicit separation between monitoring the behavior of a net, and modeling the behavior of the system.

  12. Levels of monitors • Standard monitors • Very easy to define • Do not require users to write any code • Parameterized monitors • Similar to standard monitors, but slightly more flexible, and require some programming • User-defined monitors • Very flexible, but require more programming

  13. Monitoring subnets • A monitor can inspect markings and occurring transitions, with variable bindings, during a simulation • Zero or more places • Zero or more transitions • Monitors are activated after simulation steps • After every simulation step, if no transitions are monitored • After every relevant transition has occurred

  14. Data Collector monitors • Mark Size (used on places) • List Length Data Collector (used on places) • Count Transition (used on transitions) • Generic Data Collector (used on subnets)

  15. Breakpoint monitors • Place Content (used on places) • Transition Enabled (used on transitions) • Generic Breakpoint (used on subnets)

  16. Other monitors • Write in file (used on subnets) • User defined (used on subnets)

  17. Monitoring functions • Initialization function • Called once before a simulation • Predicate function • Called after simulation steps • Observation function • Called when predicate function returns true • Extracts relevant data from the model • Action function • Does something appropriate with the observed value • Stop function • Called once after a simulation

  18. Questions?

More Related