Computational Logic in IMPACT and in Agent Systems

Computational Logic in IMPACT and in Agent Systems

Jürgen Dix

The University of Manchester

(University of Maryland)

1

ESSLLI02, Trento, Italy 16/8/2002 2

Overview

• Part I: A Bird’s Eye View on IMPACT

• Part II: Planning: IMPACT’ing SHOP

• Part III: Heavily Loaded Agents

• (Part VI: Regular Agents)


I.1 Agent DefinitionsShoham’s definition- an agent

is a program supporting:• Ongoing execution,

planning• adaptiveness, autonomy• reactivity, mobility,

intelligence

FIPA’s definition:• speech, visual, I/O

primitives• Messaging languages

DARPA’s definition:• autonomous, adapt,

cooperate

These are “behavioral” definitions.

IMPACT provides

a “structural” def.

formal models of the desired “behaviors” specified by Shoham, FIPA, DARPA.


I.2 Motivations• Agents are for everyone!

Agentize arbitrary Legacy Code.

• Knowledge is distributed and heterogenous.Code-Call mechanism.

• Agents act wrt a clearly articulated semantics. Agent Program wrt Status Sets

• (Agents Implementation should be feasible.) (Complexity Analysis, Regular Agents)


I.3 What is Legacy Code?Arbitrary Code S can be seen

as a triple S=(T,F,C), with

1. T is the set of all data types managed by S

2. F is a set of predefined functions accessing the data objects

3. 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

1. an action is executed or

2. a message has been received from another agent.


• Code Call: d:f(arg1,…,argk).

• Code Call Atom: in(X,d:f(arg1,…,argk)).

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

I.4 Data Access

Succeeds if X is in the set of objects returned

–in(X, Oracle:select( ‘depots.rel’,item,=,oxygen masks)). Find all tuples with item field equal to “oxygen masks”–in(X, Route:plan( ‘map1’,20,20,50,43)). Find all routes returned by route planner between points (20,20) and (50,43) w.r.t. map1.

–Route:plan( ‘map1’,20,20,50,43).–Oracle:select( ‘depots.rel’,item,=,oxygen masks)


I.5 Data Access: Code Call Conditions• A conjunction of

– code call atoms and– comparison atoms.

• in(X, Oracle:select( ‘depots.rel’,item,=,oxygen masks )) & X.qty > 1000 & in(Y,route:plan( ‘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.


I.6 Overall Architecture

What is an agent doing?

Computing its semantics and acting accordingly.

Evaluate messages

Execute Actions

Compute Semantics


I.7 What is an Agent?

Agents are built on top of legacy or specialized software modules or systems.

They access data using API functions.

Software moduleImplementation

Interface/API



msgbox

Agent state (distributed)

Implementation

Interface/API

There is a message box with suitable functionality. Code manipulates data structures, the contents of which

(including msgbox) describe the agent’s state.



Actions

msgbox


Implementation

Interface/API

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.



Agent ProgramActions

msgbox


Implementation

Interface/API

Agents have an “agent program” encoding the agent’s operating principles

The program consists of rules that are declarative and can be easily written or modified.



Integrity ConstraintsAction Constraints


msgbox


Implementation

Interface/API

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




msgbox


Implementation

Interface/API

Based on semantics and current state, actions are executed.

These actions change its own state and other agents

states as well.

ActionsIntegrity ConstraintsAction Constraints

Semantics


I.8 Agent Program (1)• Set of rules of the form Op

a(arg1,…,argn)<--- <code call condition> & Op1 a1(<args>) & … &

Opan(<args>)

• 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.


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,msgbox:getAllMsg()), =(Agent,Msg.Source)

FmaintainCourse(NoGo,Route,Loc)

in(NoGo,msgbox:getNoGo(Msg.ID)),

in(Loc,autoPilot:getLoc()),

in(Route,autoPilot:getRoute()),OprocessRequest(Msg.ID),DoadjustCourse(NoGo,Route,Loc)


II.1 Evacuation OperationsSituation:• 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


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 IMPACT’s capabilities during planning


Preconditions:• Airport available?• Weather ok for Plane?Subtasks: . . .

… methods …

Fixed WingsHelicopters

Select transportation means Select helicoptersSelect area (A)Deploy sec. force (F,A,H)

Embark sec. force(F,H)Fly(H,A)Disembark (F,H,A)

Position security force (F,A)

. . .

Preconditions:• Helicopters available?• Weather ok for Helis?Subtasks:•Select area•Deploy security force• …

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


II. 4 How to Agentize SHOP[D et al., CLIMA 2000] [D et al., Annals of Math & AI,

2002]

First, extend SHOP’s methods and operators to incorporate code calls– An agentized method is an expression of the form (:AgentMeth h t) where

h (the method’s head) is a compound task,(the method’s preconditions) is a code call

condition t is a task list

– An agentized operator is an expression of the form (:AgentOp h add del) where

h (the head) is a primitive taskadd and del are code call conditionsThe set of variables in add and del is a subset of

the set of variables in h


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.


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)


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 agent’s 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


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.


