IMPACT A Heterogenous Agent System Juergen Dix University

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

Overview Part I: A Bird’s Eye View Part II: Selected Topics in more Detail Part III: Efficiently Implementing Agents CACIC 2000, Ushuaia, Argentina 2

References 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) Funding: ARL/ DARPA/ NSF 3/ 0, 7 / 0, 2 Mio $ (Hendler/ Subrahmanian) URL: www. cs. umd. edu/projects/impact 4 years, in its 3 rd Heterogenous Agent Systems, MIT Press 2000 640 pages, released June 2000 CACIC 2000, Ushuaia, Argentina 3

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 All the above definitions are “behavioral” definitions. IMPACT provides a “structural” definition of an agent, together with formal models of the desired “behaviors” specified by FIPA, Co-ABS and Shoham. DARPA’s definition autonomous, adapt, cooperate CACIC 2000, Ushuaia, Argentina 4

I. 2 Motivations Agents are for everyone! Agentize arbitrary Legacy Code. Knowledge is distributed and heterogenous. -Call mechanism. Agents act wrt a clearly articulated semantics. Agent Program wrt Status Sets Agents Implementation should be feasible. Complexity Analysis, Regular Agents CACIC 2000, Ushuaia, Argentina Code 5

I. 3 What is Legacy Code? Arbitrary Code S can be characterized as a triple S=(T, F, C), where 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. 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 CACIC 2000, Ushuaia, Argentina State of an agent: at any State Change: only when an action is executed or a message has been received by another agent. 6

