Adaptive Process Management in Highly Dynamic and Pervasive Scenarios
MM.H. ter Beek (Ed.): Young Researchers Workshopon Service-Oriented Computing 2009 (YR-SOC’09).EPTCS 2, 2009, pp. 83–97, doi:10.4204/EPTCS.2.7 c (cid:13)
M. de LeoniThis work is licensed under the Creative CommonsAttribution-Noncommercial-No Derivative Works License.
Adaptive Process Management in Highly Dynamic andPervasive Scenarios
Massimiliano de Leoni
Dipartimento di Informatica e SistemisticaSAPIENZA – Universit`a di Roma [email protected]
Process Management Systems (PMSs) are currently more and more used as a supporting tool forcooperative processes in pervasive and highly dynamic situations, such as emergency situations, per-vasive healthcare or domotics/home automation. But in all such situations, designed processes canbe easily invalidated since the execution environment may change continuously due to frequent un-foreseeable events. This paper aims at illustrating the theoretical framework and the concrete imple-mentation of
SmartPM , a PMS that features a set of sound and complete techniques to automaticallycope with unplanned exceptions. PMS
SmartPM is based on a general framework which adopts theSituation Calculus and
IndiGolog . Nowadays organisations are always trying to improve the performance of the processes they are part of.It does not matter whether such organisations are dealing with classical static business domains, such asloans, bank accounts or insurances, or with pervasive and highly dynamic scenarios. The demands arealways the same: seeking more efficiency for their processes to reduce the time and the cost for theirexecution.According to the definition given by the Workflow Management Coalition, a workflow is “the com-puterised facilitation of automation of a business process, in whole or part”. The Workflow ManagementCoalition defines a Workflow Management System as “a system that completely defines, manages andexecutes workflows through the execution of software whose order of execution is driven by a computerrepresentation of the workflow logic”. Workflow Management Systems (WfMSs) are also known as Pro-cess Management Systems (PMSs), and we are going to use both of them interchangeably throughout thisthesis. Accordingly, this thesis uses many times word “process” is place of word “workflow”, althoughthe original acceptation of the former is not intrinsically referring to its computerised automation.In this paper we turn our attention to highly dynamic and pervasive scenarios. Pervasive scenarioscomprise, for instance, emergency management, health care or home automation (a.k.a. domotics). All ofthese scenarios are characterised as being very dynamic and turbulent and subject to an higher frequencyof unexpected contingencies with respect to classical scenarios. Therefore, PMSs for pervasive scenariosshould provide a higher degree of operational flexibility/adaptability.According to Andresen and Gronau [1] adaptability can be seen as an ability to change something tofit to occurring changes. Adaptability is to be understood here as the ability of a PMS to adapt/modifyprocesses efficiently and fast to change circumstances. Adaptation aims at reducing the gap of the virtualreality , the (idealized) model of reality that is used by the PMS to deliberate, from the physical reality , thereal world with the actual values of conditions and outcomes [2]. Exogenous events may make deviate http://wfmc.org Product Manual Pre-planned Unplanned
YAWL X COSA
X X
Tibco
X X
WebSphere
X X
SAP
X X
OPERA
X X
ADEPT2 X ADOME X AgentWork X the virtual reality from the physical reality. The reduction of this gap requires sufficient knowledge ofboth kinds of realities (virtual and physical). Such knowledge, harvested by the services performing theprocess tasks, would allow the PMS to sense deviations and to deal with their mitigation.In pervasive settings, efficiency and effectiveness when carrying on processes are a strong require-ment. For instance, in emergency management saving minutes could result in saving injured people,preventing buildings from collapses, and so on. Or, pervasive health-care processes can cause people’spermanent diseases when not executed by given deadlines. In order to improve effectiveness of pro-cess execution, adaptation ought to be as automatic as possible and to require minimum manual humanintervention. Indeed, human intervention would cause delays, which might not be acceptable.In theory there are three possibilities to deal with deviations:1. Ignoring deviations – this is, of course, not feasible in general, since the new situation might besuch that the PMS is no more able to carry out the process instance.2. Anticipating all possible discrepancies – the idea is to include in the process schema the actionsto cope with each of such failures. This can be seen as a try-catch approach, used in someprogramming languages such as Java. The process is defined as if exogenous actions cannot occur,that is everything runs fine (the try block). Then, for each possible exogenous event, a catch block is designed in which the method is given to handle the corresponding exogenous event. Forsimple and mainly static processes, this is feasible and valuable; but, especially in mobile andhighly dynamic scenarios, it is quite impossible to take into account all exception cases.3. Devising a general recovery method able to handle any kind of exogenous events – consideringagain the metaphor of try/catch, there exists just one catch block, able to handle any exogenousevents, included the unexpected. The catch block activates the general recovery method to modifythe old process P in a process P ′ so that P ′ can terminate in the new environment and its goals areincluded in those of P . This approach relies on the execution monitor (i.e., the module intended forexecution monitoring) that detects discrepancies leading the process instance not to be terminable.When they are sensed, the control flow moves to the catch block. An important challenge here isto build the monitor which is able to identify which exogenous events are relevant, i.e. that makeimpossible process to terminate, as well as to automatically synthesize P ′ during the executionitself.Table 1 shows the adaptability features of the most valuable PMSs according to the state-of-art anal-ysis described in [11]. Column Manual refers to the possibility of a responsible person who manuallychanges the process schema to deal with exogenous events. Column
Pre-planned concerns the feature.deLeoni 85of defining policies to specify the adaptation behaviour to manage some exogenous events, whose pos-sible occurrence is foreseeable a priori. The last column
Unplanned refers to the third approach in theclassification above.The third approach seems to be the most appropriate when dealing with scenarios where (i) thefrequency of unexpected exogenous events are relatively high and (ii) there are several exogenous eventsthat cannot be foreseen before their actual occurrence. Unfortunately, as the table shows, the worldleading PMSs are unable to feature the third approach.This paper describes
SmartPM , a PMS that features some sound and complete techniques accordingto the third approach described above. Such techniques are meant to improve the degree of automatic adaptation to react to very frequent changes in the execution environment and fit processes accordingly.The techniques proposed here are based on Situation Calculus [13] and automatic planning, conceivedto coordinate robots and intelligent agents. The concrete implementation, namely
SmartPM , is based onthe
IndiGolog interpreter developed at University of Toronto and RMIT University, Melbourne.In
SmartPM , every entity performing task is generally named “service”. A service may be a humanactor/process participant as well as an automatic service that execute a certain job (e.g., a SOAP-basedWeb Service).Let us consider a scenario for emergency management where processes show typical a complexitythat is comparable to business settings. Therefore, the usage of PMS is valuable to coordinate the ac-tivities of emergency operators. In these scenarios, operators are typically equipped with low-profiledevices, such as PDAs, which several services are installed on. Such services may range from usualGUI-based applications to automatic ones. For instances, some applications can be installed to fill ques-tionnaires or take pictures. In addition, PDAs can be provided with some automatic services that connectto the Civil Protection headquarters to retrieve information for the assessment of the affected area andpossibly send back the data collected.PDAs communicate with each other by Mobile Ad-hoc Networks (
MANET s), which are Wi-Fi net-works that do not rely on a fixed infrastructure, such as Access Points. Devices can be the final recipientsof some packets sent by other devices as well as they can act as relays and forward packets towards thefinal destination.In order to orchestrate the services installed on operator devices, such devices need to be continuallyconnected to the PMS through a loose connection: devices and the PMS can communicate if there existsa path of nodes that connects them in the graph of the communication links.In the virtual reality, devices are supposed to be continuously connected (i.e., a path always existsbetween pairs of nodes). But in this physical reality continuous connections cannot be guaranteed: theenvironment is highly dynamic and the movement of nodes (that is, devices and related operators) withinthe affected area, while carrying out assigned tasks, can cause disconnections and make deviate the tworeality. Disconnections results in the unavailability of nodes and, hence, the services provided. From thecollection of actual user requirements [6], it results that typical teams are formed by a few nodes (lessthan 10 units), and therefore frequently a simple task reassignment is not feasible. Indeed, there may notbe two “similar” services available to perform a given task. Reordering task executions would not solvethe problem, either. There is no guarantee that eventually those services that provide unique capabilityconnect again to the PMS.So, adaptaption is needed: adaptability might consist in this case to recover the disconnection of anode X, and that can be achieved by assigning a task “Follow X” to another node Y in order to maintainthe connection. When the connection has been restored, the process can progress again.6 Adaptive PMin Highly Dynamic and Pervasive ScenariosTable 2:
IndiGolog constructs.
Construct Meaning Platform Statement a A primitive action a f ? Wait while the f condition is false ?(phi) ( d ; d ) Sequence of two sub-programs d and d [delta1,delta2] proc P ( −→ v ) d Invocation of a procedure passing a vector −→ v of parame-ters proc(P,delta) ( f ; d ) | ( ¬ f ; d ) Exclusive choice between d and d according to the con-dition f ndet([?(phi);delta1],[?(neg(phi)),delta2]) while f do d Iterative invocation of d while(phi,delta) ( d k d ) Concurrent execution rrobin(delta1,delta2) d ∗ Indeterministic iteration of program execution (The plat-form statement limits the maximum iterations number to n ) star(delta,n) S ( d ) Emulating off-line execution searchn(delta,n) p a . d Indeterministic choice of argument a followed by the ex-ecution of d pi(a,delta) In this section we introduce the Situation Calculus, which we use to formalize
SmartPM and its adap-tation features. The Situation Calculus [13] is a second-order logic targeted specifically for representinga dynamically changing domain of interest (the world). All changes in the world are obtained as resultof actions . A possible history of the actions is represented by a situation , which is a first-order termdenoting the current situation of the world. The constant s denotes the initial situation. A special bi-nary function symbol do ( a , s ) denotes the next situation after performing the action a in the situation s .Action may be parameterized.Properties that hold in a situation are called fluents . These are predicates taking a situation term astheir last argument. For instance, we could define the fluent f ree ( x , s ) stating whether the object x is freein situation s , meaning no object is located on x in situation s .Changes in fluents (resulting from executing actions) are specified through successor state axioms .In particular for each fluent F we have a successor state axioms as follows: F ( −→ x , do ( a , s )) ⇔ F F ( −→ x , do ( a , s ) , s ) where F F ( −→ x , do ( a , s ) , s ) is a formula with free variables −→ x , a is an action, and s is a situation.In order to control the executions of actions we make use of high level programs expressed in In-diGolog [14], which is equipped with primitives for expressing concurrency. Table 2 summarizes the con-structs of
IndiGolog used in this work. Basically, these constructs allow to define every well-structuredprocess as defined in [7]. The last table column shows the corresponding statement defined in the
In-diGolog platform developed at University of Toronto and RMIT University. From the formal point of view,
IndiGolog programs are terms. The execution of
ConGolog programsis expressed through a transition semantic based on single steps of execution. At each step a programexecutes an action and evolves to a new program which represents what remains to be executed of theoriginal program. Formally two predicates are introduced to specify such a sematic: Downloadable at .deLeoni 87Figure 1: Execution Monitoring. • Trans ( d ′ , s ′ , d ′′ , s ′′ ) , given a program d ′ and a situation s ′ , returns (i) a new situation s ′′ resultingfrom executing a single step of d ′ , and (ii) d ′′ which is the remaining program to be executed. • Final ( d ′ , s ′ ) returns true when the program d ′ can be considered successfully completed in situa-tion s ′ .By using Trans and
Final we can define a predicate Do ( d ′ , s ′ , s ′′ ) that represent successful completeexecutions of a program d ′ in a situation s ′ , where s ′′ is the situation at the end of the execution of d ′ .Formally: Do ( d ′ , s ′ , s ′′ ) ⇔ ∃ d ′′ . Trans ∗ ( d ′ , s ′ , d ′′ , s ′′ ) ∧ Final ( d ′′ , s ′′ ) where Trans ∗ is the definition of the reflective and transitive closure of Trans .To cope with the impossibility of backtracking actions executed in the real world,
IndiGolog incorpo-rates a new programming construct, namely the search operator . Let d be any IndiGolog program, whichprovides different alternative executable actions. When the interpreter encounters program S ( d ) , beforechoosing among alternative executable actions of d and possible picks of variable values, it performsreasoning in order to decide for a step which still allows the rest of d to terminate successfully. If d isthe entire program under consideration, S ( d ) emulates complete off-line execution. The general framework which we shall introduce in this paper is based on the execution monitoring scheme as described in [2] for situation calculus agents. As we will later describe in more details, whenusing
IndiGolog for process management, we take tasks to be predefined sequences of actions (see later)and processes to be
IndiGolog programs. After each action, the PMS may need to align the internal worldrepresentation (i.e., the virtual reality) with the external one (i.e., the physical reality).Before a process starts, PMS takes the initial context from the real environment and builds the cor-responding initial situation S , by means of first-order logic formulas. It also builds the program d corresponding to the process to be carried on. Then, at each execution step, PMS, which has a completeknowledge of the internal world (i.e., its virtual reality), assigns a task to a service. The only “assignable”8 Adaptive PMin Highly Dynamic and Pervasive Scenariostasks are those whose preconditions are fulfilled. A service can collect data required needed to executethe task assigned from PMS. When a service finishes executing a task, it alerts PMS of that.The execution of the PMS can be interrupted by the monitor module when a misalignment betweenthe virtual and the physical realities is discovered. In that case, the monitor adapts the (current) programto deal with such discrepancy.In Figure 1, the overall framework is depicted. At each step, the PMS advances the process d insituation s by executing an action, resulting then in a new situation s ′ with the process d ′ remaining to beexecuted. Both s ′ and d ′ are given as input to the monitor, which also collects data from the environmentthrough sensors . If a discrepancy between the virtual reality as represented by s ′ and the physical realityis sensed, then the monitor changes s ′ to s ′′ , by generating a sequence of actions that explains the changesperceived in the environment, thus re-aligning the virtual and physical realities. Notice, however, thatthe process d ′ may fail to execute successfully (i.e., assign all tasks as required) in the new (unexpected)situation s ′′ . If so, the monitor adapts also the (current) process by performing suitable recovery changesand generating then a new process d ′′ . At this point, the PMS is resumed and the execution continueswith program-process d ′′ in situation s ′′ . Next we detail the general framework proposed above by using Situation Calculus and
IndiGolog . Weuse some domain-independent predicates to denote the 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 In the light of these predicates, we have defined a shortcut to refer to the capability of a certain service a to perform a list of tasks, a.k.a. worklist. Service a can execute a certain worklist wrkList iif a providesall capabilities required by all tasks in the worklist: Capable ( a , wrklist ) ⇔ (cid:0) ∀ b , t . t ∈ wrkList ∧ require ( b , t ) ⇒ provide ( a , b ) (cid:1) Every task execution is the sequence of four PMS actions: (i) the assignment of the task to a service,resulting in the service being not free anymore; (ii) the notification to the service to start executingthe task. Then, the service carries out the tasks and, after receiving the service notification of the taskconclusion, (iii) the PMS acknowledges the successful task termination. Finally, (iv) the PMS releasesthe service, which becomes free again. We formalise these four actions as follows: • Assign ( a , x ) : task x is assigned to a service a • Start ( a , x , p ) : service a is allowed to start the execution of task x . The input provided is p . • AckTaskCompletion ( a , x ) : service a concluded successfully the executing of x . Here, we refer as sensors not only proper sensors (e.g., the ones deployed in sensor networks), but also any softwareor hardware component enabling to retrieve contextual information. For instance, it may range from GIS clients to specifichardware that makes available the communication distance of a device to its neighbors. [10] .deLeoni 89 • Release ( a , x ) : the service a is released with respect to task x .In addition, services can execute two actions: • readyToStart ( a , x ) : service a declares to be ready to start performing task x • f inishedTask ( a , x , q ) : service a declares to have completed executing task x returning output q .The terms p and q denote arbitrary sets of input/output, which depend on the specific task. Specialconstant /0 denotes empty input or output.The interleaving of actions performed by the PMS and services is as follows. After the assign-ment of a certain task x by Assign ( a , x ) , when the service a is ready to start executing, it executesaction readyToStartTask ( a , x ) . At this stage, PMS executes action Start ( a , x , p ) , after which a startsexecuting task x . When a completes task x , it executes the action f inishedTask ( a , x , q ) . Specifically,we envision that actions f inishedTask ( · ) are those in charge of changing properties of world as re-sult of executing tasks. When x is completed, PMS is allowed in any moment to execute sequentially AckTaskCompletion ( a , x ) and Release ( a , x ) . The program coding the process will the executed by onlyone actor, specifically the PMS. Therefore, actions readyToStartTask ( · ) and f inishedTask ( · ) are con-sidered as external and, hence, not coded in the program itself.For each specific domain, we have several fluents representing the properties of situations. Someof them are modelled independently of the domain whereas others, the majority, are defined accordingto the domain. If they are independent of the domain, they can be always formulated as defined in thischapter. Among the domain-independent ones, we have fluent f ree ( a , s ) , that denotes the fact that theservice a is free, i.e., no task has been assigned to it, in the situation s . The corresponding successor stateaxiom is as follows: f ree ( a , do ( t , s )) ⇔ (cid:0) ∀ x . t = Assign ( a , x ) ∧ f ree ( a , s ) (cid:1) ∨ (cid:0) ¬ f ree ( a , s ) ∧ ∃ x . t = Release ( a , x ) (cid:1) (1)This says that a service a is considered free in the current situation if and only if a was free in the previoussituation and no tasks have been just assigned to it, or a was not free and it has been just released. Thereexists also the domain-independent fluent enabled ( x , a , s ) which aims at representing whether service a has notified to be ready to execute a certain task x so as to enabled it. The corresponding successor-stateaxiom: enabled ( x , a , do ( t , s )) ⇔ (cid:0) enabled ( x , a , s ) ∧ ∀ q . t = f inishedTask ( a , x , q ) (cid:1) ∨ (cid:0) ¬ enabled ( x , a , s ) ∧ t = readyToStartTask ( a , x ) (cid:1) (2)This says that enabled ( x , a , s ) holds in the current situation if and only if it held in the previous oneand no action f inishedTask ( a , x , q ) has been performed or it was false in the previous situation and readyToStartTask ( a , x ) has been executed. This fluent aims at enforcing the constraints that the PMS canexecute Start ( a , x , p ) only after a performed begun ( a , x ) and it can execute AckTaskCompletion ( a , x , q ) only after f inishedTask ( a , x , q ) . This can represented by two pre-conditions on actions Start ( · ) and AckTaskCompletion ( · ) : ∀ p . Poss ( Start ( a , x , p ) , s ) ⇔ enabled ( x , a , s ) ∀ p . Poss ( AckTaskCompletion ( x , a ) , s ) ⇔ ¬ enabled ( x , a , s ) (3)provided that AckTaskCompletion ( x , a ) never comes before Start ( x , a , p ) , s .0 Adaptive PMin Highly Dynamic and Pervasive Scenarios IndiGolog Engine
Execute the sense-think-act loop
Communication Manager
Manage the communication with each Device Manager
SPIDEProcess DesignerDevice 1Device 2 ...
Device N Transition System
Compute the evolution of high-level programs
Temporal Projector
Handle the current situation and fluent values
Domain Programs
Encode the IndiGolog program representing a businnes process
Domain Axioms
Encode the action theory for the current programProcess.pl
PMS architectureEnvironment & Services XML to IndiGolog Parser
Translate the Activity Diagram in a format readable by PMS
Device Manager
Device Manager
Device Manager ...
Execution Monitor
Tackle adaptivity
XML
Figure 2: Architecture of the PMS.Furthermore, we introduce a domain-independent fluent started ( x , a , p , s ) that holds if and only if anaction Start ( a , x , p ) has been executed but the dual AckTaskCompletion ( x , a ) has not yet: started ( a , x , p , do ( t , s )) ⇔ (cid:0) started ( a , x , p , s ) ∧ t = Stop ( a , x ) (cid:1) ∨ (cid:0) ∄ p ′ . started ( x , a , p ′ , s ) ∧ t = Start ( a , x , p ) (cid:1) (4)In addition, we make use, in every specific domain, of a predicate available ( a , s ) which denoteswhether a service a is available in situation s for tasks assignment. However, available is domain-dependent and, hence, requires to be defined specifically for every domain. Knowing whether a serviceis available is very important for the PMS when it has to perform assignments. Indeed, a task x is assignedto the best service a which is available and provides every capability required by x . The fact that a certainservice a is free does not imply it can be assigned to tasks (e.g., in the example described above it hasto be free as well as it has to be indirectly connected to the coordinator). The definition of available ( · ) must enforce the following condition: ∀ a s . available ( a , s ) ⇒ f ree ( a , s ) (5)We do not give explicitly pre-conditions to task. We assume tasks can always be executed. Weassume that, given a task, if some conditions do not hold, then the outcomes of that tasks are not asexpected (in other terms, it fails). SmartPM
System
This section aims at describing the internal structure of PMS. Figure 2 shows its conceptual architecture.At the beginning, a responsible person designs an Activity Diagram through SPIDE, a
Process Designer
Graphical tool with which
SmartPM is equipped. Later, Such a tool translates the Activity Diagram in aXML format file. Then, such a XML file is loaded into PMS. The
XML-to-
IndiGolog
Parser componenttranslates this specification in a
Domain Program , the
IndiGolog program corresponding to the designed.deLeoni 91process, and a set of
Domain Axioms , which is the action theory that comprises the initial situation, theset of available actions with their pre- and post-conditions.When the program is translated in the Domain Program and Axioms, a component named
Commu-nication Manager (CM) starts up all of device managers , which are basically some drivers for makingcommunicate PMS with the services and sensors installed on devices. For each real world device PMSholds a device manager. Each device manager is also intended for notifying the associated device aboutevery action performed by the
SmartPM engine as well as for notifying the
SmartPM engine about theactions executed by the services of the associated device.After this initialization process, CM activates the
IndiGolog
Engine , which is in charge of executing
IndiGolog programs. Then, CM enters into a passive mode where it is listening for messages arrivingfrom the devices through the device managers. In general, a message can be a exogenous event harvestedby a certain sensor installed on a given device as well as a message notifying the start or completion of acertain task. When CM judges a message as significant, it forwards it to
IndiGolog . For instance, relevantmessages may be signals of the task completion or the sudden unavailability of a given device.In sum, CM is responsible of deciding which device should perform certain actions, instructing theappropriate device managers to communicate with the device services and collecting the correspondingsensing outcome. The
IndiGolog
Engine is intended to execute a sense-think-act interleaved loop [8].The cycle repeats at all times the following three steps:1. check for exogenous events that have occurred;2. calculate the next program step; and3. if the step involves an action, execute the action, instructing the Communication Manager.The
IndiGolog
Engine relies on two further modules named
Transition System and
Temporal Projec-tor . The former is used to compute the evolution of
IndiGolog programs according to the statements’semantic, whereas the latter is in charge of holding the current situations throughout the execution aswell as letting evaluate the fluent values for taking the right decision of the actions to perform.The last module that is worth mentioning is the
Execution Monitor (MON), which get notificationsof exogenous events from the Communication Manager. It decides whether adaptation is needed andadapts accordingly the process. Section 7.2 gives some additional details of the concrete implementationof monitoring and adaptation.
We turn to describe the approach by an example concerning emergency management in an area affectedby an earthquake. The emergency response process in question comprises various activities that mayneed to be adapted on-the-fly to react to unexpected exogenous events that could arise during the op-eration. Figure 3 depicts an Activity Diagram of a process consisting of two concurrent branches; thefinal task is send data and can only be executed after the branches have successfully completed. Theleft branch, abstracted out from the diagram, is built from several concurrent processes involving tasks rescue , evacuation and others. The right branch begins with the concurrent execution of three sequencesof tasks: go , photo , and survey . When all survey tasks have been completed, the task evaluate pictures is executed. Then, a condition is evaluated on the resulting state at a decision point (i.e., whether thepictures taken are of sufficient quality). If the condition holds, the right branch is considered finished;otherwise, the whole branch should be repeated.2 Adaptive PMin Highly Dynamic and Pervasive ScenariosFigure 3: An activity diagram of a process concerning emergency management.Figure 4 shows some parts of the IndiGolog program representing the process of the example. Thecode proposes here has been slightly simplified and abstracted for the sake of brevity. The main pro-cedure, called main , involves three interrupts running at different priorities. The first highest priorityinterrupt fires when an exogenous event occurs (i.e., condition exogEvent is true). In such a case, the monitor procedure is executed, evaluating whether or not adaptation is required (see Section 7.2).If no exogenous event has occurred, the second interrupt triggers and execution of the actual emer-gency response process is attempted. Procedure process , also shown in the figure, encodes the ActivityDiagram of the example process. It relies, in turn, on procedure manageTasks(WrkLists) , where
WrkLists is a sequence of elements workitem(T,I,D) , each one representing a task T , with identifier I , and input data D , which needs to be performed. This procedure is meant to manage the execution ofall tasks in the worklist, and it assigns them all to a single service that provides every capability required.Of course, to assign tasks to an service, SmartPM needs to reason about the available ones, theircurrent state (e.g., their location), and their capabilities, as not every service is capable of performingany task. In fact, before assigning the first task in any task list, procedure manageTasks(WrkLists) executes a pick operation is done to choose a Service srvc that is involved in no task execution (i.e.,.deLeoni 93 proc(main,prioritized_interrupts([interrupt(exogEvent, monitor),interrupt(true, process),interrupt(neg(finished), wait)])).proc(process, [rrobin(processRescue,while(or(noPhotos<7,neg(goodPics)),[rrobin([manageTasks([workitem((go,id19,loc(5,5)),workitem((photo,id20,loc(5,5)),workitem((survey,id21,loc(5,5))]),manageTasks([workitem((go,id19,loc(15,15)),workitem((photo,id20,loc(15,15)),workitem((survey,id21,loc(15,15))]),manageTasks([workitem((go,id19,loc(50,50)),workitem((photo,id20,loc(50,50)),workitem((survey,id21,loc(50,50))]),]),manageTasks([workitem((evalPics,id28,input)])]) % end of while), % end concurrent subprocessesmanageTasks([workitem((sendData,id29,input)])]).proc(manageTasks(WrkList),pi(srvc,[?(and(Available(srvc),Capable(srvc,WrkList))),manageExecution(WrkList,srvc),])).proc(manageExecution([],Srvc),[]).proc(manageExecution([workitem(Task,Id,I)|TAIL],Srvc),[assign(Task,Id,Srvc,I),start(Task,Id,Srvc,I),ackTaskCompletion(Task,Id,Srvc),release(Task,Id,Srvc,I),manageExecution(TAIL,Srvc)])
Figure 4: An example of process management with
IndiGolog .fluent
Free(actr) holds) and able to execute the whole worklist.Once a suitable service has been chosen, PMS assigns the list of tasks to it by executing assign(srvc,WrkList) . In addition to inform the service about the task assignment, such an actionturns fluent
Free(actr) to false.Then, PMS calls procedure manageExecution(WrkList) , which handles the execution of each taskin the list. For each task T in the list (with identifier I and input data D ), the procedure invokes action start(T,D,I,srvc) that provides the required information to the chosen service srvc . In this way, theservice is instructed to begin working on the task and receives the required input. When a service finishesexecuting an assigned task, it alerts SmartPM via action finishedTask(T,srvc) ; PMS acknowledgesby performing ackTaskCompletion (T,D,actr) . When the whole work-item list is execution, thePMS releases the service by executing the action release(T,D,actr) , after which fluent
Free(srvc) is turned to true again.4 Adaptive PMin Highly Dynamic and Pervasive ScenariosIt is worth mentioning that, if the process being carried out cannot execute temporarily further, thelowest priority interrupt fires. This interrupt makes PMS wait for the conditions in which some taskscan be executed. The fact that the process gets stuck does not imply necessarily the occurrence of somerelevant exogenous events. It could be also caused by the fact that next tasks can be only assignedto services that are currently busy busy performing other tasks. The latter situation does not preventprocesses from being completed successfully; indeed, such services will be eventually free to work onthose tasks.
SmartPM
Next we formalize how the monitor works. Intuitively, the monitor takes the current program d ′ andthe current situation s ′ from the PMS’s virtual reality and, analyzing the physical reality by sensors,introduces fake actions in order to get a new situation s ′′ which aligns the virtual reality of the PMSwith sensed information. Then, it analyzes whether d ′ can still be executed in s ′′ , and if not, it adapts d ′ by generating a new correctly executable program d ′′ . Specifically, the monitor work can be abstractlydefined as follows (we do not model how the situation s ′′ is generated from the sensed information): Monitor ( d ′ , s ′ , s ′′ , d ′′ ) ⇔ (cid:0) Relevant ( d ′ , s ′ , s ′′ ) ∧ Recovery ( d ′ , s ′ , s ′′ , d ′′ ) (cid:1) ∨ (cid:0) ¬ Relevant ( d ′ , s ′ , s ′′ ) ∧ d ′′ = d ′ (cid:1) (6)where: (i) Relevant ( d ′ , s ′ , s ′′ ) states whether the change from the situation s ′ into s ′′ is such that d ′ cannotbe correctly executed anymore; and (ii) Recovery ( d ′ , s ′ , s ′′ , d ′′ ) is intended to hold whenever the program d ′ , to be originally executed in situation s ′ , is adapted to d ′′ in order to be executed in situation s ′′ .Formally Relevant is defined as follows:
Relevant ( d ′ , s ′ , s ′′ ) ⇔ ¬ SameCon f ig ( d ′ , s ′ , d ′ , s ′′ ) where SameCon f ig ( d ′ , s ′ , d ′′ , s ′′ ) is true if executing d ′ in s ′ is “equivalent” to executing d ′′ in s ′′ (seelater for further details).In this general framework we do not give a definition for SameCon f ig ( d ′ , s ′ , d ′′ , s ′′ ) . However weconsider any definition for SameCon f ig to be correct if it denotes a bisimulation [12]. Formally, forevery d ′ , s ′ , d ′′ , s ′′ holds:1. Final ( d ′ , s ′ ) ⇔ Final ( d ′′ , s ′ ) ∀ a , d ′ . Trans (cid:0) d ′ , s ′ , d ′ , do ( a , s ′ ) (cid:1) ⇒∃ d ′′ . Trans (cid:0) d ′′ , s ′′ , d ′ , do ( a , s ′′ ) (cid:1) ∧ SameCon f ig (cid:0) d ′ , do ( a , s ) , d ′′ , do ( a , s ′′ ) (cid:1) ∀ a , d ′ . Trans (cid:0) d ′′ , s ′′ , d ′ , do ( a , s ′′ ) (cid:1) ⇒∃ d ′′ . Trans (cid:0) d ′ , s ′ , d ′ , do ( a , s ′ ) (cid:1) ∧ SameCon f ig (cid:0) d ′′ , do ( a , s ′′ ) , d ′ , do ( a , s ′ ) (cid:1) Intuitively, a predicate
SameCon f ig ( d ′ , s ′ , d ′′ , s ′′ ) is said to be correct if d ′ and d ′′ are terminableeither both or none of them. Furthermore, for each action a performable by d ′ in the situation s ′ , d ′′ in the situation s ′′ has to enable the performance of the same actions (and viceversa). Moreover, theresulting configurations ( d ′ , do ( a , s ′ )) and ( d ′′ , do ( a , s ′ )) must still satisfy SameCon f ig .The use of the bisimulation criteria to state when a predicate
SameCon f ig ( · · · ) is correct, derivesfrom the notion of equivalence introduced in [5]. When comparing the execution of two formally differ-ent business processes, the internal states of the processes may be ignored, because what really matters.deLeoni 95is the process behavior that can be observed. This view reflects the way a PMS works: indeed what isof interest is the set of tasks that the PMS offers to its environment, in response to the inputs that theenvironment provides.Next we turn our attention to the procedure to adapt the process formalized by Recovery ( d , s , s ′ , d ′ ) .Formally is defined as follows: Recovery ( d ′ , s ′ , s ′′ , d ′′ ) ⇔ ∃ d a , d b . d ′′ = d a ; d b ∧ Deterministic ( d a ) ∧ Do ( d a , s ′′ , s b ) ∧ SameCon f ig ( d ′ , s ′ , d b , s b ) (7) Recovery determines a process d ′′ consisting of a deterministic d a (i.e., a program not using theconcurrency construct), and an arbitrary program d b . The aim of d a is to lead from the situation s ′′ inwhich adaptation is needed to a new situation s b where SameCon f ig ( d ′ , s ′ , d b , s b ) is true.The nice feature of R ECOVERY is that it asks to search for a linear program that achieves a certainformula, namely
SameState ( s ′ , s ′′ ) . That is we have reduced the synthesis of a recovery program to aclassical Planning problem in AI [4]. As a result we can adopt a well-developed literature about planningfor our aim. In particular, if the services and input and output parameters are finite, then the recovery canbe reduced to propositional planning, which is known to be decidable in general (for which very wellperforming software tools exists).Notice that during the actual recovery phase d a we disallow for concurrency because we need fullcontrol on the execution of each service in order to get to a recovered state. Then the actual recoveredprogram d b can again allow for concurrency.In the previous sections we have provided a general description on how adaptation can be definedand performed. Here we choose a specific technique that is actually feasible in practice. Our main stepis to adopt a specific definition for SameCon f ig , here denoted as S
AME C ONFIG , namely:S
AME C ONFIG ( d ′ , s ′ , d ′′ , s ′′ ) ⇔ SameState ( s ′ , s ′′ ) ∧ d ′ = d ′′ (8)In other words, S AME C ONFIG states that d ′ , s ′ and d ′′ , s ′′ are the same configuration if (i) all fluentshave the same truth values in both s ′ and s ′′ ( SameState ), and (ii) d ′′ is actually d ′ . In papers [11, 9], wehave proved that the above-defined S
AME C ONFIG is a correct bisimulation.Using Equation 8 as
SameCon f ig definition feasible in practice, relevancy results to be:R
ELEVANT ( d ′ , s ′ , s ′′ ) ⇔ ¬ SameState ( s ′ , s ′′ ) (9)In the next section, we are going to show how the abstract planner specification given here has beenconcretely used inside SmartPM . Specifically the current version of
SmartPM uses the proportionalplanner available in the
IndiGolog platform developed by University of Toronto and RMIT in Melbourne.In order to adapt,
SmartPM is based on the concrete definitions of relevancy and
SameCon f ig given byEquations 9 and 8.
As already told, adaptation amounts to find a linear program (i.e., without concurrency) that is meantto be “appended” before the current
IndiGolog program remaining to be executed. Such a linear programis meant to resolve the gap that was just sensed by restoring the values of affected fluents to those beforethe occurrence of the deviation. Observe that
SameState can actually be defined as a first-order formula over the fluents, as the conjunction of F ( s ′ ) ⇔ F ( s ′′ ) for each fluent F . proc(monitor,[ndet([?(neg(relevant))],[?(relevant),recovery])]).proc(recovery, searchn([searchProgram],10).proc(searchProgram, [star(pi([Task,Id,Input,srvc],[?(and(Available(srvc),Capable(srvc,[workitem(Task,Id,Input)]))),manageExecution([workitem(Task,Id,Input)],srvc)])),?(SameState)]). Figure 5: The procedure for managing automatic adaptation with the
IndiGolog interpreter.Figure 5 shows how adaptability has been concretely implemented in
SmartPM . The execution ofthe process being carried out by
SmartPM can be interrupted by the monitor procedure when a mis-alignment between the virtual and the physical reality is discovered.The monitor procedure is the concrete coding of Equation 6 and relies on procedure relevant .Procedure relevant returns true if the exogenous event has created a gap between the physical andvirtual reality that is in accord with Equation 9. For this aim,
SmartPM keeps a “copy” of the expectedvalue of each defined fluent so that when an exogenous action is sensed it can check whether the actionhas altered the value of some fluent.If the gap is relevant, procedure recovery is invoked. It amounts to find a linear program (i.e.,without concurrency) to reduce the gap sensed as well as, if such a program is found, to execute it. Afterexecuting such a linear program, the program coded by routine process (and its possible sub-routines)can progress again. This behaviour is equivalent to that expressed formally in Equation 7 where theadapting linear program is “appended before” and, hence, executed before the remaining process.The recovery procedure looks for a sequence of actions that brings to a situation in which proce-dure
SameState returns true: S (cid:0) ( p a . a ) ∗ ; SameState ? (cid:1) . Procedure SameState tests whether executing ( p a . a ) ∗ really has really reduced the gap. The use of the IndiGolog ’s lookahead operator S guaranteesthe action sequence ( p a . a ) ∗ is chosen so as to make SameState true. In fact, we do not look for anyaction sequence ( p a . a ) ∗ but we reduce the search space since we search for sequences of invocations ofprocedure manageExecution with appropriate parameters. Most of existing PMSs are not completely appropriate for very dynamic and pervasive scenarios. In-deed, such scenarios are turbulent and subject to a higher frequency of unexpected contingencies withrespect to usual business settings that show a static static and foreseeable behaviour. This paper describes
SmartPM , an adaptive PMS that is able to adapt processes thus recovering from exceptions. Adaptationis synthesized automatically without relying either on the intervention of domain experts or on the ex-istence of specific handlers planned in advance to cope with specific exceptions. Space limitation hasprevented from including concrete examples of adaptation: interested readers can refer to [11].Future works aim mostly at integrating
SmartPM with state-of-art planners. Indeed, current imple-mentation relies on the
IndiGolog planner, which performs a blind search without using smarter tech-niques recently proposed to reduce the search space by removing a priori all the possibility surely takingto no solution. The most challenging issue is to convert Action Theories and
IndiGolog programs in away they can be given as input to planners (e.g., converting to PDDL [3])..deLeoni 97
Acknowledgments
The author wishes to thank to Giuseppe De Giacomo, Andrea Marrella, Massimo Mecella and SebastianSardina, who have contributed to different aspects of the
SmartPM development.
References [1] K. Andresen & N. Gronau (2005):
An Approach to Increase Adaptability in ERP Systems . In: ManagingModern Organizations with Information Technology: Proceedings of the Information Resources Manage-mentAssociationInternationalConference. Idea Group Publishing, pp. 883–885.[2] G. De Giacomo, R. Reiter & M. Soutchanski (1998):
Execution Monitoring of High-Level Robot Programs .In: Proceedingsofthe6thInternationalConferenceonPrinciplesofKnowledgeRepresentationandReason-ing(KR’98). pp. 453–465.[3] M. Fox & D. Long (2006):
Modelling Mixed Discrete-Continuous Domains for Planning . JournalofArtificialIntelligenceResearch 27, pp. 235–297.[4] M. Ghallab, D. Nau & P. Traverso (2004):
Automated Planning: Theory and Practice . Morgan KaufmannPublishers.[5] J. Hidders, M. Dumas, W.M.P. van der Aalst, A.H.M. ter Hofstede & J. Verelst (2005):
When are two work-flows the same?
In: Proceedings of the Australasian symposium on Theory of computing (CATS’05).Australian Computer Society, Inc., pp. 3–11.[6] S.R. Humayoun, T. Catarci, M. de Leoni, A. Marrella, M. Mecella, M. Bortenschlager & R. Steinmann(2009):
The WORKPAD User Interface and Methodology: Developing Smart and Effective Mobile Applica-tions for Emergency Operators . In: Proceedingsof the13th InternationalConferenceon Human-ComputerInteraction(HCI’09). Springer. To appear.[7] B. Kiepuszewski, A.H.M. ter Hofstede & C. Bussler (2000):
On Structured Workflow Modelling . In: Pro-ceedingsof the 12th InternationalConferenceon AdvancedInformationSystems Engineering(CAiSE’00).Springer-Verlag, London, UK, pp. 431–445.[8] R.A. Kowalski (1995):
Using meta-logic to reconcile reactive with rational agents . Meta-logics and logicprogramming, pp. 227–242.[9] M. de Leoni, Massimo M. & G. De Giacomo (2007):
Highly Dynamic Adaptation in Process ManagementSystems Through Execution Monitoring . In: Proceedings of the 5th Internation Conference on BusinessProcessManagement(BPM’07), LectureNotesinComputerScience 4714. Springer, pp. 182–197.[10] M. de Leoni, M. Mecella & R. Russo (2007):
A Bayesian Approach for Disconnection Management in MobileAd Hoc Networks . In: Proceedings of the 16th IEEE International Workshops on Enabling Technologies:InfrastructureforCollaborativeEnterprises(WETICE’07). IEEE Computer Society, Washington, DC, USA,pp. 62–67.[11] M. de Leoni (2009):
Adaptive Process Management in Highly Dynamic and Pervasive Scenarios . ComputerEngineering, SAPIENZA – Universit`a di Roma. Draft Downloadable at .[12] R. Milner (1980):
A Calculus of Communicating Systems , LectureNotesinComputerScience 92. Springer.[13] R. Reiter (2001):
Knowledge in Action: Logical Foundations for Specifying and Implementing DynamicalSystems . MIT Press.[14] S. Sardina, G. De Giacomo, Y. Lesp´erance & H.J. Levesque (2004):