220 TIMED PETRI NETS

act

P3

Figure 8.2 Sample ER net.

enabling tuple for transition t. Firing t produces an environment in place p3 where p3.x = −1 + 1 = 0 and p3.y = 2.

In the next section, we describe in detail time ER nets, the most recent of the three time-extended Petri nets introduced here.

8.3 TIME ER NETS

To extend ER nets to specify the notions of time, a variable chronos is introduced [Ghezzi et al., 1991] to represent the time-stamp of the token in each environment. This time-stamp gives the time when the token is produced. The time-stamps of the tokens put in output places are produced by the actions associated with the transitions and are based on the selected input enabling a tuple’s environments’ values.

The variable chronos can take on nonnegative real numbers when used in a continuous time model, or nonnegative integers when used in a discrete time model. This concept of a time-stamp assigned to a token when it is produced is similar to the time value given by the occurrence function in real-time logic and the time value τ indicating the time of the corresponding event occurrence in timed languages and automata. An occurrence function assigns a time to the occurrence of an instance of an event. τ denotes the occurrence time of an event ρ in the pair (ρ, τ ).

To enforce time restrictions on chronos, we need the following axioms.

Local Monotonicity Axiom: Let c1 be the value of chronos in the environments removed by (before) any firing, and let c2 be the value of chronos in the environments produced by (after) this firing. Then, c1 ≤ c2.

Constraint on Time-Stamps Axiom: The values of all elements of the tuple prod in any firing x = enab, t, prod are equal to chronos. This time of the firing is denoted as time(x).

222 TIMED PETRI NETS

A car arriving at the intersection is represented by a token in place p1 (car(s) at intersection), with a time-stamp indicating the time when this car arrives and stops at the intersection. There may be no token in p1, indicating no car is at the intersection, or there may be one or more tokens in p1, indicating one or more cars present at the intersection. Each token contains a variable indicating the position of the car at the intersection. This is useful in determining which token (car) to be selected for making the next move, whether or not to cross the intersection. The second choice models a car stalling (staying in the same position) due to mechanical problems or the driver falling asleep.

A token in place p2 (no-pedestrian) means that no pedestrians crossing the intersection. At most one token can be in this place.

The firing of transition t1 models the car traffic light turning green. If the light is already green, then this transition keeps the light green. This transition removes one token from place p1 when fired to indicate the car selected for crossing the intersection. This car must be at the front of the queue of cars waiting at the intersection (indicated by the variable position of the car token), and the time interval between the time when the light turns green and the current time cannot exceed δ1 (so that the right of way is not monopolized by cars traveling on one street). δ1 can be a constant or a function dependent on how busy the intersection is and the time of day. Function f1 indicates how the status of the car changes when the light turns green and the car is selected for further action (the driver gets ready to release the brake and press the accelerator):

act1 = { p1, p2 , p3 |p3.chronos - turn green ≤ δ1

p3.car = p1.car

p3.car status = f1( p1, p2)}.

The firing of transition t2 models a car moving forward and crossing the intersection, whereas the firing of transition t3 models a car staying in the same position without crossing the intersection. Functions f2 and f3 model the state changes of the car in these two scenarios, respectively:

act2 = { p3, p4 |p3.chronos ≤ p4.chronos

≤ turn green + δ1 p4.car status = f2( p3)} act3 = { p3, p5 |p5.car status = f3( p3)}.

Example. Suppose we have a partial TERN similar to the one in Figure 8.3 but with the use of more timing features. This TERN models clients’ requests for using a resource and the assignment of this resource to satisfy a client’s request.

A client (or its request) arriving at the waiting center is represented by a token in place p1 (waiting center), with a time-stamp indicating the time when this client’s request arrives. There may be no token in p1, indicating no request is at the waiting center, or one or more tokens in p1, indicating one or more requests at the waiting

