Thomas Eiter, Technical Univ. of Vienna joint work with V.S. Subrahmanian, Univ. of Maryland 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

Building IMPACT Agents: A Step by Step Procedure

21999 IMPACT Workshop

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 probabilistic reasoning structures


Motivating Example (RAMP)


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


AgentDE Data Type Definition Window


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


AgentDE Function Definition Window


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!


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

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: P1P2

add list: in(true,terrain:useMap(Map1)) &

in(RP, terrain:getPlan(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 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.

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,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)

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

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

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.

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

Documents

impact workshop step

impact workshop message

agent developer

agent program

hisher agent

impact workshop motivation

message type

agent state action constraints