Highly Dynamic Adaptationin Process Management Systemsthrough Execution Monitoring

Massimiliano de Leoni, Massimo Mecella, and Giuseppe De Giacomo

Dipartimento di Informatica e SistemisticaSAPIENZA – Universita di RomaVia Ariosto 25, 00185 Roma, Italy

{deleoni,mecella,degiacomo}@dis.uniroma1.it

Abstract. Nowadays, process management systems can be used notonly in classical business scenarios, but also in highly mobile and dynamicsituations, e.g., in supporting operators during emergency managementin order to coordinate their activities. In such challenging situations,processes should be adapted, in order to cope with anomalous situations,including connection anomalies and task faults. In this paper, we presenta general approach, based on execution monitoring, which is (i) practical,by relying on well-established planning techniques, and (ii) does notrequire the definition of the adaptation strategy in the process itself(as most of the current approaches do). We prove the correctness andcompleteness of the approach.

1 Introduction

Nowadays, process management systems (PMSs, [1, 2]) are widely used in manybusiness scenarios, such as government agencies, insurances, banks, etc. Besidessuch scenarios, which present mainly static characteristics (i.e., deviations arenot the rule, but the exception), PMSs can be used also in mobile and highlydynamic situations, such as in coordinating operators/devices/robots/sensors inemergency situations [3, 4].

As an example, in [5] a project is presented in which PMSs are used withinteams of emergency operators, in order to coordinate their activities. In suchscenarios, the members of a team are equipped with PDAs and coordinatedthrough a PMS residing on a leader device (usually a laptop); devices communi-cate among them through ad hoc networks, and in order to carry on the process,they need to be continually connected each other. But this is not simply guaran-teed: the environment is highly dynamic, since nodes (i.e., devices and the relatedoperators) move in the affected area to carry out assigned tasks; movements maycause possible disconnections and, so, unavailability of nodes. Therefore the pro-cess should be adapted. Adaptivity might simply consist in assigning the taskin progress to another device, but collecting actual user requirements [6] showsthat typical teams are formed by a few nodes (less than 10 units), and thereforefrequently such reassignment is not feasible. Conversely, other kind of adaptivitycan be envisioned, such as recovering somehow the disconnecting node through

specific tasks, e.g., when X is disconnecting, the PMS could assign the “followX” task to another node so to guarantee the connection. This example showsthat in such scenarios (i) the process is designed (and deployed on the PMS) asif everything would be fine during run-time, and (ii) it needs to be continuouslyadapted on the basis of rules that would be infeasible to foresee at design time.

The aim of this paper is to propose a general conceptual framework for theabove issue, and to present a practical technique for solving it, which is basedon planning in AI; moreover, we prove the correctness and completeness of theapproach. In a PMS, process schemas are defined that describe the different as-pects, i.e., tasks/activities, control and data flow, tasks assignment to services 1,etc. Every task gets associated a set of conditions which have to be true in orderto perform the task. Conditions are defined on control and data flow (e.g., aprevious task has to be finished, a variable needs to be assigned a specific rangeof values, etc.). This kind of conditions can be somehow considered as “internal”:they are handled internally by the PMS and, thus, easily controllable. Anothertype of conditions exist, that is the “external” ones: they depend on the environ-ment where process instances are carried on. These conditions are more difficultto keep under control and a continuous monitoring to detect discrepancies is re-quired. Indeed we can distinguish between a physical reality and a virtual reality[7]; the physical reality is the actual values of conditions, whereas the virtualreality is the model of reality that PMS uses in making deliberations. A PMSbuilds the virtual reality by assuming the effects of tasks/actions fill expecta-tions (i.e., they modify correctly conditions) and no exogenous events break out,which are capable to modify conditions.

When the PMS realizes that one or more events caused the two kinds ofreality to deviate, there are three possibilities to deal with such a discrepancy:

1. Ignoring deviations – this is, of course, not feasible in general, since thenew situation might be such that the PMS is no more able to carry out theprocess instance.

2. Anticipating all possible discrepancies – the idea is to include in the processschema the actions to cope with each of such failures. As we discuss in Sec-tion 7, most PMSs use this approach. For simple and mainly static processes,this is feasible and valuable; but, especially in mobile and highly dynamicscenarios, it is quite impossible to take into account all exception cases.

3. Devising a general recovery method able to handle any kind of exogenousevents – this can be seen as a try-catch approach, used in some program-ming languages such as Java. The process is defined as if exogenous actionscannot occur, that is everything runs fine (the try block). Whenever the ex-ecution monitor (i.e., the module intended for execution monitoring) detectsdiscrepancies leading the process instance not to be terminable, the controlflow moves to the catch block. The catch block activates the general re-covery method to modify the old process P in a process P ′ so that P ′ canterminate in the new environment and its goals are included in those of P .

