Building IMPACT Agents: A Step by Step Procedure

1. Building IMPACT Agents: A Step by Step Procedure Thomas Eiter, Technical Univ. of Vienna joint work with V.S. Subrahmanian, Univ. of Maryland 1

2. Motivation • A step by step procedure to build an IMPACT agent. • “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

3. Motivating Example (RAMP)

4. 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 Step 1: Data type definitions

5. AgentDE Data Type Definition Window

6. 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 Step 2: Specifying API Function Calls

7. AgentDE Function Definition Window

8. 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! Message Box

9. 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)) Agent Integrity Constraints

10. 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 Agent Action Base

11. Action Base Screendump

12. 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. Notion of Concurrency

13. 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 Action Constraints

14. 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) Agent Program

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

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

17. To be deontically consistent, S must satisfy the following: if Oa is in S then Wa must not be in S if Pa in S then Fa must not be in S if Pa in S, then the agent’s state must satisfy Pre(a). To be action-consistent, S must satisfy the following: for each action constraint ac, if the agent state satisfies the body of ac, then the set { DOa | a in head(ac) } cannot be a subset of S. EXAMPLE: We cannot have both FmntnCourse(NoGo,Route,Loc) DOmntnCourse(NoGo,Route,Loc) in the same status set. We cannot have bothDOcomputeLoc(Report) and DOadjustCourse(Route,Loc)in the same status set. Deontic/Action Consistency

18. Deontic ClosureDCL(S) is the closure of S under the rule “If OainSthenPais in S”. S is deontically-closed iff DCL(S)= S. Action ClosureACL(S) is the closure of Sunder the rules If Oa in S then DOa in S . If DOa in S then Pa in S . S is action-closed iff ACL(S)= S. EXAMPLE: It is possible thatOcomputeLoc(Report)is in S but PcomputeLoc(Report)is not. Then it has to be added. This has to be done for all status atoms. We also have to includeDOcomputeLoc(Report)to ensure Action Closure. This has to be done for all status atoms. Deontic/Action Closure

19. 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. State Consistency

20. APP(S, O) is the set of all status atoms inferrable in one step by agent A, assuming its state is O and it has already inferred S. APP(S, O) is constructed by examining each rule r in the agent program as follows: if all positive status atoms in r’s body are in S and if no negative status atom in r’s body is in S and the code call condition in r’s body is true in O THEN insert head of r into APP(S, O). S is closed under program rules iff S contains APP(S, O). EXAMPLE: OpR  ccc1 FmC  ccc2, OpR, DoaC state O: ccc1, ccc2 are true S ={ DoaC } APP(S, O) = { OpR } S is not closed add a rule: DoaC  ccc1 S´={ DoaC, OpR, FmC } is closed Closure under Program Rules

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

22. AgentDE Feasible Status SetComputation Screendump

23. 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. EXAMPLE: S1 = { Dofly_to(x1,y1,a1,s1),… } S2 = { Dofly_to(x2,y2,a2,s2),….} Objective Function 1: minimize fuel consumption. Choose S1, if the cost of fly_to(x1,x2,a1,s1) is lower than fly_to(x2,y2,a2,s2) . Objective Function 2: minimize in-flight threat. Choose S1, if the threat along the route fly_to(x1,x2,a1,s1) is lower than the threat along the route fly_to(x2,y2,a2,s2) . Objective Function 3: select destination with lower threat and/or greater tactical value. Cost-based Semantics

24. 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, we have studied algorithms and complexity for executing such status sets.