Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring

1
Highly Dynamic Adaptationin Process Management
Systemsthrough Execution Monitoring

• Massimiliano de Leoni, Massimo Mecella and
  Giuseppe De Giacomo
• deleoni,mecella,degiacomo_at_dis.uniroma1.it
• Dipartimento di Informatica e Sistemistica
• SAPIENZA Università di Roma

2
The Rationale / 1

• Process Management systems, a.k.a. Workflow
  Management Systems, are traditionally used in
  many business scenarios, such as government
  agencies, insurances, banks, etc.
• Besides this static scenario, it is more and more
  spreading their use in very dynamic scenarios.
• For instance in mobile scenarios in order to
  coordinate the interventions of on-field teams
  for disaster 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 any way.
• For instance, involved actors may change in the
  time
• Actors provide specific (possibly unique)
  capabilities which are required to carry on
  processes.
• Some tasks may require skills which no actor
  provides any longer.

• For instance, in Mobile scenarios

• Actors equipped with mobile devices can move
  around to perform assigned tasks, causing
  disconnections from the others or path changes

• New devices can come in anytime

• Devices may run down or break, causing actors
  fall down.

X

• A many many others, mostly unforeseeable!

4
The Rationale / 3

• In these scenarios, high dynamicity yields to
  many events which can change the context,
  avoiding the process progressing.
• Of course, ignoring deviation is not feasible!
• new situation might be such that the PMS is no
  more able to carry out the process instance.
• So adaptation is needed in several scenarios!!

5
Scenario (Just an example)
Affected Area
Picture Store
Museum
Operator
Precarious Bell-Tower Building
Photo-Camera
Church
Operator
He has got installed the PMS!
Team Leader
6
A typical cooperative process
7
Adaptive Process Management
Affected Area
Picture store
Museum
Operator
Precarious Bell-Tower Building
Photo-Camera
Church
Team Leader
Bridge
8
New activity for disconnection management
9
Two ways for adapting

• Anticipating all possible discrepancies.
• Most APMSs currently use this approach.
• Feasible and valuable in static context, where
  there are a few exceptions.
• In such very dynamic scenarios, too many
  exceptions would be to consider.

• Like the try/catch construct of Java
• 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 happens?
10
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 the
  process not to be terminable, the control moves
  to the only 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 Ps goals

• Like the try/catch construct of Java
• try task1 task2 task3 subProcess()
• catch(Any Exception) The generic method!
  

It analyses the changed environment and
automatically adapts
11
Execution Monitoring

• Techniques for monitor of anomalies sensing of
  the real world and aligning of the internal
  virtual reality.
• Possibly predicting misalignments before they
  actually happen.
• Techniques for identification of corrective
  actions.
• Techniques for automatic process restructuring.

Process P is NO MORE terminable in the context C1
1
e
lt P, C gt
lt P, C1 gt
Process P is terminable in the context C
Adaptation
Process P1 is terminable in the context C1 AND P1
pursues all Ps goals
lt P1, C1 gt
2 and 3
12
The Architecture of our Adaptive PMS

• Task assignment
• Input Output
• Data

• Initial process
• initial context

GUI for process design
Process Engine
Sensors are intended as any software and/or
hardware component able to get contextual
information from the external world.

• Adapted Process
• Alignment of mental
• context with sensed
• data

• Changes in process
• and in
• mental context

ExecutionMonitor
Its 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
Sensor
External World
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 actor
  (humans, softwares or robots) performing tasks.
• 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
• We define four domain-independent actions
• 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 acknowledges the
  successful termination of x with output q
• Release(a x) the service a is released with
  respect to the task x

14
Environment Definition / 1

• We define anytime the situation si as the formal
  specification of the environment after the i-th
  action.
• The predicate si1 do (t,si ) the situation
  after the t action on the situation si .
• Situation calculus relies on fluents representing
  properties of the world, such as
• free(as) the actor/service a is not busy (no
  task assigned) in the situation s. Its defined
  as
• available(as) the actor can get another task
  assigned. It is true the following but not the
  vice versa

15
Environment Definition / 2

• The fluent available(as) is domain-dependent.
• For instance, in mobile scenarios, an actor is
  available if and only if it is not busy and it is
  connected through multi-hops to the team leader.
• We define preconditions as axioms on such
  fluents.
• For instance, the condition stating an actor a
  must be available in order to get a task x
  assigned is as follows
• Of course, specific tasks may require some
  stricter conditions
• That means actors needs provide a GPRS connection
  in order to perform the task SendDataByGPRS

16
Definition of schemas

• In our framework Process schema are defined by
  CONGOLOG programs.
• Nevertheless, everything works also through any
  formal specification language, such as Petri
  Nets.
• CONGOLOG is a logical language allowing actions
  concurrence
• widely used to describe robot plans.

Here a sub-program is any CONGOLOG program
Actions are the basic building blocks.
17
A CONGOLOG Example
Choose an available service/actor a0 for all
required capabilities by Compile
Here, 1 assignment for two tasks to force them to
the same service/actor, that must provide all
required capabilities for both
18
Adaptation

• As soon as actions are executed, the CONGOLOG
  program counter progresses.
• It is equivalent to say that, after every action,
  the process d evolves in d, which is obtained
  from d by removing the already executed action.
• Let be
• d the process after each action
• s the supposed world state (virtual reality)
• s the real world state as monitored through
  sensors.
• d the adapted process executable in s
• If the differences between s and s are not
  relevant d d otherwise d is an adapted
  version of d.
• Relevant means d can be carried out even in s.

19
Formal definition
Recovery (d,s,s,d) returns the adapted
process d
Relevant (d,s,s) states if the change from
s to s is such that d cant be carried out

• Formally
• Let
• The predicate SameConfig (d,s, d, s) holds
  if and only if d, performed in the
  situation/environment s, is bisimilar to d,
  performed in the context/environment s.
• The predicate Recovery(d,s,s,d) is formally
  as follows

• If we use the special bisimulation
  SameConfig(d,s, d,s)?? d d ?
  SameState(s,s), then we have reduced the
  problem to the classical AI problem of finding a
  plan to achieve the formula SameState
• Many planners already exist

Do (d,s,s) states d, when starting in s, can
terminate and it does in s
LinearProgram (d) states d to have no fork!
20
An example

• Lets suppose that, while going to Location for
  taking some photo, the actor is going to
  disconnect.
• That is violated the predicate Connected
• It wasnt supposed to happen!
• No predefined rule to handle it

Graphically

• APMS analyses every possible action, every task
  from the predefined set.
• It decides that another node should move to the
  location x where disconnecting actor is
• That restores the predicate!

21
Conclusion

• This is a general approach for automatic process
  adaptation in highly dynamic scenarios.
• Based on AI techniques, which are widely used in
  Robot Planning
• Proved correctness and completeness
• We are going to implement it through the
  IndiGolog developed by the Cognitive Robotics
  Group at Toronto University and Intelligent
  Agents group at RMIT University, Melbourne
• The APMS will be then used in the European
  project WORKPAD in the context of disaster
  management.
• We are working on improving this approach in
  defining how assigning properly tasks to actors,
  giving more evidence to those more urgent.
• Of course, we have to define how to prioritize
  (which parameters to take into account)