Thomas Eiter, Technical Univ. of Vienna

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 agents behavior
• a notion of concurrency
• Non-core part of an agent consists of
• security structures
• meta-reasoning structures
• temporal and probabilistic reasoning structures

3
Motivating Example (RAMP)
4
Step 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

5
AgentDE Data Type Definition Window
6
Step 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

7
AgentDE Function Definition Window
8
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!

9
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, tankgetSpeed()) ? S ?
  MaxSpeed
• Helicopters have a maximal altitude.
• in(S, heligetAlt()) ? S ?
  MaxAlt
• Only one Map in use.
• in(true,terrainuseMap(Map1)) Map1 ? Map2
  ? in(false,terrainuseMap(M
  ap2))

10
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
• P1?P2
• add list
• in(true,terrainuseMap(Map1)) in(RP,
  terraingetPlan(P1,P2,Vehicle))
• delete list (false)
• method code

11
Action Base Screendump
12
Notion of Concurrency

• A notion of concurrency takes as input, a set of
  actions AS the agent is to execute and the
  agents 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.

13
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

14
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,msgboxgetAllMsg()),
  (Agent,Msg.Source)
• FmaintainCourse(NoGo,Route,Loc)
• ? in(NoGo,msgboxgetNoGo(Msg.ID)),
• in(Loc,autoPilotgetLoc()),
• in(Route,autoPilotgetRoute()),
• OprocessRequest(Msg.ID,terrain),
• DoadjustCourse(NoGo,Route,Loc)

15
Semantics of an agent

• Semantics refers to what the agents 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.

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
Deontic/Action Consistency

• 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 agents 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 both DOcomputeLoc(Report) and
  DOadjustCourse(Route,Loc) in the same
  status set.

18
Deontic/Action Closure

• Deontic Closure DCL(S) is the closure of S under
  the rule If Oa in S then Pa is in S .
• S is deontically-closed iff DCL(S ) S.
• Action Closure ACL(S ) is the closure of S under
  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 that OcomputeLoc(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 include DOcomputeLoc(Report) to
  ensure Action Closure.
• This has to be done for all status atoms.

19
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, tankgetSpeed()) ? 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.

20
Closure under Program Rules

• 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 rs body are in S
  and
• if no negative status atom in rs body is in S
  and
• the code call condition in rs 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

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

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

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.