Abstract Ambient intelligence (AmI) systems are now considered a promising approachto assist people in their daily life. AmI proposes the development of context aware systemsequipped with devices that can recognize your context and act accordingly. Agents providean effective way to develop such systems since agents are reactive, proactive and exhibit anintelligent and autonomous behavior. However, current agent approaches do not adequatelyfulfill the requirements posed by AmI systems. From a modeling point of view, the aimshould be to help in the design by providing adequate tools that assist in the developmentof important properties of AmI systems, such as context-awareness; and from an implemen-tation point of view, agent technologies must be adapted to the diversity of AmI devicesand communication technologies. As a solution to these issues we propose a Model drivenengineering process, which supports the automatic generation of agent-based AmI systems.The source metamodel is PIM4Agents, a general purpose agent metamodel that we haveadapted to support the explicit modeling of context aware systems, and the target meta-model is Malaca, an aspect-oriented agent architecture. Aspect-orientation makes Malacaplatform-neutral for FIPA compliant agent platforms, simplifying the model driven process.The solution generates MalacaTiny agents, an implementation of Malaca that is able to runin AmI devices. We have evaluated the convenience of applying a model driven approach bymeasuring the degree of automation of our process and we have evaluated MalacaTiny formobile phones by assessing different parameters, related to the scarcity of resources in AmIsystems. All the results obtained are satisfactory.
I. Ayala (B) · M. Amor · L. FuentesDepartamento de Lenguajes y Ciencias de la Computación, Universidad de Málaga,Malaga, Spaine-mail: [email protected]
Ambient Intelligence (AmI) systems are currently considered a hit. The AmI technologyhas great potential to assist people in their daily tasks, by promoting new ways of seamlessinteraction between people (with each other) and also between people and their environment,improving their quality of life [15]. AmI proposes the development of a new generation ofadvanced systems, by defining an intelligent environment with special devices (e.g. sensors,home appliances, tablets or smartphones) that can recognize you and your situational context.So, AmI devices should be enhanced with software able to react and adapt to user actions orevents that have occurred in the environment. Considering the special requirements of AmIsystems [34], the agent technology provides an effective way to develop such context-awareAmI systems because software agents are reactive and proactive and exhibit an intelligentand autonomous behavior [15,34]. In fact, apart from the ubiquitous and embedded sys-tem technologies, the AmI domain is considered a good candidate to benefit from artificialintelligence technologies, such as software agents.
In recent years, the demand for AmI systems has increased enormously and many of thesesystems have been effectively developed with agent technology [13,15,34,36,40]. But, manyof these AmI systems do not address the AmI requirements well, preventing a more extensiveuse of agents in AmI. So, in order to enforce a more effective use of agents to develop AmIsystems, general purpose agent technologies, i.e. agent architectures or toolkits and agentplatforms (APs), must principally adapt to the critical resource limitations of AmI devices andto the diversity of communication protocols and wireless technologies. Recently, some of themost well-known agent approaches have released new versions specifically for lightweightdevices (e.g. Jade-Leap [9,10], μFIPA-OS [41]) and new ones have been proposed (e.g.Andromeda [1], MAPS [2]). They provide a more or less complete framework or toolkit tofacilitate the implementation of agent-based applications; and an AP principally to supportthe execution, registration and interaction of agents installed in some small devices, typicalof AmI systems. However, in order for agent-based computing to become a widely acceptedtechnology for developing AmI systems it would be advantageous to ease both the designand implementation of AmI systems by providing adequate development tools that automatesome of the developer’s tasks, augmenting the production of applications for AmI systems.The purpose of these tools should be to alleviate the complexity of programming with agents,and of the agents’ configuration for each specific AmI device and/or communication protocoland wireless technologies.
Model-driven engineering (MDE) [37] is an approach for software development that pro-motes the use of models to formally represent domain-specific concepts. One importantcontribution of MDE is that a software system is obtained through the transformation of dif-ferent metamodels defined at different abstraction layers. With MDE it is possible to designan agent-based AmI system specifying high level concepts in a platform-independent agentmodel, (focusing on the domain model), and later automatically transform it for differentimplementation models, bridging the gap between design and implementation. However, theapplication of MDE to develop agents for AmI systems presents some challenges.
One of the main challenges is the effort required to express AmI domain concepts, whichnormally concentrate on the context awareness concept, at a high level of abstraction. Thecontext awareness is not explicitly managed or supported by the majority of existing agent
123
216 Auton Agent Multi-Agent Syst (2014) 28:214–255
metamodels. So, existing agent metamodels should be endowed with context awareness mod-eling to adequately enable the design of AmI systems from a high level domain perspective.Another important challenge stems from the lack of complete and implemented metamodelsof existing agent technologies for lightweight devices, preventing the application of MDE andthe automation of the process from design to implementation. One alternative is to define somemappings and transformations in an ad-hoc manner, but this requires an in-depth knowledgeof the agent implementation framework. In addition, the main characteristic of AmI environ-ments is the diversity of devices involved in these systems with a limited set of resources,interconnected through different communication protocols and wireless technologies. So, theresulting agent code has to be resource-efficient since agents have to run efficiently in smalldevices to be useful in practice for real AmI applications. Furthermore, for each device onlya subset of agents’ toolkits and APs is available.
The work presented here builds upon previous work [5,6]. The paper [6] presents an MDEprocess from PIM4Agents [20], a general purpose agent metamodel that we have adapted tosupport an explicit modeling of context aware systems, to Malaca [3], an aspect-oriented agentarchitecture. Additionally, the use of both metamodels in the process is justified, focusing onthe advantages of Malaca and its platform neutrality for FIPA compliant APs. We focus onFIPA compliant APs as most AmI systems are considered open systems, and FIPA promotesthe use of agents in an open environment. In Malaca, the internal modularization of the agentis enhanced, and the platform dependent properties (such as issues related with the distribu-tion of messages to interact with other agents, mostly through the Message Transport Service(MTS) provided by an AP) are modeled separately as aspects.1 This feature makes Malacaplatform-neutral, simplifying the model driven process. In the paper [5], we presented thedevelopment process of platform-neutral agents using the DDE Tool; from the PIM4Agentsapproach, and the MAD tool; from the Malaca approach, and results in order to validate ourapproach were also provided. The work presented here starts with these and introduces moredetails on some of the aspects, which were not covered by [6] and [5]. In addition, in thispaper we introduce the code generation of the MDE process from Malaca to MalacaTiny(Malaca for Tiny devices). MalacaTiny is an implementation of the Malaca agent architec-ture able to be executed in heterogeneous lightweight devices. This agent technology, whichis a contribution of this paper, is capable of being effectively deployed in different FIPAcompliant APs, able to interact through heterogeneous APs and wireless technologies, at thesame time. Its platform-neutrality for FIPA compliant APs also facilitates the incorporationof new APs and wireless technologies, which are continuously appearing. So, our approachapplies MDE to transform a system design model in an implementation of the AmI systemas a set of MalacaTiny agents, which are able to be executed in lightweight devices and areable to interact through different FIPA compliant APs and communication technologies. Thispaper also evaluates the convenience of applying a MDE process by measuring the degreeof automation of our process. Moreover, the generated system has been tested with an evalu-ation of the MalacaTiny agent technology. Specifically, we have measured the performanceand the resource consumption of this technology, comparing it with Jade-Leap. Finally, wepresent how to develop a plugin for MalacaTiny to use RFCOMM Bluetooth as an alternativecommunication mechanism to the TCP/IP-based communication service normally providedby APs.
The MDE-based development process presented in this paper has been totally imple-mented and tested. The metamodels are implemented in Ecore, the metamodel of the EMF
1 Aspect Oriented Software Development, see http://www.aosd.net/
Auton Agent Multi-Agent Syst (2014) 28:214–255 217
framework2 and the transformation rules in ATL3, a model transformation language andtoolkit, and the code generation in MOFScript.4 MalacaTiny framework is currently imple-mented in Java (for desktop computers), Java ME (for mobile phones with MIDP profile andSun SPOT5 sensors) and Java for Android.6 It can use different versions of Jade-Leap APand as stated before, it can also be deployed in an AP that we developed based on RFCOMMBluetooth and in the Sol AP [7]. From among the different versions of MalacaTiny, thisarticle focuses on the version for smartphones with MIDP profile and Android. Currently, inthe mobile applications market it is of utmost importance to have multi-platform solutions:Symbian7 continues to be the most used operative system for smartphones [16], while thepresence of Android, Apple iOS and Windows Mobile devices increases each year. Thus theportability and availability of the applications for different devices have become the norm.
The structure of the paper is as follows: Sect. 2 highlights the limitations of other propos-als and provides a general overview of how our approach overcomes them. Specifically, wepresent related work first of AmI systems based on agents (Sect. 2.1), second agent technolo-gies for the development of AmI systems (Sect. 2.2) and third of MDE processes for agents(Sect. 2.3). Section 3 includes an overview of our approach summarizing the main contribu-tions (Sect. 3.1); To continue, Sect. 3.2 describes the motivating case study of an intelligenttransport system (ITS) that is used to illustrate the contributions of this paper. Section 4presents how the ITS system is designed using PIM4Agents and Malaca (source and targetmetamodels of our MDE process). Section 5 shows the implementation of the MDE processfrom PIM4Agents to Malaca, by means of transformation rules. In Sect. 6, we give someimplementation details of MalacaTiny and present the generation of MalacaTiny agents, theoutput of our MDE process. Section 7 shows some validation results of our approach, firstlywith regard to the utility of the MDE process and secondly to the efficiency of MalacaTinyagents. A section discussing lessons learned is also provided (Sect. 7.6). The paper ends withconclusions and future work.
2 Motivation
2.1 Use of agents in AmI systems
AmI systems are naturally distributed and normally composed of a myriad of devices inter-connected through a great diversity of communication technologies. The main goal of thisapproach is to automatically generate agents that can be used as building blocks for AmI sys-tems, shortening development times. In order to demonstrate both the importance and benefitsof this work, we have conducted a study of the AmI literature with the following objectives:(i) to know what the main features of AmI systems are, which differentiate them from othersystems; and exactly what agent technology must incorporate in order to be effectively usedin AmI systems development; (ii) to analyze the use of agents in AmI systems until now,in order to identify their potential benefits and find out future challenges that agent technol-ogy may face; (iii) to show the current importance of AmI systems in different application
domains. Table 1 summarizes the results from analyzing 67 AmI systems [15,34]. Thesesystems have been grouped by their application domain (typical of AmI), i.e. Smart homes,Ambient Assisted Living (AAL), Healthcare, Transportation systems, Education, Business,and Leisure (first column). Then in the columns the percentage of AmI systems that havesome of these features is detailed. The second column “Distributed” specifies the percentageof systems that present a distributed architecture, the third column specifies the percentage ofsystems composed of sets of heterogeneous devices, the fourth column shows the percentageof systems the devices of which communicate using different wireless technologies. The lastcolumn labeled “Agent Technology” represents the percentage of studied systems that applythe agent technology.
From the results shown in Table 1 we can see that the greater majority of AmI systems aredistributed, with a mean of 81 %. It is striking that some AmI systems are not distributed, as isthe case of ITSs (only 43 % are distributed). In the latter case, the reason is that most transportsystems integrate monitoring devices on vehicles simply to assist drivers in different circum-stances. Secondly, a significant percentage of AmI systems are composed by heterogenousdevices (e.g. home appliances, hand held devices, sensors, onboard computers), 69.9 % isthe mean. So including an open set of heterogeneous devices can be considered a must forany technology that is presented for use in AmI systems. Thirdly, most AmI systems, apartfrom the traditional communication technologies, make use of new wireless communicationtechnologies such as Wi-Fi, Zigbee, Bluetooth, Wireless USB or Z-Wave, since these AmIsystems are mostly deployed in personal area networks (PAN). So, the diversity of communi-cation technologies seems to be an important requirement for the technologies used to developAmI systems. Lastly, 38.64 % of the AmI systems surveyed use agent technologies. This canbe interpreted in two ways. This rate is close to 50 %, showing a significant presence of agenttechnology in these environments. On the other hand, a percentage below 50 % also shows thenecessity of improving current agent technologies in order to achieve a wider adoption in thedomain of AmI systems. Note that these results were taken from surveys that are not specific toagents, so we assume the results are unbiased towards agent technology. Of course, there areother papers, and surveys more specific to AmI and agents [13,36,40], that show that agentsare the most appropriate technology to be used in AmI, but this assertion can be consideredslightly biased because of the interest the authors have in applying agent technology to AmI.
Now we are going to analyze those AmI systems developed with agents, in order to identifythe challenges that AmI systems pose, for agent technology. In the literature we found thatagents can be used as abstractions to model and implement both functionality and devices ofan AmI system [32], to encapsulate artificial intelligence techniques [4], and to coordinate thedifferent elements that compose the application [21]. Although the reasons and purposes that
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 219
justify the use of agents are different, they contribute to highlight the suitability of the agentparadigm in AmI environments. Most AmI systems developed with agents and Multi-AgentSystems (MASs) are relative to leisure activities, which includes applications to aid shoppingand tourist activities. These AmI applications demand context aware behavior, by providingservices that must be adapted to meet user preferences and current context conditions. Also,these AmI systems are executed in open and highly dynamic environments, where nodesof the application are continuously appearing and disappearing. So, the conclusion is thatagents are particularly well suited for managing context-awareness and the dynamism ofopen systems.
Among the agent-based AmI systems surveyed, we have not found a common approachregarding the agent solution adopted. Some AmI agents were developed using general-purpose agent toolkits for AmI (such as Jade-Leap), while numerous systems developedtheir own special-purpose agents specific to an application domain, or to a specific device.In some of these approaches agents execute inside the device and are coordinated throughtuple space mechanisms [32]; or agents are mobile and move from one device to another[24], most of them adopt an entirely distributed and decentralized architecture. Addition-ally, by embedding agents in AmI devices, these special purpose MASs are able to adaptagents to the specific device’s characteristics (regarding hardware and software resources) inwhich it is running [28]. These solutions are the preferred approach in some AmI environ-ments because of the advantages provided by agents embedded in devices: (i) agents provideservices customized to device resources [39]; (ii) agents encapsulate complex functionalitythat must be hidden from other agents in the MAS [28] (e.g. keep privacy of critical data);(iii) to vary components (i.e. agents) of the architecture without modifying the architectureof the system [14]; (iv) it can be considered a more flexible approach to model open systems,because it enables modeling genuine decentralized MASs [8].
However, the approaches based on the embedding of agents in AmI devices usually pro-pose ad-hoc solutions, normally specific to a particular AmI domain (e.g. AAL). But, theadoption of such ad-hoc solutions imposes severe limitations on interoperability and exten-sibility: (i) agents can not be easily reused in other AmI systems; (ii) the emergence of newdevices, including the software or hardware updating of the devices may require developingagents from scratch; (iii) likewise, it is not easy to modify the agent in order to incorporatenew communication technologies; (iv) normally not possible to construct an AmI systemcomposed with agents running on heterogenous devices communicating with heterogeneoustechnologies at the same time; (v) because of the minor use of these agents, the existence oftools, documentation and integration in well-known agent-oriented methodologies is reduced(unlike general-purpose agents toolkits for AmI, to be discussed in the next section). We there-fore conclude that these are limitations and deficiencies that hinder a wider adoption of theagent technology.
2.2 Agent technologies for AmI systems
In this section we analyze the currently available general-purpose agent toolkits for develop-ing AmI systems. There are a number of approaches that facilitate both the development andthe execution of general purpose agents in lightweight devices, contributing to the adoptionof agent technology for AmI systems. These agent approaches involve an agent develop-ment toolkit, and also the necessary infrastructure for the management and communicationof the agents which run embedded in lightweight devices and communicate through an agentplatform. Table 2 shows an up-to-date list of agent approaches currently available for AmIdevices. Each agent approach is evaluated according to the following criteria: the devices they
123
220 Auton Agent Multi-Agent Syst (2014) 28:214–255
Table 2 Agents for AmI systems
AP Device API AP IDE Transport Wireless FIPAmanagementGUI
protocols technology
Jack PC, PDA Java Yes Yes TCP 802.11 No
Jade-Leap PC, MIDP,PDA,Android
Java, Java ME,Java forAndroid
Yes No TCP 802.11 Yes
μFIPA-OS PDA Java Yes No TCP 802.11 Yes
3APL-M PC,MIDP,PDA
Java, Java ME No No TCP 802.11 Yes
AFME MIDP,SunSPOT
Java, Java ME Yes No HTTP (over TCP),Radiogram(datagram-based)
802.11,802.15.4
Yes
Andromeda Android Java for Android No Yes TCP 802.11 Yes
MAPS Sun SPOT Java, Java ME No No Radiogram(datagram-based)
802.15.4 No
MASPOT Sun SPOT Java, Java ME Yes No Radiogram(datagram-based)
802.15.4 No
MalacaTiny PC, MIDP,PDA,Android,Sun SPOT
Java,Java ME,Java forAndroid
AP dependable Yes TCP, UDP,RFCOMM,Radiogram(datagram-based)
802.11,802.15.1,802.15.4(extensi-ble)
Yes
are intended for (column “Device”); the API used for programming agents (column “API”);whether they provide a graphical interface for managing the life cycle of agents (fourth col-umn); whether they provide a tool for assisting developers (column “IDE”). The next twocolumns concern the communication issues: the transport protocol used to distribute agentmessages (column “Transport protocols”), and the wireless technologies that enable devicecommunication in wireless networks (column “Wireless technology”). Finally, the supportof FIPA specification (column “FIPA compliant”) is checked.
Jack [23] is a mature, cross-platform environment for building, running and integratingcommercial-grade MASs. Jack is a compact and efficient BDI implementation that runs onany system where Java is available (PDA, high-end multi-CPU enterprize servers, PC, etc.).In addition, Jack provides an IDE that eases the development process of a MAS based onJack using a graphical notation that enables code-generation. Jack is extremely lightweightand is designed to handle thousands of agents running on relatively low-end hardware, butJack does not run in devices with MIDP profile nor in sensors.
Jade-Leap [10] is the lightweight version of the Jade that allows the execution and com-munication of Jade agents in PCs, PDAs, Android devices and MIDP devices. Like Jade,Jade-Leap offers a management GUI and other tools that facilitate the development andmaintenance of the MAS.
μFIPA-OS [41] is an extension of the FIPA-OS approach, which has been designed fromthe bottom up. However, it can only be executed on PDAs with Linux or PocketPC operatingsystems. Similarly to Jade, this AP provides a set of tools to monitor AP execution.
The 3APL-M [25] AP defines a programming language for implementing BDI agents.This AP provides different versions for execution in different devices as does Jade-Leap.
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 221
Agent Factory Micro-Edition (AFME) [29,30] is a FIPA compliant framework for thefabrication of BDI agents that can run in MIDP devices and Sun SPOT sensors. This frame-work has tools to manage the AP and a compiler that eases the development of AFME forthe different devices that can support it. However, the communication between agents run-ning in different devices is not possible. AFME agents for MIDP only communicate using aremote mail service (using HTTP confections), while AFME agents for Sun SPOT only usethe Sun SPOT radiogram protocol. Therefore, despite AFME supporting different transportprotocols, these are independently supported for its different agent versions.
Andromeda [1] is an AP specifically oriented to embed agents in the Android operatingsystem.
Additionally, there are agent approaches solely for wireless sensor networks [42], althoughmost of these approaches focus on mobility features. Following this trend, we find MAPS[2] and MASPOT [27], two lightweight APs for Sun SPOT.
As you can see from this related work, there is no agent approach that supports the threekinds of devices that we find in AmI environments (i.e. PC, personal devices and sensors) orin the case of AFME, does not offer an interoperable solution. Additionally, although FIPAcompliance is a feature that has been taken into account in most approaches, interoperabilitybetween all of them is not possible.
Another important concern is the extensibility of the agent approaches. Nowadays, theappearance and disappearance of new devices and wireless communication technologies isbecoming usual. In recent years we have seen how some of them have became obsolete(such as IrDa8) while new ones have appeared (e.g. NFC9 and Wi-Fi Direct10). However,it is rather complex to extend current agent platform message transport services or incor-porate new functions into agents to support new wireless communication capabilities. Suchextension is not straightforward and depends on the programmers’ expertise in certain agentplatforms. More flexible agent architectural design should allow software agents to cope withthe evolution and emergence of new technologies and devices (e.g. new transport services,message encoding, etc.), boosting the production of adequate versions of agents for differentlightweight devices.
We have seen in this section that current agent approaches for the development of AmIsystems present serious limitations and deficiencies in coping with the technological require-ments concerning the implementation of these systems. As a solution to these issues we pro-pose MalacaTiny agents, that try to overcome the limitations present in other agent approachesfor AmI environments, as we will show in Sect. 3.
2.3 MDE for agents
As we have already stated, MDE is an advanced software technology that naturally addressesthe generation of agents for diverse APs, by means of transformations between computa-tion independent models (CIM), platform independent models (PIM) and platform specificmodels (PSM). There are some MDE agent-based approaches that consider the CIM, some-times called a domain model [12]. The CIM level is mainly used in agent approaches mainlyto analyze and represent the requirements of the system. With the CIM level it is possibleto explore and specify the problem domain of AmI systems using agents. However, MDEprocesses that provide a general purpose solution for agents in AmI (as we do), contribute to
222 Auton Agent Multi-Agent Syst (2014) 28:214–255
Fig. 1 The overall picture: MDE straight forward approach (DSML4MAS) on the left hand side and fromPIM4Agents to MalacaTiny on the right hand side
the solution space and not to the problem or domain space. So, normally these approachesdo not consider the CIM level, closer to an AmI specific application or domain. So, a straightforward definition of a general purpose MDE process for agents would use a generic agentmetamodel such as PIM, one PSM for each AP, and define model-to-model (M2M) trans-formations for each PSM. In order to generate code, the subsequent model-to-text (M2T)transformations must also be defined. Most of the most important agent-oriented method-ologies apply MDE to the development of MAS. One of the most relevant MDE approachesfor agents is the DSML4MAS approach. A general overview of this MDE process is shownFig. 1, left hand side. The MDE process of the DSML4MAS approach uses a generic PIM foragents named PIM4Agents [20] to generate Jack and Jade agents. The generation process iscomposed of 4 transformations: two M2M transformations to generate Jack and Jade modelsand two M2T transformations to generate Jack and Jade code. MDE principles have alsobeen applied in [1], specifically to generate mobile agents for Android phones. It takes theagent−π as PIM, a metamodel for mobile agents, and defines transformations for two mobile-specific PSMs, Andromeda and Jade-Leap. Similarly to DSML4MAS it follows the MDEstraight forward approach depicted in Fig. 1, left hand side. With a similar proposal, otheragent-methodologies, like Tropos [18], INGENIAS [31], ASEME [38], and Prometheus [17],support the development process of MAS using MDE processes.
Although these MDE approaches improve and automatize the development process, whengenerating agents for multiple APs (mainly for Jade), we have found that only one of the
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 223
methodologies provides explicit support for the generation of code for lightweight devicestypical of AmI systems [1]. Although in general terms, MDE improves the adoption ofnew technologies just by developing a new code generator, the fact is that, for all the MDEapproaches considered, a different set of transformations must be defined and implementedfrom the corresponding PIM (specific to each MDE process) for each AP (i.e. PSM). Thismeans that the cost of extending the proposal with a new AP (PSM) is very high. Althoughthis is acceptable for some application domains, for AmI systems, which are composed by aset of heterogeneous devices with different APs interacting with each other, this is a seriouslimitation. Including a new AP for a specific device, e.g. as in the DSML4MAS approach,requires the definition of two new sets of transformation rules: a M2M transformation fromPIM4Agents to the metamodel of the new AP; and a M2T transformation from the new APmetamodel into code. This is a very complex task, sometimes impossible to perform properlydue to: (i) the metamodel of the target AP must be available, which is not always the case;(ii) sometimes the target metamodel is not specified completely, and some mappings forthe target metamodel are carried out in an ad-hoc manner; (iii) this task also requires someexpertise in a transformation language (e.g. ATL); and (iv) also the transformations from thetarget platform metamodel to code have to be implemented, requiring an in-depth knowledgeof the target agent’s implementation framework.
3 Our approach: from PIM4Agents to Malaca
3.1 Challenges
The goal of the work presented in this paper is the automatic generation of applicationsfor AmI, based on software agents. As stated, the development of an AmI system usingcurrent MDE approaches and adopting current agent technologies for lightweight devicespresents diverse limitations. Our approach tries to overcome, or at least reduce the followingchallenges:
Specific to a MDE agent generation process:
C1. Facilitate the high level modeling of AmI features: The complexity of programmingwith APs for lightweight devices should be alleviated by providing facilities to expressAmI domain concepts at a higher level of abstraction. In the case of AmI systems, contextawareness is the most specific one. From Sect. 2.1 we saw that most current agent-basedAmI systems provide ad hoc solutions, without considering the high level modeling of AmIproperties. From Sect. 2.2, that the majority of APs for lightweight devices do not provideany modeling tool. The benefit of addressing this challenge would be to make the agentplatform dependent issues of AmI systems transparent to the developer who would thereforeonly have to focus on high level AmI features.
C2. Facilitate the automation of agent development: As we showed in Sect. 2.1,although agents are recognized as being a very good option to develop AmI systems, only38.64 % of AmI applications from different domains are developed using agents. So moreeffort towards augmenting the productivity of using agents for AmI should be made, andautomatic code generation could be very fruitful. From Sect. 2.3, it can be deduced thatMDE technologies are a good option for the automatic generation of agents, bridging the gapbetween design and implementation. So, one challenge is to propose novel MDE processesfor the automatic generation of agents that can be executed in heterogeneous AmI devices.
123
224 Auton Agent Multi-Agent Syst (2014) 28:214–255
Then, by simply clicking a button, it would be possible to augment the productivity of MASfor AmI.
C3. Facilitate the extensibility of the MDE process: The generation process of agentsmust consider the continuous emergence of AmI devices with new operating systems (e.g.recently Android) and accordingly, the APs for these devices. So, a crucial requirement foran automatic generation process of agents for AmI, is to facilitate the extensibility of theprocess to incorporate new PIMs. In Sect. 2.3 we see that some approaches already provethe benefits of MDE in agents. But, it is preferable to define a process for the automaticgeneration of agents capable of being executed in diverse APs from a single domain model,rather than defining several transformation processes for different target APs.
Also, the implementation of AmI systems based on agents poses important challengessuch as the following:
Specific to the implementation of agents for AmI systems:
C4. Manage AP/device Heterogeneity: Sect. 2.1 shows that the majority of AmI systemsare composed of a heterogeneous set of devices. But, current agent technologies for smalldevices normally only run in some of them, and cannot interact with agents deployed indifferent APs (see Sect. 2.2). This is an important limitation, since it prevents the developmentof some AmI systems using agents, in the case that an AmI device is not supported by thechosen agent platform. Also, it should be possible for agents of the same MAS to be executedand able to interact through heterogeneous APs/devices.
C5. Cope with Wireless network diversity: Normally AmI devices can interact throughdifferent wireless technologies. For example, nowadays, most mobile phones include WiFi,Bluetooth or IrDA interfaces. Current APs for AmI are limited by their use of only one networkinterface, and are not designed to be easily extended to adopt new wireless technologies (seeSect. 2.2).
C6. Achieve efficiency of the generated code:In an AmI system based on agents, agentexecution in lightweight devices, such as smartphones, tablets or sensors, with a limited setof resources must be possible. Then the code generation process for a given target AP mustmanage these limitations in order to produce resource efficient code, particularly in regardto energy.
The main contributions of our approach focus on achieving solutions to these challenges.A general overview of the approach is presented on the right-hand side of Fig. 1. As sourcePIM and starting point of our MDE process we decided to use PIM4Agents instead of defininga new metamodel, because this metamodel meets the following requirements: (i) it is possibleto represent concepts from different agent types (e.g. BDI, reactive agents), (ii) it is easy tospecify MAS for different domains; (iii) it has a graphical tool for modeling the MAS (theDDE tool) and (iv) provides enough elements to model the context-aware behavior, requiredby AmI systems. In order to fulfill C1, we firstly extend the PIM4Agents to cope with contextawareness. The design of an MAS using the DDE Tool corresponds to the first step of ourdevelopment process, contributing to the achievement of C1.
Following an MDE approach, and in order to define automatic transformations fromsource and target metamodels, we propose using Malaca, an agent architecture, as the targetmetamodel. Both metamodels are implemented in Ecore, and the transformation rules inATL contribute to automatizing the MDE process (C2). ATL is a de facto standard whichprovides ways of producing a set of target models from a set of source models via a set of ATLtransformations. The second step of the MDE process is to generate MalacaTiny agents fromthe PSM. In this step the choice of Malaca as the PSM is because of its platform-neutrality.This means, that Malaca agents are able to use the communication infrastructure and services
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 225
of any FIPA compliant AP or even use other communication technology to interact with otheragents. Malaca refers only to the agent architecture metamodel, and MalacaTiny, is an efficientimplementation of Malaca that can be executed in multiple devices (Android, PDA, PC, MIDPand Sun SPOT sensors) (see Table 2) and deployed on top of various APs, running differentoperating systems. The agent implementation generated by the M2T transformation from theMalaca model is independent to the target platform where the agent will be executed. Thekey is that MalacaTiny agents maintain the modularization of the Malaca agent model. TheMalaca agent model separates platform-dependent functions (i.e the access to the AP services,such as the MTS, the Directory Facilitator (DF) or the Agent Management Service (AMS)) asaspects, following an aspect-oriented approach. The entire agent functionality that dependson the target AP is encapsulated in an independent component (i.e. the distribution aspect),which can be incorporated inside the agent implementation as a plug-in in the deploymentphase. So, we just need an M2M transformation from PIM4Agents to Malaca (second stepof our process), and a single M2T transformation from Malaca to MalacaTiny (third step ofour process). Our process can automatically derive agents that can be deployed to use thecommunication infrastructure of different AP using the appropriate plug-in. So, our MDEcan be considered more extendable than others as adding a new device or agent platform onlyentails implementing a new plug-in thereby meeting challenge C3.
So, the benefit of using Malaca as a PSM is threefold: (i) the incorporation of new APs tothis proposal has a lower cost than in an MDE straight forward approach like DSML4MAS.Instead of requiring the specification of PSM metamodels and coding a new set of transfor-mation rules, we only require the implementation of a new plug-in encapsulating the partic-ularities of use of the new AP communication facilities (C3); (ii) the implementation of anMAS for different APs does not require transforming and implementing it for each platform,instead, it just involves selecting and using the appropriate AP plug-in for each MalacaTinyagent (C4). This plug-in receives the incoming messages and delivers outgoing messages toan AP, hiding platform-specific dependencies. This plug-in is modeled and composed as anaspect (i.e. the Distribution aspect), following an aspect-oriented approach as we will show insubsequent sections (C5); and (iii) thanks to the separation of platform and communication-dependent concerns, it is possible to easily extend Malaca/MalacaTiny to support new APsand communication technologies (contributing to C5). For example, MalacaTiny agents run-ning in smartphones can communicate using IEEE 802.11 (Wi-Fi), while the communicationof MalacaTiny agents running in sensors relies on IEEE 802.15.X (WPAN/Bluetooth/Zigbee)technologies. MalacaTiny is an efficient implementation of Malaca, addressing C6. We willshow some interesting results of the resource consumption and performance of MalacaTinyin the following sections.
3.2 Case study
This section describes the ITS that is used in the case study to illustrate our proposal. An ITSis an AmI environment [33] that improves transportation systems of all kinds. With this aim,different elements of the transportation system (users, vehicles, and elements of the transportinfrastructure such as bus stops and bus stations, to name a few) incorporate different kindsof lightweight devices (sensors, smartphones, tablets, etc.) in order to provide valuable anduseful services for the vehicle’s occupants for a journey. In most cases, this informationis obtained from diverse information sources that are located in different kinds of devicesand locations, mainly external to the vehicle. Figure 2 depicts the aforementioned scenarioand the different users, resources and elements involved. Agents have been extensively usedto develop ITS applications [13] that include platforms for traffic management, roadway
123
226 Auton Agent Multi-Agent Syst (2014) 28:214–255
BUS
Efficiency
Transport protocol diversity
Device heterogeneity
Fig. 2 Diagram of the application scenario
transportation or traffic simulations. The AmI application we propose offers real time routeplanning to bus passengers at bus stops and inside buses. Imagine a scenario where theuser is near a bus stop. The user has an application installed in his/her mobile phone thatprovides him/her with the number of buses that he/she should take in order to arrive at aspecific destination from this bus stop. This application generates the fastest routes takinginto consideration some context parameters such as the distance, the connections between thedifferent bus stops and the current traffic conditions. This application is context-aware becauseduring the journey it monitors the buses that the user takes and checks traffic conditions inorder to replan the route. This is useful in the case that the user does not take the correct busor the traffic conditions drastically change due to an accident. The traffic updates are gatheredfrom the buses themselves which offer information about speed and position in real time. Inaddition to the smartphone of the bus user, bus stops and buses are endowed with lightweightdevices to provide up-to-date information. The case study has been modeled as an MAS thatincludes three kinds of agents: Personal agents for bus passengers (UserAgent), agents forbus stops (StopAgent) and agents for buses (BusAgent). A UserAgent is executed in the user’smobile phone and it provides the user with routes to a specific destination, context aware routemonitoring and route replanning if it becomes necessary. A StopAgent is embedded inside thebus stop’s structure, providing UserAgents with the requested routes, and collaborating withother StopAgents to generate routes and provide real time information to the people at the busstop about the approaching buses. Finally, the BusAgent is executed in a device incorporatedinside the bus. This agent provides information on the speed and position of the bus to theStopAgents embedded in the bus stops associated with its route. It also provides informationon the progress along the route to UserAgents inside the bus and mediates between StopAgentsand UserAgents, when the latter needs to replan its current route.
Our case study presents the fundamental properties depicted in the beginning of thissection, it is embedded in the mobile phone of the users, in buses and bus stops. Additionally,it presents an intelligent behavior because it uses a context-aware planning algorithm andrequires the collaboration between interacting agents and finally, it is context aware because it
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 227
has an anticipatory behavior to offer services depending on the current context. Additionally,in order to reduce the cost and improve the response time of the communication betweenagents, the MAS promotes the communication of agents in proximity. User agents do notneed an active Internet connection (Wi-Fi or 3G) all the time because they can gather thenecessary information to generate the route via Bluetooth from an access point located atthe bus stop. The localization of system agents in devices nearby is complemented by theuse of other wireless technologies such as NFC and RFID. These are used as a previous stepto the establishment of Bluetooth connections. When a UserAgent (i.e. the user and his/herdevice) is near a bus stop, NFC and RFID allow the agent to obtain (contextual) informationto identify the corresponding StopAgent. Similarly, when the user gets on the bus, the agentcan identify and easily locate the corresponding BusAgent.
4 Designing with PIM4Agents and Malaca
This section shows how to model a system (our case study, the ITS) in PIM4Agents (theDSML4MAS approach) using the DDE Tool. Before describing the design of the ITS, wewill explain the main concepts of the PIM4Agents metamodel, the source metamodel in ourapproach, and how we use them to specify context awareness. In the following subsectionwe explain the main concepts of the Malaca/MalacaTiny agent architecture, to which wewant to transform the PIM4Agents model of the ITS. Due to limitations of space, an in-depthdescription of both metamodels is not provided in this paper but more information aboutthem can be found in [20] and in [6].
4.1 Multi-agent system design in PIM4Agents
A system design in PIM4Agents is structured as several viewpoints of the MAS (a systemdesign is composed of 12 different viewpoints). The DDE tool facilitates the graphical rep-resentation of these viewpoints. The first viewpoint in the design process of our applicationis the MAS viewpoint, which specifies the main building blocks of the MAS (roles, inter-actions, agents, services, organizations and so on) and their relationships. Figure 3 showsthe MAS viewpoint of the ITS system in the DDE Tool. The representation of the agents,organizations and roles is straightforward in the PIM4Agents design model. In order foragents to interact, first they must be members of an Organization in this viewpoint. AgentsUserAgent, StopAgent and BusAgent, all interact for route planning, and are members of theITSOrganization (this membership relation is represented by the requires relation of theseagents through the depicted roles). This viewpoint also includes a representation of the agentexecution environment, which includes the set of objects, data types and functions that canbe accessed by agents (represented by the ITSEnvironment element in Fig. 3); and the set ofmessages that are exchanged between the agents within the organization (in Fig. 3 we cansee some of them target, route and nextStop). In the Environment viewpoint the designercan describe the internal information of the system (data and functions). This viewpoint (afigure is not included because of limitations of space) contains the description of the internalcomponents of the agents (such as the set of available sensors and actuators) that providecontext data (e.g. GPS, RouteController and RFIDScanner in the case of the BusAgent); thedata types to model the context (e.g. time table and position in the case of StopAgent); andthe internal events. These elements can be related to the agents in the MAS viewpoint.
The Agent viewpoint is the second step in the DSML4MAS design process and it deals withthe design of the agent’s internal elements (by means of data, behaviors and capabilities). An
123
228 Auton Agent Multi-Agent Syst (2014) 28:214–255
Fig. 3 PIM4Agents Multi-Agent system diagram in the DDE Tool
agent in PIM4Agents is an entity that can play particular roles and show various behaviors;and the agent has certain capabilities that group a set of behaviors. The Agent viewpointshows how agents perform the roles included in the MAS viewpoint by the plans that eachrole has associated with it. For the ITS case study, the UserAgent agent, which plays therole of the user of the system, includes ten different plans to: connect and disconnect to aspecific bus or bus stop; to request a route; to control the progress along the route that a useris following (user does not miss the corresponding bus stop and check that the expected timeof the journey has not dramatically increased); and to refine the current user route if it isnecessary. The StopAgent agent, which plays the role of infrastructure for the ITS, includesseven plans to: subscribe and unsubscribe BusAgents; receive information from subscribedbuses and show said information to users; plan routes and cooperate with other StopAgentsfor the same purpose. Finally, the BusAgent agent plays the role of vehicle and has nineplans for adding and removing UserAgents from the group of current users of the bus, tocontrol its current journey, transmit the next stop to the group users on the bus, subscribe andunsubscribe to the stops that are found on the route and transmit information on speed andposition to the agents embedded at those bus stops.
The information managed internally by the agents is described by the Knowledge view-point. The Collaboration, Organization and Interaction viewpoints deal with the design ofinteractions from specific perspectives. Due to limitations of space, this paper only focuseson the design of the interaction protocols, which is done in the Interaction viewpoint, sincethis is the most complex element to transform to Malaca/MalacaTiny. The ITS case study iscomposed by 9 Interaction view points and Fig. 4 shows the interaction viewpoint of the Bus-RouteRequest interaction protocol, which covers the interaction between two roles (played byagents) in the provision of a route to an specific target. This viewpoint shows the set of actorsinvolved (RouteRequesterBus and BusStopRouteProvider), the set of messages exchanged(Request and Propose), and how the exchange of messages takes place (the BusRouteRequestsends a Request that is answered by BusStopRouteProvider with a Proposal message). Atrun-time, the RouteRequesterBus is performed by BusAgent agent, while the StopAgent agentwill act as the BusStopRouteProvider. This protocol corresponds to the situation in which theuser is inside the bus and requests a refining of his/her current route (this could be becausehe/she missed the corresponding bus stop or the current route has a huge delay), in this caseBusAgent acts as an intermediary between StopAgent and UserAgent. There is a differentprotocol named RouteRequest which shows the same pattern of interaction, in this protocolthe UserAgent plays the role of the requester of the route, while the provider continues beingthe StopAgent.
The Behavior viewpoint describes the plans by means of plan diagrams in the DDE Tool.A plan is composed of a set of atomic tasks or actions, such as sending a message, which are
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 229
Fig. 4 BusRouteRequest protocol diagram in the DDE Tool
Fig. 5 RouteReplanning plan diagram in the DDE Tool
related using complex control structures. Additionally, the plan diagram shows how infor-mation flows between the different actions that compose the plan. The plan RouteReplanning(Fig. 5), which is used to determine whether to replan the route and requests the route replan-ning, represents a context dependent behavior. Context awareness is normally modeled bydefining the elements that fit the context data (which are defined in the Knowledge view-point), and how a change in the context influences the internal behavior of the agent (whichis shown in the Behavior viewpoint). When the context changes, the knowledge base of theagent is updated with the context value. When the knowledge base is updated, an event isthrown (KnowledgeBaseEvent in Fig. 5) which contains information about the change (theresource that has been updated). For this case study the agent context is represented by thecurrent route that the user is following, the expected delay and the next stop. The informationon the expected delay is gathered by UserAgent periodically querying the BusAgent andthe information about the next stop is transmitted by BusAgent to UserAgents inside thebus. This fits the contextual information, which is stored in the knowledge base. Therefore,when the expected delay is very high or BusAgent sends a new next stop, i.e. the contextchanges, the knowledge base of the agent is updated, and an internal event informing ofthe change is thrown. However, the event handling is a feature that is not explicitly sup-ported by the PIM4Agent metamodel. We have solved this limitation using an atomic tasknamed ReceiveEvent that shows that an event (that is a resource) has been thrown and caught.Once the event is caught (i.e. when an event is received), a subsequent action (isRouteCor-rect element) focuses on handling this context change, by deciding whether replanning itis required (by an if-then-else control construct). The decision isRouteCorrect means theuser has missed the corresponding bus stop or the time to complete his/her journey fol-lowing this route is much higher than expected. In this situation the UserAgent sends amessage requesting a new route. In the case that the next stop would be the destinationof the user (isDestination decision) a notification is presented to the user (ShowNotifica-tion).
Finally, the DDE Tool also provides the description of information at runtime (such asagents’ identifiers and number of instances of a specific agent or an organization) in a view-point named Deployment viewpoint.
123
230 Auton Agent Multi-Agent Syst (2014) 28:214–255
4.2 Architectural design of Malaca agents
Before presenting the transformation rules from PIM4Agents to Malaca, we will show inthis section, the main architectural elements of the Malaca metamodel, which are neededto understand the mapping between both metamodels. Since the transformation rules onlyentail the metamodel, and not the implementation issues, in this section we refer to Malacainstead of MalacaTiny. The Malaca agent metamodel combines the use of component-basedand aspect-oriented technologies, by modeling the agent domain specific functionality ascomponents and any other non-functional or crosscutting concerns as an aspect. In Aspect-Oriented Software Development (AOSD) crosscutting concerns are defined as propertiesthat affect many architectural components, and should be modeled separately as aspects.Following an aspect-oriented approach, the Malaca metamodel separates the specification ofthe agent’s internal components from crosscutting concerns related with the processing ofinput and output messages, and internal events produced inside the agent. Specifically, Malacaseparates several aspects (e.g. coordination, learning, distribution, etc.). The list of aspectsmodeled by Malaca and how they are composed (i.e. woven in AOSD terminology) togetherwith the rest of the components are described extensively in [3] and are not a contribution ofthis paper.
So, in this section we will principally describe the architectural elements of the UserAgentof our case study, with the sole purpose of explaining the transformation from PIM4Agentsto Malaca, one of the contributions of this paper. The description of a Malaca agent archi-tecture is specified in MaDL, a domain specific description language (based in XML). Thusin our process, instead of generating code we generate architectural descriptions in MaDL,and reuse most of the components and aspect implementations provided by the MalacaTinyframework. Accordingly this approach can be considered an architecture centric approach.The MaDL description of components and aspects provides information for their identifi-cation and composition inside the agent architecture. Instead of showing the XML code ofMaDL, which is not very legible, we use the corresponding UML representation of the XMLelements and attributes (see Fig. 6): classes represent the XML elements and class attributesrepresent XML element attributes. Figure 6 accurately shows the UML representation of theinternal architecture of the UserAgent. In the UML diagram it can be seen that the basicstructure of the MaDL agent description contains three main blocks: BaseFunctionality,AspectualProperties and the InitialConfiguration.
The element BaseFunctionality encloses the description of the components of the agentarchitecture, providing base application-specific functionality. In our ITS system, any exter-nal device or function (i.e. sensors and actuators) could be represented as internal components(for example a NFC or RFID scanner). In the ITS, the UserAgent receives contextual infor-mation about the bus or the stop, about the bus that the user has taken or bus stop thathe/she uses to request a route from before communicating with the corresponding agents.This contextual information is provided by NFC and RFID readers (included in the light-weight device the user wears), which are considered sensor components in our approach. Sothe BaseFunctionality section of the UserAgent description contains a component descrip-tion (ComponentDescription element) for any sensor and actuator of the vehicle, providingupdated information (NFCScanner) and (RFIDScanner). The UserAgent also includes acomponent which represents the graphical user interface (UserGui).
The element AspectualProperties encloses the description of the aspects considered in theagent design. The description of aspects at the design phase specifies the necessary informa-tion to compose (i.e. weave) each aspect inside the agent architecture by setting up a set ofrelevant attributes. Two of these attributes refer to the identification of the aspect (role and
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 231
Fig. 6 UML architectural diagram of the UserAgent in MaDL and RouteRequest protocol in ProtDL
123
232 Auton Agent Multi-Agent Syst (2014) 28:214–255
the roleInstance —the second is used to distinguish between different instances of aspectswith the same role identifier). The scope attribute, which determines and describes the ambitof the aspect behavior, and the relevance attribute which is related to aspect weaving andspecifies the criticality of being successful or not in the evaluation of each aspect. Giventhat Malaca is an architecture-centric approach, it provides prefabricated solutions (aspectpatterns) modeling generic and reusable aspects of some agent specific and commonly occur-ring crosscutting concerns at the architectural level (e.g. interagent communication). Specif-ically, aspect patterns describe the relationships, dependencies and functionalities of a set ofaspects. For instance, there is a generic aspect pattern that helps in the specification of theFIPA-compliant communication by specifying three basic aspects (i.e. distribution, repre-sentation and coordination). So, any Malaca agent that communicates with other agents hasto include at least the three aspects identified in this generic aspect pattern, in addition toothers specific to a particular MAS or application (e.g. context-awareness, security, learning,etc.). The identification of the communication aspect pattern (also known as core aspects) isdescribed in depth in [3].
Figure 6 shows a partial view of the AspectualProperties section. The UserAgent includes,among other things, a context-awareness aspect in charge of gathering context changes andnotifying the user when they should get off the bus or requesting the replanning of thecurrent route. Its description identifies this aspect (role identifier is set to ContextAwarenessand roleInstance to role RouteController) and, according to this description, this aspect canintercept any event or message from the agent.
The AspectualProperties description also includes a description of a CoordinationAspectfor each interaction the agent takes part in (supported by an interaction protocol). To give anexample, Fig. 6 includes the coordination aspect description for the RouteRequest protocol, inwhich the UserAgent participates as participant. Within the additional information providedin the description of the coordination aspect, the reference for the XML document thatdescribes this protocol is given. This description will be explained further on in this section.
After aspect description, the AspectWeaving section encapsulates the aspect compositionrules, which sets when and how aspects are woven. According to AOSD practices, aspectsare composed when the system reaches certain execution points (join points). In AOSD joinpoints represent the execution points that can be intercepted (e.g. a message is received)and the predicate describing the set of join points intercepted by an aspect is called pointcut(e.g. interception of each “cfp” message received). The joinpoint model (JPM) of Malacadefines three join points: for the interception of the incoming (RECV_MSG) and outgoing(SEND_MSG) messages, and internal events (THROW_EVENT ). In the ITS system (and inAmI systems), agents are required to capture environmental context changes (e.g. any changein the data of a sensor), which are notified by events. Then, context-awareness aspects, whichare required to capture environmental context changes, have to be applied and composedat the interception point (THROW_EVENT ). Figure 6 shows a partial description of thecomposition rule for the RECV_MSG interception point, which provides an ordered list ofthe aspects that have to be composed (Representation and Coordination) in the same termsthat aspect description in the AspectualProperties section.
Finally, the design of the agent architecture also includes a description of the knowledgebase (as part of the element InitialConfiguration in Fig. 6). This description enumeratesthe resources that the agent manages internally. In this section, any contextual informationthe agent has to process is included as a resource of the agent’s internal knowledge base.For the UserAgent, the knowledge base will store the updated information relative to theexpected delay of the route, the agent that can process its route requesting, both the currentroute that it is following and the next stop of that bus, DELAY, ROUTE_PROVIDER, ROUTE
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 233
and NEXT_STOP respectively. Deployment information of the agent can be given in a followup section of the agent description named DeploymentInfo, which enables the initial set ofresources and behaviors of the agent to be set up.
The design of the agent in Malaca is completed with the external description of theinteraction protocols in ProtDL (which can be considered part of the MaDL description).The main elements and the structure of a ProtDL description are depicted in Fig. 6. Inbrief, the description of the interaction protocol provides an XML-based description of themessages exchanged (enclosed in a InterchangedMessages element) and a description of theinternal behavior of the roles involved (enclosed in a RoleDescription element with each actorinvolved). For each role, its description represents its behavior with a finite state machine(FSM for short). An FSM description (enclosed in a FiniteStateMachine element) contains:a declaration of the FSM states, the set of rules that describes state transitions (each rule isenclosed in a stateTransitionRule element), and the set of actions and activities the agentperforms as a consequence of the transition (enclosed in a TransitionDescription element).Although more details on protocol description will be given in the following sections, a proofspecification of interaction protocol description is given in [3].
5 Transformation rules from PIM4Agents to Malaca
Exactly as we have presented it above, Malaca models the application dependent functionalityof the agent in MaDL and the specification of interaction protocols in ProtDL metamodels.In this section we summarize the main mappings between PIM4Agents concepts and MaDLand ProtDL concepts, performed by a set of ATL mapping rules. The mapping rules includedin this paper do not constitute an exhaustive list. We have only included those that help inunderstanding the most relevant model mappings required for the use case scenario. Somemapping rules are applied automatically (simple ATL rules), while the application of otherrules depends on the previous application of other mapping rules or must be invoked byother rules (ATL lazy rules). For each concept from the PIM4Agents metamodel there areone or more transformation rules to map this concept to the Malaca metamodels. This is notthe case of the organization concept of PIM4Agents. Malaca focuses on the internal designof the agent and organizations are not considered explicitly. Therefore, this concept is notmapped to Malaca. In this section the transformation rules are described in detail and Table 3summarizes the main mappings between the concepts of PIM4Agents and MaDL conceptsand Table 4 does the same for ProtDL concepts. We have labeled each rule in the form of anMRnumber for MaDL rules and a PRnumber for ProtDL rules to make the identification ofa specific rule in the text easier.
We also illustrate the application of each rule in our example. The diagrams presented inSect. 4.1 provide enough information to generate the MaDL and ProtDL specifications forUserAgent, StopAgent and BusAgent. Due to limitations of space, this section focuses onthe code generation process of the UserAgent agent (Fig.7) and BusRouteRequest protocol(Fig. 8).
5.1 Generating MaDL
MaDL Rule 1 The first rule applied is MR1. This rule maps a PIM4Agents!Agent to thebasic structure of an AgentDescription in MaDL and its constituent parts, i.e. the agentarchitecture: BaseFunctionality, AspectualProperties and InitialConfiguration (lines 1, 2,7, 26). In our example the AgentDescription name is UserAgent. The AspectualProperties
123
234 Auton Agent Multi-Agent Syst (2014) 28:214–255
Table 3 Mapping process between the PIM4Agents metamodel and MaDL metamodel
Target Source Explanation
MR1: AgentDescription Agent Each Agent is mapped to an AgentDescription
MR2: AgentDescription AgentInstance Each AgentInstance is mapped to an AgentDescrip-tion with the same associated interactions and thesame identifier at runtime.
MR3: CoordinationAspect DomainRole Each DomainRole associated with a Protocol meansof a Collaboration element is mapped to a Coordina-tionAspect
.
MR4: ComponentDescription Resource Each Resource is mapped to a ComponentDescription.
MR5: CompositionRule Agent For each Agent is derived an AspectCompositionRulefor RECV_MSG InterceptionPoint
.
MR6: AspectDescription DomainRole For each DomainRole is derived an AspectDescrip-tion for RECV_MSG InterceptionPoint.
MR7: Resource Knowledge For each Knowledge a Resource whose type is beliefis derived with the same name, value and type
.
MR8: Aspect Behavior For each Behaviour that has a context-aware action anAspect with the role ContextAwareness is generated.
Table 4 Mapping process between the PIM4Agents metamodel and ProtDL metamodel
Target Source Explanation
PR1: ProtocolDescription Protocol Each Protocol is mapped to a ProtocolDescrip-tion
PR2: RoleDescription Actor Each Actor is mapped to a RoleDescription asso-ciated with a specific ProtocolDescription
.
PR3: StateTransitionRule MessageFlow, MessageFlow From two MessageFlow elements this rule cre-ates a StateTransitionRule that begins in the firstMessageFlow and ends in the second one.
PR4: TransitionDescription MessageFlow, MessageFlow From two MessageFlow elements this rule cre-ates a TransitionDescription that begins in the firstMessageFlow and ends in the second one.
PR5: RoleDescription Plan, String This rule creates a RoleDescription from a Planand a String that is the name for the Role
.
PR6: StateTransitionRule Activity, Activity From two Activity elements this rule creates aStateTransitionRule that begins in the first Activ-ity and ends in the second one.
PR7: TransitionDescription Activity, Activity From two Activity elements this rule createsa TransitionDescription that begins in the firstActivity and ends in the second one.
PR8: ProcessComponent InternalTask Each InternalTask is mapped to a ProcessCom-ponent
.
PR9: ProcessComponent Sequence Each Sequence or any StructuredActivity ismapped to a ProcessComponent that have associ-ated a CompositeProcess
.
PR10: ProtocolDescription Protocol, Organization Each Protocol which is from an Organization ismapped to a Protocol
.
element is partially generated, since only those aspects considered obligatory for the correctfunctioning of the agent are derived (i.e. the Representation and Distribution aspects, lines 8and 9). Both aspects are platform-dependent so only the default information is generated here.The rest of the required information is bound later for each agent once implementation anddeployment decisions have been taken in the model to text transformation, presented later.
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 235
Fig. 7 MaDL specification for UserAgent in XML from Eclipse Modeling Framework
MaDL Rule 2 This rule is applied only when a deployment diagram has been specified withthe DDE Tool (line 32). In this case, the transformation process knows how many agentsparticipate in the MAS and some additional information per agent. So, with this informationprovided by the deployment diagram, this transformation rule can derive one agent structure(i.e. AgentDescription element), for each AgentInstance present in the deployment diagram,by calling MR1. Additionally, it also completes some deployment information such as theagent name, in the initialConfiguration section of MaDL (User1234 in the example, line 32).
MaDL Rule 3 This rule is in charge of generating the coordination aspects. This kind ofaspect can be easily identified in the source metamodel, since it must be defined in theinteraction viewpoint. So, if a DomainRole is associated with a Protocol in PIM4Agents (bymeans of a Collaboration element), then a Coordination Aspect element in MaDL is derived.In this case, this rule links the MaDL agent specification with the separated description ofthe protocol in ProtDL. In our example, coordination aspects for two interaction protocolsare derived (i.e. RouteRequest (line 11), JoinBus, UpdateStop and RefineRoute).
MaDL Rule 4 This rule maps a PIM4Agents!Resource to a ComponentDescription in MaDLwhich is a set of identifiers that permit the identification of the component in the deploymentphase in order to assign a specific implementation to it. Specifically, it generates the compo-nents name, its type, operations and internal attributes (only if this information was set bythe DDE Tool). In our example, four component elements are derived (i.e. UserGui (line 3),RFIDScanner (line 4), NFCScanner (line 5) and Alarm).
MaDL Rule 5 We have defined one MR5 rule, for each interception point defined inMalaca metamodel. Specifically, the one included in Table 3 derives an AspectComposi-tionRule element for the RECV_MSG InterceptionPoint (line 13). By default, the aspects
123
236 Auton Agent Multi-Agent Syst (2014) 28:214–255
Fig. 8 ProtDL specification for BusRequestRoute protocol in XML from Eclipse Modeling Framework
applied when a message is received are Representation and Coordination for each of thePIM4Agents!DomainRole associated with the Agent entity. Likewise, similar rules are definedfor the SEND_MSG and THROW_EVENT InterceptionPoints.
MaDL Rule 6 To specify the aspects applied in the AspectCompositionRule MR6-like rulesare defined. Fig. 7 shows the output of this rule, which indicates that each time a message isreceived by the agent, the representation (lines 14–16) and coordination aspects (17–22)areevaluated. In the SEND_MSG InterceptionPoint normally the Distribution aspect is appliedin order to decide which AP and/or communication protocol must be used to deliver themessage.
MaDL Rule 7 In MaDL, the InitialConfiguration element is associated with a Knowledge-BaseContent element that is formed by a set of Resource elements with different categories(belief, goal, instance, condition, data). This rule generates those Resource elements for thebelief category (lines 27 and 30).
MaDL Rule 8 This rule generates the context-aware aspects of the agent. Each context awarePIM4Agents! Behavior is mapped to an MaDL!Aspect with Role mapped to ContextAware-ness, RoleInstance mapped to Behavior’s name and Scope mapped to Agent (line 10).A PIM4Agents! Behavior is context aware if it has an AtomicTask named ReceiveEventwith a PIM4Agents! Knowledge associated with it (Fig. 5).
5.2 Generating ProtDL
As stated, each interaction protocol is specified in an individual description in ProtDL. AProtDL specification is composed of a set of message descriptions and a set of role descriptionsthat describe the behavior of each participating role using an FSM. The description of anFSM includes the list of states (initial, intermediate and final), the state transition rules andthe actions taken when a transition is executed. However, during an incremental specificationof an MAS in PIM4Agents, the designer may choose not to specify plans associated witheach interaction protocol. Rules PR3 and PR4 are defined for this case. Since this is not thecase of our example, these rules do not appear in the generated code (Fig. 8).
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 237
Figure 8 describes the BusRequestRoute protocol that covers the interaction between theRouteRequesterBus and BusStopRouteProvider actors in the provision of a route to a specifictarget 4.
ProtDL Rule 1 This rule maps a PIM4Agents!Protocol to a ProtocolDescription in Malacawith the same ID, exchanged messages and actors.
ProtDL Rule 2 Each Actor in the PIM4Agents!Protocol is mapped to a RoleDescription inProtDL!Protocol. The RoleDescription has the same ID as the Actor. The Actor activeStatesare mapped to the states of the RoleDescription’s FiniteStateMachine.
ProtDL Rule 3 This rule is linked to PR2 and is used to derive the StateTransitionRule of aFiniteStateMachine. The occurrence of two consecutive MessageFlows (for a given Protocoland Actor) is mapped to a StateTransitionRule. The first MessageFlow is mapped to thecurrent state while the second one is mapped to the next state.
ProtDL Rule 4 This rule is linked to PR2 and it is very similar to PR3. The occurrence oftwo consecutive MessageFlows is mapped to a TransitionDescription which describes thesending of a message.
ProtDL Rule 5 The role description structure is mapped using PR5; it takes a role name andits associated plan and then calls PR6 and PR7 which generate the description of the FSM. Thisis a lazy rule that maps a Plan (associated with a given Actor or Agent denoted by the Stringthat is passed as an argument) to RoleDescription, identified with the same String. During itsapplication, PR5 needs a special function (helper) to ignore ReceiveMessage Activity. In ourexample, the role description structure for the roles Initiator (line 6) and Responder (line 7)are generated.
ProtDL Rule 6 Transition rules are generated by PR6. This rule is very similar to PR4but it considers Activities instead of MessageFlows to generate StateTransitionRule(s) of theFiniteStateMachine. In order for this rule to be applied, the first Activity is for the reception ofa message (PIM4Agents!Receive) or for event reception (a PIM4Agents!InternalTask namedReceiveEvent and is associated with a LocalKnowledge). The latter is a mechanism created forthis transformation process in order to solve the lack of vocabulary of the PIM4Agents, whichdoes not model event reception. In our example, the state transition for the BusRouteRequestFIPA protocol is generated (lines 9 – 11). This state transition rule specifies that after receiv-ing the BusRouteRequest_1 under the ReceiveRequest state, the FSM remains in the samestate.
ProtDL Rule 7 This rule is very similar to PR6 but instead of generating StateTransition-Rule, it generates TransitionDescription (line 12). Transition descriptions are very similar tothe PIM4Agents plans so the mapping between these two concepts is straightforward. Thedescription of the TransitionDescription sub-elements is derived from the application of thesubsequent rules.
ProtDL Rule 8 This rule maps a PIM4Agents InternalTask of a ProtDL DoActionTypeAtomic Process. Specifically, line 16, states that the invocation of the PlanifyRoute servicewill be performed as part of the transition TranReceiveRequest_1 (line 16). Note that it isnot possible to generate the component name where this service is implemented, since thisinformation is not present in PIM4Agents’s diagrams. In the model to text transformation,this information is completed. We specify one PR8-like rule for each type of atomic actionin PIM4Agents (e.g. lines 22–25, for the sendMessage action)
123
238 Auton Agent Multi-Agent Syst (2014) 28:214–255
ProtDL Rule 9 As we do for PR8, we specify a PR9-like rule for each type of complexaction in PIM4Agents like sequence (line 14), conditions, loops, parallel executions, etc.Concretely, each PIM4Agents StructuredActivity is mapped to a ProtDL CompositeProcess.
ProtDL Rule 10 This rule maps each PIM4Agents Protocol within an Organization to aProtDL ProtocolDescription. A ProtocolDescription includes a RoleDescription which cor-responds to a set of actions describing the behavior of the agent during the interaction, andthe interchangedMessages. If there is no PIM4Agents Plan associated with the protocol, thenjust the message exchange is described using PR3.
6 Generating MalacaTiny agents from Malaca
This section shows the implementation of the MalacaTiny for devices with MIDP profile. Asstated before, we currently provide different implementations of MalacaTiny, but because oflimitations of space and the strong presence of this technology in the market of smartphones,this paper focuses on this version of the platform.
6.1 Internal design of MalacaTiny agent implementation
As stated before, components offer the application specific functionality of the MalacaTinyagent, while aspects encapsulate crosscutting properties of the agent, such as coordination,among others [3]. The MalacaTiny implementation presented in this section (Fig. 9) mustbe efficient in resource consumption and also consider the particular limitations of the JavaME compared to the standard Java. One of these limitations is the absence of the ReflectionAPI, which gave us, in the former Malaca implementation for PC, the technical support tocompose their internal elements (components and aspects) by a late binding mechanism. Withthis mechanism the developer only has to specify (not codify) the necessary information toinstantiate and invoke the method of a specific component. But, this is not possible in JavaME, so we implemented a simpler mechanism in MalacaTiny: the components are addedto the agent with an identifier (e.g. addComponent(“GUI”, UserGuiClass)) so that otherelements of the architecture (normally the aspects) can refer to this identifier and require theservices provided by a certain component, by first obtaining the reference of the requiredcomponent using the getComponent method (e.g. getComponent(“GUI”)). This improvesthe modularization and evolution of application specific functionality, since aspects do not
Mediator
+receiveMessage( msg : Object ) : void+sendMessage( msg : ACLMessage ) : void+throwEvent( event : Object ) : void#addComponent( id : String, instance : Object ) : boolean+getComponent( id : String ) : Object#addKnowledge( id : String, knowldg : Object ) : boolean+getKnowledge( id : String ) : Object#addInstantiateAspect( id : String, instance : Aspect ) : void#addCompositionRuleFor( ip : int ) : void
Fig. 10 UML class diagram for aspects in MalacaTiny
keep an explicit reference to the components they use, and only need to maintain a link to theMediator entity, in charge of performing the composition between components and aspects,according to the composition rules.
The use of aspects, and specifically the distribution aspect helps to achieve solutions tomost of the challenges of AmI systems. The distribution aspect encapsulates how to use andaccess the message transport service (MTS) for message delivering. The implementation ofthe distribution aspect strongly depends on the services offered by the AP and the transportprotocol used. In fact, this aspect supports platform-neutrality for FIPA compliant APs: thisaspect hides platform dependencies, and makes the rest of the classes of the agent architecture(components and aspects) independent from the AP (challenge C4) and the communicationservice (challenge C5) used at runtime. Indeed, the distribution aspect is an interface for theFIPA standard services provided by a remote AP. The implementation of an aspect for thedistribution of messages in a specific AP has to extend the DistributionAspect class and has toimplement the methods defined in the FIPAAgentPlatform interface (Fig. 10). The definitionof this interface enables the use of different implementations of the distribution aspect trans-parent to the rest of the elements of the architecture and provides a unified interface to FIPAstandard services (i.e. communication between agents, deploy or kill agents, start or stop theAP, register services and locate agents and services). The current implementation of Mala-caTiny provides distribution aspects for Jade-Leap, Sol and Bluetooth. In Fig. 10 the classesshown implement the distribution aspect for Jade-Leap AP: JadeLeapPlugin class extendingDistributionAspect and MIDPJadeLeapAP class that implements FIPAAgentPlatform inter-face; both have a reference to JadeProxy class that acts as a proxy between Jade-Leap APand these objects. Also, it is possible that an agent communicates with other agents throughdifferent APs (part of the C4 challenge).
The Aspect Orientation provides MalacaTiny agents with a better modularization of theirinternal architecture that facilitates the (re)use of the domain specific agent functionality. Inthe case of the distribution aspect it makes it possible to deploy the agent in different APsor in multiple APs simultaneously with minimum changes in the internal agent architecture.Additionally, it is easier to modify the context-aware behavior of the agent, even at runtime.This is done by means of the composition rules of the agent, that decide the aspects that arecomposed in the aforementioned join point of MalacaTiny (see Sect. 4.2).
6.2 Developing a distribution aspect for Bluetooth
To illustrate the accomplishment of challenge C5, we will demonstrate how to extend thedistribution aspect to enable the communication of agents with different wireless technologiesand without the use of AP distribution services. In AmI environments, the communication ofneighboring devices is very popular. In this scenario, Bluetooth allows devices to wirelessly
123
240 Auton Agent Multi-Agent Syst (2014) 28:214–255
communicate over short distances. This wireless technology enables ad hoc networks tobe formed dynamically between Bluetooth-capable devices. Bluetooth makes it possibleto use the Bluetooth network interface to send and receive TCP/IP transport data. However,Bluetooth’s specification defines four major transport protocols, nearly all of which are specialpurpose. Of these protocols, the Radio Frequency Communications (RFCOMM) protocol isoften the best choice, and sometimes the only choice (some environments only supportthis protocol). RFCOMM is a general-purpose reliable stream-based protocol. It provides,roughly, the same service and reliability guarantees as TCP. The Logical Link Control andAdaptation Protocol (L2CAP) is a packet-based protocol that is also widely used when thestreaming nature of RFCOMM is not needed.
In order to enable MalacaTiny to communicate with other agents using BluetoothRFCOMM connections, we just need to implement a new plugin. From the agent perspec-tive, its functionality remains the same: the distribution of ACL messages is provided bythe distribution aspect. However, this implementation of the distribution aspect encapsulatesall the particularities of Bluetooth: device and service discovery, and the establishment ofRFCOMM connections. Prior to data transmission, Bluetooth devices need to perform deviceinquiry and service discovery. When these processes have finished, a Bluetooth device canestablish a connection that enables communication with devices nearby. The device that startsthe search plays a client role in the communication and the devices discovered are servers.This initial process is not so different to the AMS and the DF query in APs.11
A FIPA compliant AP offers a DF for service discovery, but a service must be previouslyregistered in the DF. In a Bluetooth network, service discovery is very similar, since eachBluetooth-enabled device running an agent publishes services that can be found by clients(i.e. agents running in other Bluetooth devices). The published services allow the agentsto communicate. Then the distribution aspect uses the Service Discovery Protocol (SDP)to discover devices (i.e. agents), and, for each device, it seeks a specific service that allowsagents to exchange ACL messages (the approach in Bluetooth is to assign every single servicea unique identifier). The service record returned by the SDP contains the URL that allows thedistribution aspect, acting as a client, to establish a RFCOMM connection with the distributionaspect of the other agent (that plays the role of a server). In parallel, the distribution aspectpublishes its own service for communicating with other agents. Therefore, each agent thatuses the distribution aspect for Bluetooth plays a server role and additionally, if it seeks otheragents it is considered an inquiring client. Finally, both roles are a way to get Bluetoothconnections, which are identified by the Bluetooth address of the other side’s device. As aBluetooth address is a unique identifier for each device, this guarantees that each connectioncan be univocally identified.
The design of this aspect is shown in Fig. 11. The BluetoothPlugin class is in charge ofthe communication between agents using Bluetooth. By default it sets up a BTHost objectthat waits for requests from BTClient objects (a Bluetooth device never inquiries in itself).When one of these artifacts sets a connection, it creates a BluetoothConnection object that istransmitted to BluetoothPlugin, which keeps a hashtable with all connections indexed by theBluetooth address as a key. The purpose of BluetoothConnection is to hide the complexity ofthe message exchange from BluetoothPlugin. The class BlueAgentPlatform implements theFIPAAgentPlatform interface, providing AP services to the MalacaAgent and additionally it isin charge of initializing the internal objects of the distribution aspect (e.g. the BluetoohPluginobject). Since the data transmitted between Bluetooth devices using the RFComm socketscannot be Java objects, then a message representation aspect based on String format has also
Auton Agent Multi-Agent Syst (2014) 28:214–255 241
RepresentationAspect
BlueMRepresentation
BluetoothConnection
FIPAAgentPlatform
BlueAgentPlatform
DistributionAspect
BluetoothPlugin
BTClient BTHost
-_host
-_plugin
-_client-_connections
Fig. 11 UML class diagram of the distribution aspect for Bluetooth in MalacaTiny
been developed. This format is called BlueMessage and the aspect that processes messagesin this format is called BlueMRepresentation (see Fig. 11).
The effort required to develop this plug-in and integrate it as part of the agent internals tosupport a new communication protocol was not very high, thanks to the good modularizationof the MalacaTiny architecture that uses aspects orientation. In addition, the plug-in can bereused in any MalacaTiny agent, regardless of whether the MAS of the agent is involved. Asa result, agents can decide to use this communication protocol, to support the communicationof neighboring agents. Moreover, it is possible to provide plug-ins to enable the discoveryand communication of agents using other wireless technologies (e.g. IEEE 802.15.4/Zigbeefor agents running in Sun SPOT sensors), or the services provided by new agent platformsas they appear. In addition, the composition of aspects inside the agents allows the use ofmore than one plug-in at a time. This feature makes the communication of agents in multipleheterogeneous devices possible, even at the same time.
6.3 Transformation rules from Malaca to MalacaTiny
In order to generate executable code for mobile devices, a final step in the process is necessary.Given the XMI files (corresponding to MaDL and ProtDL files), these are translated to JavaME code using a M2T transformation.
Firstly, each AgentDescriptionType element in a MaDL file is equivalent to a MalacaAgentclass. So, for each agent description a MalacaAgent class with the same name, knowledge,components, aspects and composition rules is generated (see Fig. 9). With the informationprovided by the DDE Tool, it is only possible to derive empty Java classes for knowledgeand components with the corresponding name. Therefore, knowledge and components areadded but they are linked to artifacts (classes, interfaces, attributes) that must be filled in byprogrammers.
For the aspects, there is a default set of aspects, mainly concerning agent communication(such as JadeLeapPlugin for the distribution aspect in Fig. 10), that have already been imple-mented. The incorporation of these aspects and their composition rules are derived from theM2M transformation process from PIM4Agents to Malaca, and the use of predefined aspectpatterns. For these aspects, the programmer only needs to indicate the IP address and port inwhich Jade AP is running.
Returning to our case study, Fig. 12 shows the generated implementation of the com-position rules for UserAgent in the interception point RECV_MSG. The composition ruleat this point requires the composition of the representation aspect named ACL_ADAPTORaspect (line 123), and then one of the following coordination aspects (if the message belongsto the corresponding protocol, determined by an instance of the class MessagePattern):routeRequestPN (line 127), joinBusPN (line 131), updateStopPN (line 135), or refineR-outePN (line 139). This code is generated automatically from the MaDL description. Gen-
123
242 Auton Agent Multi-Agent Syst (2014) 28:214–255
Fig. 12 Section of code of composition rules for RECV_MSG interception point for the UserAgent agent
Fig. 13 Section of code in Java ME of the request of a route by bus behavior derived from the BusRequestRouteprotocol description
erated values for RoleInstance and Scope usually have to be changed to guarantee a correctbehavior of the system. By default, Scope for coordination aspects is PROTOCOL_SCOPE,but it depends on the application whether this is applicable or not. If it is necessary to changethe Scope, then RoleInstance is modified using the Malaca aspect identification mechanism[3].
Finally, we want to point out that for the THROW_EVENT interception point, all thecoordination aspects are applied (all the aspects catch the event). If an aspect it not supposedto handle the event, it simply does nothing (i.e protocol connector does not change its internalstate and an exception is not thrown), but for greater efficiency it is preferable to remove thelines of code that do not match the THROW_EVENT interception point.
The initial ProtDL file is transformed to a set of Java ME classes; at least one class for eachRoleDescription element is included, and additionally, one class for each TransitionDescrip-tion element. The resultant code for initial setup of BusRequestRoute behavior can be seen inFig. 13. This figure shows the setup method of this class, where the states and transitions of theFSM are defined. There is a direct mapping between the ProtDL of Fig. 8 and de Java code ofFig. 13. The ProtDL line 10, that defines the message BusRouteRequest_1 is used to generatelines 23 – 25 in the Java code. Line 9 in ProtDL, describes the transition rule Transition-ReceiveRequest_1, used to generate the code to instantiate the initial state (ReceiveRequestline 27) and register all the information about the transition (line 28 in Java code). This classthat stores all the information about one transition TransitionReceiveRequest_1 is generatedfrom lines 12 – 27 in ProtDL.
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 243
Fig. 14 Section of code of TransitionReceiveKBE_1 class in Java ME
In the case that a TranstionDescription is specified in PIM4Agents as a plan (Fig. 5)then, the generation process generates a Java class (that implements the plan in the execute()method) and a Java interface defining a set of methods with the same name of the internaltasks of the plan and other tasks corresponding to control structures. For example, the codeshown in Fig. 14 corresponds to the execute() method of the plan implemented in the Tran-sitionReceiveKBE_1 class. This plan requires the execution of the following internal tasks:ComposeMessage (line 20), the sending of a message (line 21–25) and ShowNotification (line28). Note that the activity ReceiveEvent used in the design in PIM4Agent to model the recep-tion of an event is ignored in the implementation. The execution of these tasks is enclosedin two decision control structure implemented in the methods ComposeMessageCondition(line 19), isDestinationCondition (line 26) and ShowNotificationCondition (line 27) gener-ated from the M2T transformation process. This M2T generation process can be implementedusing any MDE code generator language as in our case MOFScript.
7 Validation
In order to evaluate our proposal we present and discuss some results with regard to theautomatic generation process of agents for AmI systems and we also present some resultsshowing the energy efficiency of MalacaTiny agents for devices with profile MIDP andAndroid devices compared with Jade-Leap. Agents implemented in Java ME and in Androidhave been widely used to develop AmI systems [11,26,29,35]. In our case study UserAgentruns on the mobile phone of the users, while BusAgent and StopAgent agents are embeddedin buses and the bus stop’s structure and therefore have no limitations on their computationalresources. Therefore, the results presented here focus on the agents running in user devices.
On the one hand, the experiments for Java ME were performed in a 5630 XpressMusicand in a N96 but in this section we present only those results obtained for XpressMusic.The monitoring of mobile phone parameters has been done using the Nokia Energy ProfilerThis application offers real time values collected while the mobile phone is functioning. Onthe other hand, the experiments for Android were performed in a HTC Desire12 and in a
244 Auton Agent Multi-Agent Syst (2014) 28:214–255
Samsung Galaxy13 but in this section we present only the results obtained from the HTCDesire. Meanwhile, the memory footprint of a process is difficult to measure in Androidbecause a lot of memory is actually shared across multiple processes [19], so we only presentstatic results captured in the Android emulator in order to provide a notion of the size of theagents.
7.1 Discussion
This section evaluates the contributions of this paper and provides a critical discussion ofthe benefits and limitations of our approach in comparison with current MDE processes forgenerating agents, particularly focusing on the DSML4MAS process.
7.1.1 Required effort to change transportation system
Cost of including a new agent platform Let us consider the scenario of extending aDSML4MAS-like process with a new AP. In the first place the metamodel of the targetAP must be available. Otherwise, the developer must specify this metamodel in a variant ofMOF. This effort could be considerable; requiring an extremely in-depth knowledge of theinternal architecture of the new AP. Secondly, the set of mappings from the PIM4Agents tothe new AP metamodel must be implemented in a transformation language such as ATL.Normally, programmers are not familiar with these kinds of languages, so additional learn-ing time/effort could be necessary. Finally, the generation of executable code in the targetAP must be accomplished by implementing a second set of mapping rules. These mappingrules must be implemented in a M2T transformation language, like MOFScript. As can beseen, the effort of including a new AP is considerable, especially because the developer mustacquire knowledge both in agent models and in many novel MDE languages (e.g. MOF, ATL,MOFScript).
On the other hand, in our approach the developer (i.e. we, the MalacaTiny providers) mustimplement a new plug-in in charge of instantiating the corresponding platform-dependentcommunication subsystem (which uses the specific MTS provided by the AP), and relateddata, for example the classes representing ACL messages. In our approach any expert pro-grammer will be able to implement this plug-in in no time at all (for instance, the Jade-Leapfor MIDP AP took half a day, implemented by a PhD student who was not very familiarwith the implementation of MalacaTiny). So, we consider that the effort and skills requiredto incorporate a new platform are much lower in our approach.
Optimization of the generated code. Now we will analyze the code generated by bothapproaches. Normally, the code obtained by automatic generation is not optimized. Specifi-cally for this case study, 240 classes were generated with the DDE tool for Jade, and only 104classes for MalacaTiny. There is such a big difference because the code generated by DDEincludes several dummy classes with empty methods (e.g. the action() method of behavioralJade classes). Exactly 31.66 % of the 240 classes generated are dummy code. One negativeconsequence of dummy classes is that they increase the number of indirections required, forexample, to invoke a behavioral method. In lightweight devices where memory and compu-tation resources are scarce, this is not acceptable as the code must be highly optimized toconsume the least amount of resources possible. Since our approach is architecture centric,most of the code that we generate are agent and protocol configurations and we only have
Auton Agent Multi-Agent Syst (2014) 28:214–255 245
to concentrate on MalacaTiny framework optimization, whose code is used as part of thegenerated code.
Limitations for the AmI domain. An AmI environment is often made up of different devices,which could contain agents running on top of different APs. With Malaca it is possible togenerate agents that cooperates in the same MAS for different APs where the interoperabilityis guaranteed. In other MDE approaches, following the traditional approach, the code foreach agent, of the same MAS must be generated by a different set of transformation rulesand completed by the agent designer several times for each AP, which is not what is wanted.
7.2 Degree of automation
In order to measure Productivity, Automation and Reuse in systems based on applicationframeworks (such as MalacaTiny or Jade) the Line Of Code metric (LOC) cannot be directlyused to compare the size of the generated MAS. Instead we use an adaptation of the approachpresented in [22], called degree of automation.
The effort (of development) required to implement a case study such as the ITS is recordedusing the number of drawn elements (NDE) a metric of the graphical elements required formodeling the agents with the DDE tool, coordination protocols and plans of the case study.Our experiments consist of extending the ITS by adding new agents with new capabilities, andnew states to protocols and plans that complete protocol specification. After each experimentis performed, the NDE metric is calculated again for the extended model. The increasedagent and coordination data produced by the transformation process is recorded and used asan alternative measure for the increased functionality in the extended scenario.
The ratio of increased PIM4Agents model development effort can be compared to theratio of the increased number of features in protocols and agents for MalacaTiny generatedcode. These ratios indicate the expressive power of the PIM4Agents abstractions and theircontribution to the transformation process in order to generate application functionality. Thisratio is measured as:
δ(Model)/δ(Feature_Size) (1)
where
δ(Model) = Extended P I M4 Agents Model (N DE)
Original P I M4 Agents Model (N DE)(2)
and
δ(Feature_Size) = Extended FeatureSi ze
Original FeatureSi ze(3)
The degree of automation metric is useful for measuring the related evaluation criteriaof productivity gain, automation and reuse. Both the extension of agent specifications andprotocols and the re-running of the transformation process show the reuse of domain modelcomponents. Since we have two transformation processes, we apply these metrics twice. Onthe one hand, for the MaDL transformation process that generates agents (knowledge, com-ponents, aspects and composition rules), the studied feature is the number of these elements.The NDE measure is applied to PIM4Agents diagrams that model these features (MAS,organization, collaboration, agent). On the other hand, the second transformation processcorresponds to the ProtDL and generates a protocol description by means of a finite statemachine for each participant role. In this case, the studied feature is the number of the tran-sition rules; plans executed in these transitions (transition descriptions) and atomic actions
123
246 Auton Agent Multi-Agent Syst (2014) 28:214–255
contained in these plans. The NDE measure is applied to the protocol diagram and associatedplan diagrams in the DDE Tool.
Scenario 1 Firstly, we add a new agent to our MAS for ITS named LineAgent. This agentruns in the main office of the bus company and advises the bus managers to add or removevehicles from its corresponding line. To do so, it gathers information about the buses of aspecific line, specifically this agent is interested in bus occupancy levels and the time requiredby the bus to complete a round-trip. So, this agent periodically receives information fromBusAgent agents of its line. Adding this agent means adding the following elements: we add anew agent, which is a member of ITSOrganization (Fig. 3); a user interface to present resultsto the bus company managers; two new protocols to model the interaction between LineAgentand BusAgent and associated plans for this protocol. We recalculate the NDE for the extendeddesign model. The NDE of agent features in the original model is 142, while the NDE forthe extended model is 166. The number of generated entities in the original model for thesefeatures is 55 and for the extended model is 65. Therefore, the value of the measure is:
δ(Model) : δ(Feature_Size) = 166
142: 65
55(4)
An increase of 16 % in agent development effort results in an increase of 19 % of theapplication functionality (measured by the number of coordination aspects, default aspects,distribution and representation, composition rules, components and knowledge).
Scenario 2 In order to check the Degree of Automation in ProtDL transformation process, forthe case study presented above, we transform the BusRouteRequest protocol (Fig. 4), whichis a classical FIPA-Request14 protocol, into a FIPA-ContractNet15 protocol (this protocolis similarly modeled in the DDE Tool to the BusRouteRequest protocol, but adding newmessages, messages flows and sub-actors associated with the actors depicted in Fig. 4). Thisprotocol involves one initiator and a set of participants, so it is a more complex protocol, withmore messages and states. The Initiator solicits m proposal from other agents by issuing acall for proposals (cfp for short) communicative act, as well as any conditions the Initiatoris placing upon the execution of the task (in our example the Initiator requires the set of busand stops to reach a destination).
In order to modify the BusRouteRequest protocol to follow the FIPA contractNet protocolit is necessary to modify the corresponding protocol diagram and the associated plans. TheNDE obtained for these elements in the original model is 78 and the NDE for the extendedmodel is 114. The number of generated entities in the original model for these features(transition rules, plans and atomic actions in plans) is 18 and for the extended model is 33.Therefore, the value of the degree of automation is:
δ(Model) : δ(Feature_Size) = 114
78: 33
18(5)
This result shows that an increase of 46 % in the protocol development effort results in anincrease of 83 % in agent functionality (in terms of the number of transition rules, transitiondescriptions and atomic actions generated). So, in this scenario, the percentage of generatedcode is 37 %, showing that the grade of automation is high for complex change scenarios,justifying the use of an MDE approach.
Auton Agent Multi-Agent Syst (2014) 28:214–255 247
Table 5 Memory-footprint of Jade-Leap and MalacaTiny agents in Android devices for resource consumptiontests in KiloBytes
Jade-Leap MalacaTiny
Reception Sending Reception Sending
IdleAgent 3915 3290
ChattyAgent 4721 4798 4780 4925
Fig. 15 Memory occupation (left) and power consumption (right) averages for IdleAgent
7.3 Resource consumption
The goal of the experiments presented in this section is twofold: (1) To quantify the memoryfootprint and power consumption of MalacaTiny agents in MIDP and Android versions andusing (for all of them) two different communication mechanisms, i.e. a Jade-Leap AP andBluetooth (we will call them JL-MalacaTiny and B-MalacaTiny, respectively); and (2) tocompare them, in terms of memory usage and power consumption, with a Jade-Leap versionof the same agent. We have made this comparison using Jade-Leap because as can be seenin Table 2 it is the only FIPA-compliant agent technology that supports Android and MIDPdevices. Memory usage (in KiloBytes) is measured both in MIDP and Android versions.Power consumption is only evaluated in milliamperes (mA) in the MIDP versions using theNokia Energy Profiler, since the Android emulator does not provide these data. In orderto measure the resource consumption of MalacaTiny agents and perform the comparisonwith the corresponding Jade-Leap agents, we have conducted a battery of tests based ondifferent executions of the JL-MalacaTiny, the B-MalacaTiny and Jade-Leap agents in MIDPand Android mobile phones. For each MIDP agent (in Jade-Leap, JL-MalacaTiny and B-MalacaTiny), each test took fifteen seconds and was repeated ten times. The average of theresults for each test is shown graphically. For Android agents, the tests for memory footprint(in KiloBytes) were performed in the emulator and the results shown are the average of theresult obtained after ten executions. Table 5 summarizes the results of the different tests forAndroid agents.
Firstly, we considered memory and power consumption for idle agents (i.e without per-forming any action). In order to do that, we monitored mobile phone resources while an idleagent was running (IdleAgent) and then we compared these results with the mobile resourcesconsumption without agents. This test has been realized for JL-MalacaTiny and Jade-Leapagents. Results are shown in Fig. 15. As expected, resource consumption is lowest when thereis no agent running. However, the MalacaTiny agent resource consumption is lower than theresource consumption exhibited by the Jade-Leap agent. So, the MalacaTiny implementationis more efficient in terms of memory and power consumption than Jade-Leap. In MalacaTiny
123
248 Auton Agent Multi-Agent Syst (2014) 28:214–255
Fig. 16 Memory occupation (left) and power consumption (right) for ChattyAgents during reception
Fig. 17 Memory occupation (left) and power consumption (right) for ChattyAgents during sending
we have optimized the resources by enabling and disabling aspects, depending on the agent’sneeds. The same test was performed in Android phones with similar results (as can be seenin Table 5, row labeled IdleAgents), i.e. the memory size of the Jade-Leap agent is 3915 kBwhile the memory required by a MalacaTiny agent is lower, 3290 kB.
Memory and power consumption have also been measured during agent interaction. Sometests were performed where multiple messages were sent or received. For this experiment, twopaired agents were developed: an agent which waited ten seconds and sent ten messages, andan agent that waited for these messages. These agents are named ChattyAgents. Figures 16and 17 show the memory occupation and power consumption results for the time slot in whicha message is sent or received. For message reception (Fig. 16), Jade Leap has good results formemory occupation (although higher than B-MalacaTiny), but the worst results for powerconsumption. For MalacaTiny, the memory occupation is the highest for JL-MalacaTiny, butthe lowest in the B-MalacaTiny implementation. Regarding power consumption, MalacaTinyis the most energy efficient with the lowest power consumption in JL- and B-MalacaTinyversions, something so important in AmI systems since it means it is possible to extendthe lifetime of devices. Again, the B-MalacaTiny agent had the best results for messagesending in memory and power consumption tests (Fig. 17). The difference is notable forpower consumption with an average of 64’8mA, while the average of Jade-Leap is 116’4mAand for JL-MalacaTiny is 121’9mA. The second best results for both measures are Jade-Leap but they are quite similar to JL-MalacaTiny results. Different implementations of theChattyAgent agents are also executed on Android mobile phones. Memory footprint resultsare given in Table 5 (row labeled ChattyAgents). For reception, Jade-Leap has a memoryfootprint of 4721 kB and MalacaTiny of 4780 kB. For sending, the results are similar andJade-Leap achieves 4798 kB, while MalacaTiny 4925 kB.
Finally, to summarize, the conclusions of these tests are: (1) MalacaTiny does not introducea critical overhead when it is used on the top of an AP, and therefore developers can benefitfrom the advantages offered by the MalacaTiny approach at design and implementation witha minimum resource penalty, and (2) the implementation of B-MalacaTiny is the one which
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 249
Fig. 18 Memory occupation with different numbers of coordination aspects
better scales in memory and power consumption, showing that it is worth having agentswith the capacity of interacting through different communication protocols. This offers thepossibility of choosing the optimal communication protocol, taking into account the expectedresource and power consumption.
7.4 Scalability
In this section we include some of the tests that show how MalacaTiny for MIDP scalesregarding the number of aspects instantiated by the agent. These results of the tests forAndroid agents are not shown since they are not very reliable due to the fact the memorybetween Android process is mostly shared and it is difficult to measure the real memoryfootprint of a process. We chose to measure aspects since the functionality in MalacaTinyis encapsulated in components implemented by classes, as with Jade-leap. Furthermore inMalacaTiny each agent conversation implies the instantiation of a coordination aspect. Ifwe measure how well MalacaTiny scales with regard to the number of aspects, implicitlywe are measuring how well it scales regarding the active behaviors of the agent. The testsmeasure the increment of the agents memory footprint when the number of active aspectsfor MalacaTiny or behaviors for Jade-Leap increases. We measured the average memoryfootprint for fifteen seconds with a different number of coordination aspects or conversationsfor Jade-leap (5, 10, 20, 100), repeating each test ten times and calculating the average ofthese results (Fig. 18).
As the results show, B-MalacaTiny again scales better than the other agent implemen-tations. For a low number of active aspects, results are very similar for Jade-Leap and JL-MalacaTiny but for a high number of aspects Jade-Leap performs much better.
7.5 Performance
In this section the performance of MalacaTiny agents is evaluated and compared with Jade-Leap agents. The evaluation and comparison are presented in Tables 6 to 9. The numbersgiven correspond to the average and the standard deviation of the results that came fromthe multiple execution of each experiment. Our first experiment measures the time requiredfor sending and receiving a message (round-trip delay time). Two paired agents were imple-mented: an agent that sends a message and waits for a response, and an agent which receives
123
250 Auton Agent Multi-Agent Syst (2014) 28:214–255
Table 6 Average and standarddeviation for message sendingand reception in MIDP devices inmilliseconds
Jade-Leap JL-MalacaTiny B-MalacaTiny
Average 139.4 176.4 257.8
Standard deviation 39.8 68.1 9.6
Table 7 Average and standarddeviation for message sendingand reception in Android devicesin milliseconds
Jade-Leap JL-MalacaTiny
Average 411.3 360.2
Standard deviation 217.64 180.01
Table 8 Average and standarddeviation for FIPA-Queryprotocol execution in MIDPdevices in milliseconds
Jade-Leap JL-MalacaTiny B-MalacaTiny
Average 676.7 530.5 22418.6
Standard deviation 39.1 76.8 18045.9
Table 9 Average and standarddeviation for FIPA-Queryprotocol execution in Androiddevices in milliseconds
Jade-Leap JL-MalacaTiny
Average 262.3 372.73
Standard deviation 142.1 292.06
a message and sends a reply. These agents were implemented using Jade-Leap and Mala-caTiny for MIDP and Android. MalacaTiny agents have been executed using Jade-Leapand Bluetooth. Each experiment was repeated thirty times. Table 6 shows the results forthe agents implemented in MIDP. As can be seen, the results for Jade-Leap agent and theMalacaTiny agent deployed in this AP are quite similar (a difference of just 37 millisec-onds). The result for the agent using Bluetooth shows that this is the slowest communi-cation system, as expected. The results for agents implemented for Android (showed inTable 7) are different. In this experiment, the times measured are a little better for Mala-caTiny (51.1ms).
Table 8 shows the latency of an interaction following the FIPA-Query protocol. Theresult includes message delivery, internal message processing and the realization of a simpleactivity. In the implementation of the FIPA-Query protocol used in our experiment, theinitiator requests the participant to perform some kind of informing action by sending aquery-if message. Once the participant receives and processes the query-if message, it decideswhether to accept or refuse the query request (in this implementation the query is alwaysaccepted) and sends the corresponding message to the initiator.
In Table 8, we can see the average and standard deviation of ten executions of the agentsimplemented in Jade-Leap, JL-MalacaTiny agent and the B-MalacaTiny agent for MIDP.The highest result is achieved for the B-MalacaTiny agent (as expected). The reason is thatboth service discovery and message delivery (see Table 6) is slower in agents using Bluetooththan in the agents using the Jade-Leap AP with MIDP. In addition, we want to highlight thatJL-MalacaTiny exhibits the lowest result (despite message delivering being slightly slowerin JL-MalacaTiny agent). Finally, as in the previous experiment, the results are differentfor the Android versions of the agents, being the performance of the Jade-Leap agent forAndroid better than MalacaTiny agents for Android. From these results we can conclude
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 251
that the internal design of MalacaTiny agents does not introduce a critical overhead and thedifferences in the performance are not remarkable.
7.6 Lessons learned
Our approach is intended for the development of AmI systems in which agents are themeaningful entities of the application. The related work has shown that the use of agenttechnology is not required by all AmI systems. However, once the use of the agent technologyis justified by the specific requirements of the AmI system, we want to discuss the lessonslearned, which include the pitfalls and main limitations of our approach from two view points:the MDE process, and considering integration and interoperability.
Model Driven Engineering. (i) We are conscious that our approach may not be attractivefor AmI developers that are not familiar with agent technologies; and (ii) the election ofPIM4Agents as PIM of the MDE process could also reduce the number of potential usersof our approach, even those users who are experts on agent technologies. The latter, arenormally familiar with agent’s toolkits (as Jade), but in our approach they must learn how todesign an MAS using PIM4Agents. This inconvenience is mitigated because: (1) the designis simplified using the DDE tool; (2) the proposal can be easily extended with other PIMsjust providing corresponding M2M transformations to the Malaca model; and (3) our MDEprocess starts at the design phase with PIM4Agents as the solution adopted. But is not possibleto specify AmI general requirements at requirements level. What we have done is to extendthe PIM4Agents agent metamodel to incorporate some properties specific to AmI systems.A more complete solution would be to include in our MDE process the definition of a CIMfor AmI. A set of M2M transformation rules would transform the CIM to the corresponding(extended) PIM4Agents model, including AmI specific requirements. In addition, the CIMwould be useful for identifying the weaknesses of other agent metamodels when designingAmI systems.
Finally, the development tools that our approach uses (the DDE Tool and the MAD tool)do not carry out the validation, evaluation or optimization of the design. Therefore, we mustassume that developers would provide the best possible design of the MAS.
Integration and Interoperability. Another important lesson is the performance of ourapproach cannot compete with specific agent technologies or ad-hoc solutions developedfor environments with special requirements (both hardware and software). Our approach isan alternative to general purpose agent technologies such as Jade-Leap. Our added value isto offer the possibility of modifying the agent to meet specific requirements imposed by theAP or the communication mechanism used by the system.
On the other hand, a good modularization of the agent’s internal architecture makes theadaptation and the evolution of the agent easier and the MAS for new technologies andrequirements. Currently, the appearance and disappearance of network technologies andlightweight devices (i.e. mobile phones technologies, sensors and actuators) is becoming aregular occurrence. Therefore, promoting and facilitating the evolution of AmI systems fornew technologies offers a great advantage.
Nowadays the number of applications and services for lightweight devices (like tablets,smartphones) is gaining market share. In this scenario, wireless network technologies playan important role, providing full connectivity to these devices. Some years ago, the costand the immaturity of the wireless technologies limited their use in lightweight devices.Currently this is no longer the case, most of the personal devices and sensor technologies
123
252 Auton Agent Multi-Agent Syst (2014) 28:214–255
have multiple wireless interfaces that can be successfully exploited in AmI systems. However,an additional problem that we have found is that interoperability is not possible in all cases (forinstance, sensors use IEEE 802.15.4 standards to communicate, which are still not supportedby personal lightweight devices). In order to achieve interoperability we need additionalsolutions. One solution is the usage of gateways. In this situation our approach can enablethe interoperation by means of the generation of an adequate plugin and the design of the agentto act as a gateway. This is of great value if we consider the development of specific purposeagents (using its corresponding toolkit) and later integrate them with a MAS composed ofgeneral purpose agents.
Regarding the use of aspect-orientation in the internal design of MalacaTiny, it providesan enhanced modularization, resulting in greater flexibility, which MalacaTiny exploits espe-cially in separating the communication-related concerns. As we have shown in the precedingsections, the weaving process introduces an additional overhead (affecting the consumptionof time and memory space) since it is the weaver which effectively invokes the agent func-tionality, introducing an extra level of indirection. But, as shown in the experiments describedin Sect. 7 the differences in performance are not remarkable, especially since due to the limi-tations of most device platforms (e.g. Java ME), the implementation of the weaving is static.A special case is MalacaTiny for Android, where it was possible to implement dynamicweaving. In this latter case, the overhead introduced by the dynamic weaving is a little bithigher, but the flexibility and extensibility endowed to agent implementations compensatethis penalty in performance. The conclusion is that the results given throughout Sect. 7 showthat the overhead is acceptable and it does not prevent the use of aspect-oriented agents inreal AmI applications.
8 Conclusions
In this paper we have presented an MDE process to automatically generate agents-basedsystems using the Malaca/MalacaTiny platform-neutral framework, especially well-suitedfor AmI systems. The model driven solution proposed covers the design and implementationphases by the transformation of a design model of the AmI system in PIM4Agents, a generalpurpose agent metamodel that we adapted to support an explicit modeling of context awaresystems, to a set of MalacaTiny agents, able to be executed in heterogeneous lightweightdevices. We have shown the limitations of current agent technologies for their use in thedevelopment of AmI applications. Some of them, offer an AP able to be executed in severalAmI devices (e.g. Jade-leap), but are neither extensible enough to include new communi-cation protocols, nor define domain models to facilitate the automatic development of AmIsystems. Others, which define MDE processes (e.g. Andromeda), cannot be executed in manyAmI devices. However, in Malaca at the design level and MalacaTiny at implementation level,agent platform dependent properties (e.g. communication protocol) are modeled separatelyas aspects, which makes both Malaca and MalacaTiny platform-neutral for FIPA-compliantAPs, simplifying the model driven derivation process. We have evaluated the convenience ofapplying a model driven approach by assessing the grade of automation of the MDE processproposed. The results show that it is possible to automatically generate more or less 40 %of code in complex AmI systems. This model driven process also facilitates the generationof agents able to communicate through different communication protocols. Finally, we havepresented and discussed an evaluation of the MalacaTiny implementation for MIDP devicesand Android enabled phones by assessing different parameters: performance, memory con-sumption and energy efficiency comparing Jade-Leap and using different communication
123
Auton Agent Multi-Agent Syst (2014) 28:214–255 253
protocols. The results demonstrated that the internal design of MalacaTiny is very efficient,so using our framework even over another AP like Jade-leap has very little or no penalty inresource consumption. Also, we have shown that MalacaTiny is easily extensible to includenew communication protocols. In particular, with the use of Bluetooth-based communica-tion we obtained very good results: MalacaTiny/Bluetooth is the one which scales the bestin memory and power consumption, showing it is worth having agents with the capacityof interacting through different communication protocols and technologies. This offers thepossibility of choosing the optimal communication protocol and/or technology, taking intoaccount the expected resource consumption of the agent, even at runtime.
As for future work, we are developing a graphic IDE in the Eclipse Modeling Frameworkthat contains our model driven development process and integrates the DDE tool and theMAD tool in Eclipse. Another future development for our approach is the addition of theCIM level to the MDE process. Additionally, we are extending the MalacaTiny approach tonew communication paradigms and mechanisms [7] and more lightweight devices such asLibellium Waspmotes.16
Acknowledgements This work has been funded by the Spanish Ministry Project RAP TIN2008-01942 andthe regional project FamWare P09-TIC-5231.
References
1. Agüero, J., Rebollo, M., Carrascosa, C., & Julián, V. (2010). Model-driven development for ubiquitousmas. In J. Augusto, J. Corchado, P. Novais, & C. Analide (Eds.), Ambient intelligence and future trends-international symposium on ambient intelligence (ISAmI 2010), advances in intelligent and soft computing(Vol. 72, pp. 87–95). Heidelberg: Springer.
2. Aiello, F., Fortino, G., Gravina, R., & Guerrieri, A. (2011). A java-based agent platform for programmingwireless sensor networks. The Computer Journal, 54(3), 439–454.
3. Amor, M., & Fuentes, L. (2009). Malaca: A component and aspect-oriented agent architecture. Informa-tion and Software Technology, 51, 1052–1065.
4. Augusto, J., & Nugent, C. (2004). The use of temporal reasoning and management of complex events insmart homes. In ECAI (Vol. 16, p. 778).
5. Ayala, I., Amor, M., & Fuentes, L. (2010). A model driven development of platform-neutral agents.In J. Dix, & C. Witteveen (Eds.), Multiagent system technologies: 8th German conference, MATES2010, Leipzig, Germany, September 27–29. Proceedings. Lecture notes in computer science (pp. 3–14)Heidelberg: Springer.
6. Ayala, I., Amor, M., & Fuentes, L. (2010). Towards the automatic derivation of malaca agents usingmde. In W. van der Haek et al. (Eds.), The eleventh international workshop on agent oriented softwareengineering. AOSE 2010. Toronto, Canada, 10 of May 2010 (pp. 61–72).
7. Ayala, I., Amor, M., & Fuentes, L. (2012). ITMAS: An agent platform for self-configuring agents in theinternet of things. In Third international workshop on infrastructures and tools for multiagent systems.(pp. 65–78).
8. Ayala, I., Amor, M., & Fuentes, L. (2012) Self-management of ambient intelligence systems: a pureagent-based approach. In Proceedings of the 11th international conference on autonomous agents andmultiagent systems–Vol. 3, AAMAS ’12 (pp. 1427–1428). Richland, SC: International Foundation forAutonomous Agents and Multiagent Systems.
9. Bellifemine, F., Caire, G., Poggi, A., Rimassa, G. & Jade, A. (2008). A software framework for developingmulti-agent applications. Lessons learned. Information and Software Technology, 50(1–2), 10–21.
10. Bergenti, F., & Poggi, A. (2002). Leap A fipa platform for handheld and mobile devices. In J. J. Meyer& M. Tambe (Eds.), Intelligent agents VIII. Lecture notes in computer science (Vol. 2333, pp. 436–446).Berlin: Springer.
11. Bromuri, S., Schumacher, M., & Stathis, K. (2010). Towards distributed agent environments for pervasivehealthcare. In J. Dix & C. Witteveen (Eds.), Multiagent system technologies. Lecture notes in computerscience (Vol. 6251, pp. 125–137). Berlin: Springer.
254 Auton Agent Multi-Agent Syst (2014) 28:214–255
12. Brossard, A., Abed, M., & Kolski, C. (2011). Taking context into account in conceptual models using amodel driven engineering approach. Information and Software Technology, 53(12), 1349–1369.
13. Chen, B., & Cheng, H. (2010). A review of the applications of agent technology in traffic and transportationsystems. IEEE Transactions on Intelligent Transportation Systems, 11(2), 485–497.
14. Cook, D., Youngblood, M., & Das, S. (2006). A multi-agent approach to controlling a smart environment.In J. Augusto & C. Nugent (Eds.), Designing smart homes. Lecture notes in computer science (Vol. 4008,pp. 165–182). Heidelberg: Springer.
15. Cook, D. J., Augusto, J. C., & Jakkula, V. R. (2009). Ambient intelligence: Technologies, applications,and opportunities. Pervasive and Mobile Computing, 5(4), 277–298.
16. Cozza, R. (2010). Forecast: Mobile communications devices by open operating system, 2007–2014. http://www.gartner.com/resId=1428830
17. Gascueña, J. M., Navarro, E., & Fernández-Caballero, A. (2012). Model-driven engineering techniquesfor the development of multi-agent systems. Engineering Applications of Artificial Intelligence, 25(1),159–173.
18. Giorgini, P., Mylopoulos, J., Perini, A., & Susi, A. (2005). The tropos metamodel and its use. Informatica,An International Journal of Computing and Informatics, 29(4), 251–273.
19. Hackborn, D. (2010). Service api changes starting with android 2.0. http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html
20. Hahn, C., Madrigal-Mora, C., & Fischer, K. (2009). A platform-independent metamodel for multiagentsystems. Autonomous Agents and Multi-Agent Systems, 18, 239–266.
21. Haigh, K. Z., Kiff, L. M., Myers, J., Guralnik, V., Geib, C. W., Phelps, J., & Wagner, T. (2004). Theindependent lifestyle assistant (i.l.s.a.): Ai lessons learned. In Proceedings of the 16th conference oninnovative applications of artifical intelligence, IAAI’04 (pp. 852–857). AAAI Press.
22. Harrington, A., & Cahill, V. (2011). Model-driven engineering of planning and optimisation algorithmsfor pervasive computing environments. Mobile & Pervasive Computing, 7(6), 705–726.
23. Howden, N., Rönnquist, R., Hodgson, A., & Lucas, A. (2001). Intelligent agents—summary of an agentinfrastructure. In 5th International conference on autonomous agents.
25. Koch, F., Meyer, J. J., Dignum, F., & Rahwan, I. (2006). Programming deliberative agents for mobileservices: The 3apl-m platform. In R. Bordini, M. Dastani, J. Dix, & A. Fallah Seghrouchni (Eds.),Programming multi-agent systems. Lecture notes in computer science (Vol. 3862, pp. 222–235). Berlin:Springer.
26. Lech, T. C., & Wienhofen, L. W. M. (2005). Ambieagents: A scalable infrastructure for mobile and context-aware information services. Proceedings of the fourth international joint conference on Autonomousagents and multiagent systems, AAMAS ’05 (pp. 625–631). New York, NY: ACM.
27. Lopes, R., Assis, F., & Montez, C. (2011). Maspot: A mobile agent system for sun spot. In 10th interna-tional symposium on autonomous decentralized systems (ISADS 2011) (pp. 25–31).
28. Muñoz, M. A., Rodríguez, M., Favela, J., Martinez-Garcia, A. I., & González, V. M. (2003). Context-awaremobile communication in hospitals. Computer, 36(9), 38–46.
29. Muldoon, C., O’Hare, G., Collier, R., & O’Grady, M. (2006). Agent factory micro edition: A frameworkfor ambient applications. In V. Alexandrov, G. van Albada, P. Sloot, & J. Dongarra (Eds.), Computationalscience ICCS 2006, lecture notes in computer science (Vol. 3993, pp. 727–734). Heidelberg: Springer.
30. Muldoon, C., O’Hare, G., O’Grady, M., & Tynan, R. (2008). Agent migration and communication in wsns.In Ninth international conference on parallel and distributed computing, applications and technologies,2008 (pp. 425–430).
31. Pavón, J., Gómez-Sanz, J., & Fuentes, R. (2006). Model driven development of multi-agent systems. InA. Rensink & J. Warmer (Eds.), Model driven architecture foundations and applications. Lecture notesin computer science (Vol. 4066, pp. 284–298). Heidelberg: Springer.
32. Penserini, L., Bresciani, P., Kuflik, T., & Busetta, P. (2005). Using tropos to model agent based architec-tures for adaptive systems: A case study in ambient intelligence. In Proceedings of IEEE internationalconference on software–Science, technology and engineering (pp. 37–46).
33. Ramos, C., Augusto, J. C., & Shapiro, D. (2008). Ambient intelligence the next step for artificial intelli-gence. IEEE Intelligent Systems, 23(2), 15–18.
34. Sadri, F. (2011). Ambient intelligence: A survey. ACM Computing Surveys, 43(4), 1–36.35. Sánchez-Pi, N., Carbó, J., & Molina, J. (2008). Jade/leap agents in an aml domain. In E. Corchado, A.
Abraham, & W. Pedrycz (Eds.), Hybrid artificial intelligence systems, lecture notes in computer science(Vol. 5271, pp. 62–69). Heidelberg: Springer.
36. Sánchez-Pi, N., Mangina, E., Carbó, J., & Molina, J. (2010). Trends in practical applications of agents andmultiagent systems advances in intelligent and soft computing. In Y. Demazeau, F. Dignum, J. Corchado,
Auton Agent Multi-Agent Syst (2014) 28:214–255 255
J. Bajo, R. Corchuelo, E. Corchado, F. Fernández-Riverola, V. Julián, P. Pawlewski, & A. Campbell(Eds.), Multi-agent system (mas) applications in ambient intelligence (ami) environments (Vol. 71, pp.493–500). Berlin: Springer.
37. Schmidt, D. C. (2006). Guest editor’s introduction: Model-driven engineering. Computer, 39, 25–31.38. Spanoudakis, N., & Moraitis, P. (2010). Modular jade agents design and implementation using aseme. In
IEEE/WIC/ACM international conference on web intelligence and intelligent agent technology (Vol. 2,pp. 221–228).
39. Stock, O., Zancanaro, M., Busetta, P., Callaway, C., Krger, A., Kruppa, M., et al. (2007). Adaptive,intelligent presentation of information for the museum visitor in peach. User Modeling and User-AdaptedInteraction, 17, 257–304.
40. Tapia, D., Abraham, A., Corchado, J., & Alonso, R. (2010). Agents and ambient intelligence: case studies.Journal of Ambient Intelligence and Humanized Computing, 1, 85–93.
41. Tarkoma, S., & Laukkanen, M. (2002). Supporting software agents on small devices. Proceedings of thefirst international joint conference on Autonomous agents and multiagent systems: Part 2, AAMAS’02(pp. 565–566). New York, NY: ACM.
42. Vinyals, M., Rodriguez-Aguilar, J. A., & Cerquides, J. (2011). A survey on sensor networks from amultiagent perspective. Computer Journal, 54(3), 455–470.
