Enhancing intelligence and dependability of a product line enabled pervasive middleware

Pervasive and Mobile Computing 6 (2010) 198–217

Contents lists available at ScienceDirect

Pervasive and Mobile Computing

journal homepage: www.elsevier.com/locate/pmc

Enhancing intelligence and dependability of a product line enabledpervasive middlewareWeishan Zhang a, Klaus Marius Hansen b,c, Thomas Kunz d,∗a Computer Science Department, University of Aarhus, Aabogade 34, 8200 Aarhus N, Denmarkb University of Iceland, Sæmundurgata 2, 101 Reykjavík, Icelandc University of Aarhus, Aabogade 34, 8200 Aarhus N, Denmarkd Department of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa, Canada K1S 5B6

a r t i c l e i n f o

Article history:Received 3 March 2008Received in revised form 8 April 2009Accepted 1 July 2009Available online 10 July 2009

Keywords:BDI (Belief-Desire-Intention) agentsOWL (Web Ontology Language)Self-diagnosisSWRL (Semantic Web Rule Language)XVCL (XML-based Variant ConfigurationLanguage)Self-managementMiddleware

a b s t r a c t

To provide good support for user-centered application scenarios in pervasive computingenvironments, pervasive middleware must react to context changes and prepareservices accordingly. At the same time, pervasive middleware should provide extendeddependability via self-management capabilities, to conduct self-diagnosis of possiblemalfunctions using the current runtime context, and self-configuration and self-adaptationwhen there are service mismatches. In this article, we present an approach to combinethe power of BDI practical reasoning and OWL/SWRL ontologies theoretical reasoningin order to improve the intelligence of pervasive middleware, supported by a setof Self-Management Pervasive Service (SeMaPS) ontologies featuring dynamic context,complex context, and self-management rules modeling. In this approach, belief setsare enriched with the results of OWL/SWRL theoretical reasoning to derive beliefs thatcannot be obtained directly or explicitly. This is demonstrated with agents negotiatingsports appointments. To cope with self-management, the corresponding monitoring,configuration, adaptation and diagnosis rules are developed based on OWL and SWRLutilizing SeMaPS ontologies. Evaluations show this combined reasoning approach canperform well, and that Semantic Web-based self-management is promising for pervasivecomputing environments.

© 2009 Elsevier B.V. All rights reserved.

1. Introduction

To support user-centered concepts in pervasive computing, context awareness is one of the most importantrequirements. To facilitate context awareness, OWL1 ontologies have been promoted recently as a good approach tocontext modeling [1]. OWL can, among others, provide reasoning potentials for contexts. In order to handle runtime-related requirements for self-management, not only static knowledge, but also dynamic and runtime contexts should beincorporated in context ontologies. For example, we can run a status check of a system at runtime, which is an importantrequirement for dependable pervasive computing. Consequently, this dynamic runtime information should be modeled incontext ontologies.

∗ Corresponding author. Fax: +1 613 520 5727.E-mail addresses: [email protected] (W. Zhang), [email protected] (K.M. Hansen), [email protected] (T. Kunz).URLs: http://www.daimi.au.dk/∼zhangws/ (W. Zhang), http://www.hi.is/∼kmh/ (K.M. Hansen), http://www.sce.carleton.ca/faculty/kunz.html

(T. Kunz).1 OWL homepage. http://www.w3.org/2004/OWL/.

1574-1192/$ – see front matter© 2009 Elsevier B.V. All rights reserved.doi:10.1016/j.pmcj.2009.07.002

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 199

Let us assume that there may be problems with pervasive computing devices at runtime, for example a device error,a downgrading of functionality, or even a complete device failure, which may need immediate action to diagnose theproblem(s) and further action to recover from the problem(s). Diagnosis can be accomplished by monitoring the dynamiccontexts of a system and then making decisions on where the problem is, why the problem happened, and how to tacklethe problem. It is important that a middleware can provide such self-management capabilities, including self-diagnosis,self-configuration and self-adaption. To specify self-management rules that span multiple instances of OWL concepts andproperties, the SemanticWeb Rule Language (SWRL)2 can be used to enhance the expressive power of OWL as demonstratedin [2].OWL and SWRL are adopting the OpenWorld Assumption (OWA). In the OWA, statements about knowledge that are not

included in, or inferred from, the knowledge explicitly recorded, are considered unknown rather than wrong or false (asassumed under the Closed World Assumption). The OWA works well for knowledge representations where the system cannever be completely described in advance, such as pervasive computing systems, which are intrinsically open and dynamic.OWL and SWRL can provide reasoning capabilities based on incomplete knowledge, which is arguably a natural fit for theopen world settings in pervasive computing systems [2].Within pervasivemiddleware, agent-based platforms are often used to address pervasive andmobile-computing specific

challenges to achieve autonomy. A BDI agent is a particular type of software agent that is modelled as having specificattitudes, namely Beliefs, Desires and Intentions (BDI) [3]. BDI agents are using the theory of practical reasoning inwhich the action to perform next is a moment-by-moment decision based on beliefs. These beliefs can come from userpreferences, environments, habitual experiences and so on, which are contexts used to provide practical intelligence tosupport personalized services. BDI agents are widely used for supporting intelligent decisions and to take actions fornegotiation, consultation, and selection that are necessary tomeet user-centric requirements in order to enable autonomousexecution of actions [4].In practice, some of the context information may not be encoded in the form of agent beliefs initially, as this information

may not be known in advance or can only be obtained through reasoning. Therefore, the integration of OWL/SWRL reasoningto provide implicit facts for the BDI agents tomake better decisions and to provide better service would be very valuable [5].This idea is reinforced by recent research on software agents,where sharing of agent knowledge usingOWLand subsumptionreasoning for goals and plans is explored in practice [6]. This integration of BDI agents’ practical reasoning with OWL/SWRLtheoretical reasoning is promising in improving the intelligence of pervasivemiddleware.When speaking of ‘‘intelligence’’ inthe context of this article, we generally mean support for reasoning on information and acting upon the results of reasoning.To address these issues, in this article, we present a set of Self-Management Pervasive Service (SeMaPS) ontologies

featuring dynamic context, complex context, and self-management rulesmodeling.We describe our approach of integratingthe OWL/SWRL ontologies theoretical reasoning and BDI agent practical reasoning in the context of the ongoing researchprojects PLIPerM (Product Line enabled Intelligent Pervasive Middleware) and Hydra.3 OWL ontology reasoning and SWRL-based reasoning are triggered from time to time to update and maintain belief sets. Context-awareness is extendedto support Semantic Web based self-management using the SeMaPS ontologies. Our evaluations show this combinedreasoning approach can performwell, and that SemanticWeb based self-management is promising for pervasive computingenvironments.The remainder of the article is structured as follows: Section 2 discusses the current status of pervasive middleware,

and provides a summary of our contributions, together with a scenario focusing on self-management that illustrates ourideas throughout the article. Then in Section 3 we present the SeMaPS ontologies used in PLIPerM. The SeMaPS ontologiesare modeling the dynamic contexts of a system and, as a further step, SWRL is used to specify complex context and self-management rules. Section 4 discusses our approach for enhancing the intelligence of pervasive middleware in order totackle some of the existing problems identified in Section 2.We demonstrate our approachwith an example of person agentsnegotiating a sport appointment in Section 5, together with performance evaluations of the combined BDI+ OWL+ SWRLreasoning. We present our approach of Semantic Web based self-management in Section 6, with evaluations of the self-diagnosis capability. The future work and concluding remarks end the article.

2. Related work and contributions

The need to support the development of pervasive applications with appropriate middleware is widely recognized. Anumber of researchers have developed middleware proposals that address one or multiple of the challenges in pervasivecomputing environments. This section reviews and evaluates some of the proposals in light of our goals, concentrating onagent-based and context-aware middleware. Other types of mobile middleware such as Tuple Space-based [7], CORBA4-based, Event-based, Reuse-based, and Reflection-based are reviewed and evaluated in more depth in [5]. This sectioncomplements the survey in [8], in that we are clarifying dynamic contexts and intelligence issues for some middlewaresystems.

2 http://www.w3.org/Submission/SWRL/.3 http://www.hydramiddleware.eu/.4 http://www.corba.org/.

200 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

2.1. Agent-based middleware

The idea of mobile agents is, by its very nature, well suited for pervasive computing environments. For example, codemovement when a connection is available can potentially overcome the unreliability of wireless networks. Some mobileagent-based mobile middleware, for example SOMA [9], use CORBA to interact with other mobile objects, relying on acentral server. FarGo [10] does not support automatic re-binding when an object reference gets lost. ACAI [11] is basedon the ontology context model, but neither user-centric concepts nor dynamic contexts, for example device statuses, areconsidered.

2.2. Context-aware middleware