center. Each token contains a variable deadline, indicating the deadline by which to complete serving the request, and a variable valid interval, indicating the validity interval of the data in this request. The variable deadline indicates the time instant after which the service of the request is no longer useful. The variable valid interval indicates the time interval within which the data is current; the data become obsolete after this validity interval. The second endpoint of this validity interval is the data’s expiration time. The values of these variables determine which token (request) will be selected for making the next move, whether or not to be assigned the resource. The second choice may model the resource controller not allocating the resource to this request due to unforeseen problems.

A token in place p2 (resource center) means that the single resource is available for allocation. At most one token can be in this place.

The firing of transition t1 models the resource controller ready to allocate the resource to a request. This transition, when fired, removes one token from place p1 to indicate the request selected for using the resource. The deadline of this selected request must be less than the current time and the current time must still be within the validity interval of the request’s data (the current time cannot be greater than the data’s expiration time):

act1 = { p1, p2 , p3 |p3.chronos < p1.deadline p3.chronos

≤ p1.expiration time − p1.chronos p3.request

= p1.request p3.resource center status = f1( p1, p2)}.

The firing of transition t2 models the resource controller, assigning the usage of the resource to the selected request, whereas the firing of transition t3 models the resource controller not allocating the resource to the request due to unforeseen problems. The assignment and usage of the resource must happen before the deadline and the expiration time of the selected request. Also, due to buffering restrictions for a request, this resource assignment must occur within δ time units after the request is selected for resource assignment:

act2 = { p3, p4 |p4.chronos < p3.deadline p4.chronos

≤ p3.expiration time − p3.chronos p4.request status = f2( p3)} act3 = { p3, p5 |p5.request status = f3( p3)}.

8.3.1 Strong and Weak Time Models

In untimed Petri nets, whether or not a transition is enabled depends on its input places. An enabled transition may or may not fire; it is not required to always fire. Hence, firing decisions are made locally. The same is true for TERNs. However, situations occur in which we have to specify that certain transitions must fire when enabled and within a certain period, especially in real-time systems. To handle these cases, the Milano’s group [Ghezzi et al., 1991; Ghezzi, Morasca, and Pezze, 1994] introduces the strong time model, where enabled transitions must fire. To define strong TERNs, we need the following definitions.

224 TIMED PETRI NETS

Set of Possible Firing Times: Given a tuple i of input tokens and a transition t in a TERN, the set of firing times for i and t is

f time(t, i) = {x| i, o α(t)x = o.chronos}.

The following definition of strong firing sequence says that an enabling tuple must fire by a due time and there exists no other firing that would prevent it from firing later.

Strong Firing Sequences Axiom: All firing sequences are strong.

Strong Time ER Nets (STERNs): A STERN is a TERN satisfying the local monotonicity axiom, the constraint on time-stamps axiom, and the strong firing sequences axiom.

In fact, STERNs are a proper subset of TERNs. TERNs, which do not represent strong time models, are appropriate to represent weak time models. If we do not specify that a TERN is strong, it is understood that it represents a weak time model without stating that it is a weak TERN. Weak TERNs do not satisfy the strong firing sequences axiom.

It is possible to construct a strong TERN from any given TERN. One way to do this that preserves the topology of the original TERN is to add to it a new place Arbiter (ARB), which is a member of the preset and postset of every transition. The ARB environment records the global state of the net and the actions (associated with the transitions dependent on the ARB environment) are augmented to satisfy the strong firing sequences axiom. Basically, an added constraint is present in each action such that its associated transition may fire before or at a time that is the minimum of the maximum times of the possible firings of the original TERN.

To avoid increasing the visual complexity of a TERN by making it a strong TERN, we can simply interpret it as a strong TERN without introducing the new place ARB and adding the above constraint to every action.

8.4 PROPERTIES OF HIGH-LEVEL PETRI NETS

We now introduce several properties of high-level Petri nets (ER nets) and comment on how difficult it is to determine these properties. These properties apply also to TPNs and TERNs. Let M0 be the initial marking.

