Computational Logic in IMPACT and in Agent Systems

1
Computational Logic in IMPACT and in Agent
Systems

• Jürgen Dix
• The University of Manchester
• (University of Maryland)

1
2
Overview

• Part I A Birds Eye View on IMPACT
• Part II Planning IMPACTing SHOP
• Part III Heavily Loaded Agents
• (Part VI Regular Agents)

3
I.1 Agent Definitions

• Shohams definition- an agent is a program
  supporting
• Ongoing execution, planning
• adaptiveness, autonomy
• reactivity, mobility, intelligence
• FIPAs definition
• speech, visual, I/O primitives
• Messaging languages
• DARPAs definition
• autonomous, adapt, cooperate

• These are behavioral definitions.
• IMPACT provides
• a structural def.
• formal models of the desired behaviors
  specified by Shoham, FIPA, DARPA.

4
I.2 Motivations

• Agents are for everyone! Agentize arbitrary
  Legacy Code.
• Knowledge is distributed and heterogenous. Code-C
  all mechanism.
• Agents act wrt a clearly articulated semantics.
  Agent Program wrt Status Sets
• (Agents Implementation should be feasible.)
  (Complexity Analysis, Regular Agents)

5
I.3 What is Legacy Code?

• Arbitrary Code S can be seen as a triple
  S(T,F,C), with
• T is the set of all data types managed by S
• F is a set of predefined functions accessing the
  data objects
• C is a set of type composition operations

• State of an agent at any given point t
  in time, the state of an agent is the set
  OS(t) of objects from the types T ,
  managed by its internal code.
• State Change only when
• an action is executed or
• a message has been received from another agent.

6
I.4 Data Access

• Code Call df(arg1,,argk).
• Code Call Atom in(X,df(arg1,,argk)).

Execute function f defined in agent d on the
specified arguments. Returns a set of objects.

• Routeplan( map1,20,20,50,43).
• Oracleselect( depots.rel,item,,oxygen masks)

Succeeds if X is in the set of objects returned

• in(X, Oracleselect( depots.rel,item,,oxygen
  masks)). Find all tuples with item field
  equal to oxygen masks
• in(X, Routeplan( map1,20,20,50,43)).
  Find all routes returned by
  route planner between points (20,20) and (50,43)
  w.r.t. map1.

7
I.5 Data Access Code Call Conditions

• A conjunction of
• code call atoms and
• comparison atoms.
• in(X, Oracleselect( depots.rel,item,,oxyge
  n masks )) X.qty 1000
  
  in(Y,routeplan( map,99.25,X.x,X.y)).
• The above says find X,Y such that
• X is a tuple in an Oracle depot relation
  specifying a depot with over 1000 oxygen masks,
  and
• Y is a route from the location of that depot to a
  location (99,25) where the entity requesting the
  oxygen masks is located.

8
I.6 Overall Architecture

• What is an agent doing?
• Computing its semantics and acting
  accordingly.

9
I.7 What is an Agent?
Software module

• Agents are built on top of legacy or specialized
  software modules or systems.
• They access data using API functions.

10
I.7 What is an Agent?
msg box
Agent state (distributed)

• There is a message box with suitable
  functionality.
• Code manipulates data structures, the contents of
  which (including msgbox) describe the agents
  state.

11
I.7 What is an Agent?
Actions
msg box
Agent state (distributed)

• Agents have available actions to change the
  state.
• Actions are declaratively described through
  add/delete lists containing code call conditions.
  They are implemented through software code.

12
I.7 What is an Agent?
Agent Program
Actions
msg box
Agent state (distributed)

• Agents have an agent program encoding the
  agents operating principles
• The program consists of rules that are
  declarative and can be easily written or modified.

13
I.7 What is an Agent?
Agent Program
Actions
msg box
Integrity Constraints Action Constraints
Agent state (distributed)

• Integrity Constraints (to preserve properties of
  the state)
• Action constraints (to ensure actions do not
  interfere)

14
I.7 What is an Agent?
Agent Program
Actions
Actions
msg box
Integrity Constraints Action Constraints
Semantics
Agent state (distributed)

• Based on semantics and current state, actions are
  executed.
• These actions change its own state and other
  agents
• states as well.

15
I.8 Agent Program (1)

• Set of rules of the form Op
  a(arg1,,argn)
  Op1 a1() Opan()
• Op is a deontic modality and is either
• P - permitted
• O - obligatory
• Do - do
• F forbidden
• If code call condition is true and the deontic
  modalities in the rule body are true, then
  Op a(arg1,,argn) is true.

16
I.8 Agent Program (2)

• Most important part of the agent.
• Agent program rules must be carefully crafted to
  avoid inconsistencies.