Context awareness is important to provide appropriate services in pervasive computing. Context-aware middleware iscurrently amain focus in pervasivemiddleware research. The pioneering context-awaremiddleware solutions are location-aware middleware solutions that have been around for a long time, such as Shopping Assistant [12], CyberGuide [13],and Conference Assistant [14]. But context is much more than location, and in general includes all information about theenvironment of a system that could affect the behavior of the application.Current context-awaremiddleware considersmore than location, for example, SOCAM (Service-oriented Context-Aware

Middleware) [15], CASS (Context-awareness sub-structure) [16], Context Toolkit [17], Hydrogen [18], Context ManagingFramework [19], CoBrA (Context Broker Architecture) [20], Gaia [21], GLOSS (GLObal Smart Space)[22], CoOL (ContextOntology Language)[23] and Amigo [24]. It has been noted that OWL ontologies have strong context modeling capabilities,stronger than OWL’s predecessor DAMIL + OIL, and other counter-parts such as XML, key-value pairs, object-orientatedmodels, and RDF [1,2].SOCAM has a distributed structure but it does not consider runtime contexts. Its implementation is based on RMI,

which limits its applicability to resource-scarce J2ME/CLDC5-enabled mobile devices. CASS uses the relational model forcontext modeling. Not only context but also domain knowledge is stored in the database. Its centralized structure makesit potentially hard to adapt to the dynamic nature of pervasive systems. The relational model used by CASS has limitedreasoning capabilities when compared to the requirements of intelligence for user-centric scenarios.The Context Toolkit applies key-value pairs to model contexts, which limits its capability for context handling and

reasoning, and reduces the possibility for knowledge sharing as needed for Internet-scale computing. Hydrogen uses a peer-to-peer style for context information sharing and exchange. The context is modeled with object-oriented concepts, whichlimits its context reasoning capabilities. The Context Managing Framework uses a blackboard structure, where context ismodeledwith RDF. RDF has limited reasoning capabilities and expressive power comparedwithOWL. CoBrA is implementedusing software agents and OWL ontologies are used for context modeling, but CoBrA does not consider the dynamism ofpervasive systems, and neither other self-management considerations.Gaia adopted DAMIL + OIL, a predecessor of OWL, to model a relatively complete set of contexts including physical,

environmental, and personal context. DAMIL + OIL among others lacks the capabilities to define symmetry of properties.Gaia does not explicitly model dynamic contexts, which are vital to conduct self-management activities. GLOSS is aninfrastructure to support people’s interaction with their surroundings in a smart way, in which location, person, time andactivity are modeled with XML, a limitation on its reasoning capabilities. CoOL is a general approach for enabling contextsinteroperability, which does not model a person concept. Amigo is dedicated to smart home applications, where contextontologies are used for achieving personalized service provisioning and adaption, but dynamic contexts and self-diagnosisare not considered in Amigo.

2.3. Survey summary

We summarize the survey in Table 1, comparing representatives of mobile middleware categories. We choose contexttypes, context model and intelligence as evaluation criteria.The N/A (not available)means that this aspect is not specially addressed. Thereforewe do not expect that themiddleware

will provide strong support for that aspect. The evaluation of intelligence is denoted with ‘‘+’’ for an approach with betterintelligence and reasoning support, andwith ‘‘−’’ for weak support (the longer the ‘‘−’’, theweaker the support). None of theexisting mobile middleware considers all types of contexts, including user contexts, environmental contexts, and networkcontext. In general, the current middleware technology fall short in several important ways to meet our expectations:

• The common ‘‘one size fits all’’ approach is not suitable for the range of hardware, software platforms, available services,networks, etc. in the pervasive computing environment as discussed in [25]. Existing mobile middleware is inefficient inhandling the multi-dimensional variabilities in all aspects of the pervasive environment.• The existing ontology-based mobile middleware never mentions how to address ontology evolution [26], resulting fromthe adaptation of an ontology to changes over time, and the consistent propagation of these changes to dependentartifacts.

5 http://java.sun.com/products/cldc/.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 201

Table 1Comparison of surveyed mobile middleware.

Usercontext

Environmentcontext

Networkcontext

Dynamiccontext

Context model Intelligence

Agent based ACAI Partial Partial Partial N/A Ontology +

Others N/A N/A N/A N/A N/A -

Location-aware Partial Partial Partial N/A Spatial model —

Context aware SOCAM Partial Partial Partial N/A Ontology -CASS Partial Partial Partial N/A Relational data —Context toolkit Partial Partial Partial N/A Attribute–value pair —Hydrogen Partial Partial Partial N/A Object-Oriented –CoBrA Partial Yes Partial N/A Ontology +

Gaia Partial Yes Yes N/A Ontology -GLOSS Partial Yes Partial N/A XML –CoOL N/A Yes Partial N/A Ontology –Amigo Yes Yes Partial N/A Ontology +

• No runtime contexts are considered in existing ontology models. Although pervasive systems are intrinsically dynamicand open, the existing ontologymodels for pervasive computing are not considering any runtime/dynamic context,whichis vital for conducting runtime diagnosis for possible problems when faults/malfunctions occur.• Weak intelligence. Most existing agent-based middleware are not fully exploring BDI agent capabilities, and not muchintelligence is built into the used agents. Particularly, notmuch context knowledge is used to enhance BDI agents. Tomakepervasive middleware practical in user-centric scenarios, practical intelligence is required to support various automateddecisions.• Weak support for malfunction recovery and other self-management features. Most existing pervasive middleware doesnot address self-management, for example self-diagnosis in the event of problems. Self-management is important, as nodevice can run for longer periods of time without problems. Also, available services may not exactly match a requiredinterface, and self-adaption and self-configuration is then needed.

2.4. Scientific contributions of the article

We have addressed how to tackle the first two problems in detail in previous papers [27,28,5]. This article will focuson the last three issues. It discusses a complete set of ontologies that consider user-centric context, runtime context, andcomplex context, and applies these contexts to conduct context-aware self-management to improve the dependability ofpervasive middleware. Improving the middleware intelligence is achieved by the combination of both BDI agent practicalreasoning and theoretical reasoning using OWL ontologies and SWRL rules. The contributions of this article are summarizedas follows:

• Self-management ontologies for pervasive service middleware. We describe a complete set of context ontologies featuringself-management characteristics, where dynamic states of devices, networks, quality of service, and service runtimecalling relationships are modeled in OWL-DL (Description Logic) ontologies. This set of ontologies is called SeMaPS (Self-Management for Pervasive Service) ontologies, and incorporates the dynamic nature of pervasive systems.• Semantic web based self-management in pervasive middleware supported by the SeMaPS ontologies. An application ofSemantic Web technologies, especially SWRL, is proposed to specify self-management rules and to achieve self-management goals for pervasive middleware, for example self-diagnosis and self-configuration rules. This approachextends the usage of context ontologies to achieve context-aware self-management.• Combination of BDI agent practical reasoning with OWL/SWRL ontologies theoretical reasoning in pervasive middleware. Thiscombination can potentially improve the expressiveness of relationships between Beliefs, Desires, Intentions of BDIagents by applying OWL/SWRL reasoning to add facts, and infer relationships of BDIs. Initially, we started the explorationof this combination with updating and enhancing agent beliefs.

The work related to SeMaPS is part of the Hydra project and the middleware developed in the Hydra project. The use ofBDI-agents is a PLIPerM-specific extension and is in this way another example of middleware using the SeMaPS ontologies.

2.5. Illustrative scenarios

The following scenarios are used throughout this article to illustrate our vision of self-managed pervasive middleware,as exemplified by PLIPerM, and to demonstrate our contributions.

John is a fan of new technologies and he has a digital personal assistant to automatically schedule sport/socialappointments with friends based on his schedule and preferences. He also owns a SmartHome system, which isequipped with self-managed heating and ventilating systems. While he is abroad for an academic conference, hishome security system automatically turned on to the highest security level when detecting he is far away from home.While he is in a hotel, his home ventilating system detects an error through self-diagnosis. He is notified with an SMS

202 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

on hismobile and he acknowledges thatmessage to initiate a self-repairing process. A new service to resolve this erroris found from a third party service provider, and begins to download some new software. Not surprisingly, the newservice does not exactly match his system, and the problem is detected and resolved by invoking an adapter serviceto seamlessly integrate the new service with the existing system.

In the coming sections, we will demonstrate how to enable this story with the support from the SeMaPS ontologies(including SWRL rules). A SWRL rule is developed to decide whether John is far away from home as a complex context. Aset of self-management rules are developed to cope with self-management requirements, including one rule for diagnosingventilating system errors using device states, another one for detecting interface mismatch during the installation of a thirdparty service for resolving this error, and an adapter is added to the configuration to resolve the mismatch.

3. The SeMaPS ontologies

Existing pervasive computing context ontologies, such as SOUPA [20] andAmigo [24], are not targeting self-management.They therefore contain almost no dynamic and runtime models of the underlying pervasive systems. This makes theseexisting ontologies unsuitable for self-management purposes, which depend on the timely report of the status of devices,the network, and even running processes. In the SeMaPS ontologies, different context types are considered, including usercontext, network context, and environment context. These are used further to developmore complex context and diagnosisand monitoring rules using SWRL. In practice, we restrict our ontologies to OWL-DL to guarantee (decidable) reasoningwithin acceptable performance limits. The SeMaPS ontologies have someunique features compared to the existing pervasivecomputing ontologies, these include:

