The document discusses adaptive process management in highly dynamic scenarios. It notes that traditional process management systems are not well-suited for dynamic environments where actors and services can join or leave unpredictably. It proposes two approaches for adaptation: 1) anticipating all possible exceptions or 2) using a general recovery method to handle any exception. The latter is preferable for highly dynamic scenarios due to the large number of possible exceptions.

1. Adaptive Process Management in Highly Dynamic and Pervasive Scenarios Massimiliano de Leoni Dipartimento di Informatica e Sistemistica SAPIENZA – Università di Roma

2. The Rationale / 1 Process Management Systems ( PMSs ) , a.k.a. Workflow Management Systems , are traditionally used in many business domains, such as government agencies, insurances, banks, etc. Besides these static domains, it is gaining momentum their use in very dynamic scenarios. For instance in mobile scenarios in order to coordinate the intervention of on-field teams for the emergency management. During war battles to carry on more effective attacks or defences.

3. The Rationale / 2 In these highly-dynamic scenarios, the execution environment can change over the time in an unpredictable way. For instance, actors/services can join or leave at any time Services can provide specific capabilities required to carry on processes. Some services can provide capabilities that none else can furnish. If such services leave, the process cannot be completed successfully X For instance, in Mobile scenarios: Devices may run down and fail, causing unavailability of services. New devices can join at any time Actors equipped with mobile devices can move around to perform assigned tasks, becoming isolated and, hence, unable to take part in the process performance A many many others, mostly unforeseeable!

4. The Rationale / 3 In these scenarios, high dynamicity yields to many events which can change the context and prevent process from progressing and completing successfully Of course, ignoring deviation is not feasible! The new situation might be such that the PMS is no more able to complete the process, achieving the goal pursued. So, some adaptation is a “must” in highly dynamic and pervasive scenarios

5. Adaptive Process Management Museum Precarious Bell-Tower Building Church Operator Bridge Team Leader Photo-Camera Affected Area Picture store

6. Adaptive Process Management The handler to deal with the exception, the relevant exogenous event which would affect the successful termination of the process

7. Two ways for adapting… Anticipating all possible discrepancies. Nowadays, APMSs use mostly this approach. Feasible and valuable in static contexts, where exceptions occur rarely. In very dynamic scenarios, too many exceptions need to be considered. Using the metaphor of the try/catch construct: try { task1; task2; task3 || subProcess(); } catch(Disconnection) { … } catch(Devices Down) { … } catch(Exception1) { … } catch(Exception2) { … } catch(Exception3) { … } catch(Exception4) { … } ... The list of all expected exceptions. What if any unexpected occurs?

8. Two ways for adapting… Devising a general recovery method. This method should be able to handle any kind of event, even unexpected. The process is defined as if exogenous actions cannot occur (the try block). Whenever discrepancies are detected leading to no successful process termination, the control moves to the sole catch block. It activates a general recovery method It modifies the old process P in a process P0 terminable in the new environment and achieving all P’s goals Using the metaphor of the try/catch construct : try { task1; task2; task3 || subProcess(); } catch(Any Exception) { The generic method! } It analyses the changed environment and automatically adapts

9. Related Work on Adaptiveness The process schema is adapted manually to changing policies, laws, practices, etc… Single instances are adapted to cope with changes in the environment where instances are executed The issue is to change running instances to fit with changes of the schema Manual Adaptation approach envisions an expert who is charge of modifying the instances to handle these events The schema of the running instances is automatically adapted to make terminate them in the new environment There exist some ECA-like rules that define how to handle specific events affecting instance terminations

10. WASA e CBRFlow do not allow ad-hoc adaptation of single instances Comparison of Existing Approaches There exists no Process Manager handling adaptation of unplanned exogenous events Policies defined at design-time. It’s decided at run-time what policy to apply

