SEKE 2012 Proceedings - Knowledge Systems Institute

vector and available resources are decreased . If the
transition represents the end of a task, R(t k ) is negative and
available resources are increased. If no resource involved,
then available resources remain unchanged.
Based on the transition firing rule reachability analysis
can be perf ormed, which explores all p ossible states and
execution paths, reveals possible deadlocks due to resource
contention.
E. An Example
Fig. 2 shows an ROWN with four tasks. Assume three
types of resources are involved in the workflow execution
and their initial quantities are S 0 = (30, 25, 20). Resource
changes by task execution are specified as follows:
R(B 1 ) = R + (TS 1 ) = (3, 8, 5)
R(E 1 ) = R - (TS 1 ) = (-3, -2, -5)
i
B 1
InEx 1
Idle 1
Fig. 2 An RCWN of 4 tasks.
a
b
E 1
B 2 InEx 2
E 2
Idle 2
B 3 E 3 InEx 3
Idle 3
R(B 2 ) = R + (TS 2 ) = (5, 0, 10)
R(E 2 ) = R - (TS 2 ) = (0, 0, -5)
R(B 3 ) = R + (TS 3 ) = (15, 10, 5)
R(E 3 ) = R - (TS 3 ) = (-5, -2, -5)
R(B 4 ) = R + (TS 4 ) = (0, 5, 15)
R(E 4 ) = R - (TS 4 ) = (0, -5, -5)
At the initial state, B 1 is the only transition that is
enabled. After it fires, S 1 = S 0 – R(B 1 ) = (27, 17, 15). Then
E 1 is the only transition that is enabled. After E 1 is fired, S 2
= S 1 – R(E 1 ) = (30, 12, 20). At state (M 2 , S 2 ), both B 2 and
B 3 are enabled. If B 2 fires, S 3 = S 2 – R(B 2 ) = (25, 1 2, 10).
Then if B 3 fires, S 4 = S 3 – R(B 3 ) = (10, 2, 5). We can
continue this process until we get to a state th at no
transitions are enabled.
III. RESOURCE REQUIREMENT ANALYSIS
After a workflow is built and the resource consumption
and production are def ined for all tas ks, the resource
requirement for executing the workflow can be f ormally
analyzed. We are in terested in the maximum resource
consumption (MRC), which is defined as the minimum
amount of resources that if satisfied, the workflow can be
executed along any possible path till finish without the
B 4
c
d
InEx 4
Idle 4
E 4
o
occurrence of resource shortage. Meeting MRC
requirement is very important for emergency response
workflows because it is de sired to not see an y resource
shortage in an y case in emergence response. To analyze
MRC, we need to f ind out the maximum amount of each
type of resources that can be held or co nsumed in the
execution of a workflow. We present two approaches in
this section. One is through reachability analysis, the other
one is based on ROWN structure and applies to a class of
ROWNs.
A. Reachability Analysis Based Approach
Let H be th e reachable state set. For each t ype of
resource r i , Find a state (M k , S k ) such that
S k (r i ) = min{S j (r i ) | (M j , S j ) H} (5)
S k (r i ) is the lowest possible level of availability of resource
r i during the workflow execution. Therefore, S 0 (r i ) - S k (r i )
indicates the minimum requirement on resource r i in order
for the workflow to be exec uted along all possible pat h.
Denote it by Rq(r i ).
Rq(r i ) = S 0 (r i ) - min{S j (r i ) | (M j , S j ) H} (6)
There are several advantages using this approach for
resource requirements analysis: First, it is si mple. One can
easily modify an existing Petri net tool to s upport this
functionality. Secondly, it allows multi-case resources
requirements analysis. The number of cases are specif ied
by the number of tokens in the source place i at the initial
state. Thirdly, it v irtually works for all workflows,
regardless of whether they are complex or simple in terms
of control flow and whether they are big or small in size.
B. Free-choice Workflow Nets
We only consider free-choice workflows. A w orkflow
net free-choice if and only if
p 1 *p 2 * ≠ => |p 1 *|=|p 2 *| = 1, p 1 , p 2 P,
Free-choice workflow net does not allow confusion, a
situation where conflict and concurrency are mixed.
C. Well-nested Workflows
Based on the concept of free-choice workflows, we
further introduce well-nested workflows. To facilitate the
definition of well-nested workflows, a piece of workflow
in which tasks are seriall y connected to f orm a si ngle
branch is called a procedural branch, and a piece of
workflow in which two or more procedural branches are
sprung out from a start task and then join in an end task is
called a fork-join block. There are two types of fork-join
blocks: one is parallel split-synchronization block (PSblocks),
in which multiple tasks are trigged by one task,
run currently and are even tually synchronized at anot her
task. The other type is exclusive choice-simple merge
blocks (ES-blocks), in which multiple tasks are trigged by
one task, run exclusively, and whichever is selected to run
383