• Incorporation of user-centered concepts and software agent-related concepts, such as user habit information andpreferences.• Incorporation of runtime and dynamic context. A StateMachine ontology is developed to model device runtime statusand is then used to conduct state-based diagnosis. AMessageProbe ontology is used to report service calling relationshipsin order to reason about network conditions and device liveness. Other ontologies are also involved in the modeling ofdynamic context.• Complex contexts that span multiple instances and properties, which are not expressible by an OWL-DL ontology itselfare described by SWRL, which is also extensible through built-ins.• Semantic modeling of dependability of middleware, especially the self-recovery related concepts and properties inontologies, which support decisions in the self-diagnosis process using theoretical reasoning, and possibly practicalreasoning in the near future.

3.1. Structure and design of the SeMaPS ontologies

The relationships between the SeMaPS ontologies are illustrated in Fig. 1. The SeMaPS ontologies are originated inPLIPerM, which are further developed in the Hydra project, and are then used by both PLIPerM and Hydra.The Location ontology models of where events happen, in which SetBased, SemanticBased, CoordinateBased and

GraphBased modeling of location are encoded in a separate ontology, is based on [29]. The Time ontology models time-and date-related knowledge, for example a time zone concept. This ontology is developed based on OWL-Time.6The Person ontology encodes themajority of user-centered concepts. It contains information about a person’s hobbies like

sport (with badminton, tableTennis and soccer as instances), color (e.g. skyblue), music (various styles such as CountryMusicand RocknRoll) and also mood (happy, normal) descriptions. Depending on a user’s mood, he/she may want to listen todifferent kinds of music, for example listen to country music in a happy or normal mood.The Device ontology is used to model equipment in pervasive computing, including SoftwarePlatform and

HardwarePlatform. It presents Device (as a concept) type classification (e.g. mobile phone, PDA, Thermometer), which isbased mainly on the device classification in the Amigo project ontologies [24]. To facilitate self-diagnosis, a concept calledSystem models a system composed of devices that provide services. A corresponding object property hasDevice is added,which has the domain System and range Device. The Device concept has a data-type property currentMalfunction which isused to store the inferred device malfunction diagnosis information at runtime.The HardwarePlatform ontology defines concepts such as CPU, Memory, and so on, and also relationships between the

devices (in the Device ontology), for example hasCPU. This ontology is based on the hardware description part of theW3C deliveryContext ontology.7 Power consumption concepts and properties for different wireless networks are addedto the HardwarePlatform ontology to facilitate power-awareness, including a batteryLevel property for monitoring batteryconsumption.The Malfunction ontology is used to model knowledge of malfunctions and recovery resolutions. It also provides a

classification of device malfunctions (for example, BatteryError). The malfunctions are classified into two categories: Error

6 http://www.w3.org/TR/owl-time/.7 Delivery Context Overview for Device Independence. http://www.w3.org/TR/di-dco/.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 203

Fig. 1. Structure of SeMaPS ontologies.

(including complete device failure) and Warning (including function scale-down, and plain warning), according to theirsevereness. Two other concepts, Cause and Remedy, are used to describe the origin of a malfunction and its resolution.The QoS ontology defines important QoS parameters, such as availability, reliability, latency, and error rate. It also

contains properties for these parameters, such as their nature (dynamic, static) and the impact factor. There is also aRelationship concept in order to model the relationships between these parameters. The QoS ontology is developed basedon the Amigo QoS ontology [24].The OSGiComponent ontology is based on OSGi DS (Declarative Services) [30] as we are adopting OSGi as the underlying

component model in our middleware. It specifies the Component ’s dynamic status, for example whether it is enabled, andalso static characteristics such as its reference to other service, its implementation interface, and services provided.Three different classes of schedules are modeled in the current Schedule ontology, namely Appointment, Meeting and

Course, which have object properties participant and holdLocation, and datatype properties starts and ends, denoting thetime for the scheduled event to start and end, respectively. This information is used to schedule appointments, for examplea sports appointment.

3.2. Modeling dynamic context in the SeMaPS ontologies

Context can be of static and dynamic nature [31]. For example, a device has CPU informationwhich remains static and notchangeable, but its availablememory or remaining battery are dynamically changing. Also, a device is changing its status, forexample, from the status of measuring the temperature to the stop state. To make self-management work, these dynamiccontexts are key factors inmaking decisions on actions to be taken to achieve self-management goals. For example, differenttransport protocols can be chosen to fulfill the requirements of throughput (one of the QoS metrics) based on whether thedevice is connected via a wired or wireless network, whether Bluetooth is used, or TCP/UDP should be used to transport theservice. Here the throughput requirement is of a dynamic nature, the capabilities of the networks are static.To model device state changes, a StateMachine ontology is developed based on [32], with many improvements to

facilitate self-management: the State concept has data-type property isCurrent to indicate whether a state is current or notfor the purpose of device monitoring, a doActivity object property is added to the State in order to specify the correspondingactivity in a state, and also a data-type property hasResult is added to the Action (including activity) concept in order to checkthe execution result at runtime, together with three extra data-type properties to model historical action results in order toconduct history-based self-management.To model the invocation of services, a MessageProbe ontology is developed to monitor the liveness of a computing node,

and to facilitate the monitoring of QoS, such as the request/response time of a corresponding service call. The SocketProcessconcept is used to model a process running in a client or service, and SocketMessagemodels a message sent between clientand service. There is also a concept IPAddress, which is related to Devicewith a property hasIPAddress in the Device ontology.The object properties invoke, messageSourceIP, and messageTargetIP are used to build the invoking relationships, and datatype property initiatingTime is used to model the timestamp for a message.The key to view a software component and connector in a configuration for a pervasive system is to understand the

services a component and connector can provide and which they require in order to function. This is modeled by a Service

204 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

Fig. 2. Partial details of the SeMaPS ontologies facilitating self-management.

ontology (using a service profile) and a ProcessModel ontology (using a service process model), similar to the idea in theOWL-S8 ontologies for Semantic Web services. The Service ontology and ProcessModel ontology are used at runtime toconduct self-configuration and self-adaptation, potentially based on quality-of-service requirements (supported by the QoSontology).In summary, the dynamic contexts are modeled with runtime concepts and properties in the related ontologies, mainly

the StateMachine ontology, MessageProbe ontology, Malfunction ontology, Component ontology, QoS ontology, Serviceand ProcessModel ontology, and other concepts and properties in the Device ontology, such as currentMalfunction andSystem. The currentMalfunction is used to store the current diagnosis information for the malfunction case, System is used todynamicallymodel a device joining and leaving and to reflect the composition of a system. It is not necessary to differentiatethe usage of dynamic contexts and static contexts in SeMaPs as they are working together to provide support for contextmodeling. A more detailed but simplified view of the SeMaPS ontologies is given in Fig. 2.

3.3. Rule languages for context modeling

OWL-DL by itself makes it difficult to express global constraints across multiple properties and instances in an ontology,and can not mix classes and properties directly, which limits OWL-DL’s capabilities to express complex contexts andrestrictions. Therefore, there is a need to improve the expressiveness and capabilities of OWL-DL, while maintaining OWL-DL’s decidability.SWRL9 (pronounced ‘‘swirl’’) is aW3C recommendation for the rule language of the SemanticWeb, which can be used to

write rules to reason about OWL individuals and to infer new knowledge about those individuals. A SWRL rule is composedof an antecedent part (body), and a consequent part (head). Both the body and head consist of positive conjunctions ofatoms. A SWRL rule means that if all the atoms in the antecedent (body) are true, then the consequent (head) must also betrue. SWRL is built on OWL-DL and shares its formal semantics. In our work, all variables in SWRL rules bind only to knownindividuals in an ontology in order to develop DL-Safe rules, making them decidable. SWRL provides built-ins such as math,string, and comparisons that can be used to specify extra contexts, which are not possible or very hard to express by OWLitself.In addition to SWRL, a number of different rules languages have been proposed. Table 2 compares SWRL and other rules

languages currently available in terms of standardization, tool support and relationship with OWL. Taking into account oftheir maturity and tool support, and its adoption among various reasoners, SWRL became our preferred choice because:

• It is expressive enough to allow both global and local constraints that span across concepts and concept properties(relationships).

8 http://www.w3.org/Submission/OWL-S/.9 SWRL: A Semantic Web Rule Language Combining OWL and RuleML. http://www.w3.org/Submission/SWRL/.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 205

Table 2Feature comparisons of different rule languages.

SWRL WSML-rulea

WRLb SWSL-rulesc ERDFrulesd

RuleMLe R2MLf

Relationship with OWL OWL extension N/A Translate to a subset of OWL N/A RDF N/A N/AStandardization W3C submission N/A W3C submission W3C submission N/A N/A N/ATool support Pelletg ,

RacerProh . . .IRISi ,MINSj

N/A N/A Jenak DR-devicel

N/A