quence enab1, t1, prod1 , · · · , enabk , tk , prodk where k > 0, enabi is enabled in the marking Mi−1, and the firing of enabi yields the marking Mi for 1 ≤ i ≤ k.

Using this reachability property, we can specify a desirable configuration that the net should enter, and using an appropriate analysis strategy similar to state-graph reachability analysis, we can check if this property is satisfied. Similarly, we may want to specify an undesirable configuration that the net should never enter, and check that this is true.

Boundedness Property: A high-level Petri net is S-bounded iff the number of tokens in each marking reachable from M0 and in each place is at most S. The net is bounded iff a nonnegative integer S exists such that the net is S-bounded.

Using this boundedness property, we can express that the number of tokens in a place is bounded or not. Since tokens may represent instances of resources or processes, this property is very useful in specifying termination and finiteness requirements. For instance, in the smart traffic light system example, we can specify that the number of cars at the intersection is at most S.

Weak Boundedness Property: A high-level Petri net is S–weakly bounded iff the number of tokens that are part of an enabling tuple in each marking reachable from M0 and in each place is at most S. The net is weakly bounded iff a nonnegative integer S exists such that the net is S–weakly bounded.

Since tokens in a place may have valid time intervals after which they expire, they cannot participate in enabling transitions after these expiration times. Hence, it is possible for these dead tokens to accumulate in a place in a particular application without an upper bound on their number. The tokens with no validity time intervals or within their valid time intervals are live tokens and can participate in enabling transitions. In many applications, as long as the number of these live tokens is bounded in each place in the net, the modeled application is correct even if the total number of tokens may be unbounded in a place. This scenario is captured by the weak boundedness property.

If a net is weakly bounded, each transition has a bounded number of enabling tuples. Note that boundedness implies weak boundedness, but not vice versa. For instance, tokens may represent sensor information that trigger a system response only when this information is current. Thus, sensor information that is not current can be represented by dead tokens and thus do not trigger a system response.

Transition Liveness: An ER net is transition live iff for each transition t and for each marking M reachable from M0, a marking M is reachable from M and t is enabled in M .

226 TIMED PETRI NETS

This property specifies that every transition from any marking leads to another reachable marking.

Token Liveness: An ER net is token live iff for each token q in any marking M

reachable from M0, a marking M is reachable from M and q is in an enabling tuple in M .

This property means that every token in a place is live.

Net Liveness Property: An ER net is net live iff at least one enabled transition exists in every marking reachable from M0.

This property indicates that there is at least one firable transition in the net.

Static-Conflict Free Net: An ER net is static-conflict free iff for any two different transitions t1 and t2, t˙1 ∩ t˙2 = .

Dynamic-Conflict Free Net: An ER net is dynamic-conflict free iff for any reachable marking M a different pair does not exist in M enab1, t1 , enab2, t2 such that enab1 enables t1, enab2 enables t2, and the firing of t1 using tuple enab1 disables the firing of t2 using tuple enab2.

To determine whether a net is static-conflict free, we can check the net topology. To determine whether a net is dynamic-conflict free, we have to know the values while the net runs.

Only one general proven relationship exists among these properties: An ER net that is transition live implies that it is net live. In general, determining whether the above properties hold is undecidable. However, if we make the HLTPN or TERN specifications less precise, we are able to check some of the above properties.

8.5 BERTHOMIEU–DIAZ ANALYSIS ALGORITHM FOR TPNS

Determining state reachability is a fundamental problem in the analysis of Petri nets. The same is true for the analysis of time Petri nets. Even for classical Petri nets, the rechability problem is undecidable. [Berthomieu and Diaz, 1991] invented an efficient enumerative method to analyze time Petri nets. They restrict the static EFTs and LFTs for transitions to use only rational numbers. Furthermore, related states are grouped into a state class to reduce the state exploration time.

State class: A state class is a pair C = (M, D) where M is a marking such that all states in the class have the same marking and D is the firing domain of the class, that is, the union of the firing domains of all the states in the class.