I. 4 IMPACT Agents: Data Access Code Call: d: f(arg 1, …, 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( ‘map 1’, 20, 50, 43). Code Call Atom: in(X, d: f(arg 1, …, 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( ‘map 1’, 20, 50, 43)). Find all routes returned by route planner between points (20, 20) and (50, 43) w. r. t. map 1. CACIC 2000, Ushuaia, Argentina 7

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. CACIC 2000, Ushuaia, Argentina 8

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 CACIC 2000, Ushuaia, Argentina 9

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 CACIC 2000, Ushuaia, Argentina 1

I. 7 Overall Architecture Registration: Agents offer Services Service Description Language: Describing Services. Matchmaking: Using Thesauri and Ontologies. CACIC 2000, Ushuaia, Argentina 1

I. 8 IMPACT Agent Architecture Agent Program Actions Concurr’cy MSG Box Function Calls Legacy/Special Data Structures Action Constraints Integrity Constraints Other agents NETWORK CACIC 2000, Ushuaia, Argentina (distributed) data - agent state 1

I. 9 Agent Decision Cycle What is an agent doing? Computing its status set and acting accordingly. Evaluate messages. Compute Status Set. Take Actions. CACIC 2000, Ushuaia, Argentina 1

II. Motivating Example (RAMP) CACIC 2000, Ushuaia, Argentina 1

II. 1 Data type definitions EXAMPLE: Your agent is built on top of some body of code (written in C, C++, Java, or whatever). ; ; All Agents: ; Int, Bool, List, String ; Speed, Angle Tanks: ; What data types are manipulated by that code ? ; ; Tracking: ; ; Each such type must be explicitly defined via the IMPACT Agent. DE (Agent Development Environment). CACIC 2000, Ushuaia, Argentina Vehicle Type Helicopters: ; ; ; 2 D Position, Route 2 D Map 3 D-, 4 D Position 3 D Map (like DTED) Terrain: ; ; Flight Plan Satellite Report 1

II. 2 Agent. DE Data Type Definition Window CACIC 2000, Ushuaia, Argentina 1

II. 2 Specifying API Function Calls Your agent manipulates its data types via a set of API function calls. EXAMPLE: ; Tanks: ; You must define these function calls within Agent. DE. ; ; its name its input parameter names and types its output parameter names and types. Terrain: ; For each function call, specify: ; ; Ushuaia, Argentina set_alt(Altitude) into Bool get_fuel() into Real Tracking: ; CACIC 2000, visible(Map, Point 1, Point 2) into Bool get. Plan(P 1, P 2, Vehicle) into Plan Helicopters: ; ; aim_gun(Point, angle) into Bool fire_gun() into Bool get_position(Agent. Id) into 2 DPoint get_enemies(Area) into Enemy. List 1

II. 2 Agent. DE Function Definition Window CACIC 2000, Ushuaia, Argentina 1

II. 3 Message Box Every agent has access to a message box which contains tuples of the form (‘i/o’, ‘src’, ‘dest’, ‘message’, time). A message ‘msg’ is a table of triples (Field. Name, Field. Type, value) Message Box Functions The Agent. DE environment automatically provides access to the message box. No need to define message box types and functions - these are available to all agents ! CACIC 2000, Ushuaia, Argentina send. Msg(‘src’, ‘dest’, ‘msg’): generates the quintuple (o, ‘src’, ‘dest’, ‘msg’, t) and puts it into the Msg. Box get. Msgs(‘src’): reads all tuples (i, ‘src’, ‘dest’, ‘msg’, t) from Msg. Box timed_get. Msg(op, valid): reads all messages tup in Msg. Box where tup. time op valid holds. Plus some other functions! 1

II. 4 Agent Integrity Constraints The agent developer must write a set of integrity constraints for his/her agent. EXAMPLES: ? Tanks have a maximal speed. in(S, tank: get. Speed()) S Max. Speed 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. ? CACIC 2000, Ushuaia, Argentina Helicopters have a maximal altitude. in(S, heli: get. Alt()) S Max. Alt Only one Map in use. in(true, terrain: use. Map(Map 1)) & Map 1 Map 2 in(false, terrain: use. Map(Map 2)) 2

II. 5 Agent Action Base Each agent has a set of actions it can execute. EXAMPLE: Each of these actions must be “declared”. Name: evaluateground. Plan arguments: Map 1, P 2, Vehicle of appropriate types precondition: P 1 P 2 add list: in(true, terrain: use. Map(Map 1)) & in(RP, terrain: get. Plan(P 1, P 2, Vehicle)) delete list : {} (false) method: code 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 CACIC 2000, Ushuaia, Argentina 2

II. 5 Action Base Screendump CACIC 2000, Ushuaia, Argentina 2

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). EXAMPLE: AS = { action 1, action 2 } F precondition: in(t 1, cc) delete list: in(t 1, cc) add list: {} It forms out of AS a single action to execute. Naive: Takes add/del list of all actions and executes. Linear. Seq. Conc: Finds an executable sequence. NPcomplete. Full. Conc: Checks that all sequences are executable. Co -NP-complete. CACIC 2000, Ushuaia, Argentina action 1: F action 2: precondition: in(t 1, cc) add list, delete list: {} Problem: Executing action 1 makes action 2 not executable; This and other conflicts might be solved by ordering the actions in a suitable way. 2

II. 7 Action Constraints Specify that in a given situation, certain actions cannot be concurrently executed. Agent developer specifies action constraints in Agent. DE. EXAMPLE: F not both compute. Loc(Report) and adjust. Course(Route, Loc) can be executed concurrently. F not both evaluateground. Plan(Map, P 1, P 2, V 1) and In some applications, one may not need to define action constraints at all. CACIC 2000, Ushuaia, Argentina evaluateground. Plan(Map, P 1, P 2, V 2) can be executed concurrently if V 1 V 2 2

II. 8 Agent Program Set of rules of the form Op a(arg 1, …, argn) <----- <code call condition> & +/- Op 1 a 1(<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(arg 1, …, argn) is true. CACIC 2000, Ushuaia, Argentina 2

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. CACIC 2000, Ushuaia, Argentina EXAMPLE: Oprocess. Request(Msg. ID, Agent) in(Msg, msgbox: get. All. Msg()), =(Agent, Msg. Source) Fmaintain. Course(No. Go, Route, Loc) in(No. Go, msgbox: get. No. Go(Msg. ID)), in(Loc, auto. Pilot: get. Loc()), in(Route, auto. Pilot: get. Route()), Oprocess. Request(Msg. ID, terrain), Doadjust. Course(No. Go, Route, Loc) 2

IMPACT Agent Architecture (rev) Agent Program Actions Concurr’cy MSG Box Function Calls Legacy/Special Data Structures Action Constraints Integrity Constraints Other agents NETWORK CACIC 2000, Ushuaia, Argentina (distributed) data - agent state 2

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. CACIC 2000, Ushuaia, Argentina 2

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. CACIC 2000, Ushuaia, Argentina 2

II. 9 State Consistency EXAMPLE: ? 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. Recall our integrity constraints from a previous slide: O O in(S, tank: get. Speed()) S Max. Speed in(S, heli : get. Alt()) S Max. Alt 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. CACIC 2000, Ushuaia, Argentina 3

II. 9 Example Feasible Status Sets Program: Op. R ccc 1 Doa. C ccc 1 Fm. C ccc 2, Op. R, Doa. C state O: ccc 1, ccc 2 are true S = { Op. R, Dop. R, Pp. R, Doa. C, Pa. C, Fm. C } is a feasible status set CACIC 2000, Ushuaia, Argentina 3

II. 9 Agent. DE Feasible Status Set Computation Screendump CACIC 2000, Ushuaia, Argentina 3

II. 10 Cost-based Semantics Agent programs may have zero, one, or many feasible status sets. Objectives may consider: Objective functions may be used by an agent to optimize what it does. CACIC 2000, Ushuaia, Argentina 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. 3

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. CACIC 2000, Ushuaia, Argentina 3

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. CACIC 2000, Ushuaia, Argentina Run-time compute status set. trigger actions. incrementally compute status set (algorithm developed, not implemented). 3

II. 1 Conflict freedom Two ground rules Head 1 Body 1 Head 2 Body 2 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. EXAMPLE: Consider the following two non ground rules: ? Fmaintain. Course(No. Go, Route, Loc) ccc 1 , Do action 1 Omaintain. Course(No. Go, Route, Loc ) ccc 2 , F action 2, ? Both can be conflict-free (depending on ccc 1, ccc 2 being true in the state) or not. CACIC 2000, Ushuaia, Argentina 3

III. 1 Conflict freedom performance 1. Sufficient Condition: 0. 008 sec Even for many actions, it is fast. CACIC 2000, Ushuaia, Argentina 2. Sufficient Condition: 0. 02 sec Even for many arguments, it is fast. 3

III. Algorithms Compile time check syntax check regularity – 1 conflict freedom – 2 strong safety – 3 deontic stratification Run-time compute status set. trigger actions. incrementally compute status set (algorithm developed, not implemented). – 4 boundedness: unfold out agent program. Compute initial status set. • CACIC 2000, Ushuaia, Argentina 3

III. 2 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: get. Plan(P 1, P 2, Vehicle)) & in(RP’, terrain: get. Plan(P 2, P 3, Vehicle)) & in(P 3, coord: next. Point(P 1, P 2, Goal)) is safe, if P 1, P 2, Vehicle, Goal are given: Reorder the ccc! CACIC 2000, Ushuaia, Argentina 3

III. 2 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 Agent. DE “infiniteness table” listing all code calls returning infinite answers. CACIC 2000, Ushuaia, Argentina 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). ) 4

