Monitoring Functions | CPN Tools help |
Introduction to monitoring functions | CPN ML |
Monitoring a CP-net, Data types for monitored subnets
Each monitor has a number of different functions that are used for different purposes. Some examples of functions for monitors are:
A general introduction to the different kinds of monitoring functions can be found below. For a more detailed description of the monitoring functions for the different kinds of monitors see these pages:
Predicate functions determine when a monitor should be activated. They periodically examine the places and transitions associated with the monitor, and they return boolean values. When a predicate function returns true
, the observation and action functions of the monitor will also be called. When a predicate function returns false
the observation and action functions will not be called.
The predicate function for a monitor is called after steps in a simulation. Predicate functions are not called before the first step in a simulation.
If the monitor is not associated with any transitions, then its predicate function will be called after every simulation step. In this case, the predicate function will not be able to examine any information regarding the transitions that occur during a simulation.
If the monitor is associated with one or more transitions, then its predicate function will be called each time one of the associated transitions occurs. In this case, the predicate function called after any one of the associated transitions have occurred, i.e. after tokens have been removed from input places, after the corresponding code segment has been evaluated, and after tokens have been added to the output places of the transition.
Observation functions extract information/data from the places and transitions that are associated with the monitor. The observation function of a monitor is called if and only if the predicate function of the monitor is called and it returns the value true
.
Observation functions can return any type of values, such as integers, reals, strings, booleans, or functions.
The action function in a monitor does something relevant with the values that are returned by the observation function of the monitor. The action function of a monitor is called if and only if the predicate function is called and it returns the value true
.
Action functions cannot examine the nodes associated with the monitor.
Initialization functions are used to extract data from a CP-net and/or initialize monitors before a simulation is started the first time. (A simulation may be started several times by applying the Fast Forward, Play, Single Step or Bind Manually tools several times before applying the Rewind tool). Initialization functions can examine the places associated with a monitor, but they cannot examine the transitions associated with a monitor.
Initialization functions are called once before each simulation starts. If the monitor exists when the step number equals 0 for a simulation, then its initialization function will be called. If a monitor is created after some simulation steps have occurred, then its initialization function will not be called during that simulation.
Initialization functions are called either immediately after loading a net or after the CP-net has been returned to the initial marking. A CP-net is returned to the initial marking when the Rewind tool is applied and prior to each individual simulation when running simulation replications.
Stop functions are used to extract data from a CP-net and/or conclude the work of a monitor when simulation stop criteria have been met. Stop functions can examine the places associated with a monitor, but they cannot examine the transitions associated with a monitor.
In general, stop functions are called when a simulation stops because simulation stop criteria have been met.
When the Fast forward tool is applied, the monitor stop functions will be called in the following situations when the simulation stops:
When the Rewind tool is applied, the stop functions will be called
The stop functions will not be called in the following situations:
For some kinds of monitors, the monitoring functions are completely hidden from users, and for other kinds of monitors some or all monitoring functions are accessible for users. If a monitoring function is accessible for a user, then the user may modify it to obtain the desired behavior.
For example, for a Marking Size monitor, all monitoring functions are hidden, but for a Write-in-file monitor almost all monitoring functions are accessible for the user.
When a monitoring function is accessible, the user is not required to write the function from scratch. When the monitor is created, monitor template code will be generated for the accessible functions, and the user can then modify the template code.
The monitoring functions for a monitor are able to examine the nodes associated with the monitor. As described above, some monitoring functions can examine places and transitions, while other monitoring functions can only examine places.
A monitoring function is not required to examine all of the nodes that are associated with the monitor.
Consider, for example, a generic data collector monitor that extracts data from the marking of a place whenever the marking changes. In this case, the predicate function will probably return true whenever one of the surrounding transitions occurs. The predicate function can simply ignore the marking of the place. Similarly, the observation function will extract data from the marking of the place, but it will ignore the information about the transitions that occur.
The order of monitors in the index determines, in part, the order in which the monitoring functions of monitors are called both before, during and after simulations. In the following, assume that M1 and M2 are monitors, that M1 was created before M2, that M1 comes before M2 in the list of monitors, and that neither M1 nor M2 is disabled. (Disabling/enabling of monitors is described under Edit a monitor).
The initialization and stop functions of the monitors are called in the same order as the order of the monitors in the index. This means that the initialization function of M1 would be called before the initialization function of M2 before a simulation starts. Furthermore, the stop function of M1 would be called before the stop function of M2 when a simulation stops because simulation stop criteria have been met.
Predicate, observation, and action functions are called only after a simulation step has completed. Not all predicate functions will be called after every step.
When a predicate function is called (and returns true
) in a monitor, then the observation and action functions for that monitor will be called before any monitoring function in any other monitor is called.
The order in which predicate, observation, and action functions from different monitors, e.g. M1 and M2, are called depends on:
true
.
If a monitor is disabled, then none of its monitoring functions, including its predicate function, will be called.
In the example below, the data collector monitor named Queue_Delay
comes before the
breakpoint monitor named OneHundred_QueueDelays
, and both are associated with the same transition which is named Start
.
The breakpoint monitor uses the Queue_Delay.count
function, which is one of the data collector functions, to find out how many times the Queue_Delay
monitor has extracted values from the net. The breakpoint monitor will stop a simulation when the Queue_Delay
monitor has extracted exactly 100 values.
The ordering of these two monitors in the index ensures that whenever the Start
transition occurs, the Queue_Delay
monitor will extract a data value before the predicate function of the breakpoint monitor is evaluated. In other words, each time the Start
transition occurs, it can never happen that the counter of the Queue_Delay
monitor will be updated after the predicate function of the breakpoint monitor has been invoked.