a http://www.w3.org/2004/12/rules-ws/paper/128/.b http://www.w3.org/Submission/WRL/.c http://www.daml.org/services/swsf/1.0/swsl/.d http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=ERDF.e http://www.ruleml.org/.f http://rewerse.net/I1/oxygen.informatik.tu-cottbus.de/rewerse-i1/@q=r2ml.htm.g http://clarkparsia.com/pellet.h http://www.racer-systems.com/.i http://iris-reasoner.org/.j http://tools.deri.org/mins/.k http://jena.sourceforge.net/.l http://lpis.csd.auth.gr/systems/dr-device.html.

• It is is decidable using DL-Safe rules (rules written only on known instances in ontologies).• SWRL is OWL specific, and is basically a combination of OWL and RuleML.• It is already a de facto rule standard for Semantic Web rule specifications.• It is extensible with new built-ins, and rules can be parameterized and changed dynamically at runtime, and executed asrule groups to resolve rule conflicts and improve performance (confirmed in our evaluations later in this article as well).

The disadvantage of OWL-DL and SWRL is that operations (such as queries) are computationally complex, which maycause a performance bottleneck. Therefore it is important to measure performance to check whether the combination issuitable to achieve self-management goals with reasonable performance. Another disadvantage is that SWRL is limited tounary or binary relationships, therefore rulesmay become verbose for human readers. However, SWRL is primarily intendedfor machine processing and, as discussed below, appropriate rule editors hide this complexity from the human user.

3.4. Complex context specification with SWRL rules

In a SWRL rule, the symbol ‘‘∧’’ means conjunction, ‘‘?x’’ stands for a variable, ‘‘→’’ means implication, and if there is no‘‘?’’ in the variable, then it refers to a specific individual.For example, we can specify a farAwayFromHome context (e.g. 100 miles away from home using the GPS distance

calculation formula10). Then this new context can be used to take actions, for example, if the GPS location of John is 100miles away from his home, his home surveillance system will switch automatically to the highest security level with allcameras turned on.

Rule: FarAwayFromHomeperson : hasHome(?person, ?home)∧person : inLocation(?person, ?coord1)∧loc : hasCoordinates(?home, ?coord2)∧coord : latitude(?coord1, ?lan1)∧coord : latitude(?coord2, ?lan2)∧swrlb : subtract(?sub1, ?lan1, ?lan2)∧swrlb : multiply(?squaresublan, ?sub1, ?sub1)∧swrlb : multiply(?par1, ?squaresublan, 4774.81)∧coord : longitude(?coord1, ?long1)∧coord : longitude(?coord2, ?long2)∧swrlb : subtract(?sub2, ?long1, ?long2)∧swrlb : multiply(?squaresublong, ?sub2, ?sub2)∧swrlb : multiply(?par2, ?squaresublong, 2809)∧swrlb : add(?parameter, ?par1, ?par2)∧swrlm : sqrt(?distance, ?parameter)∧swrlb : greaterThan(?distance, 100)∧→ sqwrl : select(?person, ?home, ?distance)∧farAwayFromHome(?person, ‘‘true’’)

10 See, e.g., How to calculate the distance between two points on the Earth. http://www.meridianworlddata.com/Distance-Calculation.asp.

206 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

3.5. Self-management rules

3.5.1. Self-diagnosis rulesMonitoring and diagnosis rules are the basis for the diagnosis service and can be developed based on the introduced

SeMaPS ontologies.Device level rulesDevice level rules are used for a certain type of devices and are generic for that type of device. The following example rule

specifies themonitoring of a mobile phone battery level. If the battery level is less than 10%, a warning should be published.

Rule: LowBatteryMobilePhonedevice : MobilePhone(?device)∧device : hasHardware(?device, ?hardware)∧Hardware : primaryBattery(?hardware, ?battery)∧Hardware : batteryLevel(?battery, ?level)∧swrlb : lessThanOrEqual(?level, 0.1)→ VeryLowBattery(?device)

System level rulesSystem level rules are used to specify rules that span multiple devices in a system. For example John’s SmartHome has

ventilating and monitoring systems, thermometers are used to measure both indoor and outdoor temperature, and arenamed PicoTh03_Outdoor and PicoTh03_Indoor respectively. When the outdoor temperature is between 18 and 28 degree,the indoor temperate should follow the same trend as the outdoor temperature. Otherwise, we infer that the ventilator isdown.

Rule: SmartHome_VentilatingDowndevice : hasStateMachine(device : PicoTh03_Outdoor, ?sm)∧statemachine : hasStates(?sm, ?state)∧statemachine : doActivity(?state, ?action)∧statemachine : actionResult(?action, ?r)∧statemachine : historicalResult1(?action, ?r1)∧statemachine : historicalResult2(?action, ?r2)∧statemachine : historicalResult3(?action, ?r3)∧swrlb : add(?tempaverage, ?r1, ?r2, ?r3)∧swrlb : divide(?average, ?tempaverage, 3)∧swrlb : subtract(?temp1, ?r, ?r1)∧swrlb : subtract(?temp2, ?r1, ?r2)∧swrlb : subtract(?temp3, ?r2, ?r3)∧swrlb : add(?temp, ?temp1, ?temp2, ?temp3)∧swrlb : greaterThan(?average, 18.0)∧swrlb : lessThan(?average, 28.0)∧swrlb : lessThan(?temp, 0)∧device : hasStateMachine(device : PicoTh03_Indoor, ?smb)∧statemachine : hasStates(?smb, ?stateb)∧statemachine : doActivity(?stateb, ?actionb)∧statemachine : actionResult(?actionb, ?rb)∧statemachine : historicalResult1(?actionb, ?r1b)∧statemachine : historicalResult2(?actionb, ?r2b)∧statemachine : historicalResult3(?actionb, ?r3b)∧swrlb : subtract(?temp1b, ?rb, ?r1b)∧swrlb : subtract(?temp2b, ?r1b, ?r2b)∧swrlb : subtract(?temp3b, ?r2b, ?r3b)∧swrlb : add(?tempb, ?temp1b, ?temp2b, ?temp3b)∧swrlb : greaterThan(?tempb, 0)→ device :currentMalfunction(device : VentilatorMY0193, ‘‘VentilatorDown’’)

The processing of this rule will obtain the trends via the difference of continuous temperature measurements of both theindoor and outdoor temperatures. If there is a difference between the trends, an instance of the currentMalfunction property(‘‘VentilatorDown’’) of concept Device (which is VentilatorMY0193) will be inferred. Then the Malfunction ontology will bechecked for the resolution of the problem based on the malfunction cause. In our case, the Malfunction ontology would giveus the suggestion: ‘‘power supply off because of fuse blown’’.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 207

3.5.2. Self-configuration rulesTo resolve the error that causes the fuse to blow, let us assume that a third party service component is found online when

the SmartHome system is searching for a solution. The following rule is used to detect interface mismatch and resolve thismismatch by adding a connector to the current configuration. For anOSGiDS component, if it has a referencewhich has a car-dinality of the form ‘‘1..n’’ (at least one reference to other services), then theremust be a component providing that requiredservice. In a referencing component, the references to another component are modeled in the hasInput datatype propertyin the ProcessModel ontology, in the format ‘‘component name(including package name)+operation name#input types withorders$return type’’. Then this information is compared with that from the referenced component with respect to a specificinterface. If they do not match exactly, the references are invalid. Additionally, if a connector resolving the interface mis-match exists (its instance is adaptConnector1 as in theOSGiComponent ontology), we can then infer that an adapter connectorneeds to be added to the current configuration in order to correctly match the references, shown in the last line of the rule.

