In Philosophy, the term awareness is often associated to theories of consciousness and self-referential behavior. In computer science, the awareness is a topic of increasing relevance in both Software Engineering and Arti cial Intelligence, being closely related to autonomy and proactiveness. We can distinguish two orders of awareness: the rst order is the awareness of the environment also known as context-awareness; conversely, self-awareness is a higher order awareness (knowledge about one's own mental states). Nowadays, many agent oriented languages o er native instruments to implement context-awareness. However, self-awareness is not adequately supported and it requires further considerations. This paper focuses on implementation techniques, based on JASON, for creating software agents able to dynamically reason about their knowledge of the environment, as well as on their missions, capabilities and current execution state.
Runtime adaptation is, today, an important aspect of complex systems such
as distributed systems, defense software, and pervasive computing systems [
Recently, the research community in the area of distributed-systems is
focusing on the general area of self-* [
Several scientists agree [
The complexity of current and emerging computing systems has lead to take
inspiration from several areas (for instance complex systems, control theory,
arti cial intelligence, sociology, philosophy, biology, . . . ). In Philosophy, the term
awareness is often associated with theories of consciousness and of self-referential
behavior [
Examining the literature we discovered several approaches to self-adaption.
Holland and Goodman [
This work focuses on creating tools for implementing agents that reason on their own goals, capabilities and knowledge of the environment. Above all, we experienced the use of JASON where an agent is able to reason in order to act in the environment for pursuing its goals but it is not able to re ect on its plans and to re-organize them for dealing with changing situations. Thus inspired by the beliefs of beliefs mechanism we provide some implementation techniques for enabling agents to dynamically reason on their knowledge about the environment as well as on the knowledge of themselves: their goals, their capabilities and their current execution states.
We aim at reducing the gap between self-awareness theory and implementation in the context of multi-agent systems, since self awareness is not native in the most common and used agent oriented language.
The paper is organized as follows: Sections 2 provides an overview on the JASON agent language, Section 3 shows how to implement self-awareness in JASON, section 4 discusses the proposed work using an experiment and nally Section 5 draws some conclusions.
The JASON [
Beliefs are information the agent owns about the environment where it runs and, of course, it could also be out of date, inaccurate or false.
Desires correspond to the possible states of the world the agent might like to
achieve. A desire, however, does not imply that an agent acts for ful lling it. A
desire is then only an option among all the future possible actions of the agent.
Instead, intentions are states of world that the agent has decided to achieve.
The BDI paradigm is based on a decision making model known as Practical
Reasoning (PR). PR consists in two steps. First, the PR process takes into
account all the Desires of an agent and selects the most suitable ones according
to the agent's Beliefs. This deliberation step produces as results that an agent
adopts an intention to pursue the selected desire. Intentions play a much stronger
role in in uencing the following action of the agent than desires do [
Intentions are characterized by an important property: they persist. When an agent adopts an intention, then it attempts to achieve it. If it initially does not success, then it would try again, and it will not easily give up. However, it may happen that beliefs (or other changes in the world) make the intention not useful or interesting anymore. In this case it will be dropped it. Thus the agent reconsiders the new situation and selects another desire.
Moreover, once an agent adopted an intention, its future deliberative reasoning will consider or adopt options that are consistent with that intention. Finally, intentions are closely related to beliefs about the future. In particular, to pursue an intention for achieving a particular state implies that this state is in principle possible. Under normal circumstances, the agent will then succeed with its intention. However, it is possible that its intention might fail. The second step PR is called mean-ends reasoning. It is the process of deciding how to achieve an intention on the base of the actions the agent can perform in his environment. Means-ends reasoning is based on goals or intentions, beliefs and actions; it should generate a plan, that is a sequence of actions. If the mean-ends reasoning works properly it would produce the sequence of action the agent should execute for attaining its goal or intention.
However, it is a common practice in current application to develop collections of partial plans at design time. The task of the agent is then to pursue these plans for their execution at run time. This approach lacks of exibility because the ability of an agent to deal with changing circumstances is dependent on the plans coded for it by the agent programmer. Nevertheless, this approach can work well in practice and AgentSpeak is based on that model.
AgentSpeak is a programming language based on events and actions [
In JASON, the agent's knowledge is expressed by a symbolic representation (based on implicit ontology) by using beliefs, that are simple predicates (such as tall(john). or likes(john,music).) that state what the agent thinks to be true. Sources of agent's beliefs are: (i) perception (the agent acquires beliefs as a consequence of sensing the environment), (ii) communication (information acquired from other agents is annotated by beliefs) and (iii) mental activity of an agent, that may generate new information (mental notes), deducted from current beliefs and added to the belief base for convenience. The current state of the agent, its environment, and other agents, can be viewed as its current belief state. States which the agent wants to bring about can be viewed as desires, that are used for activating plans. The context of a plan is used for checking the current situation so as to determine which plan is more suitable to be executed. The context is a logic formula that must be true in order the plan to be applicable. The three parts of a plan are triggering event : context body. Trigger conditions tell the agent what are the speci c changes in the agent's mental attitudes for which the plan is to be used.
A JASON agent is continuously perceiving the environment and it is reasoning about how to act on it for achieving its goals. The reasoning part of the agent's cyclic behavior is done according to the plans the agent has in its own plan library. In the current implementation, JASON agents are actually not aware neither of their goals nor of their capabilities. The speci cation of a goal is strictly connected to the plans to be executed for achieving it. In order to implement adaptivity and self-awareness we have to separately de ne goals and capabilities that is the sequence of actions or of sub-goals necessary for achieving the goal. Such an issue will be discussed in the next sections. 3
We consider self-awareness as a sort of ability of introspection the agent can use to adapt its behavior to its own internal state. As well as in BDI systems, when
Listing 1: Beliefs about a goal we mention the internal state of an agent, we refer to the agent's knowledge of its Goals, of its Capabilities and of the Environment.
We adopt the de nition of system goal from GoalSPEC [
In the agent belief-base, a goal is represented as a set of beliefs. Listing 1 reports an example of goal. The agent believes that: (at line 1) g1 is a goal; (at line 2) the system is responsible to address g1; (at lines 3-8) the triggering condition of g1 is the AND-condition of two context-properties (property( unclassi ed, [doc] ) and property( done, [received document] ) ); (at lines 9-12) the nal state of g1 is also given by two context-properties (property(classif ied; [doc]) and property(done; [classif y]) ).
The rst advantage of having goals in the agent belief base is that they can dynamically change during the agent life. Indeed new goals can be added into the belief-base, or existing goals can be ejected. Di erently from JASON, a goal that is injected into the system does not automatically becomes a trigger for a plan. Indeed, when injected, a goal has a lifecycle; Figure 1(a) shows the possible states of a goal. The initial state is Injected. When the agent decides to address it, then the goal moves to a state of Ready. When the goal's triggering condition is true then the goal becomes Active. This state changes when the agent executes its attempt to address it: if the goal's nal state is true then the goal is now Addressed. Otherwise the goal stays Active unless a capability failure occurs.
Another advantage is that the agent may reason on goals in the belief base in order to decide its behavior. This property pushes the agent autonomy and proactivity: for instance the agent can decide to commit to a goal only if it nds this action convenient for itself. In any case, the necessary condition since an agent can commit to a goal is shown in Listing 2.
Listing 2: Rule for goal belief-set. The agent is able to commit to a goal when it is able to catch the triggering condition and to address the nal state 1 a b l e t o c o m m i t t o ( G , C o n te x t ) 2 : g o a l (G) 3 & t r i g g e r i n g c o n d i t i o n (G , TC ) 4 & f i n a l s t a t e (G , FS ) 5 & a b l e t o c a t c h (TC, C on t e x t ) 6 & a b l e t o a d d r e s s ( FS , C o nt e x t ) 7 .
A Capability is composed of two components: a description and an implementation. The capability description contains indications about when the capability can be used and it is represented as a set of beliefs. On the other hand, the implementation is a set of Jason plans to be executed when the agent wants to activate the capability. Listing 3 reports an example of capability. The agent believes that: (at line 1) classif y document is a capability the agent owns; (at lines 2-3) classif y document works on objects of type doc; when doc is in the initial condition of available this capability promises to return a classif ied doc, if no failures occur. The remaining part of the code concerns the capability implementation. It is composed of three plans: (at line 5) the prepare plan is executed before of all the other capability plans; it may be used to prepare data to work on, or to wait some internal condition to be true; (at lines 6-11) the action plan contains the body of the capability that addresses the state transition, as a set of traditional Jason instructions; (at line 12) the terminate plan is executed after the action is nished and may be used to de-allocate all data that has been used.
All the three plans have the same arguments: the rst is the name of the capability and the second is the Context variable that will be explained later on this section. This makes to invoke a capability a ordable simply by knowing its name. Listing 4 shows the Jason plan to invoke a capability and to retreat it.
GOAL LIFECYCLE FS=false Addressed FS=true
Active Injected capability
failure commit
TC=true
Ready eject commitment failure
goal addressed
Idle ignojeaclted goal disclaim
GOAL ACHIEVEMENT LIFECYCLE
Commitment goal Perceiving
decision ready TC rceocmomnsitimdeernt goal a/cptliavne goal addressing
Capability execution Recovering failure alternative solutions /replan capability failure
Perceiving
FS (a) The lifecycle of a goal
(b) The lifecycle of a capability Fig. 1: State charts for a goal and its achievement by an agent
Listing 3: Beliefs about a capability 1 a g e n t c a p a b i l i t y ( c l a s s i f y d o c ) . 2 i n p u t s t a t e ( c l a s s i f y d o c , p r o p e r t y ( a v a i l a b l e , [ doc ] ) ) . 3 o u t p u t s t a t e ( c l a s s i f y d o c , p r o p e r t y ( c l a s s i f i e d , [ doc ] ) ) . 4 5 +! p r e p a r e ( c l a s s i f y d o c , Context ) < t r u e . 6 +! a c t i o n ( c l a s s i f y d o c , Context ) 7 < 8 ! g e t d a t a ( doc , Doc , Context ) ; 9 ! c l a s s i f y d o c ( Doc ) ; 10 ! r e g i s t e r s t a t e ( p r o p e r t y ( c l a s s i f i e d , [ doc ] ) , Context ) ; 11 . 12 +! t e r m i n a t e ( c l a s s i f y d o c , Context ) < t r u e .
Listing 4: How to invoke a capability 1 +! i n v o k e c a p a b i l i t y ( C a p a b i l i t y , Context ) 2 : 3 a g e n t c a p a b i l i t y ( C a p a b i l i t y ) 4 < 5 ! p r e p a r e ( C a p a b i l i t y , Context ) ; 6 ! a c t i o n ( C a p a b i l i t y , Context ) ; 7 . 8 +! r e t r e a t p r o j e c t c a p a b i l i t y ( C a p a b i l i t y , Context ) 9 : 10 a g e n t c a p a b i l i t y ( C a p a b i l i t y ) 11 < 12 ! t e r m i n a t e ( C a p a b i l i t y , Context ) ; 13 .
The advantage of this programming style, is to decouple goals from the plans used to achieve them. However, the agent architecture must include a technique for recreating the link among plans and goals at run-time (means-end reasoning).
Listing 5 is a trivial example of a plan that given a Goal, tries to nd a Capability among those the agent owns, that is suitable to address the goal's nal state. The plan decomposes the FinalState into a set of properties that must be true for considering the goal satis ed. Then the plan searches in the agent belief base if at least one capability matches with this nal state. Of course this plan can be more sophisticated, for instance it could consider additional parameters for selecting the best capability to pick according to non functional requirements such as quality of service, cost, etc.
The variable Context, shown in Listings 3-Listing 4, is a reference for grouping all the beliefs about the environment. There are cases in which an agent may work with di erent contexts at the same time. It is more common that an unique context exists for each agent. The Context reference may be used to store property of the environment that are believed true, or value of parameters. Listing 6 reports an example to store a property and one data-value into the context. Of course these beliefs can be improved with other parameters on purpose, for instance the trustability of the source, the timestamp of acquisition and so on.
Listing 5: Plans for creating the bridge between a goal to address and the plan to be executed 1 +! l i n k g o a l t o c a p a c i t y (G , C a p a b i l i t y ) 2 : 3 f i n a l s t a t e (G , F i n a l S t a t e ) 4 < 5 6 7 .
! d e c o m p o s e s u b s t a t e ( F i n a l S t a t e , S t a t e L i s t ) ; ! p i c k c a p a b i l i t y f o r ( C a p a b i l i t y , S t a t e L i s t ) ;
Listing 6: Beliefs for representing properties and data of the context 1 e n v i r o n m e n t ( c o n t e x t , p r o p e r t y ( c l a s s i f i e d , [ doc ] ) . 2 e n v i r o n m e n t ( c o n t e x t , v a l u e ( doc , 12) ) .
As we already described, the goal trigger condition belief set declares the requirement for addressing a goal, and the capability input state beliefs declare the requirements for activating a capability. Therefore before invoking the capability, it is necessary to check if the current Context variable contains the proper beliefs.
Figure 1(b) shows the lifecycle of an agent when tries to address a goal by using its own capabilities. The agent is initially in an Idle state, until a goal is injected. Then it decides if making a commitment to the goal. The trivial case for that is to check if it is able to do it according to the rule reported in Listing 2. Of course this decision may be more complex, for instance by involving additional parameters, and/or by looking for collaborations with other agents in the society. If the agent commits to the goal, then it activates its perception capabilities to detect when the goal's trigger condition is true. When this happens the agent picks a capability according to the plan in Listing 5 and activates this capability according to the plan in Listing 4. During the execution of the capability, the agents also activates its perception capabilities again, in order to check if the nal state has been properly addressed, thus to come back to the Idle state. Otherwise the agent declares a capability failure and it enters in a Recovering state. This can be solved in two ways: by selecting another capability to execute, if available, or by coming back to the Commitment state, for changing its intentions. In the case of a collaborative solution, the agent may ask for help from other agents, or it may conclude with the complete failure in addressing the goal. 4
The Innovative Document Sharing (IDS) research project arose to deal with selfadaption in work ow enactment. The mission of the project was to develop a smart document management system to deploy in local small/medium enterprise. business analyst
BPMN goal-pack
MAS goal goal web server web page workflow users Documents Currently, a beta version of the described framework is already redeployed for beta testing at three project partners.
The grounding principle of our framework is to decouple what should be addressed from how this result can be achieved; this allows to make the system and the goal-set evolve independently. Thus, being dynamic, system requirements may be considered as part of the execution context.
The result has been a work ow engine (see Figure 2) realized as a multi-agent system that exploits its features (mainly autonomy and proactivity) in order to monitor the execution state of the process and to discover a distributed solution to unpredictable situations or to speci cations' evolution.
In such a system, each autonomous software agent must be self-aware as described in Section 3. However, an agent is not generally able to execute the whole work ow alone, so agents have to collaborate for building a distributed plan.
All together, the agents have to self-organize in groups that proactively discover a distributed solution as the orchestration of many capabilities. 4.1
From BPMN to System Goals Achievement
The whole engine grounds on GoalSPEC [
A di erence with the engine described in Section 3 is that goals coming from the same work ow are correlated. They must be considered as a goal-pack that is injected into the system as a whole. Agents collaborate to discover a solution that is a set of potential commitment to a subset of the goal-pack. The goals of a solution are closely related, since if the solution is actuated, then the commitment must be done for all or none of them at the same time.
Listing 7: Example of a perception capability 1 a g e n t c a p a b i l i t y ( m o n i t o r r e p o s i t o r y ) [ c a t e g o r y ( p e r c e p t i o n ) ] . 2 o u t p u t s t a t e ( m o n i t o r r e p o s i t o r y , p r o p e r t y ( a v a i l a b l e , [ doc ] ) ) . 3 o u t p u t v a l u e ( m o n i t o r r e p o s i t o r y , v a l u e ( doc ) ) . 4 5 +! p r e p a r e ( m o n i t o r r e p o s i t o r y , C on t e x t ) < t r u e . 6 +! p e r c e p t ( m o n i t o r r e p o s i t o r y , C on t e x t ) 7 < 8 //MONITOR NEW DOCUMENTS 9 . 10 +! t e r m i n a t e ( m o n i t o r r e p o s i t o r y , C on t e x t ) < t r u e . 4.2
The Agent Level The work ow enactment is possible because every agent owns special capabilities for addressing the activities speci ed in the business plan. Anyway agents are not designed with a priori knowledge about which plan is good for a given BPMN activity, nor which is the right order for executing plans.
It is up to the agents' autonomy to generate, at run-time, the missing link between a goal set address and the plans to execute. In line with Figure ?? and Listings 4-5, these are the main features of an agent: (i) agents are able to interpret the injected goals and to reason on the trigger condition and the desired nal state; (ii) agents are aware of their own capabilities and can check if they are able to commit to a system goal or a portion of it; and (iii) agents monitor the current state of the context in order to identify when an expected condition holds (trigger condition or nal state) and to check if something wrong happens.
Therefore, the architecture of Section 3 provides the engine for allowing an agent to know its capabilities and for creating the bridge between capabilities and goals (what an agent is able to do and what it is expected).
The context is the portion of the environment in which the work ow operates. It may include both software abstractions (document repository, web-services, software resources, database, etc) and physical resources (hardware devices/resources, physical environment and also human participants). In particular we decided to use a di erent Context variable for each work ow instance in order to separately store the state of parallel processes. Moreover the Context is shared among all the agents that are involved in the enactment of the work ow instance. Finally, all the beliefs concerning the state of the process and the availability of resources are persistent, thus to let the system to be restored after a restart.
For updating the Context, we implemented a proactive monitor loop based on a set of Perceptions. Compatibly with the architecture of Section 3, agent perceptions are also capabilities, that are specialized in monitoring a portion of the environment. Listing 7 is an example of perception capability. The agent capability belief uses the Jason Annotation syntax (e.g. [category(perception)] ) to tag the capability as a perception one. The invocation of perception capability is similar Listing 8: Example of a capability for interacting with human participants by web pages to those shown in Listing 4, but it invokes the percept plan cyclically until the Context variable does not contain the conditions declared in the output state.
Another new category of capability is used to interact with human participants of the work ow. In our framework interaction has been realized by dynamic web pages. Any participant has a personal page that lists all the Tasks that are assigned to him. Any item in this list is a web-link to a dynamic web-page that is generated ad hoc by the agent of the system that is responsible of monitoring the Task progress. In other words the agent acts as a web server, reacting to URL request by building and then routing the proper HTML page. Listing 8 is an example of capability for interacting with human participants. The annotation ([category(manual)] ) indicates the capability can be selected for handling manual tasks. A new belief participant speci es the human role that is involved. The beliefs input state and output state specify as usual the input and output conditions for the capability execution. Finally a new belief http url speci es routing information for the http protocol.
The capability invocation mechanism di ers slightly from that of Listing 4. The plan serve page substitutes the plan action that is invoked only when a HTTP request incomes from the user. Listings 9 shows three new plans that substitute the plan invoke capability of Listing 4, and the plan link goal to capacity of Listing 5. The event +request triggers when a new http request incomes from the user. A http request is associated to a relative path and a set of parameters (in the form www.mydomain.net/path?par1=val1&par2=val2). By the http url belief it is possible to identify the capability that is responsible of building the reply. The plan check capability is ready veri es the capability is currently active (otherwise the agent will reply with an http error code). Finally the plan serve request invokes the capability and then sends the web-page as response to the user.
Listing 9: How to invoke a capability for handling manual task implemented as a web page ? h t t p u r l ( C a p a b i l i t y , Path ) ; ! c h e c k c a p a b i l i t y i s r e a d y ( C a p a b i l i t y , Path , ParamSet , P r o x y S e r v e r ) ;
! s e r v e p a g e ( C a p a b i l i t y , Context , Path , ParamSet , ReplyHtml ) ; . send ( P r o x y S e r v e r , t e l l , html ( Path , ParamSet , ReplyHtml ) ) ; We already mentioned goal commitment becomes a social activity. This requires to add further Jason plans to the basic mechanism of goal commitment presented in Section 3.
When a new goal-pack is injected, each agent may check if its own capabilities allow to commit to some of these goals. Anyway, commitment is regulated because: 1) goals in the same goal-pack are related one with the others, thus the commitment must be for all or none of them at the same time; 2) more agents could be able to commit the same goal, thus a synchronization technique is required.
The collective commitment to a goal-set is possible thanks to the formation of many Teams of agents, each of them proposing a possible Solution to the goalpack. A Solution is a set of related potential commitments to a subset of the goals in the goal-pack that allows to address the whole work ow. Agents involved in a solution form a Team. We omit to report the algorithm used for Team formation and Solution discovery. Eventually, all the Solutions are compared on the base of many possible parameters thus to select the winning one. The agent who formed the winning Team is nominated leader and it is responsible to coordinate the team for actuating the solution. Listing 10 reports the source code for handling the social commitment. The Solution variable is a structure that contains the name of the Leader agent and a list of Contracts. Every contract is a tuple of: 1) the Agent who has engaged, 2) the Goal to which commit to, and 3) the Cost requested by the agent for address the goal (this variable can in turn be a structure formed by multiple parameters). By the .send instruction, all the agents in the team receive the noti cation to commit to the proper goal.
Listing 10: Plan for handling the commitment of a while goal-pack Therefore the leader has also the additional responsibility to monitor when the whole state transition is completed (the work ow is completed). 5
The presented framework is based on decoupling the two concepts Goal and Capability thus to make them evolve independently. To let agent a means-end reasoning, we follow the approach of bridging at run-time what to do with how to do. We have provided our agents the ability to explicitly reason on their goals, capabilities and the knowledge of the environment.
Another possible approach for implementing a mechanism of self-awareness in JASON is to use the exible technique of subclassing. By customizing the agent class and the architecture class it is also possible to extend the agent reasoning cycle for implementing a more sophisticated technique for selecting the plan to execute. However, making explicit the deliberation cycle without modifying the agent architecture, (as in our approach) makes the concepts such as Goal, Capability and Context rst class citizens of the language together with native concepts of rules, plans and beliefs. The result is a exible and easy way for customizing the agent architecture but maintaining the compatibility with all the Jason extensions and plugins.
In addition the approach o ers several extension points for programmer in order to extend the basic functionalities. An example of this process has been shown in Section 4 in which the Context variable is shared among many agents, the commitment is a social activity, and more categories of capabilities have been introduced over the existing architecture.
Concluding, our approach mainly exploits rst-order logic programming that
is a common feature of other agent programming languages such as GOAL [
Acknowledgements This work has been partially funded by the Innovative Document Sharing (IDS) Project funded by the Autonomous Region of Sicily (PO FESR Sicilia 2007-2013).