Upload
trevor-brendan-miles
View
213
Download
0
Embed Size (px)
Citation preview
2APL A Practical Agent Programming Language
March 6, 2007
Cathy Yen
Introduction
3APL (triple-a-p-l) An Abstract Agent Programming Language 3APL project was carried out by the Intelligent Systems Group
at Utrecht University, the Netherlands it is used for implementing cognitive agents and multi-agent
systems. It provides programming constructs to implement agents in
terms of beliefs, goals, plans, actions, and practical reasoning rules.
3apl program is executed by an interpreter in Java it makes use of an embedded Prolog reasoning engine. Intended to bridge the gap between agent theory and agent
programming
3APL Architecture
3APL Modules belief base
implemented by a subset of first-order predicate language (prolog like facts and rules)
goal base Implemented by expressions of an imperative language ( procedural or
to-do goals) plan base
built from basic actions composed through program operators sequential “;”, iteration “while-do”, conditional “if-then-else”
action base (capabilities) Implemented as triplets consisting of action name together with pre-
condition (under which action can be performed) and post-conditions (effect of the action after it’s performed).
goal plan rules Revision blocked actions, not achievable goals, generation/optimize
goals plan revision rules – used to revise, adopt, and drop plans Interpreter - implementing the Deliberation process
Applying reasoning rules, selecting goals and actions
Introducing 2APL
2APL (double-a-p-l) A Practical Agent Programming Language 2APL is designed and developed at the Intelligent Systems
Group at the University of Utrecht. 2APL is the successor of 3APL 2APL interpreter is built on the JADE platform. It provides practical extensions with constructs that makes it
easier to program in and debug Testing, different execution modes, event and exception handling
mechanism Supports the integration of declarative concepts (belief, goals) with
imperative style programming (events, plans) Aims at improving the practical application of BDI agent
programming language.
The 2APL Language
Specification in EBNF notation <atom> denotes a Prolog like atomic formula starting
with lowercase letter <Atom> <ident> denotes a string <Var> denotes a string starting with capital letter <ground_atom> denotes a grounded atomic formula <testbelief> with “?” is a syntactic entity of the 2APL
language
2APL Language Specification
2APL Language Specification
The 2APL Language
Composed of various ingredients Specify different aspects of the agency Programmed with initial state of ingredients Some ingredient change during the execution
Beliefs and goals Basic actions Plans Reasoning rules The deliberation cycle
Beliefs and goals The implementation of the initial belief base
starts with the keyword ’Beliefs:’ followed by one or more belief expressions of the form <belief>.
the agent believes that there is a bomb at location (3; 4), and that the blockworld environment is clean if there are no bombs anymore and the agent is not carrying a bomb.
Beliefs and goals The goals of a 2APL agent are implemented by its goal
base, which consists of formulas each of which denotes a situation the agent wants to realize. The implementation of the initial goal base starts with the keyword ’Goals:’ followed by a list of goal expressions of the form <goal>.
This goal base indicates that the agent wants to achieve a desirable situation in which the blockworld is clean.
Basic actions In order to achieve its goals, a 2APL agent needs to act.
Basic actions specify the capabilities that an agent can perform to achieve its desirable situation.
There are six types of basic actions are distinguished: Belief Update Action : actions to update the belief base Communication actions External actions Abstract actions Belief and Goal Test Actions : actions to test the belief and goal
bases Goal Dynamics Actions : actions to manage the dynamics of
goals.
Basic actions – Belief Update Action A belief update action updates the belief base of an agent when
executed. An agent can execute a belief update action if the pre-condition of
the action is derivable from its belief base. belief update actions starts with the keyword ’Beliefupdates:
an agent can remove a bomb if it is the same location as the bomb the PickUp() indicates that this belief update action can be
performed if the agent does not already carry a bomb and that after performing this action the agent will carry a bomb.
Basic actions – Communication Action A communication action passes a message to another
agent One version of the communication action is the
expression : Send(Receiver, Performative, Content). Receiver referring to the receiving agent, Performative is a
speech act name (e.g. inform, request, etc.), and Content is an expression representing the content of the message.
An example of a communication action is sally informing harry about a bomb location
Basic actions – External Action An external action is supposed to change the external
environment in which the agents operate. The effects of external actions are assumed to be
determined by the environment and might not be known to the agents
The external environment determines the effect of the action
an expression of the form Java(Env,ActionName,Return,Time-out) The parameter Env is the name of the agent’s environment to
which it has access, implemented as a Java class. The parameter ActionName is a method call (of the Java class)
that specifies the effect of the external action in the environment. Java(blockworld, east(),_,2).
This action causes an agent to go one step to the east in the blockworld environment.
Basic actions – Belief and Goal Test Action
A belief test action is to test whether a belief expression is derivable from an agent’s belief base it tests whether the agent has a certain belief.
A goal test action is to test whether a formula is derivable from the goal base whether the agent has a certain goal from
which the formula is derivableFor example, if an agent has a goal p(a) and
q(b), then the goal test action p(X)! succeeds resulting in the substitution [X/a].
Basic actions – Goal Dynamics Action
The adopt goal and drop goal actions are used to adopt and drop a goal to and from the agent’s goal base, respectively.The adopt goal action <adoptgoal> can have
two different forms: adopta(Ф) and adoptz(Ф). the drop goal action <dropgoal> can have
three different forms: dropGoal(Ф), dropSubGoal(Ф), and dropExactGoal(Ф).
Plans 2APL agent adapt plans in order to achieve its goals. Like 3APL, A plan consists of basic actions composed by
process operators. Harry enters the blockworld by performing an external
action enter. The plans of a 2APL agent are implemented by its plan
base. The implementation of the initial plan base starts with the
keyword ’Plans:’ followed by a list of plans.
Reasoning Rules The 2APL programming language
provides constructs to implement practical reasoning rules that can be used to implement the generation of plans.
Three types of practical reasoning rules are proposed: planning goal rules, procedural rules, and plan repair rules.
Reasoning Rules – Planning Goal Rules
A planning goal rule can specifies that an agent should generate a plan if it has certain goals and beliefs.
A planning goal rule of an agent can be applied when the goal and belief expressions are derivable from the agent’s goal and the belief bases, respectively.
A planning goal rule is of the form: <query>? "<-" <query> “|" <plan>
Reasoning Rules – Planning Goal Rules
a plan to achieve the goal clean(blockWorld) can be generated if the agent believes there is a bomb at position (X,Y).
Reasoning Rules – Procedural Rules
Procedural rules generate plans as a response to the reception of messages sent by other agents, events generated by the external environment, and the execution of abstract actions
like planning goal rules, a procedural rule has a belief condition indicating when a received event should cause the generation of a plan. a
procedural rule can be applied if the agent has received an event and the belief query of the rule is derivable from its belief base.
Reasoning Rules – Procedural Rules This rule indicates that if harry receives a message from sally
informing him that there is a bomb at position (X,Y) and harry does not believe there are any bombs, then harry updates his beliefs with this new fact and adds a goal to clean the blockworld again.
Reasoning Rules – Plan Repair Rules
A plan repair rule indicates that if the execution of an agent’s plan fails and the agent has a certain belief, then the failed plan should be replaced by another plan.
A plan repair rule hprrulei has the following form: <planvar> "<-" <query> “|" <planvar>
A plan repair rule of an agent can applied if: the execution of one of its plan fails, the failed plan can be matched with the abstract plan
in the head of the rule, and the belief query expression is derivable from the
agent’s belief base.
Reasoning Rules – Plan Repair Rules
an example of a plan repair rule of harry. This rule is used when the execution of a plan with the external action Java(blockworld,pickup(),L) fails. It fails due to there is no bomb to be picked up; it is possibly removed by another agent. The rule states that the plan should be replaced by a plan in which the agent updates its beliefs about the location of the bombs.
The Deliberation Cycle
Like 3APL agent, the beliefs, goals, plans and reasoning rules form the mental states of the 2APL agent.
deliberation cycle defines what the agent should do with these mental attitudes.
It states which step the agent should perform next, e.g. execute an action or apply a reasoning rule.
The deliberation cycle can be viewed as the interpreter of the agent program, as it determines which deliberation steps should be performed in which order
The Deliberation Cycle of a 2APL Agent
The 2APL Platform
A development tool that is designed to support the implementation and execution of multi-agent systems programmed in 2APL
The 2APL platform provides a graphical interface through which a user can develop and execute 2APL multi-agent
systems using several facilities, such as a syntax-colored editor, different execution modes, and several debugging/observation tools.
The platform allows communication among agents and can run on several machines connected in a network. Agents hosted on different 2APL platforms can communicate with each
other.
The 2APL Platform - startup
The 2APL Platform – with open file
When MAS is selected
Log tab - to read the multi-agent system logs
Files tab - to access the file in which the multi-agent system is specified
Messages tab - to observe the messages that are exchanged between the agents when they are executed.
When a specific agent is selected
Overview tab - to observe the selected agent’s mental state Log tab - to observe the agent’s execution log The Belief updates tab - to see the specification of belief update
actions that the agent can perform PG rules tab - to see the agent’s rule that specifies how and by
which plans the agent can realize its goals PC rules tab - to view the agent’s rules that specify how the
received events and messages should be handled PR rules tab - to view the agent’s rules that specify how the agent
can repair its failed plans Files tab to - access the complete source files that specify the
agent. The Edit button in the Files tab the source file will be open
JADE tools -
The RMA (Remote Monitoring Agent) tool - can be used to control the life cycle of the agent platform and of all the registered agents.
The sniffer - can be used for tracking messages exchanged in a JADE based environment. You can select agents to be sniffed. Every message directed to
this agent(s) or coming from this The introspector allows to monitor and control the life-
cycle of a running agent and its exchanged messages, both the queue of sent and received messages. It allows also to monitor the queue of behaviors, including executing them step-by-step.
RMA
Sniffer
2APL Specific tools
The Flexible Graphical Deliberation Cycle (FGDC) tool used to visualize and program the deliberation cycle of an agent.
The agent’s deliberation cycle is used to determine what the agent should do next, e.g.,
execute an action, or select a plan to reach a goal.
The state tracer used for showing the execution trace of an agent. Each state
shows the beliefs, plans, goals, and log of the agent as a result of executing one deliberation step.
FGDC tool
State tracer
2APL Environments
2APL agents can interact with environments that are implemented in Java.
You can implement your own environment, or use the “blockworld” environment that is provided by the 2APL platform (this option is not yet available)
Block World Environment
The blockworld is an external environment in which agents can perform actions.
The blockworldconsists of a n x n world where agents can move in four directions (north, south, east and west).
The world can contain bombs, stones, and traps. Agents can pickup and drop bombs.
Block World Environment
Reference
www.cs.uu.nl/3apl/Publications www.cs.uu.nl/2apl/downloads