III. 2 Example/Performance of (strong) safety EXAMPLE: Code call condition ccc with up to 20 conjuncts. 0. 046 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 CACIC 2000, Ushuaia, Argentina 20 conj. 4

III. Algorithms Compile time check syntax check regularity – 1 conflict freedom – 2 strong safety – 3 deontic stratification Run-time compute status set. trigger actions. incrementally compute status set (algorithm developed, not implemented). – 4 boundedness: unfold out agent program. Compute initial status set. • CACIC 2000, Ushuaia, Argentina 4

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) , misc 1 ? Do compute(Loc) Do something(P), misc 2 something(P) ¬ Do compute(Loc), misc 3 ? Do compute(Loc) ¬ O compute(Loc) , misc 4 ? But the following is harmless: compute(Loc) ¬ F compute(Loc) , misc 4 Do Do A deontically stratified program comes in finitely many strata, negative dependencies lead to strictly lower strata. CACIC 2000, Ushuaia, Argentina 4

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. CACIC 2000, Ushuaia, Argentina 0. 26 sec Number of rules: 200 4

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). CACIC 2000, Ushuaia, Argentina 4

III. Algorithms Compile time check syntax check regularity – 1 conflict freedom – 2 strong safety – 3 deontic stratification Run-time compute status set. trigger actions. incrementally compute status set (algorithm developed, not implemented). – 4 boundedness: • unfold out agent program. Compute initial status set. CACIC 2000, Ushuaia, Argentina 4

III. 5 Boundedness Consider the program ? Do com(Loc) Do some(P), ccc 1 Do some(P) Do else(Loc), ccc 2 Do else(P) ccc 3 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. and let ccc 3 be false in the state. Instead of checking Do-actions at run-time we simplify the program at compile time into: Do com(Loc) ccc 3, ccc 2, ccc 1 Do some(P) ccc 3, ccc 2 Do else(P) ccc 3 ? Replace successively in all rules the positive action atoms in the bodies. ? Boundedness: If, eventually, all positive body atoms disappear: larger but simpler program. CACIC 2000, Ushuaia, Argentina 4

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) CACIC 2000, Ushuaia, Argentina 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 4