1 In this work, we abstract all possible actors a process can coordinate, i.e., human op-erators commonly interacting through worklists, software applications/components,etc. as services providing capabilities to be matched with the ones required by thetasks.

Here the challenge is to automatically synthesize P ′ during the executionitself, without specifying a-priori all the possible catches.

The contribution of this paper is (i) to introduce a general conceptual frame-work in accordance with the third approach previously described, and (ii) topresent a practical technique, in the context of this framework, that is able toautomatically cope with anomalies. We prove the correctness and completenessof such a technique, which is based on planning techniques in AI.

The rest of the paper is organized as follows: Section 2 introduces somepreliminary notions, namely Situation Calculus and ConGolog, that are usedas proper formalisms to reason about processes and exogenous events. Section3 presents the general conceptual framework to address adaptivity in highlydynamic scenarios, and introduces a running example. Section 4 presents theproposed formalization of processes, and Section 5 deals with the adaptiveness.Section 6 presents the specific technique and proves its correctness and complete-ness. Related works are discussed in Section 7, and finally Section 8 concludesthe paper.

2 Preliminaries

In this section we introduce the Situation Calculus, which we use to formalizethe adaptiveness in PMSs. The Situation Calculus [8] is a second-order logictargeted specifically for representing a dynamically changing domain of interest(the world). All changes in the world are obtained as result of actions. A possiblehistory of the actions is represented by a situation, which is a first-order termdenoting the current situation of the world. The constant s0 denotes the initialsituation. A special binary function symbol do(α, s) denotes the next situationafter performing the action α in the situation s. Action may be parameterized.

Properties that hold in a situation are called fluents. These are predicatestaking a situation term as their last argument. Changes in fluents (resulting fromexecuting actions) are specified through successor state axioms. In particular foreach fluent F we have a successor state axioms as follows:

F (−→x , do(α, s)) ⇔ ΦF (−→x , do(α, s), s)

where ΦF (−→x , do(α, s), s) is a formula with free variables −→x , α is an action, ands is a situation. Besides successor state axioms, Situation Calculus theories arecharacterized by action precondition axioms, which specify whether a certainaction is executable in a situation. Action precondition axioms have the form:

Poss(α, s) ⇔ Πα(s)

where the formula Πα(s) defines the conditions under which the action α maybe performed in the situation s.

In order to control the executions of actions we make use of high level pro-grams, expressed in Golog-like programming languages [9]. In particular we focuson ConGolog [10] which is equipped with primitives for expressing concurrency.

Construct Meaning

a A primitive action

φ? Wait while the φ condition is false

(δ1; δ2) Sequence of two sub-programs δ1 and δ2

proc P (−→v ) δ Invocation of a procedure passing a vector −→v of parameters

if φ then δ1 else δ2 Exclusive choice between δ1 and δ2 according to the condition φ

while φ do δ Iterative invocation of δ

(δ1 ‖ δ2) Concurrent execution

Table 1. ConGolog constructs

The Table 1 summarizes the constructs of ConGolog used in this work. Basi-cally, these constructs allow to define every well-structured process as defined in[11].

From the formal point of view, ConGolog programs are terms. The execu-tion of ConGolog programs is expressed through a transition semantic basedon single steps of execution. At each step a program executes an action andevolves to a new program which represents what remains to be executed of theoriginal program. Formally two predicates are introduced to specify such a se-matic:

– Trans(δ′, s′, δ′′, s′′), given a program δ′ and a situation s′, returns (i) a newsituation s′′ resulting from executing a single step of δ′, and (ii) δ′′ which isthe remaining program to be executed.

– Final(δ′, s′) returns true when the program δ′ can be considered successfullycompleted in situation s′.

By using Trans and Final we can define a predicate Do(δ′, s′, s′′) that rep-resent successful complete executions of a program δ′ in a situation s′, where s′′

is the situation at the end of the execution of δ′. Formally:

Do(δ′, s′, s′′) ⇔ ∃δ′′.T rans∗(δ′, s′, δ′′, s′′) ∧ Final(δ′′, s′′)

where Trans∗ is the definition of the reflective and transitive closure of Trans.

3 General Framework

The general framework which we introduce in this paper is based on executionmonitoring formally represented in Situation Calculus [12, 7]. After each action,the PMS has to align the internal world representation (i.e., the virtual reality)with the external one (i.e., the physical reality), since they could differ due tounforeseen events.

When using ConGolog for process management, tasks are considered aspredefined sequences of actions (see later) and processes as ConGolog pro-grams.

Fig. 1. Execution Monitoring