• IMPACT provides facilities to create such rules.
• A class of programs is defined that can be
  efficiently implemented Regular Agents.

• EXAMPLE
• OprocessRequest(Msg.ID,Agent)
• ? in(Msg,msgboxgetAllMsg()),
  (Agent,Msg.Source)
• FmaintainCourse(NoGo,Route,Loc)
• ? in(NoGo,msgboxgetNoGo(Msg.ID)),
• in(Loc,autoPilotgetLoc()),
• in(Route,autoPilotgetRoute()),
• OprocessRequest(Msg.ID),
• DoadjustCourse(NoGo,Route,Loc)

17
II.1 Evacuation Operations

• Situation
• People need to be evacuated
• Send a Special Operations Force (SOF) team
• Task
• Plan routes and
• means of transportation to be used by the team

• Problems
• Plan editing, bookkeeping
• Access to planning knowledge
• needed information is
• heterogeneous,
• time-sensitive and
• geographically distributed
• Weather conditions
• Transportation resources
• Status of evacuees, current threats

18
II.2 How Can IMPACT Help?

• SHOP provides
• Scalable, high performance planning system
• Generate and evaluate plans
• IMPACT provides
• Access to distributed,heterogeneous data sources
• Seamless interoperability between different
  software capabilities
• Ability to coordinate multiple agents
• Integrate SHOP into IMPACT, so that SHOP can
  utilize IMPACTs capabilities during planning

19
II.3 (HTN) Planning

• Use methods to decompose tasks
• Each method may have preconditions
  (e.g., helicopters available)
• Need to resolve interactions
  (e.g., deploy security force first)
• If necessary, backtrack and try other methods

20
II. 4 How to Agentize SHOP

• D et al., CLIMA 2000 D et al., Annals of Math
  AI, 2002
• First, extend SHOPs methods and operators to
  incorporate code calls
• An agentized method is an expression of the form
• (AgentMeth h c t) where
• h (the methods head) is a compound task,
• c (the methods preconditions) is a code call
  condition
• t is a task list
• An agentized operator is an expression of the
  form
• (AgentOp h cadd cdel) where
• h (the head) is a primitive task
• cadd and cdel are code call conditions
• The set of variables in cadd and cdel is a subset
  of the set of variables in h

21
II.6 The A-SHOP Algorithm

• Theorem Let D be a set of agentized methods and
  operators.If the add/delete-lists are strongly
  safe, then A-SHOP is sound and complete.
• (1) every plan returned by A-SHOP is
  correct
• (2) A-SHOP is guaranteed to find a plan if it
  exists.

22
II.7 Experimental Scenario

• Conditions
• Each phase several possible routes
• Short routes more likely to have hostiles
• Longer routes may take too long
• Potential means of transportation
• Fixed Wing Aircraft
• Airplanes
• Rotor Aircraft
• Helicopters
• Land Vehicles
• Jeeps etc

• According to doctrinethe route will include
• Assembly Point (AP)
• Phase 1
• Prov. Headquarters (HQ)
• Phase 2
• Interm. Staging Base (ISB)
• Phase 3
• NEO Site (NEO)
• Phase 4
• Safe Haven (SH)

23
II. 8 Implementing A-SHOP

• Agents that are part of A-SHOP
• Shop receives requests to create plans, and does
  task decomposition to create those
  plans
• CodeCallConditions checks code-call conditions
  for the Shop agent
• Monitor checks individual code calls within a
  code-call condition, and maintains changes to
  states made by the Shop agents operators
• Agents external to A-SHOP
• Customer represents the user who invokes A-SHOP
• PPT IMPACT agent invoked by A-SHOP to generate a
  PowerPoint document containing the final
  plan

24
II. 8 Info-Sources for A-SHOP

• Information sources
• Transport Authority maintains information about
  assets available at different locations
• Weather Authority maintains information about
  weather conditions
• Airport Authority maintains information about
  assets available at different locations
• Other information sources
• Situation maintains information gathered during
  planning
• Math do mathematical calculations needed during
  planning
• A-SHOP generates agents on-the-fly.

25
II. 9 Results (Memoization)
26
II.9 Results

• New optimizations
• Most time is spent to evaluate code call
  conditions (network time) rather than for the
  planning itself.
• More specifically
• How can a set of code call conditions
  processed more efficiently?

27
III. Heavily Loaded Agents

• Problem
• ccc1 in(X,spatialrange(T1,40,50,25))
• ccc2 in(Z,spatialrange(T2,40,50,50))

Given a set of cccs (requests).
Instead of
executing them one-at-a-time, find more
efficient procedures.
Clearly, ccc1 is a subset of ccc2 if T1 T2.
(spatialrange(T1,x,y,z) gives all points in T1
that are at most z units away from
(x,y))
28
III.1 The very idea

