Monitoring functions

Each monitor has a number of different functions that are used for different purposes. Some examples of functions for monitors are:

predicate function
for checking if the relevant condition is fulfilled
observation function
for extracting information from the net
action function
for doing something relevant with the extracted data
initialization function
for initializing a monitor before a simulation starts
stop function
for concluding a monitor when a simulation ends

These functions are collectively referred to as monitoring functions. Some kinds of monitors will have one of each of these functions, and some monitors will only have a subset of these functions. For example, a write-in-file monitor has all of these functions. However, a breakpoint monitor does not have an observation function because it is not necessary to extract information from the net. For a breakpoint monitor the predicate function will determine when a simulation should stop, and the action function will take the necessary steps to tell the simulator that the simulation should stop.

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 Monitors see these pages:

All monitoring functions are very dependent on the Data types for monitored subnets.

Predicate functions

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

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.

Action 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

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

Stop functions are used to extract data from a CPN 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:

  • If the stop functions have not been previously called during the current simulation.
  • If the stop functions have been called during the current simulation and the step number has increased since the last time the stop functions were called.

When the Bind manually or Single step tools are applied, the stop functions are called in the following situations:

  • If any Simulation stop criteria are met before the step is executed and the stop functions have not been previously called during the current simulation.
  • If any Simulation stop criteria are met before the step is executed and the step number has increased since the last time the stop functions were called.

When the Play tool is applied, it corresponds to applying the Single step tool the specified number of times to random transitions in the appropriate net. Therefore, the monitor stop functions will be called in the situations described above for the Single Step tool.

When the Rewind tool is applied, the stop functions will be called

  • If the stop functions have not previously been called in the current simulation and the step number is greater than zero.
  • If the stop functions have been previously called in the current simulation, the step number is greater than zero, and the step number has increased since the last time the stop functions have been called.

Note that stop functions may be called more than once during a simulation. This can happen if, for example, the Fast forward tool is applied several times before applying the Rewind tool.

The stop functions will not be called in the following situations:

  • If only the Bind manually, Single step, or Play tools are applied, if no simulation stop criteria are met during the execution of the specified number of steps, and if the Rewind tool is not applied.
  • When the Stop tool is applied.
  • If the Rewind tool is applied when Step=0.

Accessibility of monitoring functions

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.

Examining nodes

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.

Ordering of monitors

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).

List of monitors

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:

  1. The order of the list of monitors
  2. The transition that occurs
  3. Whether the transition is associated with M1 and M2

Assume that transition T has just occurred. The following describes the order in which the predicate functions for M1 and M2 are called. Let M1.pred and M2.pred denote the predicate functions for monitors M1 and M2, respectively.

  • If T is associated with both M1 and M2, then M1.pred is called before M2.pred
  • If T is associated with M1 and no transitions are associated with M2, then M1.pred before M2.pred
  • If T is associated with M1 and T is not associated with M2, but T*<>T is associated with M2, then M1.pred will be called, and M2.pred will not be called
  • If no transitions are associated with M1, and T is associated with M2, then M2.pred before M1.pred
  • If T is not associated with M1, and T*<>T is associated with M1, and T is associated with M2, then M2.pred will be called, and M1.pred will not be called
  • If T is not associated with either M1 or M2, but T1<>T and T2<>T are associated with M1 and M2, then neither M1.pred or M2.pred will be called
  • If no transitions are associated with either M1 or M2, then M1.pred is called before M2.pred

The observation and action functions for M1 and M2 will be called only if the corresponding predicate function is called and it returns true.

If a monitor is disabled, then none of its monitoring functions, including its predicate function, will be called.

Example of ordering

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.

Ordering of monitors

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.

Related pages