Before a process starts to be executed, the PMS takes the initial contextfrom the real environment as initial situation, together with the program (i.e. theprocess) δ0 to be carried on. The initial situation s0 is given by first-order logicpredicates. For each execution step, the PMS, which has a complete knowledgeof the internal world (i.e., its virtual reality), assigns a task to a service. The onlyassignable tasks are those ones whose preconditions are fulfilled. A service cancollect from the PMS the data which are required in order to execute the task.When a service finishes executing the task, it alerts the PMS of its completion.

The execution of the PMS can be interrupted by the monitor when a mis-alignment between the virtual and the physical reality is sensed. When thishappens, the monitor adapts the program to deal with such a discrepancy.

Figure 1 illustrates such an execution monitoring. At each step, PMS ad-vances the process δ in the situation s by executing an action, resulting in a newsituation s′ with the process δ′ remaining to be executed. The state2 is repre-sented as first-order formulas that are defined on situations. The current statecorresponds to the boolean values of these formulas evaluated on the currentsituation.

Both the situation s′ and the process δ′ are given as input to the monitor. Itcollects data from the environment through sensors (here sensor is any softwareor hardware component enabling to retrieve contextual information). If a dis-crepancy between the virtual reality as represented by s′ and the physical realityis sensed, the monitor changes s′ in s′′ by internally simulating a sequence ofactions that re-aligns the virtual and physical reality (i.e., those are not reallyexecuted). Notice that the process δ′ may fail to be correctly executed (i.e., byassigning all tasks as required) in s′′. If so, the monitor adapts the process bygenerating a new process δ′′ that pursues at least each δ′’s goal and is executable

2 Here we refer as state both the tasks’ state (e.g, performable, running, terminated,etc.) and the process’ variables. The use of the latter variables are twofold: from theone hand, the routing is defined on them and, from the other hand, they allow tolearn when a task may fire.

in s′′. At this point, the PMS is resumed and the execution is continued from δ′′

and s′′.We end this section by introducing our running example, stemming from the

project described in [5, 6].

Example 1 A Mobile Ad hoc NETwork (manet) is a P2P network of mobilenodes capable of communicating with each other without an underlying infras-tructure. Nodes can communicate with their own neighbors (i.e., nodes in radio-range) directly by wireless links. Non-neighbor nodes can communicate as well,by using other intermediate nodes as relays that forward packets toward destina-tions. The lack of a fixed infrastructure makes this kind of network suitable inall scenarios where it is needed to deploy quickly a network, but the presence ofaccess points is not guaranteed, as in emergency management.

Coordination and data exchange requires manet nodes to be continually con-nected each other. But this is not guaranteed in a manet. The environment ishighly dynamic, since nodes move in the affected area to carry out assigned tasks.Movements may cause possible disconnections and, so, unavailability of nodes,and, consequently, unavailability of provided services. Therefore processes shouldbe adapted, not simply by assigning tasks in progress to other services, but alsoconsidering possible recovery of the services.

NONO

YES YES

NO

Compile Questionnaire Xabout destination A

Take photos ofdestination A

Evaluates photos

Reject Photo

Compile Questionnaire Yabout destination B

Take photos of destination B

Evaluates photos

Reject Photo

YES

Compile Questionnaire Zabout destination C

Take photos ofdestination C

Evaluates photos

Reject Photo

Send data by GPRS/UMTS

Move todestination A

Move to destination B

Move to destination C

Qu

estio

nna

irre

Pho

tos

Qu

estio

nna

irre

Pho

tos

Que

stio

nna

irre

Ph

oto

s

Fig. 2. A possible process to be carried on in disaster management scenarios

Figure 2 shows a possible scenario for information collecting after an earth-quake: a team is sent to the affected area to evaluate the situation of three build-ings. For each building, an actor compiles a questionnaire (by using a service,i.e., an application that it has got installed). Questionnaire compiling can be doneeverywhere: that is, movement is not required. Then, another actor/service hasto be sent to the specific building to collect some pictures (this, conversely, re-quires movement). Finally, according to information in the questionnaire, a thirdactor/service evaluates quality and effectiveness of collected pictures. If picturesare of bad quality, the task of taking new pictures is scheduled again. Wheneverthese steps have been performed for the three buildings A, B and C, the collecteddata (questionnaires and pictures) are sent by GPRS or UMTS elsewhere.

4 Formalization in Situation Calculus

Next we detail the general framework proposed above by using Situation Cal-culus and ConGolog. We use some domain-independent predicates to denotethe various objects of interest in the framework:

– service(a): a is a service– task(x): x is a task– capability(b): b is a capability– provide(a, b): the service a provides the capability b– require(x, b): the task x requires the capability b

Every task execution is the sequence of four actions: (i) the assignment ofthe task to a service, resulting in the service being not free anymore; (ii) thenotification to the service to start executing the task. Then, the service carriesout the tasks and, after finishing, (iii) the PMS stops the service, acknowledgingthe successful termination of its task. Finally, (iv) the PMS releases the service,which becomes free again. We formalize these four actions as follows (these arethe only actions used in our formalization):

