• Ingen resultater fundet

Creating a Log-File Monitor

Towards a Monitoring Framework for Discrete-Event System Simulations

9.4 Concrete Monitors

9.4.1 Creating a Log-File Monitor

In this section we describe a log-file monitor which is a monitor that can be used for any CPN model. Most of a log-file monitor can be predefined, i.e. it will be the same for all log-file monitors, independent from the model being

9.4. Concrete Monitors 121

Figure 9.6: Determining events and states to monitor.

monitored. Only minor parts of the monitor have to depend on the specific model. A log-file monitor contains predefined functions for opening, updating, and closing a file. In other words, the init,act, andconclude functions will be predefined. Only the check and observe functions have to be created by the user for defining when to observe the model and how to create the string to be saved.

Let us see how the log-file monitor from Sect. 9.2.2 can be created. Recall that the log-file monitor should update a file each time the receiver receives a packet. Each update should contain information that is specific for the partic-ular packet that was received, i.e. the sequence number of the packet, the time the packet was received, and whether or not the packet contained the expected sequence number. The black parts of Fig. 9.6 indicate the parts of the protocol model which provide relevant information for creating a log-file monitor that will generate such a log file for the receiver.

In a CPN tool, it is possible for a user to select parts of a model and then have the tool automatically deduce which elements represent (part of) the state of the system and which elements represent events in the system. This is due to the fact that CPN models consist of only two types of nodes: places (represented by ellipses) which model the state of the system, and transitions (represented by rectangles) which model the events of the system. Using the information selected by a user, it is possible for the tool to generate much of the information that is required for creating a monitor that satisfies the interface shown in Fig. 9.5. This particular log-file monitor updates a file after each event that corresponds to the receiver receiving a packet, and these events are modelled by the transitionReceive Packetand the arcs surrounding the transition.

The variables in the arc inscriptions contain information specific to the event of receiving a packet: k is the value of the counter in the receiver, and (n,p) is the packet that has been received, wherenis the sequence number, andpis the payload or data of the packet.

Defining the log-file monitor is fairly easy in Design/CPN. The complete code for the log-file monitor can be seen in Fig. 9.7, and a description of how the

datatype ReceiverLogEvent= 1

Receive Packet of {n: INT, p: DATA, k: INT} 2

3

structure ReceiverLog : MONITOR = struct 4

5

type event= ReceiverLogEvent 6

type state= unit 7

type actState = unit 8

type observeType = string 9

10

fun check (Receive Packet {n,p,k}, currentState) = true 11

12

fun observe(Receive Packet {n,p,k}, currentState) = 13

"Packet "^Int.toString(n)^ 14

" received at time"^ 15

timeToString(time())^", "^ 16

(if n=k then "EXPECTED\n" 17

else ("DISCARD - expecting "^ 18

Int.toString(k)^"\n")) 19

20

val fileID = ref TextIO.stdOut 21

22

fun act (observeStr, currentState) = 23

(TextIO.output(!fileID,observeStr); ()) 24

25

fun init (currentState) = 26

((fileID := TextIO.openOut("ReceiverLog")); 27

currentState) 28

fun conclude(currentState) = 29

(TextIO.closeOut(!fileID); currentState) 30

val init mode =AtSimStart 31

val conclude mode =AfterSim 32

33

fun monitor(anEvent, currentState) = 34

if check (anEvent, currentState) 35

then act (observe (anEvent, currentState), 36

currentState) 37

else () 38

end 39

Figure 9.7: Code for log-file monitor.

code was generated follows. After the user selected theReceive Packettransition, Design/CPN generated template code for thecheckandobservefunctions for the log-file monitor, and the template code that was generated is equivalent to lines 11 and 13in Fig. 9.7. Since the user selected only the Receive Packet transition, it is implicitly assumed in Design/CPN that the check function returns false after all other events in the system. As a consequence, the check function should always return true, since the log file should always be updated when a packet is received, regardless of the particular values of the sequence

9.4. Concrete Monitors 123 number, the payload, or the receiver’s counter. Therefore, the user does not need to make any changes to the template code for the check function. The body of theobservefunction is the only part of this monitor that the user had to define. In this case, the user only had to write a few lines of SML code (lines 14-19 in Fig. 9.7) in order to generate a file that resembles the excerpt shown in Fig. 9.2.

After the user defined thecheckandobservefunctions, Design/CPN checked the syntax of the functions and automatically generated the code that is shown in Fig. 9.7. Note that the user never needs to see more than the check and observe functions. The user chose to name the monitor ReceiverLog. The typeeventfor this monitor corresponds to the occurrences of the event Receive Packet. The monitor does not explicitly examine any portion of the state of the model, therefore the typestate is a trivial data type. However, the mon-itor will implicitly examine some of the state, e.g. the value of the counter in the receiver, but this information is available in the specification of the event Receive Packet. A log-file monitor cannot be used to change the state of the model or the simulator, therefore theactStateis also a trivial data type. The observeTypefor the monitor will bestring, since the observefunction must generate a string which will be saved in the file. The log file will be opened at the start of the simulation (AtSimStart) when the init function is called by the simulator. Similarly, the file is closed by theconclude function at the end of a simulation (AfterSim).

The monitor will be invoked only when a packet is received by the receiver.

This is achieved by augmenting the implementation of the eventReceive Packet to call themonitorfunction for the log-file monitor. As mentioned previously, thecheckfunction should always return true (because it will only be evaluated when a packet is received), the observe function will return a string that is dependent on the contents of the packet, and the predefinedactfunction will save the string in a file.