Upload
reynard-gibbs
View
212
Download
0
Embed Size (px)
Citation preview
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
CACIC 2000, Ushuaia, Argentina
I.7 Overall Architecture
Registration: Agents offer Services
Service Description Language: Describing Services.
Matchmaking: Using Thesauri and Ontologies.
12
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
I.9 Agent Decision Cycle
What is an agent doing?
Computing its status set and acting accordingly. Evaluate
messages.
Compute Status Set.
Take Actions.
15
CACIC 2000, Ushuaia, Argentina
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
17
CACIC 2000, Ushuaia, Argentina
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
19
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
23
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
33
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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).
39
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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).
43
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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).
47
CACIC 2000, Ushuaia, Argentina
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
CACIC 2000, Ushuaia, Argentina
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