• Input from the agent developer
  She knows under which conditions
  which inclusions hold.
• Definition of a language for expressing these
  inclusions These statements, invariants, will
  be used as axioms from which new invariants can
  be deduced.
• Distinguish Development/Deployment time
  Algorithms for compiling invariants at
  development time can be more costly than those
  used at deployment time.

We try to merge the requests by detecting
commonalities between them.
29
III. 4 Main Definition

• Definition (Invariant)
• An invariant is an expression of the form
• where
• ic is an invariant condition
  (conjunctions of t1 op t2 )
• iei are invariant expressions
  (unions/intersections strongly safe cccs)

ic ? (ie1 subset ie2 )
TT and XX and YY and Rad in(Z,spatialrange(T,X,Y,Rad))
subset
in(W,spatialrange(T,X,Y,Rad))
30
III.2 Architecture

• Development Time
• 1. Agent developer states set I of invariants.
• 2. Derive additional invariants
  (wrt implication check).
• Deployment Time
• Identify three relationships between cccs
• 1. Identical cccs.
• 2. Implied cccs.
• 3. Overlapping cccs (neither 1. nor 2. but
  conjunction is consistent)
• Based on the above and a cost model for ccc
  evaluations, we developed various
  merge-algorithms parameterized by heuristics.

31
III. 3 Example

• Overlapping cccs
• ccc1 in(X,spatialhorizontal(map,100,200)).
• ccc2 in(Z,spatialhorizontal(map,150,
  250)).
• Clearly, it is better to execute
• ccc3 in(X,spatialhorizontal(map,100,250 )),
  
• and then executing selections to get the
  results for ccc1 and ccc2.

spatialhorizontal(map,a,b) gives back all points
(x,y) in map s.t. a
32
III. 5 Results Development Phase

• Checking implication is
• undecidable for arbitrary datatypes and
• co-NP complete for finite domains.
• Therefore use an incomplete but sound
  algorithm (efficiency).

33
III. 6 Results Deployment Phase

• Checked against classical query optimization
  techniques (Sellis 1994) viewed as a state
  search problem and use A algorithm.
• We ran experiments on relational data and on a
  spatial database used in IMPACT

34
III.7 Results

• Spatial domain the classical method competes
  only beyond 70 sharingfactor.
• Relational domain the classical method competes
  only beyond 40 sharingfactor.

35
III. 8 Results

• Our merge algorithms handle more than twice as
  many simultaneous cccs as A .
• They run 100-6000 times faster.
• The cost of the execution plans is at most 5
  more compared with A .
• Checking for overlapping cccs pays off.

36
Summary

• IMPACT Is based on formal, mathematical methods
  (Computational Logic). Identifies efficiently
  implementable classes of programs.
• IMPACTing SHOP Emphasis is put on building on
  top of legacy code and distributed heterogenous
  data, thus taking real applications seriously.
• Heavily Loaded Agents Framework is detailed
  enough to formulate and attack general problems,
  but yet is not bound to IMPACT alone.

37
References

• Publications
• Defeasible Reasoning TCS 02 (D et
  al.)
• Super Logic Programs ACM 02 (Brass/D/Prz)
• Meta-Agent Programs JLP 00 (D/VS/Pick)
• Temporal Agent Programs AIJ 01 (D/Kraus/VS)
• Probabilistic Agent Programs ACM 00 (D/Nanni/VS)
• Heavily Loaded Agents subm.
  (D/Ozcan/VS)
• Impacting SHOP Planning AMAI 02 (D/Munoz/Nau)
• Heterogenous Agent Systems MIT Press 2000 (D et
  al.)
• Agents dealing with time and Uncertainty subm.
  (D/Kraus/VS)

38
IV. Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

39
IV.1 Conflict freedom

• EXAMPLE
• Consider the following two non
• ground rules
• FmaintainCourse(NoGo,Route,Loc) ? ccc1 , Do
  action1
• OmaintainCourse(NoGo,Route,Loc) ? ccc2
  , F action2,
• Both can be conflict-free (depending on ccc1,
  ccc2 being true in the state) or not.

• Two ground rules Head1?Body1 Head2?Body2 conflict
  in a state iff
• the heads of the two rules conflict, and
• cccs in the bodies of the rules are true in the
  state, and
• ? deontically consistent status set that makes
  the action literals in the bodies true.
• THEOREM Checking conflict freeness is
  undecidable.
• Developed 4 different sufficient conditions if
  satisfied, they all guarantee that underlying
  set of rules is conflict free.

40
IV.3 Conflict freedom performance

• 1. Sufficient Condition