– Assign(a, x): the task x is assigned to a service a– Start(a, x, p): the service a is notified to perform the task x on input p– Stop(a, x, q): the service a is stopped acknowledging the successful termina-

tion of x with output q– Release(a, x): the service a is released with respect to the task x

The terms p and q denote arbitrary sets of input/output, which depend onthe specific task; if no input or output is needed, p and q are ∅.

For each specific domain, we have several fluents representing the propertiesof situations. Among them, we have the fluent free(a, s), which is indeed domain-independent, that denotes the fact that the service a is free, i.e., no task has beenassigned to it, in the situation s. The corresponding successor state axiom is asfollows:

free(a, do(t, s)) ⇔(∀x.t 6= Assign(a, x) ∧ free(a, s)) ∨(¬free(a, s) ∧ ∃x.t = Release(a, x)

) (1)

This says that a service a is considered free in the current situation if and onlyif a was free in the previous situation and no tasks have been just assigned toit, or a was not free and it has been just released.

In addition, we make use, in every specific domain, of a predicateavailable(a, s) which denotes whether a service a is available in situation s fortasks assignment. However, available is domain-dependent and, hence, requiresto be defined specifically for every domain. Its definition must enforce the fol-lowing condition:

∀a s.available(a, s) ⇒ free(a, s) (2)

Precondition axioms are also domain dependent and, hence, vary from caseto case. However the following condition must be true:

∀x, p, q Poss(Start(a, x, p), s

) ⇒ available(a, s) (3)

Knowing whether a service is available is very important for the PMS whenit has to perform assignments. Indeed, a task x is assigned to the best servicea which is available and provides every capability required by x. In order tomodel the best choice among available services, we introduced a special con-struct, named pick. The statement pick a.[φ(a)] δ chooses the best service amatching the condition φ(·) on predicates and fluents applied in the currentsituation. This choice is performed with respect to a given (typically domain-dependent) metric. For instance, the pick might consider the queueing of tasksthat are assigned to the members, as well as the execution of multiple paral-lel process instances sharing the same resources. Observe that such a choice isdeterministic, even when there are more than one service matching the condi-tion φ(·). Then it instantiates δ with the chosen a and executes the first step ofthe resulting program. If no service matches the condition, the process δ staysblocked, until some other services make φ(a) true.

We illustrate such notions on our running example.

Example 1 (cont.). We formalize the scenario in Example 1. We make use ofthe following domain-dependent fluents (for sake of brevity we focus on the mostrelevant ones):

– connected(a, b, s): which is true if in the situation s the services a and b areconnected through multi-hop paths

– neigh(a, b, s): which is true if in the situation s the services a and b are inradio-range in the situation s

– at(a, p, s) it is true if in the situation s the service a is located at the coor-dinate p = 〈px, py, pz〉 in the situation s.

The successor state axioms for this domain are:

available(a, do(x, s)) ⇔ free(a, do(x, s)) ∧ connected(a, Coord, do(x, s))

connected(a0, a1, do(x, s)) ⇔ neigh(a0, a1, do(x, s)) ∨(∃a2.service(a2) ∧ neigh(a0, a2, do(x, s)) ∧ connected(a2, a1, do(x, s)))

neigh(a0, a1, do(x, s)) ⇔at(a0, p0, do(x, s)) ∧ at(a1, p1, s)∧ ‖ p0 − p1 ‖< rrange

at(a, p, do(x, s)) ⇔∀ p, q. x 6= Stop(a, Go, p) ∧ at(a, p, s) ∨ ∀ q. x = Stop(a, Go, p)

The first successor state axiom is the one for available, which states aservice is available if it is connected to the coordinator device (denoted by Coord)and it is free. Notice that the condition 2 is fulfilled. The axiom for connectedstates two devices are connected if and only if they are neighbors (i.e., in radio-range) or there exists a path in the manet. The successor state axiom neighstates how neighbors evolve: two nodes a and b are neighbors in situation s if andonly if their distance ‖ pa−pb ‖ is less than the radio-range. The successor stateaxiom for at states that the position p for a does not change until the assignedtask Go is acknowledged to be finished.

In the reality, in order to know the position returned by the Go task, thePMS gets such an information from the service a (here not modelled). In casethe node (hence the service) is getting disconnected, the monitor will get in andgenerate a Stop action which communicates the actual position, and a recovery isinstructed in order to keep the connection (see later). Indeed, in such a scenarionodes need be continually connected to each other, as a disconnected node is outof the PMS’s control [3].

For sake of brevity we do not look at the precondition axioms, and instead welook directly at the ConGolog program (implicitly assuming that such precon-dition axioms allow for all instructions in the program). The ConGolog pro-gram corresponding to Figure 2 is shown in Figure 3. The main program is theprocedure Process, which executes in parallel on three threads the sub-procedureEvalTake and then assigns the task SendByGPRS to the proper service that isthe one providing the capability to send data by means of GPRS (or similar).