II. 9 Results (Memoization)


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?


III. Heavily Loaded Agents

• Problem:

ccc1: in(X,spatial:range(T1,40,50,25))

ccc2: in(Z,spatial:range(T2,40,50,50))

(spatial:range(T1,x,y,z) gives all points in T1 that are

at most z units away from (x,y))

Given a set of ccc’s (requests). Instead of executing them one-at-a-time, find more efficient procedures.

Clearly, ccc1 is a subset of ccc2 if T1 =T2.


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.


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 ccc’s)

T=T’ and X=X’ and Y=Y’ and Rad<Rad’ in(Z,spatial:range(T,X,Y,Rad)) subset in(W,spatial:range(T’,X’,Y’,Rad’))

ic (ie1 subset ie2 )


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 ccc’s:

1. Identical ccc’s.

2. Implied ccc’s.

3. Overlapping ccc’s (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.


III. 3 Example• Overlapping ccc’s:

ccc1: in(X,spatial:horizontal(map,100,200)).

ccc2: in(Z,spatial:horizontal(map,150, 250)).

Clearly, it is better to execute

ccc3: in(X,spatial:horizontal(map,100,250 )),

and then executing selections to get the results for ccc1 and ccc2.

spatial:horizontal(map,a,b) gives back all points (x,y)

in map s.t. a<y<b.


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).


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:

0.1

1

10

100

1000

10000

100000

1000000

2 4 6 8 10 12 14 16 18 20

no of queries

ex

ec

uti

on

tim

es

(m

illi

se

cs)

DFMerge(1)

DFMerge(2)

DFMerge(3)

BFMerge(1)

BFMerge(2)

BFMerge(3)

Astar


III.7 Results

Spatial domain: the classical method competes only beyond 70% sharingfactor.

Relational domain: the classical method competes only beyond 40% sharingfactor.

-600

-500

-400

-300

-200

-100

0

100

0 20 40 60 80 100

sharing factor

sa

vin

gs

pe

rce

nta

ge

DFMerge(1)

DFMerge(2)

DFMerge(3)

BFMerge(1)

BFMerge(2)

BFMerge(3)

Astar


III. 8 Results Our merge algorithms handle more than

twice as many simultaneous ccc’s 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 ccc’s pays off.


Summary

• IMPACT: Is based on formal, mathematical methods (Computational Logic). Identifies efficiently implementable classes of programs.

• IMPACT’ing 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.


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)


IV. Algorithms

• 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.

• Run-time– compute status

set.– trigger actions.– incrementally

compute status set (algorithm developed, not implemented).


IV.1 Conflict freedom

EXAMPLE:Consider the following two nonground 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 Head1Body1 Head2Body2 conflict in a state iff– the heads of the two

rules conflict, and – ccc’s 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.


IV.3 Conflict freedom performance• 1. Sufficient

Condition:• 2. Sufficient

Condition:

Even for many actions, it is fast.

Even for many arguments, it is fast.

0.008 sec 0.02 sec


IV. Algorithms



• 2 strong safety• 3 deontic stratification

• 4 boundedness:







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, terrain:getPlan(P1,P2,Vehicle)) & in(RP’, terrain:getPlan(P2,P3,Vehicle)) & in(P3, coord:nextPoint(P1,P2,Goal))

is safe, if P1,P2,Vehicle, Goal are given: Reorder the ccc!


IV.2 Strong safety• Strong safety requires not

only that queries are executable, but that their evaluation terminates in finite time.

The executable cccin(X, math:geq(25)) & in(Y, math:square(X)) & Y < 2000

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:

• math:geq(X) ($) • math:fct(X,Y,Z) (X,$,Z) Modification of the safety

algorithm: Safety + Look-up in Table. (Linear in size(ccc) + linear in size(table) .)


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

20 conj.

0.046


IV. Algorithms



• 2 strong safety

• 3 deontic stratification• 4 boundedness:







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.


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.

Number of rules: 200

0.26sec


• 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.


IV. Algorithms



• 2 strong safety

• 3 deontic stratification

• 4 boundedness:– unfold out agent

program.






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 ccc’s or negative action status atoms.


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

Computational Logic in IMPACT and in Agent Systems

Documents

Transcript of Computational Logic in IMPACT and in Agent Systems