11. Execution Monitoring Techniques for monitor of discrepancies: “ sensing ” of the real world and aligning of the internal virtual reality. Possibly predicting misalignments before their actual occurrence. Techniques for identification of corrective actions. Techniques for automatic process restructuring. < P, C > < P, C1 > e Process P is successfully terminable in the context C Process P is NO MORE terminable successfully in the context C1 < P1, C1 > Process P1 is terminable in the context C1 AND P1 pursues all P’s goals Adaptation 1 2 and 3

12. Our Adaptive PMS Process Engine Tool for process design Execution Monitor Sensor External World Initial process initial context Task assignment Input & Output Data Changes in process and in mental context Adapted Process Alignment of mental context with sensed data It’s the interface used by designers to define the process schema The APMS modules assigning tasks to actors, considering context and actors’ capability For each execution step, it aligns the mental world in “PMS” mind with reality and data retrieved from external world by sensors, possibly adapting the process to unforeseen exogenous events Sensors are intended as any software and/or hardware component able to get contextual information from the external world. Services & Apps

13. Domain-independent predicates and actions Some first-order logic domain-independent predicates denote various objects in the framework: service ( a ) : a is a service, i.e. an entity (humans, softwares or robots) actively involved in task executions task ( x ) : x is a task of a workflows. 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

14. Actions of the PMS and services The framework defines four domain-independent actions executed by the PMS: Assign ( a, x ) : service a is assigned to perform a task x . Start ( a, x, p ) : service a is notified to perform the task x on input p AckTaskCompletion ( a, x ) : the PMS acknowledges service a to have received the notification of the completion of task x Release ( a, x ) : service a is released with respect to task x . Services communicates with the PMS by executing two types of actions: readyToStart ( a, x ) : service a declares to be ready to start performing task x finishedTask ( a, x, q ) : service a declares to have completed the execution of task x returning output q . When services or the PMS execute actions, the counterpart is notified about that.

15. Actions of PMS and actions of services The interaction between the PMS engine and services to be “orchestrated” foresees a precise sequence of actions invocation The interaction depicted in the left-hand side refers to the execution of one task. PMS Engine Service x Assign(a,x) readyToStartTask(a,x) Start(a,x,p) finishedTask(a,x,q) AckTaskCompletion(a,x) Release(a,x)

16. Environment Definition / 1 We define situation s i as the formal specification of the environment after the i -th action. The predicate s i+1 = do (t,s i ) the situation after the t action on the situation s i . Situation calculus relies on fluents , first-order formulas on situations Evaluation of fluents on the current situation depends on the actions executed situation by situation. In our framework, some fluents are specific of a certain domain, while others exist in any domain. Domain-independent fluents comprise free(a;s) : the actor/service a is free (no task assigned) in the situation s:

17. There exists also the domain-independent fluent enabled ( x; a; s ) which aims at representing whether service a has given an acknowledgement to execute a certain task x . The corresponding successor-state axiom: Once defined it, we can specify two preconditions, thus preventing AckTaskCompletion ( x; a ) from occurring before Start ( x; a; p ) Besides that, we never give pre-conditions to actions. We assume actions to be always executable If actions do not meet certain conditions, the process state (i.e., the values of fluents) do not change as expected. Environment Definition / 2

18. Environment Definition / 2 The framework assumes the existence of another fluent: available(a;s) : the actor can be assigned to another task. Its definition depends on the domain. The only constraint to be ensured is that a non-free actor is not available: The fluent available(a;s) is domain-dependent . For instance, in mobile scenarios, an actor is available if and only if it is free and it is connected through multi-hops to the team leader.

19. Definition of processes In our framework processes are defined by INDIGOLOG programs. The schema may comprise concurrent action sequences Every sequence is annotated with the goals it pursues INDIGOLOG is a logical language allowing actions’ concurrence and look-ahead constructs. widely used to describe robot plans. Actions are the basic building blocks. Here a sub-program is any INDIGOLOG program

20. An example Choose an available service a 1 for all capabilities c required by CompileQuest An example of domain-dependent fluent and its corresponding successor-state axiom:

21. Automatic Adaptation As soon as actions are executed, the INDIGOLOG program counter progresses. It is equivalent to say that, after every action, the process δ evolves in δ’, which is obtained from δ by removing the actions that have already been executed. Let be δ’ : the process after each action s’ : the supposed world state (virtual reality) s’’ : the real world state as monitored through sensors (physical reality) δ’’ : the adapted process executable in s’’ If the differences between s’ and s’’ are not relevant δ’ = δ’’ otherwise δ’’ is an “adapted” version of δ’. Relevant means δ’ cannot be carried out in the deviated situation s’’.

22. Annotating with the goals pursued by branches Every sequence of tasks can be optionally annotated with the goals pursued. Later, we use the regression operator to learn which intermediate goals should be achieved in order to obtain the final goal at the end of the sequence R s (  ( do ([ a 1 ; … ; an ] ; s ))) is the formula with situation s which denotes the facts/properties that must hold before executing a 1 ;…; an in situation s such that  ( do ([ a 1 …an ] ; s )) to hold

23. Dependency among parallel branches /1 Before adapting, at any time when program/process progresses executing, it can be represented δ’ = [ p 1 || p 2 || … || p N ]; δ b Branches p 1 , p 2 , … , p N may or may not be depending among them (whether they are or are not working on the same fluents). Independent branches are such that every trace of concurrent execution of the activities of branches do not affect the successful achievement of the respective goals: If m is the length of each of the sequences (supposing all having the same length) and N is the number of concurrent processes/branches, then Checking this independence directly is O(m N )

24. Dependency among parallel branches /2 Instead of taking all execution traces, we have proven that we can take the traces generated by all pairs of sub processes pi and pj The cost is O(m 2  N 2 ) where and Action a can be executed at any time during the execution of [ a 1 ,…,a n ] without affecting the achievement of G, and with no change of the invariant C

25. If branches are not independent A repairing handler h is built to repair the broken branch p i and executed: δ’’ = h; [ p 1 || p 2 || … || p i-1 || p i || … || p N ]; δ b We use a planner to build a plan/handler aiming at reducing the gap between the virtual reality and the world. p 1 p 2 p 3 Process Counter h M. de Leoni, M. Mecella, G. De Giacomo “ Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring” In Proc. of the 5th International Conference on Business Process Management (BPM 2007)

26. Formal definition Formally: Let The predicate SameConfig ( δ ’,s’, δ ’’, s’’) holds if and only if δ ’ , performed in the situation/environment s’ , is bisimilar to δ ’’ , performed in the context/environment s’’ . The predicate Recovery( δ ’,s’,s’’, δ ’’) is formally as follows: Recovery ( δ ’,s’,s’’, δ ’’ ) “returns” the adapted process δ’’ Relevant ( δ ’,s’,s’’ ) states if the change from s’’ to s’ is such that δ’ can’t be carried out If we use the special bisimulation SameConfig(δ’,s’, δ’’,s’’)  δ’ = δ’’  SameState(s’,s’’) , then we have reduced the problem to the classical AI problem of finding a plan to achieve the formula SameState LinearProgram ( δ ) states δ to have no fork! Do ( δ ,s,s’ ) states δ, when starting in s, can terminate and it does in s’

27. If branches are independent A repairing handler h is built to recovery the broken branch p i , and executed: δ’’ = [ p 1 || p 2 || … || p i-1 || (h; p i ) || … || p N ]; δ b Only p i is delayed. The others continue being executed even while p i is being repaired. In order to repair: We obtain the values that fluents should hold (i.e., the state) in order to have the p i goal achieved. We use a planner to build h by using the fluents values desired as goal The planner must ensure that handler (h; p i ) continues preserving independence, as p i did when alone. h p 2 p 3 Process Counter M. de Leoni, G. De Giacomo, Y. Lesperance, M. Mecella “ On-line Adaptation of Sequential Mobile Processes Running Concurrently” In Proc. of the 24th Annual ACM Symposium on Applied Computing (SAC 2009) p 1