• 2. Sufficient Condition

0.02 sec
0.008 sec
Even for many actions, it is fast.
Even for many arguments, it is fast.
41
IV. Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

42
IV.2 Safety

• Safety is a condition on code call conditions
  that ensures that the code call condition is
  evaluable.
• We developed a provably sound and complete
  algorithm for testing safety.
• EXAMPLE
• The code call condition
• in(RP, terraingetPlan(P1,P2,Vehicle))
  
  in(RP, terraingetPlan(P2,P3,Vehicle))
  
  in(P3, coordnextPoint(P1,P2,Goal))
• is safe, if P1,P2,Vehicle, Goal are given
  Reorder the ccc!

43
IV.2 Strong safety

• Strong safety requires not only that queries are
  executable, but that their evaluation terminates
  in finite time.
• The executable ccc
• in(X, mathgeq(25)) in(Y,
  mathsquare(X)) Y
• if executed left-to-right does not
  terminate.
• If reordered, it does it is strongly safe.
• There is no finiteness-checking!

• Solution Specifying an infiniteness table
  listing all code calls returning infinite
  answers.
• Developed a provably correct algorithm to
  polynomially check strong safety of a ccc.
• Table lists code calls and a binding pattern for
  the variables involved
• mathgeq(X) ()
• mathfct(X,Y,Z) (X,,Z)
• Modification of the safety algorithm Safety
  Look-up in Table. (Linear in size(ccc) linear
  in size(table) .)

44
IV.2 Example/Performance of (strong) safety

• EXAMPLE Code call
  condition ccc with up to 20 conjuncts.
• Each point in the graph (fixed of conjuncts) is
  the result of
• do 1000 runs by varying of arguments, of
  variables (generate ccc randomly) and take the
  average run time.
• Result safe_ccc is extremely fast. Suggests that
  safety checking for programs containing 1000
  rules can be done in 20-40 milliseconds

0.046
20 conj.
45
IV. Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

46
IV.3 Deontic stratification

• This is a complex condition requiring that an
  action not be defined negatively in terms of
  itself.
• EXAMPLE
• Do compute(Loc) ? Do compute(Loc) , misc1
• Do compute(Loc) ? Do something(P), misc2
  Do
  something(P) ? Do compute(Loc), misc3
• Do compute(Loc) ? O compute(Loc) , misc4
  
• But the following is harmless
  
  Do compute(Loc) ? F compute(Loc) , misc4
  
• A deontically stratified program comes in
  finitely many strata, negative dependencies lead
  to strictly lower strata.

47
IV.3 Deontic stratification

• We developed a polynomial algorithm to evaluate
  deontic stratifiability.
• Graph based approach.
• Algorithm is provably correct and performs well.
• Performance results on the right.

0.26sec
Number of rules 200
48

• A regular agent program is one that is
• 1 conflict free
• 2 strongly safe
• 3 deontically stratifiable
• 4 unfoldable (see next slide)
• Regular agents require that all components of the
  agent satisfy an appropriate mix of the above
  conditions (e.g., integrity constraints must have
  strongly safe bodies, etc.).
• THEOREM Every regular agent has a unique
  rational status set.
• THEOREM The data complexity of computing
  the above rational status set is
  polynomial.

49
IV. Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

50
IV.5 Boundedness

• Consider the program
• Do com(Loc) ? Do some(P), ccc1 Do
  some(P) ? Do else(Loc),ccc2
• Do else(P) ? ccc3
• and let ccc3 be false in the state.
• Instead of checking Do-actions at run-time
  we simplify the program at compile time into
• Do com(Loc) ? ccc3, ccc2, ccc1
  Do some(P) ? ccc3, ccc2
• Do else(P) ? ccc3
• Replace successively in all rules the positive
  action atoms in the bodies.
• Boundedness If, eventually, all positive body
  atoms disappear larger but simpler program.

• This is also undecidable in general.
• We developed a provably correct polynomial (under
  suitable conditions) algorithm to unfold agent
  programs.
• Run-time Computation Start with those
  rules whose bodies contain only cccs or negative
  action status atoms.

51
IV.6 Unfolding Performance

• No detailed study yet (not enough agent programs
  available, not clear how to vary large number of
  parameters).
• Sample Program Logistics demo based on US Army
  War Reserves data.
• Unfolding 0.82 sec (17 rules
  transformed into 30)

• For regular agent programs, we have developed an
  algorithm that takes the result of the unfolding
  step as input, and produces as output, a rational
  status set.
• This algorithm has been implemented and performs
  well.
• Status Set 29 sec
• Note massive amounts of data resident in flat
  (unindexed) Oracle files were accessed and
  network time (24 sec) is included.
• Status Set 5 sec 24 sec