impact: a heterogenous agent system

Juergen Dix

University of Koblenz

Technical University of Vienna

(University of Maryland)(Joint Work with

VS Subrahmanian, P. Bonatti, Th. Eiter,

S. Kraus, Fatma Ozcan, Rob Ross)

1

IMPACT: A Heterogenous Agent System

2CACIC 2000,

Ushuaia, Argentina

Overview

Part I: A Bird’s Eye View

Part II: Selected Topics in more Detail

Part III: Efficiently Implementing Agents

3CACIC 2000,

Ushuaia, Argentina

References

Funding: ARL/ DARPA/ NSF 3 /

0,7 / 0,2 Mio $ (Hendler/ Subrahmanian)

URL: www.cs.umd.edu/projects/impact

4 years, in its 3rd

Heterogenous Agent Systems, MIT Press 2000 640 pages, released June 2000

Publications:

Agent Programs, Complexity, AIJ 99 I, II (Eiter/VS/Pick)

Meta-Agent Programs, JLP 00 (Dix/VS/Pick)

Temporal Agent Programs,AIJ 01 (Dix/Kraus/VS)

Probabilistic Agent Programs, TOCL 00 (Dix/Nanni/VS)

Heavily Loaded Agents, TOCL 01 (Dix,Ozcan,VS)

Impacting SHOP: Planning AMAI 01, (Dix,Munoz-Avila,Nau)

4CACIC 2000,

Ushuaia, Argentina

I.1 Agent Definitions

Shoham’s definition- an agent is a program supporting:

Ongoing execution, planning adaptiveness, autonomy reactivity, mobility, intelligence communication, negotiation

FIPA’s definition speech, visual, I/O primitives messaging languages

DARPA’s definition autonomous, adapt, cooperate

All the above definitions are “behavioral” definitions. IMPACT provides a “structural” definitionof an agent, together with formal

models of the desired “behaviors”specified by FIPA, Co-ABS and

Shoham.

5CACIC 2000,

Ushuaia, Argentina

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

6CACIC 2000,

Ushuaia, Argentina

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

characterized as a triple S=(T,F,C), where

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 software code.

State Change: only when an action is executed or a message has been received by another agent.

7CACIC 2000,

Ushuaia, Argentina

I.4 IMPACT Agents: Data Access

Code Call: d:f(arg1,…,argk). Execute function f defined in agent d on the specified arguments. Returns a set of objects. Oracle:select( ‘depots.rel’,item,=,combat boots) Route:plan( ‘map1’,20,20,50,43).

Code Call Atom: in(X,d:f(arg1,…,argk)). Succeeds if X is in the set of objects returned. in(X, Oracle:select( ‘depots.rel’,item,=,combat boots)). Find all

tuples with item field equal to “combat boots” 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.

8CACIC 2000,

Ushuaia, Argentina

I.4 Data Access: Code Call Conditions

A conjunction of code call atoms and comparison atoms.

in(X, Oracle:select( ‘depots.rel’,item,=,combat boots )) & X.qty > 1000 & in(R,route:plan( ‘map’,99,25,X.xc,X.yc)).

The above says: find X,R such that: X is a tuple in an Oracle “depot” relation specifying a depot with

over 1000 combat boots, and Y is a route from the location of that depot to a location (99,25)

where the entity requesting the combat boots is located.

9CACIC 2000,

Ushuaia, Argentina

I.5 Motivation

“Core” part of an agent consists of: a set of data type definitions and API function calls manipulating

them a message type and API functions for messaging constraints:

integrity constraints on the agent state action constraints

a set of actions the agent may take an agent program specifying the agent’s behavior a notion of concurrency

“Non-core” part of an agent consists of security structures meta-reasoning structures temporal and probabilistic reasoning structures

10

CACIC 2000, Ushuaia, Argentina

I.6 Agentization Procedure To convert a program to an agent, do the following:

describe types manipulated by program describe I/O types of API function calls define agent’s integrity constraints select/define actions that can be executed by agents select/define concurrency notion define agent’s action constraints define agent’s agent program

In addition, one may specify yellow pages info and register agent with IMPACT

Server specify connect information

11


I.7 Overall Architecture

Registration: Agents offer Services

Service Description Language: Describing Services.

Matchmaking: Using Thesauri and Ontologies.

12


I.8 IMPACT Agent Architecture

Legacy/SpecialData Structures

(distributed) data- agent state

Function CallsConcurr’cy

