capabilities 2/3
Fig.3.Element creation cases:a)instantiation of a reference,b)instantiation of an
element,when an abstract element exists inside,c)instantiation of an element,when
a reference exists outside,d)instantiation of an abstract element assigned from the
outside
has to be assured that changes outside of a capability do not a?ect the internal
functionality,as this would violate the information hiding principle.
To solve these issues semantics is associated to the creation process of ele-
ments and proxies in all possible cases.On the one hand,a proxy might be in
the outer capability(i.e.a reference)or in the inner capability(i.e.an abstract
element).On the other hand,creation of an element might be issued on the
original element itself,or the proxy.This leads to four di?erent cases(cf.Fig.3):
In the first two cases(a and b)the creation is triggered inside the outer
capability.It is safe to create elements in the inner capability,because they are
an explicit part of the interface.In the last case(d)the initially created element
in the inner capability is just a proxy.Therefore it is necessary to subsequently
create the original element in the outer capability.As can be seen in the figure,it
is only in case c,that a proxy element is not instantiated.In this case the original
element is part of the inner capability and creation is triggered from the inside.
Creating the outer element would lead to problems,because the element(e.g.an
event)might inadvertently be handled in the outside capability,thereby breaking
functionality of the inner capability.The export/reference concept assures
that an element can be used from the outside(e.g.a goal created outside),but
the local functionality(e.g.the goal processing)remains unchanged.Abstract
elements provide a way for the inner capability to connect to functionality of an
outer capability.3.4 Initial Configurations
One important aspect of reusability is parametrization of the reused components,
to adapt them to the special requirements imposed by settings in which they
get reused[7].When considering parametrization of capabilities,two questions
have to be answered:First,what can be parametrized,i.e.what constitutes a
configuration of a capability?Second,how can a capability be parametrized from
the outside,when its elements are encapsulated?
As an answer to the first question,we introduce the notion of an initial
mental state.The initial mental state is a simplified runtime state of a capability,
containing the initial values of beliefs(which are singleton instances),as well as
zero or more initial instances of the other elements(such as goals,plans,and
events)with initial properties(e.g.goal parameter values).In addition,the initial
state defines recursively the initial mental state of all included subcapabilities.
To parametrize a capability,its initial mental state has to be adapted to
the current needs.Respecting the information hiding principle,it should not be
possible to specify all elements of the initial mental state from the outside.E.g.
some capability might require an instance of a maintain goal for proper opera-
tion,but the maintain goal should not be visible to the outside.Our approach
allows parametrization at two levels of granularity:The capability level,and the
level of individual elements.A capability itself can provide one or more initial
configurations,which can be referenced by a given name.In this way,common
use cases can be captured as a whole,allowing easy out-of-the-box reuse.These
configurations are part of the capability,and therefore can contain exported and
internal elements.Parametrization at the level of individual elements is only
possible when these elements are exported.For example for exported beliefs,the
outer capability can override the initial value by defining a reference and locally
assigning a new value to this referenced belief.
3.5 Dynamic Runtime Composition
The new improved capability concepts is also capable of handling various issues
concerning runtime modification of agent behaviour.For that purpose generally
two distinct kinds of operations can be performed.
On the one hand complete capabilities could be plugged into or removed
from an agent at runtime.The addition of a capability at runtime is conceptu-
ally not di?cult as it requires only information about the capability type,its
initial state,the target capability within the agent and some connection data
such as the instance name of the new capability.Given that all information is
provided the capability can be linked with the target capability using the con-
nection data and can subsequently be started meaning that its initial state will
be executed.The removal of a capability at runtime is far more intricate as the
agent’s execution state must be considered before a capability can be removed
safely.This means the agent e.g.could currently utilize plans or goals from the
capability to remove and it needs to be determined if these plans or goals should
be executed completely before removal.On the other hand the modification of a capability at runtime should be
possible.Prerequisite for this modifications is that each capability relies on its
personal copy of the underlying capability model,so that changes can be per-
formed without a?ecting other capability instances of the same type.The cre-
ation process for a new model element(regardless if it is an element or an element
reference)consists basically of two steps.First,the element has to be created
in the capability model.In a second step the elements has to be registered at
the runtime layer,making the agent aware of its new element.For the deletion
of an element at runtime a similar process can be used.The element has to be
deregistered at the capability instance and can afterwards be deleted from the
model.In this respect it has again to be considered if existing elements of the
removed type should be discarded at once.
For the complete freedom of removing or exchanging a capability at runtime
it is a necessary prerequisite that a capability instance is a self-contained entity
with well-defined connection points.In the proposed capability approach this is
supported by the locality principle which is also valid for capabilities at runtime.
Elements from other capabilities are not accessed directly but through local
proxies.When a capability or element of a capability is removed,proxies in
other capabilities can be preserved,and later be reconnected when an alternative
capability or element is available.Further elaborating and implementing the
details of this mechanism is planned for future work.
3.6 Discussion
Capabilities are a decomposition concept for agents allowing to reuse function-
ality captured in a self-contained module with clearly defined import and export
interface.This form of reuse is termed blackbox-reuse as only the interface and
no details about the internals are known.In contrast to(more flexible)whitebox-
reuse changing the internals of a blackbox-component does not break existing
usages,leading to application designs that are easier to maintain[16].
Furthermore,the capability concept addresses most of the five fundamental
criteria of modularization from[12]:decomposability,composability,understand-
ability,continuity and protection.The concept naturally supports decomposabil-
ity and composability as functional coherent units can be built and connected in
flexible ways.The understandability for BDI agents is increased because capabil-
ities represent encapsulated functionalities that normally have few connections
to other capabilities.Additionally,the understandability for a single capability
is supported by the locality principle which makes them self-contained.The con-
tinuity criterion requires that a small change of the problem specification leads
to limited changes in only few concerned modules.This is achieved by exten-
sively using the information hiding principle using small and simple interfaces
through the general import/export mechanism.Finally,protection is attained
when the e?ect of an abnormal condition occurring at runtime is confined to
the originating module.Capabilities do not add a new level of protection to the
development of BDI agents.Nevertheless,failure of plans is already covered by
the normal BDI mechanism.Fig.4.Capability metamodel
Another decomposition method for BDI agents inspired directly from object-
oriented ideas was proposed in[10].It is based mainly on the inheritance mech-
anism for agent classes explicitly allowing also multiple inheritance relationships
between agent classes.In order to control the exact semantics of inheritance re-
lationships an agent class consists of individual submodels for beliefs,plans and
goals respecting the specifics of the individual mentalistic concepts.Similar to
capabilities,this approach decomposes agents at the detailed design and imple-
mentation level.Other decomposition approaches consider high-level concepts
such as roles.E.g.in[9]an experimental system based on the Zeus[13]toolkit
is described,which uses roles to group primitive and rule-based tasks as well as
external code into a reusable module.Role constraints and a role algebra are in-
troduced to describe how agents can be statically composed of predefined roles.
Dastani et al.describe in[5]a formal model of roles composed of beliefs,goals,
plans and rules.The approach focuses on an operational semantics for dynamic
enacting and deacting of roles.It does not cover interfaces between di?erent roles
of the same agent,but assumes that only one role is active at each moment in
time.
4 Realization of Capabilities
The extended capability concept as presented in the last section has been im-
plemented within the Jadex BDI reasoning engine[1,14].In Jadex agents are
specified in two di?erent kinds of files.The static structure of an agent or ca-
pability including its initial mental state is defined within an XML-file that
adheres to the Jadex BDI metamodel specified in XML-schema.The behavior
of Jadex agents is encoded within plan bodies that are programmed with plain
Java.From within user programmed plans the BDI facilities such as modifying
beliefs or creating goals are accessible through an API.
In Fig.4 the condensed Jadex capability metamodel is depicted.All entities
share the same abstract base class“element”.Furthermore an agent is modeled
as an extended capability.This reflects the fact that agent specifications are verysimilar to capabilities and additionally may support entities composed of agents
such as groups sharing e.g.some beliefs or goals.
A capability is composed of two di?erent kinds of elements.On the one hand
it is a container for“referenceable elements”,which form the abstract base class
for mental attitudes such as beliefs,goals,plans and events(not illustrated).
Their common property is that they can be referenced by a proxy termed“ele-
ment reference”from another capability.Element references,which are used to
represent abstract elements as well,are themselves also“referenceable elements”
as references to references are explicitly allowed in the model.On the other hand
capabilities can contain subcapabilities,which is expressed by the relationship
to“capability references”.This indirection is used,because a capability includes
a subcapability under a symbolic name allowing for inclusion of more than one
instance of the same capability type.
5 Example Application
To illustrate the aforementioned concepts in this section an example application
for a hunter-prey scenario is detailed.Even though the hunter-prey domain is
a well-known and extensively studied AI playing field,various di?erent inter-
pretations exist making it necessary to outline our settings.The environment is
inhabited by two di?erent species of creatures(hunters and preys)and various
obstacles(trees)which hinder them in their movements.The creature’s main ob-
jective is to survive by looking for food.Hence,hunters are exploring the terrain
in search of prey which they will try to chase and eat.Contrarily,preys look for
plants growing in the environment and try to flee if chased by some hunter.
5.1 Scenario Design Details
This scenario is designed as(possibly distributed)agent-based simulation in
which the creatures as well as the environment are represented as autonomous
entities.The environment agent is responsible not only for holding a represen-
tation of the environment which is set up as a discrete grid world,but also for
controlling the advancement of time.For simplicity reasons a time-driven scheme
is employed,which requires the creatures to announce their next intended action
within an adjustable timeframe.
Initially,creatures are placed at random locations in the world and are only
able to perceive a cutout of the world according to their vision(automatically
sent from the environment to the creatures at the beginning of each round).
In each round the creatures have to decide which action they would like to
perform.Possible actions are moving to an adjacent field(up,down,left or
right)or trying to eat some object resp.creature near to it.The actions have
to be communicated to the environment as messages following a hunter-prey
domain ontology.If a creature fails to provide its intended action within the
round time(e.g.because it reasons too slowly or a network error occurred)the
simulation proceeds executing no action in that round for the creature.As all creatures need basic abilities for sensing and acting in their environ-
ment it is natural and advantageous to develop a basic module for handling this
fundamental aspect of creature behavior in a reusable way.
5.2 Defining a Capability
In Fig.5 the capability specification for basic sensing and acting in the environ-
ment is depicted.It has two main purposes:The first one is to automatically
process“inform vision”messages(lines 51-65)which contain the current vision
of the creature sent from the environment.Whenever such a message event is
received the“update vision”plan(lines 44-47)is triggered.This plan will ex-
tract the information contained in the vision and update the creature’s belief
sets about known hunters,preys,obstacles and food(lines 13-16)accordingly.
Note that all of these belief sets are exported to be accessible from an outer
capability and the creature agent itself.
The second purpose is to provide high-level abstractions for performing ac-
tions in the environment.Therefore,the capability defines exported goal types
for moving and eating(lines 24-29).To initiate an action,a creature has to cre-
ate and dispatch a new move or eat goal.Such goal instances will subsequently
be handled within the act/sense capability by triggering corresponding move or
eat plans(lines 36-43)which encode the action into a message and communicate
with the environment agent(defined as belief in line 17).
To locate the environment agent the act/sense capability itself relies on an
included directory facilitator(DF)capability(lines 8-10)which o?ers goals for
(de)registering and searching at a DF.For being able to access the DF func-
tionality the act/sense capability defines a concrete goal reference to the“df
search”goal(lines 30-32).Hence,from within plans of the act/sense capability
“df search”goals can be created and dispatched.
For the communication with the environment agent it is necessary for the
creature to identify itself which is done by including information available in
the“my self”belief.As the act/sense capability should be usable by hunters as
well as preys the value depends on the concrete usage of the capability.Thus,
the belief is specified as abstract and required(which is the default for abstract
beliefs)and needs to be assigned from the outer capability respective the agent
that uses the act/sense capability.
5.3 Capability Parametrization
To exhibit reasonable behavior it is necessary for creatures to describe their
high-level objectives and the means for achieving them.In this section a“basic
behavior”capability(Fig.6)for preys is described,which enables preys to explore
their environment,eat food and flee from near hunters.Three goal types are
designed for this purpose.An instance of a“keep alone”maintain goal(lines 27-
29)has the task to monitor if the prey is currently in danger.It becomes active
whenever a hunter is nearby and will trigger plans for fleeing from the hunter.
“Eat food”achieve goals(lines 30-35)are created automatically for every piece
element,when an abstract element exists inside,c)instantiation of an element,when
a reference exists outside,d)instantiation of an abstract element assigned from the
outside
has to be assured that changes outside of a capability do not a?ect the internal
functionality,as this would violate the information hiding principle.
To solve these issues semantics is associated to the creation process of ele-
ments and proxies in all possible cases.On the one hand,a proxy might be in
the outer capability(i.e.a reference)or in the inner capability(i.e.an abstract
element).On the other hand,creation of an element might be issued on the
original element itself,or the proxy.This leads to four di?erent cases(cf.Fig.3):
In the first two cases(a and b)the creation is triggered inside the outer
capability.It is safe to create elements in the inner capability,because they are
an explicit part of the interface.In the last case(d)the initially created element
in the inner capability is just a proxy.Therefore it is necessary to subsequently
create the original element in the outer capability.As can be seen in the figure,it
is only in case c,that a proxy element is not instantiated.In this case the original
element is part of the inner capability and creation is triggered from the inside.
Creating the outer element would lead to problems,because the element(e.g.an
event)might inadvertently be handled in the outside capability,thereby breaking
functionality of the inner capability.The export/reference concept assures
that an element can be used from the outside(e.g.a goal created outside),but
the local functionality(e.g.the goal processing)remains unchanged.Abstract
elements provide a way for the inner capability to connect to functionality of an
outer capability.3.4 Initial Configurations
One important aspect of reusability is parametrization of the reused components,
to adapt them to the special requirements imposed by settings in which they
get reused[7].When considering parametrization of capabilities,two questions
have to be answered:First,what can be parametrized,i.e.what constitutes a
configuration of a capability?Second,how can a capability be parametrized from
the outside,when its elements are encapsulated?
As an answer to the first question,we introduce the notion of an initial
mental state.The initial mental state is a simplified runtime state of a capability,
containing the initial values of beliefs(which are singleton instances),as well as
zero or more initial instances of the other elements(such as goals,plans,and
events)with initial properties(e.g.goal parameter values).In addition,the initial
state defines recursively the initial mental state of all included subcapabilities.
To parametrize a capability,its initial mental state has to be adapted to
the current needs.Respecting the information hiding principle,it should not be
possible to specify all elements of the initial mental state from the outside.E.g.
some capability might require an instance of a maintain goal for proper opera-
tion,but the maintain goal should not be visible to the outside.Our approach
allows parametrization at two levels of granularity:The capability level,and the
level of individual elements.A capability itself can provide one or more initial
configurations,which can be referenced by a given name.In this way,common
use cases can be captured as a whole,allowing easy out-of-the-box reuse.These
configurations are part of the capability,and therefore can contain exported and
internal elements.Parametrization at the level of individual elements is only
possible when these elements are exported.For example for exported beliefs,the
outer capability can override the initial value by defining a reference and locally
assigning a new value to this referenced belief.
3.5 Dynamic Runtime Composition
The new improved capability concepts is also capable of handling various issues
concerning runtime modification of agent behaviour.For that purpose generally
two distinct kinds of operations can be performed.
On the one hand complete capabilities could be plugged into or removed
from an agent at runtime.The addition of a capability at runtime is conceptu-
ally not di?cult as it requires only information about the capability type,its
initial state,the target capability within the agent and some connection data
such as the instance name of the new capability.Given that all information is
provided the capability can be linked with the target capability using the con-
nection data and can subsequently be started meaning that its initial state will
be executed.The removal of a capability at runtime is far more intricate as the
agent’s execution state must be considered before a capability can be removed
safely.This means the agent e.g.could currently utilize plans or goals from the
capability to remove and it needs to be determined if these plans or goals should
be executed completely before removal.On the other hand the modification of a capability at runtime should be
possible.Prerequisite for this modifications is that each capability relies on its
personal copy of the underlying capability model,so that changes can be per-
formed without a?ecting other capability instances of the same type.The cre-
ation process for a new model element(regardless if it is an element or an element
reference)consists basically of two steps.First,the element has to be created
in the capability model.In a second step the elements has to be registered at
the runtime layer,making the agent aware of its new element.For the deletion
of an element at runtime a similar process can be used.The element has to be
deregistered at the capability instance and can afterwards be deleted from the
model.In this respect it has again to be considered if existing elements of the
removed type should be discarded at once.
For the complete freedom of removing or exchanging a capability at runtime
it is a necessary prerequisite that a capability instance is a self-contained entity
with well-defined connection points.In the proposed capability approach this is
supported by the locality principle which is also valid for capabilities at runtime.
Elements from other capabilities are not accessed directly but through local
proxies.When a capability or element of a capability is removed,proxies in
other capabilities can be preserved,and later be reconnected when an alternative
capability or element is available.Further elaborating and implementing the
details of this mechanism is planned for future work.
3.6 Discussion
Capabilities are a decomposition concept for agents allowing to reuse function-
ality captured in a self-contained module with clearly defined import and export
interface.This form of reuse is termed blackbox-reuse as only the interface and
no details about the internals are known.In contrast to(more flexible)whitebox-
reuse changing the internals of a blackbox-component does not break existing
usages,leading to application designs that are easier to maintain[16].
Furthermore,the capability concept addresses most of the five fundamental
criteria of modularization from[12]:decomposability,composability,understand-
ability,continuity and protection.The concept naturally supports decomposabil-
ity and composability as functional coherent units can be built and connected in
flexible ways.The understandability for BDI agents is increased because capabil-
ities represent encapsulated functionalities that normally have few connections
to other capabilities.Additionally,the understandability for a single capability
is supported by the locality principle which makes them self-contained.The con-
tinuity criterion requires that a small change of the problem specification leads
to limited changes in only few concerned modules.This is achieved by exten-
sively using the information hiding principle using small and simple interfaces
through the general import/export mechanism.Finally,protection is attained
when the e?ect of an abnormal condition occurring at runtime is confined to
the originating module.Capabilities do not add a new level of protection to the
development of BDI agents.Nevertheless,failure of plans is already covered by
the normal BDI mechanism.Fig.4.Capability metamodel
Another decomposition method for BDI agents inspired directly from object-
oriented ideas was proposed in[10].It is based mainly on the inheritance mech-
anism for agent classes explicitly allowing also multiple inheritance relationships
between agent classes.In order to control the exact semantics of inheritance re-
lationships an agent class consists of individual submodels for beliefs,plans and
goals respecting the specifics of the individual mentalistic concepts.Similar to
capabilities,this approach decomposes agents at the detailed design and imple-
mentation level.Other decomposition approaches consider high-level concepts
such as roles.E.g.in[9]an experimental system based on the Zeus[13]toolkit
is described,which uses roles to group primitive and rule-based tasks as well as
external code into a reusable module.Role constraints and a role algebra are in-
troduced to describe how agents can be statically composed of predefined roles.
Dastani et al.describe in[5]a formal model of roles composed of beliefs,goals,
plans and rules.The approach focuses on an operational semantics for dynamic
enacting and deacting of roles.It does not cover interfaces between di?erent roles
of the same agent,but assumes that only one role is active at each moment in
time.
4 Realization of Capabilities
The extended capability concept as presented in the last section has been im-
plemented within the Jadex BDI reasoning engine[1,14].In Jadex agents are
specified in two di?erent kinds of files.The static structure of an agent or ca-
pability including its initial mental state is defined within an XML-file that
adheres to the Jadex BDI metamodel specified in XML-schema.The behavior
of Jadex agents is encoded within plan bodies that are programmed with plain
Java.From within user programmed plans the BDI facilities such as modifying
beliefs or creating goals are accessible through an API.
In Fig.4 the condensed Jadex capability metamodel is depicted.All entities
share the same abstract base class“element”.Furthermore an agent is modeled
as an extended capability.This reflects the fact that agent specifications are verysimilar to capabilities and additionally may support entities composed of agents
such as groups sharing e.g.some beliefs or goals.
A capability is composed of two di?erent kinds of elements.On the one hand
it is a container for“referenceable elements”,which form the abstract base class
for mental attitudes such as beliefs,goals,plans and events(not illustrated).
Their common property is that they can be referenced by a proxy termed“ele-
ment reference”from another capability.Element references,which are used to
represent abstract elements as well,are themselves also“referenceable elements”
as references to references are explicitly allowed in the model.On the other hand
capabilities can contain subcapabilities,which is expressed by the relationship
to“capability references”.This indirection is used,because a capability includes
a subcapability under a symbolic name allowing for inclusion of more than one
instance of the same capability type.
5 Example Application
To illustrate the aforementioned concepts in this section an example application
for a hunter-prey scenario is detailed.Even though the hunter-prey domain is
a well-known and extensively studied AI playing field,various di?erent inter-
pretations exist making it necessary to outline our settings.The environment is
inhabited by two di?erent species of creatures(hunters and preys)and various
obstacles(trees)which hinder them in their movements.The creature’s main ob-
jective is to survive by looking for food.Hence,hunters are exploring the terrain
in search of prey which they will try to chase and eat.Contrarily,preys look for
plants growing in the environment and try to flee if chased by some hunter.
5.1 Scenario Design Details
This scenario is designed as(possibly distributed)agent-based simulation in
which the creatures as well as the environment are represented as autonomous
entities.The environment agent is responsible not only for holding a represen-
tation of the environment which is set up as a discrete grid world,but also for
controlling the advancement of time.For simplicity reasons a time-driven scheme
is employed,which requires the creatures to announce their next intended action
within an adjustable timeframe.
Initially,creatures are placed at random locations in the world and are only
able to perceive a cutout of the world according to their vision(automatically
sent from the environment to the creatures at the beginning of each round).
In each round the creatures have to decide which action they would like to
perform.Possible actions are moving to an adjacent field(up,down,left or
right)or trying to eat some object resp.creature near to it.The actions have
to be communicated to the environment as messages following a hunter-prey
domain ontology.If a creature fails to provide its intended action within the
round time(e.g.because it reasons too slowly or a network error occurred)the
simulation proceeds executing no action in that round for the creature.As all creatures need basic abilities for sensing and acting in their environ-
ment it is natural and advantageous to develop a basic module for handling this
fundamental aspect of creature behavior in a reusable way.
5.2 Defining a Capability
In Fig.5 the capability specification for basic sensing and acting in the environ-
ment is depicted.It has two main purposes:The first one is to automatically
process“inform vision”messages(lines 51-65)which contain the current vision
of the creature sent from the environment.Whenever such a message event is
received the“update vision”plan(lines 44-47)is triggered.This plan will ex-
tract the information contained in the vision and update the creature’s belief
sets about known hunters,preys,obstacles and food(lines 13-16)accordingly.
Note that all of these belief sets are exported to be accessible from an outer
capability and the creature agent itself.
The second purpose is to provide high-level abstractions for performing ac-
tions in the environment.Therefore,the capability defines exported goal types
for moving and eating(lines 24-29).To initiate an action,a creature has to cre-
ate and dispatch a new move or eat goal.Such goal instances will subsequently
be handled within the act/sense capability by triggering corresponding move or
eat plans(lines 36-43)which encode the action into a message and communicate
with the environment agent(defined as belief in line 17).
To locate the environment agent the act/sense capability itself relies on an
included directory facilitator(DF)capability(lines 8-10)which o?ers goals for
(de)registering and searching at a DF.For being able to access the DF func-
tionality the act/sense capability defines a concrete goal reference to the“df
search”goal(lines 30-32).Hence,from within plans of the act/sense capability
“df search”goals can be created and dispatched.
For the communication with the environment agent it is necessary for the
creature to identify itself which is done by including information available in
the“my self”belief.As the act/sense capability should be usable by hunters as
well as preys the value depends on the concrete usage of the capability.Thus,
the belief is specified as abstract and required(which is the default for abstract
beliefs)and needs to be assigned from the outer capability respective the agent
that uses the act/sense capability.
5.3 Capability Parametrization
To exhibit reasonable behavior it is necessary for creatures to describe their
high-level objectives and the means for achieving them.In this section a“basic
behavior”capability(Fig.6)for preys is described,which enables preys to explore
their environment,eat food and flee from near hunters.Three goal types are
designed for this purpose.An instance of a“keep alone”maintain goal(lines 27-
29)has the task to monitor if the prey is currently in danger.It becomes active
whenever a hunter is nearby and will trigger plans for fleeing from the hunter.
“Eat food”achieve goals(lines 30-35)are created automatically for every piece