28. Design & Realisation / 1 We implemented APMS using the IndiGolog platform developed jointly by University of Toronto and RMIT University in Melbourne Exogenous events are harvested by sensors installed on devices. All communications between PMS and sensors happen via respective Device Managers .

29. More in detail… A GUI tool to design process schemas as Activity Diagrams and to export as XML files Transform the XML process schema in Indigolog Program + Action Theory (i.e. the pre- and post- conditions of tasks). It computes the evolution of programs according to the statements semantic, holding the program counter Drivers to make communicate PMS with services and sensors installed on devices. Responsible of choosing the right actor for each action and of instructing the respective device managers It gets notification from Comm. Manager of exogenous events and adapts the process schema accordingly. It holds the current situations, i.e. the fluent values to evaluate the next program step to execute Domain Programs and Axioms keep the definition of the IndiGolog program to be executed and the Action Theory

30. Design & Realisation / 2 The INDIGOLOG engine executes a “ sense-think-act” cycle: Invoking the Execution Monitor and checking if the process needs adaptation If exogenous events are happened, the Execution Monitor will adapt the process accordingly. Calculating the next program step If the step involves an action by some service, executing it . When it is to execute an action, the communication manager instructs the device manager of the device on which the service is installed. The device manager, in turn, will handle the communication with the services

31. Process definition: an example

32. Adaptability realisation / 1 Fluents are concretely defined in the platform as situation-independent. A certain fluent F (  ,s) is always defined here as F(  ) Fluents are always supposed to be evaluated in the current situation No possibility to access to any previous situations The execution monitor needs to compare the values of all fluents in the situations before and after the occurrence of a certain exogenous event If any fluent has changed the value because of the exogenous event, then the event itself is relevant. How to get access to fluent values in “past” situations?

33. Adaptability realisation / 2 For each fluent F i (  ) of the action theory, we define a second fluent F’ i (  ). When an exogenous event occurs, before applying the successor-state axioms, we make  i,x. F’ i (x)=F i (x) The exogenous event is relevant iff:  i,x F’ i (x) ≠ F i (x)

34. Adaptability realisation / 3 We make use of the look-ahead IndiGolog operator to cope with the impossibility of back-tracking actions executed in the real world Let  be any program providing different alternative executable actions. Program  (  ) performs and a choice among currently available alternative so as to have the rest of  still terminable successfully. Then, recursively the look-ahead operator is applied to the remaining part Predicate Relevant holds iff there exists a fluent F i s. t. F i (  )= F’ i (  ) This is a smarter implementation of  ( (  .a;a)*;ExpectedState? ) where ExpectedState is  i,x. F’ i (x)=F i (x)

35. Conclusion This thesis has been focused to Process Management for highly dynamic and pervasive scenarios Processes in these scenarios are typically as in complex as traditional business domains (e.g., loans, insurances)  PMSs are very useful Existing PMSs are unable to deal with pervasive scenarios Scenarios are turbulent and subject to a higher frequency of unexpected contingencies wrt. business settings, which are conversely mostly static and showing a foreseeable behaviour We have proposed techniques and frameworks to handle any kind of exogenous events, including those unforeseeable ones We have applied AI techniques to a different field, which has required a significant effort to conceptualise and formalise The proposed techniques: rely on execution monitoring to determine when exogenous events occurrence can affect the successful process termination make use of recovery planning techniques to adapt the original process to these events, while preserving the original goals.

36. Future work Overcoming the intrinsic planning inefficiency of Prolog by using state-of-the-art planners Prolog uses a very simple blind search. A challenging issue is to convert Action Theories and INDIGOLOG programs in a form which can be given to planners (e.g., PDDL). Implementing the approach that exploits the possible independence of branches. That is going to need some improvements on the IndiGolog platform. Moving the central engine to a distributed approach where every device contributes to coordination PDAs might not be power enough to handle all of coordination aspects. In very turbulent environments, a single point of failure might be inacceptable.