MSG Box

AgentProgram

Otheragents

Actions

NETWORK

Action Constraints

Integrity Constraints

13


I.9 Agent Decision Cycle

What is an agent doing?

Computing its status set and acting accordingly. Evaluate

messages.

Compute Status Set.

Take Actions.

14


II. Motivating Example (RAMP)

15


II.1 Data type definitions

Your agent is built on top of some body of code (written in C, C++, Java, or whatever).

What data types are manipulated by that code ?

Each such type must be explicitly defined via the IMPACT AgentDE (Agent Development Environment).

EXAMPLE:

All Agents: Int, Bool, List, String Speed, Angle

Tanks: 2D Position, Route 2D Map

Tracking: Vehicle Type

Helicopters: 3D-, 4D Position 3D Map (like DTED)

Terrain: Flight Plan Satellite Report

16


II.2 AgentDE Data Type Definition Window

17


II.2 Specifying API Function Calls Your agent manipulates its

data types via a set of API function calls.

You must define these function calls within AgentDE.

For each function call, specify:

its name its input parameter names

and types its output parameter names

and types.

EXAMPLE:

Tanks: aim_gun(Point,angle) into Bool fire_gun() into Bool

Terrain: visible(Map,Point1,Point2) into Bool getPlan(P1,P2,Vehicle) into Plan

Helicopters: set_alt(Altitude) into Bool get_fuel() into Real

Tracking: get_position(AgentId) into 2DPoint get_enemies(Area) into EnemyList

18


II.2 AgentDE Function Definition Window

19


II.3 Message Box Every agent has access to a

message box which contains tuples of the form (‘i/o’, ‘src’, ‘dest’, ‘message’,time).

The AgentDE environment automatically provides access to the message box.

No need to define message box types and functions - these are available to all agents !

A message ‘msg’ is a table of triples (FieldName,FieldType,value)

Message Box Functions sendMsg(‘src’, ‘dest’, ‘msg’):

generates the quintuple (o,‘src’, ‘dest’, ‘msg’,t) and puts it into the MsgBox

getMsgs(‘src’): reads all tuples (i,‘src’, ‘dest’, ‘msg’,t) from MsgBox

timed_getMsg(op,valid): reads all messages tup in MsgBox where tup.time op valid holds.

Plus some other functions!

20


II.4 Agent Integrity Constraints The agent developer must

write a set of integrity constraints for his/her agent.

Integrity constraints specify conditions that the agent state MUST always satisfy.

For many agents, no integrity constraints may apply and this can be left blank.

EXAMPLES:

Tanks have a maximal speed.

in(S, tank:getSpeed()) S MaxSpeed

Helicopters have a maximal altitude.

in(S, heli:getAlt()) S MaxAlt

Only one Map in use.

in(true,terrain:useMap(Map1)) & Map1 Map2 in(false,terrain:useMap(Map2))

21


II.5 Agent Action Base Each agent has a set of

actions it can execute.

Each of these actions must be “declared”.

An action has 6 parts: action name and arguments argument types precondition - code call

condition add list - code call condition delete list - code call

condition method - code that

implements the action

EXAMPLE:

Name: evaluategroundPlan

arguments: Map1, P1, P2, Vehicle of appropriate types

precondition: P1P2

add list: in(true,terrain:useMap(Map1)) &

in(RP, terrain:getPlan(P1,P2,Vehicle)) delete list : {} (false)

method: code

22


II.5 Action Base Screendump

23


II.6 Notion of Concurrency A notion of concurrency takes

as input, a set of actions AS the agent is to execute and the agent’s state (implicit).

It forms out of AS a single action to execute.

Naive: Takes add/del list of all actions and executes. Linear.

SeqConc: Finds an executable sequence. NP-complete.

FullConc: Checks that all sequences are executable. Co-NP-complete.

EXAMPLE:

AS = { action1, action2 }

action1: precondition: in(t1,cc) delete list: in(t1,cc) add list: {}

action2: precondition: in(t1,cc) add list, delete list: {}

Problem: Executing action1 makes action2 not executable;

This and other conflicts might be solved by ordering the actions in a suitable way.

24


II.7 Action Constraints Specify that in a given

situation, certain actions cannot be concurrently executed.

Agent developer specifies action constraints in AgentDE.

In some applications, one may not need to define action constraints at all.

EXAMPLE:

not both computeLoc(Report) and adjustCourse(Route,Loc) can be executed concurrently.