5 Adaptation

Next we formalize how the monitor works. Intuitively, the monitor takes thecurrent program δ′ and the current situation s′ from the PMS’s virtual realityand, analyzing the physical reality by sensors, introduces fake actions in orderto get a new situation s′′ which aligns the virtual reality of the PMS with sensedinformation. Then, it analyzes whether δ′ can still be executed in s′′, and if not,it adapts δ′ by generating a new correctly executable program δ′′. Specifically,the monitor work can be abstractly defined as follows (we do not model how thesituation s′′ is generated from the sensed information):

[ ]

[ ]

endproc

);SendByGPRS,(Re

);,SendByGPRS,(

);F,Q,F,Q,F,Q,SendByGPRS,(

);SendByGPRS,(

?;),(

)SendByGPRS,( )()( pick

));F,QLocC,(

||)F,QLocB,(

||)F,QLocA,((

proc

endproc

));Evaluate,(Re

);Evaluate,,(

);,,Evaluate,,(

);Evaluate,(

)],(

)Evaluate,( )()([ pick

));TakePhoto,(Re

);TakePhoto,,(

);TakePhoto,,(

);Go,,(

);Go,,(

);TakePhoto,(

)],(

)TakePhoto,( )()([ (pick

) while(

;:

);Compile,(Re

);Compile,,(

);Compile,,(

);Compile,(

),()Compile,( )()( pick

),,( proc

ccbbaa

cc

bb

aa

2

1

1

2

2

222

1

1

1

1

1

1

1

111

0

0

0

0

000

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

16

15

14

13

12

11

10

09

08

07

06

05

04

03

02

01

alease

nilaStop

}{aStart

aAssign

baprovide

brequireservice(b)baavailableaactora

EvalTake

EvalTake

EvalTake

Process

alease

isOkaStop

Photos}ireQuestionna{LocationaStart

aAssign

baprovide

brequireservice(b)baavailableaactora

alease

PhotosaStop

LocationaStart

LocationaStop

LocationaStart

aAssign

baprovide

brequireservice(b)baavailableaactora

falseisOk

falseisOk

alease

ireQuestionnaaStop

LocationaStart

aAssign

baprovidebrequireservice(b)baavailableaactora

PhotosireQuestionnaLocationEvalTake

o

⇒

∧∀∧∧

⇒

∧∀∧∧

⇒

∧∀∧∧==

=

⇒∧∀∧∧

Fig. 3. The ConGolog program of the process in Figure 2

Monitor(δ′, s′, s′′, δ′′) ⇔(Relevant(δ′, s′, s′′) ∧Recovery(δ′, s′, s′′, δ′′)

) ∨(¬Relevant(δ′, s′, s′′) ∧ δ′′ = δ′) (4)

where: (i) Relevant(δ′, s′, s′′) states whether the change from the situations′ into s′′ is such that δ′ cannot be correctly executed anymore; and (ii)Recovery(δ′, s′, s′′, δ′′) is intended to hold whenever the program δ′, to be orig-inally executed in the situation s′, is adapted to δ′′ in order to be executed inthe situation s′′.

Formally Relevant is defined as follows:

Relevant(δ′, s′, s′′) ⇔ ¬SameConfig(δ′, s′, δ′, s′′)

where SameConfig(δ′, s′, δ′′, s′′) is true if executing δ′ in s′ is “equivalent” toexecuting δ′′ in s′′ (see later for further details).

In this general framework we do not give a definition forSameConfig(δ′, s′, δ′′, s′′). However we consider any definition for SameConfigto be correct if it denotes a bisimulation [13]. Formally, for every δ′, s′, δ′′, s′′

holds:

1. Final(δ′, s′) ⇔ Final(δ′′, s′)2. ∀ a, δ′.T rans

(δ′, s′, δ′, do(a, s′)

) ⇒∃ δ′′.T rans

(δ′′, s′′, δ′, do(a, s′′)

) ∧ SameConfig(δ′, do(a, s), δ′′, do(a, s′′)

)3. ∀ a, δ′.T rans

(δ′′, s′′, δ′, do(a, s′′)

) ⇒∃ δ′′.T rans

(δ′, s′, δ′, do(a, s′)

) ∧ SameConfig(δ′′, do(a, s′′), δ′, do(a, s′)

)

Intuitively, a predicate SameConfig(δ′, s′, δ′′, s′′) is said to be correct if δ′

and δ′′ are terminable either both or none of them. Furthermore, for each actiona performable by δ′ in the situation s′, δ′′ in the situation s′′ has to enablethe performance of the same actions (and viceversa). Moreover, the resultingconfigurations (δ′, do(a, s′)) and (δ′′, do(a, s′)) must still satisfy SameConfig.

The use of the bisimulation criteria to state when a predicateSameConfig(· · · ) is correct, derives from the notion of equivalence introducedin [14]. When comparing the execution of two formally different business pro-cesses, the internal states of the processes may be ignored, because what reallymatters is the process behavior that can be observed. This view reflects the waya PMS works: indeed what is of interest is the set of tasks that the PMS offersto its environment, in response to the inputs that the environment provides.

Next we turn our attention to the procedure to adapt the process formalizedby Recovery(δ, s, s′, δ′). Formally is defined as follows:

Recovery(δ′, s′, s′′, δ′′) ⇔∃δa, δb.δ

′′ = δa; δb ∧Deterministic(δa) ∧Do(δa, s′′, sb) ∧ SameConfig(δ′, s′, δb, sb)

(5)

Recovery determines a process δ′′ consisting of a deterministic δa (i.e., aprogram not using the concurrency construct), and an arbitrary program δb.The aim of δa is to lead from the situation s′′ in which adaptation is needed toa new situation sb where SameConfig(δ′, s′, δb, sb) is true.

Notice that during the actual recovery phase δa we disallow for concurrencybecause we need full control on the execution of each service in order to getto a recovered state. Then the actual recovered program δb can again allow forconcurrency.

6 Adaptation: A Specific Technique

In the previous sections we have provided a general description on how adapta-tion can be defined and performed. Here we choose a specific technique that isactually feasible in practice. Our main step is to adopt a specific definition forSameConfig, here denoted as SameConfig, namely:

SameConfig(δ′, s′, δ′′, s′′) ⇔SameState(s′, s′′) ∧ δ′ = δ′′ (6)

In other words, SameConfig states that δ′, s′ and δ′′, s′′ are the sameconfiguration if (i) all fluents have the same truth values in both s′ and s′′

(SameState)3 , and (ii) δ′′ is actually δ′.The following shows that SameConfig is indeed correct.

Theorem 1. SameConfig(δ′, s′, δ′′, s′′) is correct.

Proof. We show that SameConfig is a bisimulation. Indeed:

– Since SameState(s′, s′′) requires all fluents to have the same values both ins′ and s′′, we have that

(Final(δ, s′) ⇔ Final(δ, s′′)

).

– Since SameState(s′, s′′) requires all fluents to have the same values bothin s′ and s′′, it follows that the PMS is allowed for the same processδ′ to assign the same tasks both in s′ and in s′′ and moreover for eachaction a and situation s′ and s′′ s.t. SameState(s′, s′′), we have thatSameState(do(a, s′), do(a, s′′)) hold. As a result, for each a and δ′ suchthat Trans

(δ′, s′, δ′, do(a, s′)

)we have that Trans

(δ′, s′′, δ′, do(a, s′′)

)and

SameConfig(δ′, do(a, s), δ′′, do(a, s′′)

). Similarly for the other direction.

Hence, the thesis holds.

Next let us denote by LinearProgram(δ) a program constituted only bysequences of actions, and let us define Recovery as:

Recovery(δ′, s′, s′′, δ′′) ⇔∃δa, δb.δ

′′ = δa; δb ∧ LinearProgram(δa) ∧Do(δa, s′′, sb) ∧ SameConfig(δ′, s′, δb, sb)

(7)

Next theorem shows that we can adopt Recovery as a definition of Recoverywithout loss of generality.

3 Observe that SameState can actually be defined as a first-order formula over thefluents, as the conjunction of F (s′) ⇔ F (s′′) for each fluent F .

Theorem 2. For every process δ′ and situations s′ and s′′, there exists aδ′′ such that Recovery(δ′, s′, s′′, δ′′) if and only if there exists a δ′′ suchthat Recovery(δ′, s′, s′′, δ′′), where in the latter we use SameConfig asSameConfig.

Proof. Observe that the only difference between the two definitions is that in onecase we allow only for linear programs (i.e., sequences of actions) as δa, while inthe second case also for deterministic ones, that may include also if-then-else,while, procedures, etc.(⇒) Trivial, as linear programs are deterministic programs.(⇐) Let us consider the recovery process δ′′ = δa; δb where δa is an arbi-trary deterministic program. Then by definition of Recovery there exists a(unique) situation s′′ such that Do(δa, s′, s′′). Now consider that s′′ as the forms′′ = do(an, do(an−1, . . . , do(a2, do(a1, s

′)) . . .)). Let us consider the linear pro-gram p = (a1; a2; . . . ; an). Obviously we have Do(p, s′, s′′). Hence the processδ′′ = p; δb is a recovery process according to the definition of Recovery.

The nice feature of Recovery is that it asks to search for a linear programthat achieves a certain formula, namely SameState(s′, s′′). That is we havereduced the synthesis of a recovery program to a classical Planning problem inAI [15]. As a result we can adopt a well-developed literature about planning forour aim. In particular, if the services and input and output parameters are finite,then the recovery can be reduced to propositional planning, which is known tobe decidable in general (for which very well performing software tools exists).

Theorem 3. Let assume a domain in which services and input and output pa-rameters are finite. Then given a process δ′ and situations s′ and s′′, it is decid-able to compute a recovery process δ′′ such that Recovery(δ′, s′, s′′, δ′′) holds.

Proof. In domains in which services and input and output parameters are finite,also actions and fluents instantiated with all possible parameters are finite. Hencewe can phrase the domain as a propositional one and the thesis follows fromdecidability of propositional planning [15].

Example 1 (cont.). In the running example, consider the case in which theprocess is between the lines 11 and 12 in the execution of the procedure in-vocation EvalTake(LocA, Q A, F A). Now, let us assume that the node a1 isassigned the task TakePhoto. But it is moving to a location such that it isnot connected to the coordinator anymore; the monitor sees that it is gettingout of reach and generates a spurious (not inside the original process) ac-tion Stop(a 1, Go, RealPosition), where RealPosition is the actual position assensed by the monitor. Since RealPosition is not LocA, adaptation is needed;the Monitor generates the recovery program δa; δb where δb is the original onefrom line 11 and δa is as follows:

Start(a 3, Go, NewLocation);Stop(a 3, Go, NewLocation);Start(a 1, Go, LocA)

Table 2. Comparison of process adaptation approaches present in literature.

where NewLocation is within the radio-range of RealPosition4.

7 Related Works

Adaptation in PMSs can be considered at two level: at the process schema orat the process instance level [16]. Process schema changes become necessary,for example, to adapt the PMS to optimized business processes or to new laws[17–19]. In particular, applications supporting long-running processes (e.g., han-dling of mortgage or medical treatments) and the process instances controlled bythem are affected by such changes. As opposed to this, changes of single processinstances (e.g., to insert, delete, or shift single process steps) often have to becarried out in an ad-hoc manner in order to deal with an exceptional situation,e.g., peer disconnection in mobile networks [3], or evolving process requirements[20].

Table 2 shows a comparison of PMSs approaches supporting changes. Thecolumns show the adaptation features addressed by existing PMSs. The secondcolumn illustrates which softwares support adaptation at schema level. As wecan see, all analyzed softwares support it. The other three columns show thesupport for adaptation of single instances. The “Pre-Planned” PMSs refer tothose systems that enable to specify adaptation rules to handle a set of excep-tional (but foreseen) events. Conversely, the “Ad-hoc” support means PMSs tobe able to adapt when unforeseen events fire. Ad-hoc adaptation of a processinstance can be performed by the responsible person who manually changes thestructure or, automatically, by the PMS.

4 Observe that if the positions are discretized, so as to become finite, this recoverycan be achieved by a propositional planner.

We note that there is no row having value “yes” in the column Ad-hoc/Automatic. That means that no considered approach allows users to man-age unforeseen exceptions in a fully automatic way. Actually, only few systems(AgentWork[21], DYNAMITE[22], EPOS[23] and WIDE[24]) support automatedprocess instance changes, but only in pre-planned way.

The work [25] is one of the few coping with exogenous events in the field of theWeb service composition. This work considers the issue of long term optimalityof the adaptation but, anyway, it does not manage unforeseen events. Moreover,it does require the definition of the probability according to which each of suchevents fires.

We underline that our approach is not another way to capture expectedexceptions. Other approaches rely on rules to define the behaviors when specialevents are triggered. Here we simply model (a subset of) the running environmentand the actions’ effects, without considering possible special exceptional events.We argue that in some cases modeling the environment, even in detail, is easierthan modeling all possible exceptions.

8 Conclusion

In this paper, we have presented a general approach, based on execution moni-toring, for automatic process adaptation in dynamic scenarios. Such an approachis (i) practical, by relying on well-established planning techniques, and (ii) doesnot require the definition of the adaptation strategy in the process itself (as mostof the current approaches do). We have proved the correctness and completenessof the approach, and we have shown its applicability to a running example stem-ming from a real project. Future works include to actually develop the AdaptiveProcess Management System. This will be done by using the IndiGolog moduledeveloped by the Cognitive Robotics Group of the Toronto University.

Acknowledgements. This work has been supported by the European Commissionthrough the project FP6-2005-IST-5-034749 WORKPAD.

References

1. Leymann, F., Roller, D.: Production Workflow: Concepts and Techniques. PrenticeHall PTR (1999)

2. van der Aalst, W., van Hee, K.: Workflow Management. Models, Methods, andSystems. MIT Press (2004)

3. de Leoni, M., Mecella, M., Russo, R.: A Bayesian Approach for DisconnectionManagement in Mobile Ad-hoc Networks. In: Proc. 4th International Workshopon Interdisciplinary Aspects of Coordination Applied to Pervasive Environments:Models and Applications (CoMA) (at WETICE 2007). (2007)

4. de Leoni, M., De Rosa, F., Mecella, M.: MOBIDIS: A Pervasive Architecture forEmergency Management. In: Proc. 4th International Workshop on Distributedand Mobile Collaboration (DMC 2006) (at WETICE 2006). (2006)

5. Catarci, T., De Rosa, F., de Leoni, M., Mecella, M., Angelaccio, M., Dustdar,S., Krek, A., Vetere, G., Zalis, Z.M., Gonzalvez, B., Iiritano, G.: WORKPAD:

2-Layered Peer-to-Peer for Emergency Management through Adaptive Processes.In: Proc. 2nd International Conference on Collaborative Computing: Networking,Applications and Worksharing (CollaborateCom 2006). (2006)

6. de Leoni, M., De Rosa, F., Marrella, A., Poggi, A., Krek, A., Manti, F.: Emer-gency Management: from User Requirements to a Flexible P2P Architecture. In:Proc. 4th International Conference on Information Systems for Crisis Responseand Management (ISCRAM 2007). (2007)

7. De Giacomo, G., Reiter, R., Soutchanski, M.: Execution monitoring of high-levelrobot programs. In: KR. (1998) 453–465

8. Reiter, R.: Knowledge in Action: Logical Foundations for Specifying and Imple-menting Dynamical Systems. MIT Press (2001)

9. J. Levesque, H., Reiter, R., Lesperance, Y., Lin, F., Scherl, R.B.: Golog: A logicprogramming language for dynamic domains. J. Log. Program. 31 (1997) 59–83

10. De Giacomo, G., Lesperance, Y., J. Levesque, H.: Congolog, a concurrent program-ming language based on the situation calculus. Artif. Intell. 121 (2000) 109–169

11. Kiepuszewski, B., ter Hofstede, A.H.M., Bussler, C.: On structured workflow mod-elling. In: CAiSE. (2000) 431–445

12. Lesperance, Y., Ng, H.: Integrating planning into reactive high-level robot pro-grams (2000)

13. Milner, R.: A Calculus of Communicating Systems. Springer (1980)14. Hidders, J., Dumas, M., van der Aalst, W.M.P., ter Hofstede, A., Verelst, J.: When

are two workflows the same? In: CATS. (2005) 3–1115. Ghallab, M., Nau, D., Traverso, P.: Automated Planning: Theory and Practice.

Morgan Kaufmann (2004)16. Weber, M., Illmann, T., Schmidt, A.: Webflow: Decentralized workflow manage-

ment in the world wide web. In: Proc. of the Intermational Conf. on AppliedInformatics (AI’98). (1998)

17. Reichert, M., Rinderle, S., Dadam, P.: On the common support of workflow typeand instance changes under correctness constraints. In: Proc. of the InternationalConf. on Cooperative Information Systems (CoopIS’03). (2003)

18. Rinderle, S., Reichert, M., Dadam, P.: Correctness criteria for dynamic changes inworkflow systems - a survey. Data and Knowledge Engineering 50 (2004) 9–34

19. van der Aalst, W., Basten, T.: Inheritance of Workflows: an approach to tack-ling problems related to change. Theoretical Computer Science, Elsevier SciencePublishers 270 (2002) 125–203

20. Reichert, M., Dadam, P.: ADEPTflex supporting dynamic changes of workflowswithout losing control. Journal of Intelligent Information Systems 10 (1998) 93–129

21. Muller, R., Greiner, U., Rahm, E.: AGENTWORK: A Workflow-System Support-ing Rule-Based Workflow Adaptation. Data and Knowledge Engineering 51(2)(2004) 223–256

22. Heimann, P., Joeris, G., Krapp, C., Westfechtel, B.: DYNAMITE: dynamic tasknets for software process management. In: Proc. of the 18th International Confer-ence Software Engineering (ICSE). (Berlin, 1996) 331–341

23. Liu, C., Conradi, R.: Automatic replanning of task networks for process modelevolution. In: Proc. of the European Software Engineers Conference. (Garmisch-Partenkirchen, Germany, 1993) 434–450

24. Ceri, S., Paul, Sanchez, G.: Wide: A distributed architecture for workflow man-agement. In: 7th International Workshop on Research Issues in Data Engineering(RIDE). (1997)

25. Verma, K., Doshi, P., Gomadam, K., Miller, J., , Sheth, A.: Optimal adapta-tion in web processes with coordination constraints. In: The IEEE InternationalConference on Web Services (ICWS’06). (2006)