1 / 48

IMPACT: A Heterogenous Agent System

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

lorant
Download Presentation

IMPACT: A Heterogenous Agent System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview • Part I: A Bird’s Eye View • Part II: Selected Topics in more Detail • Part III: Efficiently Implementing Agents

  3. 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: PlanningAMAI 01, (Dix,Munoz-Avila,Nau) References

  4. 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 I.1 Agent Definitions 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.

  5. I.2 Motivations • Agents are for everyone! Agentizearbitrary 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

  6. Arbitrary Code S can be characterized as a triple S=(T,F,C), where T is the set of all data types managed byS 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. I.3 What is Legacy Code?

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

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

  9. 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 probabilisticreasoningstructures

  10. 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 Agent Program Actions Concurr’cy Function Calls MSG Box Legacy/Special Data Structures Action Constraints Integrity Constraints Other agents (distributed) data - agent state NETWORK

  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. 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 II.1 Data type definitions

  16. II.2 AgentDE Data Type Definition Window

  17. 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 outputparameter 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 II.2 Specifying API Function Calls

  18. II.2 AgentDE Function Definition Window

  19. 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! II.3 Message Box

  20. 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)) II.4 Agent Integrity Constraints

  21. 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: P1P2 add list: in(true,terrain:useMap(Map1))& in(RP, terrain:getPlan(P1,P2,Vehicle)) delete list : {} (false) method: code II.5 Agent Action Base

  22. II.5 Action Base Screendump

  23. 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 action2not executable; This and other conflicts might be solved by ordering the actions in a suitable way. II.6 Notion of Concurrency

  24. 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 bothcomputeLoc(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 II.7 Action Constraints

  25. II.8 Agent Program • Set of rules of the form Opa(arg1,…,argn) <----- <code call condition> & +/- Op1a1(<args>) & … & +/- Opnan(<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 Opa(arg1,…,argn) is true.

  26. 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) II.8 Agent Program

  27. IMPACT Agent Architecture (rev) Agent Program Actions Concurr’cy Function Calls MSG Box Legacy/Special Data Structures Action Constraints Integrity Constraints Other agents (distributed) data - agent state NETWORK

  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 feasiblestatus 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. S is state-consistent in state O if and only if concurrently executing the set {a | DOa inS} 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 inS) does not have effects (add-list, delete list) contradicting the integrity constraints. II.9 State Consistency

  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. 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. II.10 Cost-based Semantics

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

  36. 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 rulesHead1Body1Head2Body2conflict in a state iff the heads of the two rules conflict, and ccc’s in the bodies of the rules are truein 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. II.1 Conflict freedom

  37. 1. Sufficient Condition: 2. Sufficient Condition: III.1 Conflict freedom performance 0.02 sec 0.008 sec Even for many actions, it is fast. Even for many arguments, it is fast.

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

  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, ifP1,P2,Vehicle, Goal are given: Reorder the ccc!

  40. 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) .) III.2 Strong safety

  41. 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 III.2 Example/Performance of (strong) safety 0.046 20 conj.

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

  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. 0.26sec Number of rules: 200

  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 datacomplexity of computing the above rational status set is polynomial (under appropriate assumptions).

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

  47. 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. III.5 Boundedness

  48. 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 III.6 Unfolding Performance

More Related