not both evaluategroundPlan(Map,P1,P2,V1)

and evaluategroundPlan(Map,P1,P2,V2)

can be executed concurrently if V1 V2

25


II.8 Agent Program Set of rules of the formOp a(arg1,…,argn) <----- <code call condition> &

+/- Op1 a1(<args>) & … & +/- Opn an(<args>).

Op is a “deontic modality” and is either P - permitted O - obligatory Do - do F - forbidden W - obligation is waived.

If the code call condition is true and the deontic modalities in the rule body are true, then Op a(arg1,…,argn) is true.

26


II.8 Agent Program Most important part of the

agent.

Specifies the operating rules for the agent. What is permitted (P) ? What is forbidden (F) ? What is to be done (Do) ? What is obligatory (O) ? What is waived (W) ?

Agent program rules must be carefully crafted to avoid inconsistency and other problems.

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,terrain),DoadjustCourse(NoGo,Route,Loc)

27


IMPACT Agent Architecture (rev)

Legacy/SpecialData Structures

(distributed) data- agent state

Function CallsConcurr’cy

MSG Box

AgentProgram

Otheragents

Actions

NETWORK

Action Constraints

Integrity Constraints

28


II.9 Semantics of an agent

Semantics refers to what the agent’s obligations, permissions, and actions to be done are at a given instant of time.

Status Atoms are of the form Pa,Fa,Oa,Wa,DOa where a is an action.

A status set is a set of status atoms.

Which status sets “make sense” for a given agent?

We call such status sets feasible status sets.

29


II.9 Feasible Status Sets For a status set S to be feasible, it must satisfy five types

of conditions:

Deontic Consistency: one cannot be both forbidden and permitted to do something, etc.

Action Consistency: the DO actions in a status set cannot violate the action constraints.

Deontic/Action Closure: if an action is obligatory, it must be permitted, done, etc.

State Consistency: if the agent executes all the DO actions in a status set, then the resulting state must satisfy the integrity constraints.

Closure under Program Rules: if the body of a rule in the agent program is true, then the rule head must be in S.

30


II.9 State Consistency

S is state-consistent in state O if and only if

concurrently executing the set

{a | DOa in S}

yields a state O’ that satisfies all integrity constraints.

EXAMPLE:

Recall our integrity constraints from a previous slide:

in(S, tank:getSpeed())

S MaxSpeed in(S, heli :getAlt())

S MaxAlt

We have to make sure, that executing all actions that have to be executed (DOa in S) does not have effects (add-list, delete list) contradicting the integrity constraints.

31


II.9 Example Feasible Status Sets

Program:

OpR ccc1 DoaC ccc1 FmC ccc2, OpR, DoaC

state O: ccc1, ccc2 are true

S = { OpR, DopR, PpR, DoaC, PaC, FmC }

is a feasible status set

32


II.9 AgentDE Feasible Status SetComputation Screendump

33


II.10 Cost-based Semantics

Agent programs may have zero, one, or many feasible status sets.

Objective functions may be used by an agent to optimize what it does.

Objectives may consider: cost of executing actions, desirability of resulting state, or combinations of the above

Hence, if two status sets are feasible, one may be “better” than the other according to an objective function, and the agent may act accordingly.

34


II.11 Other semantics Many refinements of the feasible status set semantics

are possible. Rational status set Reasonable status sets F-preferred status sets P-preferred status sets etc.

In 2 AI Journal papers, algorithms and complexity for executing such status sets were considered.

Extensions to meta, temporal, probabilistic, secure programs must define appropriate notions.

35


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

36


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

37


III.1 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

38


III. Algorithms


– 1 conflict freedom

– 2 strong safety– 3 deontic stratification– 4 boundedness:

• unfold out agent program.

Compute initial status set.



39


III.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!

40


III.2 Strong safety Strong safety requires not only

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

The executable code call condition in(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 in AgentDE “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) X>5 & Z<3

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

41


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

42


III. Algorithms


– 1 conflict freedom– 2 strong safety

– 3 deontic stratification

– 4 boundedness:• unfold out agent

program. Compute initial status set.



43


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

44


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

45


III.4 Regular Agent 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 (under appropriate assumptions).

46


III. Algorithms


– 1 conflict freedom– 2 strong safety– 3 deontic stratification

– 4 boundedness:• unfold out agent

program. Compute initial status set.



47


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

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.

48


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

impact: a heterogenous agent system

Documents