It is often useful to be able to record time-related information for certain objects that are represented in a model. For example, when modeling a network protocol with timed CP-nets, it might be interesting to be able to measure the amount of time that passes from when a packet is sent from one computer until the packet is received by another computer. It could also be interesting to measure the total amount of time that the packet must wait in different queues. Similarly, in a model of a bank, it might be interesting to measure the amount of time that a customer must wait in a queue, or the amount of time that passes from when the customer arrives at the bank until the customer leaves.
In order to make these kinds of measurements in the model, it must be possible to record time-related information for each representation of an individual object, such as a packet or a customer. This can easily be done by including time-related information in token values.
In timed CPNs some tokens have time stamps. Here is a token with time stamp 145:
Token with time stamp
In some cases it may be useful to be able to access the value of the time stamp when a particular transition occurs. It is currently not possible to access the time stamp directly, but it is possible to include time stamp values in token values.
The examples below show how time-related information, or time attributes, can be included in token values. The first example introduces a simple system in which objects are processed by resources. In that example, no time information is associated with the objects. The second example shows how time information can be associated with objects, and how the information can be used for different purposes.
First example without time attributes
In this example there are two kinds of objects: A and B. These objects could be, e.g. different kinds of customers in a bank, data packets and acknowledgments to be transmitted, or requests for small and large web pages. In the example, new objects arrive regularly and they need to be processed by some kind of resource.
Overview of model
The color set X represents the objects in the system. The System page is the top-level page in the model.
The Arrivals page models the arrivals of new objects. The time stamp of the token on place Next in the Arrivals page determines the time at which the next object will arrive. The expTime function is used here to generate exponentially distributed inter-arrival times with an average inter-arrival time of 100. When a new object arrives the kind of the object is chosen randomly using the X.ran() color set function. New arrivals are kept together, but they are not stored in any particular order, such as a queue. (The Arrivals page is similar to the Arrival page in the Queue System net, which is described in much more detail).
Each of the objects that arrive must be processed. There are 3 resources that are available for processing the objects. The resources could be, e.g. tellers in a bank, network links that packets must be transmitted across, or threads for processing incoming requests in a web server. The Process page models the simple process that must be executed.
Process page in model
The process consists of two tasks, both of which are modeled by the Task page.
Task page in model
For each task, each object must be processed by a resource. The processing times for objects are also generated with the expTime function, which means that processing times are exponentially distributed, and in this case, they have an average processing time of 150 time units (as determined by the declaration of avg_proc_time, shown above). Time stamps on the tokens representing objects on place Waiting for Resource and resources on place Resources determine when a resource can start processing an object. Similarly, the time stamp for a token representing an object on place Processing determines when the processing of the object will finish. After an object has been processed in a particular task, it will be added to the group of other objects that have been processed, as represented by tokens on place Output. Again, the objects are not stored in any particular order, such as a queue.
For such a model, it would be useful to be able to measure the following kinds of values for each object:
- The total amount of time the object had to wait before being processed by a resource
- The total amount of time the object was processed by resources
- The amount of time that passed from when the object arrived until it had been processed for both tasks
The next example shows how this can be done, and it also shows how time stamp values can be included in token values.
Second example with time attributes
In order to be able to measure the values described above and to include time stamp values in token values, it is necessary to define a new color set for representing the objects in the system. The color set will include information regarding time attributes for objects.
The type of model time in CPN Tools is infinite integer (as described in the help page for simulator functions). Since infinite integer color sets are not currently supported, time values must be converted from infinite integer values to values that can be used in color set, such as strings or integers.
The intTime function is declared such that it will return current model time as an integer:
fun intTime() = IntInf.toInt (time());
The time function returns an infinite integer, as described on the help page for simulator functions, and the IntInf.toInt function is a function from the SML Basis Library that will convert an infinite integer value to an integer.
As compared to the first example, the following color set declarations have been added:
colset TS = string;
colset TI = int;
colset XT = product X * TS * TI * TI * TI * TI timed;
The color set TS is used to represent a time stamp value as a string. The color set TI is used to represent time values, including time stamps, as integers.
In the first example above, an object is represented by a value from the color set X. Here an object is represented by a value from the color set XT. XT is a product color set with 6 components, which represent:
- The kind of the object, i.e. A or B
- The time stamp of the token represented as a string
- The time stamp of the token represented as an integer
- The arrival time of the object, i.e., the time at which the object arrived in the system
- The total amount of time that the object has to wait before being processed by resources
- The total amount of time that the object has been processed by resources
It is usually not necessary to include so many different kinds of time attributes in token values. This example just shows a variety of different ways in which time information can be included in token values. Time attributes can also be easily added to record color sets (see, for example, the Job color set in the Queue System).
Below is an example of a token representing an object together with time attributes. The token is on place Wait on page Process, i.e. the object has been processed in task 1, and it is waiting to be processed in task 2. (The full model is presented below).
Token with time attributes
The object is of kind B. The time stamp, which can be seen after the @ character, i.e. 1165, is accurately represented as a string "1165" and as an integer 1165 in the token value. The object arrived at time 596. The object has waited 45 units of time before being processed by a resource in task 1. The processing time for the object in task 1 was 524 units of time.
Arrivals page
The Arrivals page must be changed so that the time attributes are properly initialized when a token representing a new object is created.
Arrivals page
When the Arrivals transition occurs, the newX function is used to create a token that represents a new object. This is the declaration of the function:
fun newX() =
(X.ran(),
ModelTime.toString(time()),
intTime(),
intTime(),
0,
0)
When called, the newX function returns a value from the XT color set, i.e. it will return a 6-tuple as described above. The first component is the kind of the object, and it is again chosen randomly using the X.ran() function.
The second and third components should be string and integer representations of the time stamp of the token that is added to place New Arrivals. Since there is neither a time inscription on the transition nor an arc delay on the arc from transition Arrivals to place New Arrivals, the time stamp of the token added to New Arrivals will be equal to the model time at which Arrivals occurs. When the expression ModelTime.toString(time()) is evaluated, it will return the string representation of the current model time. The ModelTime.toString function is one of the simulator functions.
The fourth component represents the arrival time of the object. Since the arrival time of the object is equal to the model time at which Arrivals occurs, the intTime function is also used to obtain the arrival time of the object.
The fifth and sixth components represent the total wait and processing times, respectively, for the object. These values are initialized to 0.
In the figure above, Arrivals is enabled. Since the time stamp of the token on place Next is 1777, the current model time must be 1777. When the transition occurs, the newX function will be called and a new token will be added to place New Arrivals. The value of the token that is added can be seen in the figure below showing the Process page.
Process page
Few changes need to be made in the Process page with respect to the first example. Only the color sets for places New Arrivals, Wait, and Completed have been changed from X to XT.
Process page
Task page
In the Task page, several inscriptions need to be changed in order to properly handle the new token values that contain time attributes. The color sets for places Wait for Resource, Processing, and Output have been changed from X to XT.
Start transition enabled
When transition Start occurs, one token representing an object will be removed from Wait for Resource, and a token representing the same object will be added to Processing. Several of the time attributes that are associated with the object need to be updated when this token is moved. The startProc function, which is called in the code segment for Start, is used to update the appropriate time attributes for the object. This function is not used anywhere else in the model. The startProc function is defined as follows:
fun startProc ((x,tss,tsi,at,wt,pt):XT) =
let
val proc_time = expTime(avg_proc_time)
val time_stamp = ModelTime.add(time(),ModelTime.fromInt(proc_time))
val new_tss = ModelTime.toString(time_stamp)
val new_tsi = IntInf.toInt(time_stamp)
val new_wt = wt + (intTime() – tsi)
val new_pt = pt+proc_time
in
((x,new_tss,new_tsi,at,new_wt,new_pt),proc_time)
end
The function takes an XT value as an argument, and the argument represents an object that a resource is starting to process. The object is represented by a token that is removed from place Waiting for Resource. The parameters x, tss, tsi, at, wt, and pt of the function represent the kind of the object, string and integer representations of a time stamp, the arrival time of the object, and the total waiting and processing times for the object, respectively.
When the Start transition occurs, it represents the start of the time during which an object will be processed by a resource. Because it takes time to process an object, a time delay will be added to the token that is added to place Processing. In the startProc function the local value proc_time is the processing time that is generated for the object. The processing time is obtained by calling the expTime function, just as in the first example.
The value proc_time will be used to calculate the time stamp for the token. When the Start transition occurs, the time stamp for the token that is added to place Processing will be equal to (the model time at which the transition occurs) + (the value of proc_time), as determined by the occurrence rule for timed CPNs. Since the time stamp for the token to be added to Processing will be different from current model time, the string and integer representations of the token’s time stamp must be updated accordingly.
The local value time_stamp will have the same value as the time stamp of the token added to Processing. The local values new_tss and new_tsi are the string and integer representations of the value of time_stamp.
The token that is removed from place Waiting for Resource, represents an object that has been waiting for a resource. This means that the time attribute that represents the total waiting time for the object must be updated. The new total wait time is equal to the old total wait time plus the amount of time the token representing the object was on place Waiting for Resource.
Whenever a token is added to place Waiting for Resource, the time stamp of the token is equal to the model time at which the token was added to the place. This also means that the second and third components of the token value are string and integer representations of the time at which the token was added to the place. In other words, these components in the token value represent the time at which an object started to wait for a resource. Consequently, the parameters tss and tsi for function startProc can be used to calculate the amount of time that a token resided on place Waiting for Resource. When a token is removed from Waiting for Resource, the most recent wait time for the object can be obtained by subtracting the integer representation of the token’s time stamp from the model time at which the transition occurs, which is exactly what the following expression from startProc does: (intTime()-tsi). Thus, the local value new_wt is the properly updated total wait time for the object.
The total processing time for the object must also be updated when a token is moved from Waiting for Resource to Processing. As described above, the value proc_time represents the amount of time that the object will be processed in this particular task, and this value must be added to the total processing time for the object. This is precisely how the value new_pt in function startProc is obtained.
Function startProc returns two values: an updated representation of an object (where some time attributes have been changed as described above), and a processing time for the object. Note that the function does not modify either the object kind or the arrival time attribute of the object, i.e. the values bound to parameters x and at are returned unchanged. The processing time for the object is used in the arc delay inscription on the arc from Start to Processing.
In the figure above, transition Start is enabled at model time 1794. Here is the marking that was reached after the Start transition occurred:
After Start occurred
The value of the token on Processing is (A,"1821",1821,1777,17,27). Let us briefly review how this value was obtained. The value A is the kind of the object, and, as mentioned above, this value remains unchanged by the startProc function. We can deduce that the processing time that was obtained by calling expTime is equal to (time stamp of token on Processing – time at which Start occurred) = (1821 – 1794) = 27. The values "1821” and 1821 are accurate string and integer representations of the time stamp. The value 1777 is the arrival time of the object, and as expected it is unchanged with respect to the value of the token that was removed from place Waiting for Resource. The value 17 is the updated total waiting time, where 17 = 0 + (1794 – 1777), where 0 was the waiting time attribute of the token removed from Waiting for Resource, 1794 is the time at which Start occurred, and 1777 is the integer representation of the time stamp for the token removed from place Waiting for Resource.
If there is a token on place Processing, the Stop transition will become enabled when the time stamp of the token is equal to current model time. The transition represents that a resource has finished processing an object. When the transition occurs, a token representing a resource is added to place Resource, and a token representing the object that has been processed is added to place Output.
The value and time stamp of the token added to Output are the same as the value and time stamp of the token removed from Processing. Since there are no time delay inscriptions on either the Stop transition or the output arc to Output, the time stamp of the token added to Output will be equal to the time at which Stop occurs (which is equal to the time stamp of the token removed from Processing). Since the time stamp is unchanged, the string and integer representations of the time stamp in the token value do not need to be changed. The arrival time attribute for an object should never be changed, and it is therefore, not changed by the occurrence of Stop. Since the token removed from Processing represents an object that has been undergoing processing, the token does not represent an object that has been waiting for a resource, which means that the total wait time attribute for the object does not need to be updated. Finally, the total processing time attribute for the object was updated when the Start transition occurs, so it is not necessary to update this attribute either.
Accessing time attributes in monitors
The time attributes that are stored in token values can be accessed in a number of different ways. Above, we saw how the integer representation of a time stamp in the token value could be used to calculate the amount of time that a token resided on a particular place.
Time attributes in token values can also be used to calculate performance measures when doing performance analysis of a model. Three data collector monitors that access time attributes in token values have been defined for this example net.
Monitors that access time attributes
Wait time monitor
The monitor named Wait time is a generic data collector monitor. It measures the total wait time for each object that has been fully processed for both task 1 and task 2. The monitor is associated with instance 2 of the Stop transition of the Task page. In other words, the total wait time for an object is measured when the token representing the object is added to the Completed place in the Process page. (Instance 2 of the port place Output in the Task page is assigned to the socket place Completed in the Process page.)
The observation function for the monitor measures the total wait time for an object after the object has been processed in both tasks. When instance 2 of the Stop transition occurs, the total wait time for the object is bound to the variable wt, and this is exactly the value that is returned by the observation function:
fun obs (bindelem) =
let
fun obsBindElem (Task’Stop (2, {at,wt,tsi,tss,x,pt})) = wt
| obsBindElem _ = ~1
in
obsBindElem bindelem
end
Processing time monitor
The monitor named Processing time is very similar to the Wait time monitor, but it measures total processing time for an object rather than total wait time. The observation function for this monitor returns the value of variable pt which represents the total processing time for the object.
fun obs (bindelem) =
let
fun obsBindElem (Task’Stop (2, {at,pt,wt,tsi,tss,x})) = pt
| obsBindElem _ = ~1
in
obsBindElem bindelem
end
System time monitor
The monitor named System time is used to measure the total amount of time that objects spend in the system. In other words, the monitor measures the amount of time that passes from when an object arrives in the system until the object has been completely processed in task 2.
The object has been fully processed when the token representing the object is added to place Completed in page Process, and this happens when instance 2 of the Stop transition in page Task occurs. When this transition occurs, the value of variable at is the arrival time for the object that has been fully processed. The system time for the object can be obtained by subtracting the object’s arrival time from the time at which the transition occurs, and this is precisely what the observation function for the monitor does:
fun obs (bindelem) =
let
fun obsBindElem (Task’Stop (2, {at,wt,tsi,tss,x,pt})) =
intTime()-at
| obsBindElem _ = ~1
in
obsBindElem bindelem
end
Example models
The models described previously can be downloaded:
- the first example with no time attributes in token values
- the second example with several different time attributes in token values
Related pages
You must be logged in to post a comment.