Rule: OSGi_InterfaceMismatchResolutionCurrentConfiguration(?con)∧hasComponent(?con, ?comp1)∧osgi : componentName(?comp1, ?compname1)∧osgi : reference(?comp1, ?ref 1)∧osgi : cardinality(?ref 1, ?car1)∧swrlb : containsIgnoreCase(?car1, ‘‘1.’’)∧osgi : interface(?ref 1, ?inter1)∧osgi : interfaceName(?inter1, ?name1)∧hasComponent(?con, ?comp2)∧architectureRole(?comp2, ?role2)∧osgi : service(?comp2, ?ser2)∧osgi : provide(?ser2, ?inter2)∧osgi : interfaceName(?inter2, ?name2)∧osgi : componentName(?comp2, ?compname2)∧swrlb : equal(?name1, ?name2)∧component : componentServiceDetails(?comp1, ?pr1)∧service : presents(?pr1, ?prservice1)∧profile : has_process(?prservice1, ?process1)∧process : realizedBy(?process1, ?aprocess1)∧process : hasInput(?aprocess1, ?input1)∧process : parameterValue(?input1, ?ivalue1)∧component : componentServiceDetails(?comp2, ?pr2)∧service : presents(?pr2, ?prservice2)∧profile : has_process(?prservice2, ?process2)∧process : realizedBy(?process2, ?aprocess2)∧process : hasInput(?aprocess2, ?input2)∧process : name(?aprocess2, ?proname2)∧process : hasOutput(?aprocess2, ?proout2)∧process : parameterValue(?input2, ?ivalue2)∧process : parameterValue(?proout2, ?ovalue2)∧swrlb : stringConcat(?str1, ?compname2, ‘‘+ ’’)∧swrlb : stringConcat(?str2, ?str1, ?proname2)∧swrlb : stringConcat(?str3, ?str2, ‘‘#’’)∧swrlb : stringConcat(?str4, ?str3, ?ivalue2)∧swrlb : stringConcat(?str5, ?str4, ‘‘$’’)∧swrlb : stringConcat(?str6, ?str5, ?ovalue2)∧swrlb : equal(?ivalue1, ?str6)∧swrlb : substringBefore(?temp1, ?ivalue1, ‘‘+ ’’)∧swrlb : equal(?temp1, ?compname2)∧swrlb : substringAfter(?temp, ?ivalue1, ‘‘+ ’’)∧swrlb : substringBefore(?op, ?temp, ‘‘#’’)∧swrlb : equal(?op, ?proname2)∧swrlb : substringAfter(?temp2, ?ivalue1, ‘‘#’’)∧swrlb : substringBefore(?inputtype, ?temp2, ‘‘$’’)∧swrlb : notEqual(?inputtype, ?inputtype2)∧swrlb : substringAfter(?returntype, ?ivalue1, ‘‘$’’)∧swrlb : equal(?ovalue2, ?returntype)→ sqwrl : selectDistinct(?comp1, ?comp2, ?inputtype, ?inputtype2)∧

208 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

sqwrl : select(‘‘Inputtypemismtach : invalidreferences’’)∧sqwrl : select(‘‘An adaptor connector is Needed’’)∧hasComponent(?con, adaptConnector1)

3.6. Discussion

The SeMaPS ontologies cover a relatively complete set of knowledge for self-management, including dynamicinformation about pervasive systems, for example runtime device states. SWRL is flexible and powerful in developingself-management rules based on the SeMaPS ontologies. As mentioned above, since SWRL is limited to unary or binaryrelationships, a SWRL rule may therefore become too long to be readable. However, SWRL is mainly used for machineprocessing of the OWL ontologies.The development of OWL/SWRL ontologies is supported by Protege.11 Our experiences with this tool shows that a

developer will find it relatively easy to develop SWRL rules as the user interface for SWRL rule development facilitates thedevelopment of SWRL rules well. At the same time, SWRL rules can be parameterized and dynamically generated accordingto different requirements, which further improves its usability.

4. Combining the power of BDI agents and OWL/SWRL reasoning

4.1. Combining practical reasoning and theoretical reasoning results for improved intelligence

In philosophy, practical reasoning is the use of reasoning to decide how to act, i.e. practical reasoning is the processof figuring out what to do by weighing conflicting considerations provided by what an agent desires/values/cares aboutand what the agent believes [33]. Practical reasoning consists of at least two kinds of activities: deliberations, to decidewhat to do from various desires based on the beliefs about the world, and means-end reasoning, to decide how to do it.Therefore practical reasoning is directed towards actions. On the other hand theoretical reasoning is the use of reasoningto decide what to believe. A typical example is ‘‘John is a person, a person has a date of birth, therefore John has adate of birth’’. These two different approaches can be simply described as: TheoreticalReasoning ≡ Belief → Belief andPracticalReasoning ≡ Belief + Desire→ Intention.A BDI agent is using the theory of practical reasoning. It can be used to achieve a goal according to plans (either generated

or existing) based on the current beliefs an agent has. On the other hand, OWL/SWRL is using theoretical reasoning whichis directed towards beliefs. New beliefs can be generated through theoretical reasoning. These two approaches of reasoningare complementing each other: the new/updated beliefs from OWL/SWRL reasoning can enrich the beliefs for a BDI agentwhich can then be utilized tomakewiser and better decisions, compared to not having these new beliefs. OWL/SWRL has itsstrength in modeling relationships and concepts, which can not initiate any actions by themselves, BDI agents enact goalscorrelated to the underlying contexts modeled or derived from OWL/SWRL reasoning.The combination of BDI agents with SemanticWeb technologies is attractive for improving the intelligence of BDI agents.

For example, augmenting the JACK BDI agent knowledge base with OWL ontologies is explored by Holmes and Stocking,12and augmenting the Jason knowledge base with OWL ontologies is discussed in [6,34]. The anticipated advantages ofthe combined reasoning approach include: more expressive queries can be made to the agent knowledge base, and plansearching can be more flexible as subsumption relationships between concepts can be utilized [6,34]. In our opinion, SWRLreasoning should similarly be used to improve the intelligence of BDI agents. A concrete examplewill be shown in Section 4.3.BDI agents can be potentially used to help resolve conflicting options for self-management in a pervasive middleware,

using its practical reasoning capabilities. An example to demonstrate this is the usage of a BDI agent for helping themalfunction recovery. We use OWL/SWRL-based malfunction diagnosis when problems occur as discussed in Section 6.Software agents can then deliberate on the recovery goals, negotiate recovery strategies and furthermore take actionsaccordingly to recover the malfunction, which we will explore in the future.

4.2. Feasibility of combining practical reasoning and theoretical reasoning

As an initial phase, in this article, wewill use the current reasoning capabilities of OWL and SWRL. This reasoning processcan be expressed in an abstract form via the following formula: CQ = Rp(Os + Rs). Here CQ stands for the results ofclassification and query used during the reasoning process, for both the description logic reasoning and the SWRL reasoning.Rp stands for the actual reasoning process, Os stands for the OWL ontology sets used for the current reasoning, and Rs standsfor the SWRL rule sets, which are decidable as we only use DL-Safe rules. OWL and SWRL reasoning may result in changesof the agent state, e.g. new beliefs are obtained. Therefore, according to [35], we can then define a new belief update actionαub: αub = (UpdateBelief , B′, B, β,∆t). The action type is UpdateBelief , β is a parameter for belief, ∆t is the interval for

11 Protege homepage. http://protege.stanford.edu/and Protege-SWRL tab: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab.12 http://www.iliumtechnologies.com/pdf/p1106_2.pdf.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 209

Data Acquisition

Data normalization

Context aggregation

OWL/SWRLontologiesrepository

Frame based ontology-java

processing (FOJP)

Ontology/context change Events

Concepts

Beliefs/Goals/Actions/Plans

updating

OWLReasoner

(Racer Pro)

SWRLEngine(Jess)

OWLReasoning

OWL and SWRL Rule reasoning

SWRLReasoning

Reasoningresult parsing

Reaction deliberation

Beliefs Goals

Agent Internal Events

Plans

Fig. 3. Combining OWL/SWRL ontology reasoning and BDI practical reasoning.

updating, B are the original beliefs, and B′ = F(CQ ) are new beliefs after formatting the reasoning results CQ . In this way, itis feasible to combine the ontology reasoning with BDI reasoning in the context of the Jadex platform.13

4.3. Combining practical reasoning and theoretical reasoning in PLIPerM

Our approach of combining the power of practical reasoning and theoretical reasoning is shown in Fig. 3. RacerPro14is used as the main reasoning tool because of its maturity and special features for context-aware computing, such as thesupport for reasoning about geometric/spatial relationships.A main part of our approach is Frame-based Ontology-Java Processing (FOJP) components, which are based on the Frame

technology and XVCL [36]. FOJP is bridging the world of OWL ontologies and Java software agents, and propagate relatedchanges to agent definitions including the agent belief sets, plans and goals, to keep them in a consistent state. All thesenecessary changes are propagated consistently using the FOJP components. Then these changed intelligent agents are loadeddynamically to provide adaptation for different purposes. Here the features of Dynamic Models as provided by Jadex areutilized. Please note that all artifacts are managed at the meta-level (an example is shown in Figs. 5 and 6) to facilitate themanagement of asset evolutions [27] using XVCL [36].As discussed previously, BDI agents can be used to enact actions to achieve goals correlated to a context fromOWL/SWRL

reasoning. Take our scenario as discussed in Section 2.5, when John goes abroad, and his GPS detects his current location.The GPS data will be normalized and parsed using a NMEA-018315 Parser in the DataNormalization component, to retrievethe coordinates of John’s location. Then the ContextAggregation component updates the corresponding coordinates inthe CoordinateBased location ontology. This update triggers an (OWL) individual change event, and is detected by theHomeAutomation system to evaluate Rule: FarAwayFromHome in Section 3.4, which then updates the ‘‘FarAwayFromHome’’in the belief base of theHomeSecurity agent (which has anOwnerDistanceToHome belief set, and by default is set to ‘‘Normal’’)(Fig. 6). The HomeSecurity agent would then react to turn all surveillance cameras on, among other security procedures(based on a plan named ‘‘SurveillanceCamerasOn’’).Table 3 shows some of the event topics published by context updates and SWRL inferring, and also the corresponding

ontologies related to these contexts. Currently, publishing of and subscribing to events are the means for contextprovisioning. Besides nRQL (new Racer Query Language) (query examples are shown in Table 4), SPARQL (SPARQL Protocoland RDF Query Language)16 and SQWRL (Semantic Query-Enhanced Web Rule Language)17 as context query languages inPLiPerM is under development.

13 Jadex platform. http://vsis-www.informatik.uni-hamburg.de/projects/jadex/.14 RacerPro homepage. http://www.racer-systems.com/.15 http://www.gpsinformation.org/dale/nmea.htm.16 http://www.w3.org/TR/rdf-sparql-query/.17 http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL.

210 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

Table 3Events corresponding to context changes and rule inferring.

Purpose Context source Ontology Event topic

Monitor service call Services MessageProbe ServiceCallConduct state-based self-diagnosis Devices StateMachine StateChangePerson tracking Person and GPS sensor Person, CoordinateBased LocationChange

a b

BT

Fig. 4. (a) Architecture of a typical intelligent pervasive middleware (b) Deployment of reasoning capabilities.

BDI agents are widely used for automatically booking tickets online, negotiating prices in auctions on behalf of aperson [37], etc., which cannot be done through OWL/SWRL alone. We also present a case of BDI agents negotiating sportappointments in Section 5.

4.4. PLIPerM overall architecture

As proposed in [27,28,5], the combination of software product line techniques with an intelligent pervasive middlewarecan be used to provide necessary flexibility for configuration, customization and optimization for different domains andsituations. In the proposed approach, we manage all middleware components at the meta-level, which improves theadaptability of middleware assets.We show themodule architecture of a typical intelligent pervasivemiddleware in Fig. 4 (a). The context acquisition agent

collects the current contexts from various sensors. Fig. 4 (b) shows the deployment of the reasoning mechanisms used inPLIPerM. All three reasoning schemes (BDI, OWL-DL and SWRL) can be used on powerful nodes like desktops and laptops (atleast 1 GB of main memory and a 1GHz processor as required by RacerPro), SWRL and BDI reasoning can also be executedon resource-limited nodes like a PDA (at least 300 MB memory, JSE support), and BDI agents reasoning can be deployed onJME devices where resource are scarce (MIDP 2.0+ Personal Profile 1.0). For other nodes, where only JMEMIDP is available,PLIPerM either runs without any built-in reasoning capabilities, or runs a proxy to utilize some reasoning capabilities. Thislater approach is useful to equip embedded devices with reasoning capabilities. Also, it is possible to run plain softwareagents without BDI capabilities for any MIDP devices using the JADE-LEAP add-on.18We chose OSGi as the supporting service-oriented architecture framework in PLIPerM. Within the OSGi framework, an

intelligent agent can be implemented as an OSGi DS component, keeping in mind that we are considering the issue in apervasive middleware product line approach. Configuration points in the middleware product line architecture will beadded in the near future based on XVCL technologies, which can then be used to obtain specially tailored optimizations,e.g. performance and customize for different hardware and software domain or different purposes, as shown in [38].To make our ideas more concrete, in the coming sections, we will first present a case study of how to enhance the

intelligence of PLIPerM, where the performance of the combined reasoning from BDI + OWL + SWRL is tested, and thenshow Semantic Web based self-management using the SeMaPS ontologies.

5. A case study of context-aware person agents negotiating sport appointments

PLIPerM agents are designed based on the BDI agent platform called JadeX, which can be used to develop BDI agentsacross both J2SE and J2ME platforms. JadeX agents can inter-operate with JADE19 agents, including agents on small deviceswith the MIDP profile.

18 http://jade.tilab.com/.19 Jade and LEAP addon homepage. http://jade.tilab.com/.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 211

Fig. 5. Simplified ADF of person ‘‘John’’.

5.1. BDI agents design and implementation

For a person agent, the goals could be to support user decisions, for example discussing an appointment (for sport,entertainment, etc.), choosing the most suitable diet according to current health conditions (consulting the Food ontology),choose the best way for an important conference ormeeting (using the Schedule ontology and Location ontology), and so on.Beliefs, goals and plans are first-class objects in a JadeX agent whose implementation components are an XML agent

definition file (ADF), which are modeled with XML tags, and Java code for the implementation of agent actions for the Plan.Fig. 5 shows a simplified ADF for the definition of a person named ‘‘John’’, where<break> points are used to accommodatepossible customization and configuration when there are new facts from theoretical reasoning. In fact, Fig. 5 is a meta-ADFwhich can be used to accommodate customizations. It is possible to ignore the tags starting with<xvcl:>, in which case themeta-ADF becomes an original ADF.The agents interact with each other with the FIPA contract-net protocol.20 In the handling of the appointment proposal,

the initiator will first search the online person agents, and then compare these agents to verify whether they are in the listof people sharing the same hobby sport. Then, the proposal will be sent to all online people sharing the hobby.

5.2. Context ontology reasoning and SWRL rule reasoning

Table 4 lists some of the nRQL queries used in PLIPerM. Other examples include the reasoning on whether two areasare adjacent, contain each other, etc. After execution of the query, the results will be parsed, and these new facts will bepropagated and added to the belief base in related ADFs (Fig. 6) using FOJP component. For the details on how to achieveconsistent propagation of changes to all artifacts, please refer to [27].As shown in 4.3, SWRL-inferred result can be used to update facts or add a new fact for beliefs to Fig. 5. For example,

when John is inferred to be far away from home using the rule introduced in Section 3.4, the second <insert> (the first<adapt>) in Fig. 6 can be used to insert this new fact to the agent beliefs. Then the new belief can be utilized in goals andplans to take actions, for example to filter out friends far away from home during the process of appointment negotiation.

5.3. Performance evaluation

For the performance measurements, the software platform was JVM 1.6.02-b06 and Windows XP SP3. The hardwareplatform was a Thinkpad T61P T7500 2.2G CPU, 7200rpm hard disk, and 2G DDR2 RAM. The time measurements are in

20 FIPA Contract Net Interaction Protocol Specification. http://www.fipa.org/specs/fipa00029/SC00029H.html.

212 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

Table 4RacerPro queries for new possible beliefs.

Query type (example explanation) Query example

Complex role query (retrieve (?p1 ?p2 ?sport)(query for person (and (?p1 |http://plimm.org/Ontologies/Person#Person|)who share same (?p2 |http://plimm.org/Ontologies/Person#Person|)hobby sport) (?p1 ?sport |http://plimm.org/Ontologies/Person#hobbySport|)

(?p2 ?sport |http://plimm.org/Ontologies/Person#hobbySport|)))

Data mirror substrate (retrieve (?*x $?*x-toldValue) (and (?*x $?*x-toldValue(find all schedules (:owl-datatype-rolestarting on |http://plimm.org/Ontologies/Schedule#starts|))date 2009-04-13) ($?*x-toldValue (:predicate (search ‘‘2009-04-13’’)))))

Fig. 6. Propagation of OWL/SWRL ontology reasoning results.

Table 5Performance of BDI+ OWL+ SWRL reasoning.

1 2 3 4 5 Average

One round of negotiation 15 16 15 16 15 15.4Update ADF 110 109 94 110 109 106.4nQRL query 272 279 278 275 279 276.6SWRL rule 219 219 218 219 219 218.8

milliseconds. Jadex 0.95 beta1 was used for the testing. RacerPro 1.90 was used for the testing of nQRL query reasoning.Protege-OWL/SWRL APIs were from build 130. We show here the performance of one round of BDI agent negotiations andthe average over ten rounds. In practice, the developer can always limit the deadline for reaching an agreement, and devisealgorithms to increase or decrease the rounds needed.From Table 5, we can see that, on average, BDI agents need 154ms for 10 rounds of negotiation, the nQRL query for hobby

sharing takes 276.6 to obtain the hobby sharing information, the update of agent definitions takes 106.4 ms, and SWRL RuleFarAwayFromHome execution takes 218.8 ms. The sequential execution of the combined reasoning scheme takes 755.8 msfor ten rounds of negotiation of an appointment.We can see from these figures that the overall performance of the proposedapproach is acceptable for pervasive computing environments.

5.4. Discussion

BDI agent reasoning was invented because of the slow performance of pure planning systems which make planners lessusable in dynamic environments. As we can see from the performance figures in Table 5, BDI reasoning is reasonably fastand therefore promising in pervasive systems. BDI reasoning can be used to automatically deliberate both on the goal levelwith the ‘‘easy deliberation’’ strategy to choose among several goals, and on the plan level using preconditions of plans andcustomizable meta-level reasoning for choosing among several plans. Semantic web technology is a critical factor for theperformance of PLIPerMas can be imagined, and it is still in its infancy.Wewill therefore provide evaluations for SWRL-basedreasoning in the next section to demonstrate that the Semantic Web based self-management approach is also promising.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 213

Fig. 7. Functional architecture of Semantic Web-based self-management.

6. SeMaPS ontologies based self-management in PLIPerM

To fully make use of the potential of the context ontologies and their theoretical reasoning capabilities, in PLIPerM, weare applying an approach of Semantic Web-based self-management using the SeMaPS ontologies as outlined in Section 3.This approach is also adopted by the Hydra project.

6.1. Design of the self-management components

In our initial phase of the Semantic Web-based self-management, we are not yet using software agents for theimplementation, as we mainly focus on technical feasibility and performance evaluation. The architecture of the self-management components is shown in Fig. 7, using Kramer and Magee’s three-layered architectural style [39] as a referencemodel. The Goal management layer is not yet fully implemented.At the bottom of the architecture are the SeMaPS ontologies/rules, in which knowledge of devices, rule based QoS, and

state based diagnosis are encoded. The Component Control layer is mainly used for state reporting. Another major task forthe Component Control layer is to update the related information in the corresponding self-management ontologies. TheChangeManagement layer is used to execute rules developed based on the state and other runtime information, and parsingthe inferred results in order to take actions, for example the self-healing action. For the Goal Management layer, it is usedto find solutions for the malfunctions whose basic information is encoded in the Malfunction ontology, and resolve the ruleconflicts based on QoS regulations or user preference etc.

6.2. Implementation of Semantic Web-based self-management

Fig. 8 shows the high level processing sequence of the Semantic Web-based self-management. When there are stateupdates, the diagnosismodule, as a subscriber to this topic, will update the device statemachine. These updates are observedby registered listeners, and at the same time SWRL rule inferring will be started. New inferred information will be added

214 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

Fig. 8. Processing sequence of the self-management components.

to an inferred result queue, which is also observed. Next, the observer will parse the new inferred result, and publish thecorresponding diagnosis result.The SWRL APIs from Protege-OWL are the only available SWRL APIs and are thus used for the implementation and

execution of SWRL rules. The Protege-OWL code generator is used to generate Java code from the StateMachine ontologyand MessageProbe ontology. The generated code provides us with convenience through a factory class and interfaces tomanipulate ontology data, such as the creation of a new state machine instance and updating instances. The diagnosismodule follows the layered architecture style in essence.To evaluate the performance of SWRL/OWL loading and execution, and to determine where the performance bottlenecks

are, in the first iteration, we have assigned every class its own copy of the OWLmodel which pertains to its responsibilities.We tested this design and it showed that because of the complexity of OWL/SWRL and description logic, the performancewas not acceptable, as loading/unloading ontologies to/frommemory took toomuch time. In a second iteration, we adoptedamix of the Blackboard architecture style and the layered architecture, and use the observer pattern in both the updating ofstate machine ontology and inferred result parsing, where all ontologies are loading to memory in advance. In the followingsection, we show the evaluations of this second design.

6.3. Evaluating the self-diagnosis component

Self-management is being implemented incrementally. In the current iteration, we are focusing on the self-diagnosiscomponent and hence, at this stage,we evaluate the SemanticWebbased self-management approachwith the self-diagnosiscomponents. Because of potential performance problems of the Semantic Web based approach, the evaluation are mainlytargeting performance, leaving accuracy for diagnosis and rule conflict resolution as future work.

6.3.1. Extensibility for adding new self-management featuresWe started the development of the diagnosis module with the rule for temperature monitoring. A generic SWRL rule

processing component is developed. Then we added the MessageProbe ontology and service calling dynamism handling todetect whether a service is available or not. Only one piece of code was added to the reasoning result parsing component.Adding of the rule grouping feature did not affect the existing rule processing code either. The design shows good overallseparation of concerns.We are working on adding other self-management features, like self-configuration and self-adaptation where rules

have been outlined. These new features can make use of the rule processing and rule grouping features, with separatecomponents to interpret the reasoning results. In summary, the rule processing and rule grouping feature is generic and hasgood extensibility for adding new features.

6.3.2. PerformanceFor the performance,we are interested in the time it takes to update an ontology at runtime and the timeneeded to reason

with the SWRL rules based on the updated models. The self-management component uses 266M bytes Java heap memoryfor running Protege-OWL/SWRL APIs (Protege 3.4 Build 130), on the same hardware and OS as in the tests in Section 5.3.The size of the DeviceRule ontology is 238,824 bytes, and contains 20 rules, including 6 rules for the SmartHome system.We tested the performance both before and after the rule grouping featurewas added. The performance figures are shown

in Table 6. The Update column represents the time needed for updating the StateMachine ontology and/or MessageProbeontology, the InferringTime column shows the time needed for rules processing and inferring to obtain results. We can seethat more than 50% performance improvement is possible when rule grouping is used, with a minimum improvement of52%, and a maximum of 69%. We can also see that the update of ontology itself is not a light-weight operation. Fortunately,

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 215

Table 6Performance before and after using rule grouping.

Before rule grouping Using rule groupingUpdate InferringTime Update InferringTime

843 843 328 328906 906 297 281922 906 297 297719 719 297 281953 938 344 344

250000

200000

150000

100000

250000

500000 100 200 300 400 500 600

y= 425.35x–31.43R2=1.00

Fig. 9. Performance in scalability testing.

the updates of ontology and the inferring occur in parallel. Therefore it takes around 300 ms in total for rule reasoning,which is acceptable when rule grouping is used for the self-management components.

6.3.3. ScalabilityScalability is used to test whether the proposed approach is scaling well in terms of the capabilities to handle parallel

events from many devices, which will happen in real cases. To measure the scalability, a number of events are published(almost in parallel) to measure elapsed time, starting from the event publication until the end of inferring and publishingthe related inferred result. Time needed (y-axis) is shown in Fig. 9 (the x-axis shows the number of events published). Wecan see that the required time taken grows linear with the number of events that need to be processed. The prototype canhandle at least 500 events at the same time, which we deem acceptable for self-management.

6.3.4. DiscussionThe design of the rule processing and rule grouping feature is generic to be used for all self-management purposes, and

the overall design of the self-management component has shown good extensibility. The test results shown above do meetthe requirements for self-management in a pervasive environment, in terms of performance and scalability. The use of ruleprocessing and rule grouping is via simple APIs (e.g, rule name and/or rule group name) and easy to be used to developapplications.

7. Conclusions and future work

To make the user-centered pervasive computing a reality, the supporting infrastructure must be intelligent enoughin order to timely, smartly, and accurately react to context changes and prepare services accordingly. At the same time,to ensure the dependability of the underlying system, pervasive middleware should ideally provide self-managementcapabilities for achieving self-diagnosis when there are malfunctions, self-configuration when there are new services orservice updates, and other self-adaptation to meet quality-of-service requirements.In this article, we presented a set of context ontologies called the SeMaPS ontologies, which also consider human factors

such as hobbies and preferences. The context modeled by the SeMaPS ontologies is augmented with SWRL where complexcontext reasoning needs to be specified. The SeMaPS ontologies consider dynamic context as the key to achieving self-management, where self-management rules are again specified with SWRL rules.We furthermore presented an approach to combining the power of BDI practical reasoning and OWL/SWRL ontology

theoretical reasoning in order to improve the intelligence of pervasivemiddleware. In this approach, belief sets are enrichedwith the results of OWL/SWRL ontology reasoning, where some beliefs cannot be obtained directly or explicitly. In this way,we can enhance JadeX agents by adding logic reasoning capabilities indirectly to their beliefs.We are extending the context awareness for the realization of self-management supported by the SeMaPS ontologies.

Self-management capabilities are important to achieve dependability in pervasive systems, and is a challenge in pervasivecomputing. The proposed Semantic Web based self-management appears well suited to the open nature of pervasivecomputing. As SemanticWebbased contextmodeling is extensively used in pervasive computing, it is beneficial to uniformly

216 W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217

make use of this for self-management purposes as well. Evaluations with the self-diagnosis components in terms ofextensibility, scalability, and performance, showed that the proposed Semantic Web based self-management is effective.We are adding self-configuration, self-adaptation and other self-management features to the prototype. As an example,

self-protection modelling through security ontologies is going to be added to the SeMaPS ontologies. Full implementationof the three-layered self-management architecture proposed by [39] is planed by the combination of BDI agent andOWL/SWRL ontologies. Further work is needed to implement the OWL/SWRL ontologies-based self-diagnosis and otherself-management features using software agents, mainly in the planning work of self-management.

Acknowledgments

We would like to thank the anonymous reviewers for their valuable comments that helped to improve the article. Wethank Lars Braubach and Alexander Pokahr from the University of Hamburg for the support of Jadex. We also thank theProtege team at Stanford University for the support of Protege-OWL/SWRL, Sandia National Laboratories and Racer SystemsGmbH & Co. KG for research/education licenses for Jess and RacerPro respectively.Funding: The research reported in this article is supported by the Hydra EU project (IST-2005-034891).

References

[1] T. Strang, C. Linnhoff-popien, A context modeling survey, in: Workshop on Advanced Context Modelling, Reasoning andManagement, UbiComp 2004— The Sixth International Conference on Ubiquitous Computing, Nottingham/England, 2004.

[2] W. Zhang, K.M. Hansen, Semantic web based self-management for a pervasive service middleware, in: Second IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO 2008, Venice, Italy, October 2008, pp. 245–254.

[3] A. Rao, M. Georgeff, BDI agents: From theory to practice, in: Proceedings of the First International Conference on Multi-agent Systems (ICMAS-95),San Francisco, 1995, pp. 312–319.

[4] R.T. Maheswaran, M. Tambe, P. Varakantham, K. Myers, Adjustable autonomy challenges in personal assistant agents: A position paper, in: M. Klusch,G. Weiss, M. Rovatsos (Eds.), Computational Autonomy, 2004, pp. 187–194.

[5] W. Zhang, T. Kunz, K.M. Hansen, Product line enabled intelligent mobile middleware, in: ICECCS, IEEE Computer Society, 2007, pp. 148–160.[6] T. Klapiscak, R.H. Bordini, JASDL: A practical programming approach combining agent and semantic web technologies, in: Sixth InternationalWorkshop on Declarative Agent Languages and Technologies, Estoril, Portugal, 2008, May.

[7] C. Mascolo, L. Capra, W. Emmerich, Mobile computing middleware, in: Lecture Notes in Computer Science, vol. 2497, 2002, pp. 20–58.[8] J. Ye, L. Coyle, S. Dobson, P. Nixon, Ontology-based models in pervasive computing systems, Knowl. Eng. Rev. 22 (4) (2007) 315–347.[9] P. Bellavista, A. Corradi, C. Stefanelli, Mobile agent middleware for mobile computing, Computer 34 (3) (2001) 73–81.[10] O. Holder, I. Ben-Shaul, H. Gazit, System support for dynamic layout of distributed applications, in: International Conference onDistributed Computing

Systems, vol. 19, IEEE Computer Society Press, 1999, pp. 403–413.[11] M. Khedr, A. Karmouch, ACAI: agent-based context-aware infrastructure for spontaneous applications, J. Network and Computer Applications 28 (1)

(2005) 19–44.[12] A. Asthana,M. Cravatts, P. Krzyzanowski, An indoorwireless system for personalized shopping assistance, in: Proceedings of IEEEWorkshop onMobile

Computing Systems and Applications, IEEE Computer Society Press, 1994, pp. 69–74.[13] S. Long, R. Kooper, G.D. Abowd, C.G. Atkeson, Rapid prototyping of mobile context-aware applications: The cyberguide case study, in: MobiCom’96:

Proceedings of the 2nd Annual International Conference on Mobile Computing and Networking, ACM, New York, NY, USA, 1996, pp. 97–107.[14] A.K. Dey, D. Salber, G.D. Abowd, M. Futakawa, The conference assistant: Combining context-awareness with wearable computing, in: ISWC’99:

Proceedings of the 3rd IEEE International Symposium on Wearable Computers, IEEE Computer Society, Washington, DC, USA, ISBN: 0-7695-0428-0, 1999, pp. 21–28.

[15] T. Gu, H.K. Pung, D.Q. Zhang, A service-oriented middleware for building context-aware services, Journal of Network and Computer Applications 28(1) (2005) 1–18.

[16] P. Fahy, S. Clarke, CASS: A middleware for mobile context-aware applications, in: Proceedings of theWorkshop on Context Awareness, MobiSys 2004(2004).

[17] A.K. Dey, Providing Architectural Support for Building Context-Aware Applications. Ph.D. thesis, College of Computing, Georgia Institute of Technology,December 2000.

[18] T. Hofer,W. Schwinger,M. Pichler, G. Leonhartsberger, J. Altmann,W. Retschitzegger, Context-awareness onmobile devices— The hydrogen approach,in: Proceedings of the 36th Annual Hawaii International Conference on System Sciences, 2002, pp. 292–302.

[19] P. Korpipaa, J. Mantyjarvi, J. Kela, H. Keranen, E.Malm,Managing context information inmobile devices, Pervasive Computing, IEEE 2 (3) (2003) 42–51.[20] H. Chen, T. Finin, A. Joshi, An ontology for context-aware pervasive computing environments, Ontologies for Distributed Systems, Knowledge

Engineering Review 18 (2003) 197–207 (special issue).[21] A. Ranganathan, R.E. McGrath, R.H. Campbell, M.D. Mickunas, Use of ontologies in a pervasive computing environment, Knowl. Eng. Rev. 18 (3) (2003)

209–220.[22] J. Coutaz, A. Dearle, S. Dupuy-Chessa, G. Kirby, C. Lachenal, R. Morrison, G. Rey, E. Zirintsis, Working document on GlOSS ontology. Technical Report

IST-2000-26070 Report D9.2, Global Smart Spaces Project, 2003.[23] T. Strang, C. Linnhoff-popien, K. Frank, CoOL: A Context ontology language to enable contextual interoperability, in: LNCS 2893: Proceedings of 4th IFIP

WG 6.1 International Conference on Distributed Applications and Interoperable Systems, DAIS2003, in: Lecture Notes in Computer Science (LNCS),vol. 2893, Springer Verlag, Paris/France, 2003, pp. 236–247.

[24] S.B. Mokhtar, Y.-D. Bromberg, e.a.N. Georgantas, Amigo middleware core: Prototype implementation and documentation. Deliverable 3.2, EuropeanAmigo Project, March 2006.

[25] R. Hayton, A. Herbert, Flexinet: A flexible, component-oriented middleware system, in: Advances in Distributed Systems, Advanced DistributedComputing: From Algorithms to Systems, Springer-Verlag, London, UK, 1999, p. 497.

[26] N.F. Noy, M. Klein, Ontology evolution: Not the same as schema evolution, Knowledge and Information Systems 6 (2004) 428–440.[27] W. Zhang, Synergy between software product line and intelligent pervasive middleware—a PLIPerM approach, International Journal of Hybrid

Information Technology 1 (1) (2008) 17–30.[28] ZhangW., Hansen K., Synergy between software product line and intelligent mobile middleware, in: The 2007 International Conference on Intelligent

Pervasive Computing, 2007. IPC, October 2007, pp. 515–520.[29] T. Flury, G. Privat, F. Ramparany, OWL-based location ontology for context-aware services, Proceedings of the Artificial Intelligence in Mobile Systems

(2004) 52–57.[30] OSGi Alliance, OSGi Service Platform — Service Compendium. Technical Report Release 4, Version 4.1, OSGi, 2007.

W. Zhang et al. / Pervasive and Mobile Computing 6 (2010) 198–217 217

[31] O. Thiele, H. Knapp, M. Schader, N. Prat, A context-aware architecture for mobile knowledge management, in: Proceedings International Conferenceon Wireless Information Networks and Systems, Springer, 2006.

[32] P. Dolog, Model-driven navigation design for semantic web applications with the UML-guide, Engineering Advanced Web Applications (2004).[33] M.E. Bratman, D. Israel, M. Pollack, Plans and resource-bounded practical reasoning, in: R. Cummins, J.L. Pollock (Eds.), Philosophy and AI: Essays at

the Interface, The MIT Press, Cambridge, MA, 1991, pp. 1–22.[34] Á.F. Moreira, R. Vieira, Belief update in agentspeak-dl, in: R. Bordini, M. Dastani, J. Dix, A.E. Fallah-Seghrouchni (eds.), in: Programming Multi-Agent

Systems, in: Dagstuhl Seminar Proceedings, number 08361, Dagstuhl, Germany, 2008. Schloss Dagstuhl - Leibniz-Zentrum fuer Informatik, Germany.[35] A. Pokahr, L. Braubach, W. Lamersdorf, A flexible BDI architecture supporting extensibility, IEEE/WIC/ACM International Conference on Intelligent

Agent Technology (2005) 379–385. September.[36] S. Jarzabek, P. Bassett, H. Zhang, W. Zhang, XVCL: XML-based variant configuration language, in: Proceedings of the 25th International Conference on

Software Engineering, IEEE Computer Society Washington, DC, USA, 2003, pp. 810–811.[37] F. Bellifemine, G. Caire, D. Greenwood, E. Corporation, Developing Multi-agent Systems with JADE, Springer, 2007.[38] W. Zhang, S. Jarzabek, Reusewithout compromising performance: Industrial experience fromRPG software product line formobile devices, in: Lecture

Notes in Computer Science, vol. 3714, Springer, 2005, pp. 57–69.[39] J. Kramer, J. Magee, Self-managed systems: An architectural challenge. in: Future of Software Engineering, 2007, FOSE’07, May 2007, pp. 259–268.

Weishan Zhang is a Research Associate Professor in the Computer Science Department of the University of Aarhus. His researchis part of the EU HYDRA project. His research interests include intelligent pervasive middleware, software engineering andknowledge engineering with embedded system and mobile computing, and software reuse including software architecture andsoftware product line. He was a PC member of EMOBS07 (The First IEEE International Workshop on Engineering Mobile-BasedSoftware and Applications), and was invited as panelist for the ‘‘Middleware for NG networks and services’’ panel at the 31stAnnual International Computer Software and Applications Conference (COMPSAC2007).

Klaus Marius Hansen is a Professor of Software Engineering at University of Iceland (and on leave as Associate Professor atAarhus University, Department of Computer Science). His research interests are within experimental software engineering, inparticular software architecture, pervasive computing, and self-managing systems. Klaus has a PhD in Computer Science fromAarhus University.

Thomas Kunz is currently a Professor in Systems and Computer Engineering at Carleton University, Canada and Directorof the Technology Innovation Management program. He heads the Mobile Computing group, researching wireless networkarchitectures (MANETs, wireless mesh networks, wireless sensor networks), network protocols (routing, Mobile IP, QoS support),and middleware layers for innovative wireless applications. Professor Kunz authored or co-authored over 130 technical papers,received a number of awards, and has served on over 40 TPCs of international conferences and workshops in the mobile andwireless domain.