Implementing home-control applications
on service platform
Johann Bourcier, Clément Escoffier, Philippe Lalanda Laboratoire LSR-IMAG, 220 rue de la Chimie
Domaine Universitaire, BP 53 F-38041 Grenoble, Cedex 9, France
{firstname.name}@imag.fr
Abstract — The convergence of smart field devices and business services stands to profoundly change the way we interact with our environment. However, implementing and maintaining home-control applications is still far from easy. This paper discusses how service-oriented concepts can facilitate the development of home-control applications. Moreover we present an open architecture to implement these applications. A prototype of service platform for home-control is presented to illustrate the approach and its benefits.
Service oriented computing, home control applications, service platform, OSGi™, iPOJO, application model.
I. INTRODUCTION
Networks of devices will soon assist us in our daily activities using the notions of goals, context and knowledge to autonomously decide on the best actions to be undertaken [1][2]. Indeed, numerous manufacturers are already using, or planning to use, electronic devices to provide services to their customers; especially in the home context [3]. Many houses are already covered by wireless and wired network technologies and filled with electronic devices allowing the occupants to control their environment (being for comfort or for entertainment). But several business and technical challenges complicate the manufacturers’ ability to develop and manage such innovative services. To begin, the business models aren’t ready; it remains unclear how to commercialize such services and electronic devices or whether manufacturers should go the marketplace alone or with specialized partners. The second concern is technical. Putting smart services in place is a challenging task. It requires implementing the cooperation between heterogeneous devices in complex environments in which topologies, communication protocols, security policies, and such are dynamic and differ from one customer to the next. Devices and networks currently found in houses are actually very diverse. More than fifty candidate protocol and standard specifications today exist, providing communication and interoperation between access and indoor networks (see www.caba.org for extensive presentation and links).
In order to meet these requirements, innovative architectures based on the notion of service have been recently proposed [4][5]. Service-oriented computing (SOC) relies on the idea that a software resource - named service - is made available to third parties. For that, services must declaratively
define their capabilities, requirements and properties in an agreed (standard) machine-readable format. Based on service descriptions, automated service discovery, selection and binding is made possible in a service-oriented architecture. We believe that service orientation provides the level of flexibility that is required to build advanced applications in the home context. However, a number of challenges still have to be tackled. In particular, mechanisms are needed to build truly dynamic applications that can integrate new conditions at run-time. Most current service-oriented applications are not dynamic after the initial binding phase. Also, the thorny heterogeneity problem remains. Mechanisms are needed to allow applications to transparently use devices or networks based on various technological stacks.
This paper addresses the two above-mentioned challenges. It presents an open computing infrastructure for home services and, more specifically, a dynamic home control gateway seamlessly integrating distributed services based on different technologies. The gateway is based on the OSGi™ standard (see www.osgi.org) and currently integrates Jini [6] and DPWS [7] service. This work is carried out in cooperation with Schneider Electric (owner of Square D – see www.squared.com). The rest of the paper is organized as follow. First service-oriented computing is presented. Then the motivation of using service-oriented computing to build home control applications is discussed. This is followed by a description on the design of our home-control applications and how they interact with heterogeneous devices. Then a presentation of the gateway’s implementation is discussed. Finally, we conclude by pointing out major contributions of this paper and ongoing works.
II. SERVICE-ORIENTED COMPUTING
Service-oriented computing is a paradigm that defines services as fundamental elements for application design. The central objective of the service-oriented approach is to reduce dependencies among “software islands,” where an island is typically some remote piece of functionality accessed by clients. By reducing such dependencies, each element can evolve separately, so the application is more flexible than monolithic applications. SOC is based on three actors:
• A service consumer uses a service.
• A service broker contains references to available services.
Another central concept to SOC is the service specification, which is a description of the functionality provided by a service. Consequently, service providers implement a specific service specification and service consumers know how to interact with the services implementing the specifications they require. Among these three actors are three kinds of interactions: service publication between the provider and the broker to offer services for use, service discovery between the consumer and broker to find desired services, and service invocation consumers and providers to actually use the service.
From these concepts, SOC applications can exhibit interesting characteristics, such as:
• Loosely coupled: a consumer does not need to know anything about the service implementation.
• Late binding: a consumer uses a broker to find desired services at run time.
• Dynamically resilient: a service consumer cannot rely on the same service implementation being returned by the broker between invocations.
• Location transparency: providers and consumers are oblivious to the underlying communication infrastructure (e.g., local versus remote, specific protocols, etc.).
To design complex service-oriented applications, it is necessary to compose services, which means that providers may require other services to provide their own service.
III. SOC FOR HOME CONTROL GATEWAY
Home environment comprises multiple devices. These devices are structured into three categories:
• Electronic devices incorporated in the house (controllable shutters or lights for instance) providing basic services to sense and act on the environment. These devices could be static, or can appear and disappear dynamically (like cell phones).
• Gateways providing computing resources allowing to run high level services aggregating basic services brought by the previous type of devices,
• Rendering devices (TVs, smartphones or PDAs for instance) allowing users to interact with home services and, possibly, to administrate them. Homeowners will use them indifferently to interact with their environment (depending on location, convenience, etc.).
Home control applications need to interact with devices to provide added-value services. The purpose of a home-control gateway is to coordinate multiple devices and to ensure natural, sometimes invisible, interactions with the users. For instance, a home control gateway can coordinate the behaviors of specific devices like shutters, heaters or lights. This approach meets
proven market constraints stating that most manufacturers won’t provide access to their devices, neither to any operator nor to another device (for safety, security and obviously business considerations).
The current offer has demonstrated users’ interests for home control services. However, it appears that this gateway suffers from a lack of flexibility: it can only access devices through a proprietary protocol (Airlink – see www.airlink.com), it cannot be updated dynamically and is not able to dynamically consider new devices or, more generally, new execution conditions.
Using SOC to build home-control applications has several advantages. As previously said, loose coupling and location transparency allow services to use other services without any knowledge about the implementation or the used interaction protocols. Moreover, the SOC paradigm naturally supports dynamic applications like the ones encountered in the home environment. Indeed, applications have to deal with devices (service providers) that can appear or disappear at any time.
However, numerous challenges have to be dealt with. First, every device has to be compatible with a service-oriented technology (like Jini, UPnP [8] or DPWS). To use non-compatible devices, a third party has to be introduced to take care of the service publishing and invocation. In addition, we believe that a service-oriented home gateway should:
• Run a service-oriented execution framework (containing SOC primitives allowing service publishing, discovery and invocation)
• Provide deployment capabilities. The gateway is a deployment platform on which service application can be installed, executed, stopped, updated, resumed and removed.
IV. DEVELOPING HOME-CONTROL APPLICATIONS
We are currently developing home control applications on service-oriented platform in collaboration with Schneider Electric. We have been confronted with two main challenges:
• Get a model of application in the home control domain
• Build communication bridge to dynamically integrate disparate service technologies
A. Home-control application models
As the bridge concept allows the communication between a service-oriented platform and electronic devices, we are now able to build service-oriented applications controlling these devices. In order to design such applications, we have built, with experts, a model for the home control domain. This model, presented in figure 1, provides a clear separation between the different tasks to enable this control. It is basically composed of three kinds of entities: devices, business services, and scenes.
1) Devices
The main goal of a home control user is to control his house via electronic devices included in his house. During the
modeling phase of this work, we first classify electronic devices into three main categories:
• The first one concerns sensors. These devices are intended to sense the whole environment and convert their observations into numerical data or events. They periodically harvest information and store them. These devices are able to interact with other software entities in two main different ways: push mode (periodical message sending), and pull mode (response to a request). An example of such devices is a temperature sensor. In this category we class thermometers, presence detectors, and so on.
• The second category concerns controllable devices. These devices are able to perform actions influencing the environment. They could be control by other software entities. The only way of interacting with these devices is to send them a command. Examples of such devices are shutters, lights, TV and so on.
• The third category concerns devices that are part of both previously mentioned categories. These devices are able to sense and act on their surrounding area. They combine the possibility of controllable and sensor devices. Generally speaking, the sensor and the controllable part of a device have some strong functional relations. For example a heater generally integrates a temperature sensor to control the heating power. These devices are thus able to integrate and expose some higher-level operations.
BusinessService Scene +activate() +deactivate() External Service SensorDevice ControllableDevice ControllableSensorDevice 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..*
Figure 1. Home-control application model
2) Business Services
However, the device part of the model is clearly not sufficient to enable smart home control. Obviously, with the increasing number of devices, users will not be able to control separately all devices. This observation leads us to model software entities, called business services, which are able to automate some high level behaviors.
Business Services are entities that retrieve information through sensors and decide on actions on controllable devices. They contain the “smart” part of the Home Control gateway. A business service has to be written by a specialist of the application field. For example, consider someone who wants to provide an air conditioning service, which will manage the temperature of your home by sensing the temperature through thermometers, and control the temperature through heaters and coolers. This person needs to be an expert of the temperature control domain to design an efficient service.
A business service can used external service, like Web-service. For example, a service provider is able to keep the business logic of a service on its servers. In this case, he deploys a business service on the home gateway, which delegates all treatment to the service hosted on its servers. Another example is the interaction with a huge database hosted by the service provider (video on demand, map, itinerary and so on).
3) Scenes
The home control domain relies on the necessity to make the user life easier and easier. This implies that users will have very simple interactions with the system. In order to limit the number of interactions, industrial actors like Schneider Electrics have created the scene concept, which basically represents a scenario which acts on a set of house devices and business services. A scene is thus a software entity acting on devices and business services by invoking sequentially actions on theses services. It corresponds to the system’s user interface and can be activated through an interrupter. An example of such scene is presented in the section V.C.
B. Bridges
Home-control applications interact with devices to propose added-value services. To interact with these devices, we define a bridge per device. As illustrated in the figure 2, a bridge is a proxy [9] which:
• provide the device’s control interface as a service usable in the gateway
• delegate calls to the physical device
To hide the heterogeneity of the device protocols, the devices must be accessible by using gateway SOC mechanisms. The bridge publishes the control interface of the device as a service. Consequently, applications can interact with the device by invoking the service exposed by the bridge. When the service provided by the bridge is used, the bridge needs to delegate the call to the device, and to return the response. Meanwhile, the bridge needs to translate the method call into the device’s protocol. For example, a bridge, representing a DPWS device, needs to transform service invocation in a SOAP message. Moreover, some devices can send events (for example, when a phone receives an incoming call). These events must be listened by the bridge, which propagate these events inside the gateway.
Figure 2. Bridges functionalities
Bridges must also manage dynamism. For instance, a cell phone can appear and disappear dynamically when the owner enter of leave the home. To be used, a dynamic device needs to be both discoverable and trackable. To discover a device, a bridge has two standards ways:
• Passive discovery: the device announces its arrival and the bridge waits for this message.
• Active discovery: the bridge launches a probe message and the device must respond to this message.
Some protocols like WS-Discovery [11] (used in DPWS) allow the two methods. In the same manner, the departure of the device can be managed both actively by asking the device periodically (or when needed) and passively by waiting a departure message from the device.
By promoting bridges, we transform the home-control gateway in an integration gateway dealing with heterogeneous device technologies. Applications deal with bridges instead to interact directly with devices.
V. IMPLEMENTATION
This section describes an implementation of the proposed service gateway for home-control. This implementation is based on OSGi™ [12] and iPOJO [13]. This section is organized as follow. First we explain our motivation to use OSGi™ and iPOJO. Then we describe how we generate bridges for Jini and DPWS. We conclude this section by giving an example of a service-application for home-control using our application model.
A. OSGi™ and iPOJO
Our home-control gateway is implemented on top of the OSGi service platform. The OSGi service platform defines a framework to dynamically deploy services in a centralized (i.e., non-distributed) environment. The OSGi framework automatically manages aspects of local service deployment, such as Java package dependency resolution, but leaves service dependency management as a manual task for component developers. Our gateway is built on top of the OSGi service platform for three main reasons:
• It is service-oriented platform,
• It is applicable to home-control gateway
• It is a dynamic platform, which is particularly interesting to manage home environment dynamics.
Moreover, OSGi™ is a deployment platform too. It allows installing, updating, starting, stopping and uninstalling applications at any time. This property is very important in the context of the home-control. Indeed, service providers will install and remove their application dynamically.
iPOJO is a service-oriented component framework implemented on the top of OSGi™. iPOJO provides an extensible container, managing SOC mechanisms (service publishing, discovery and invocation), but can manage other non-functional property like persistency, configuration. Moreover, iPOJO manages dynamic availability of services. By providing this container, iPOJO aims to simplify the development of service application by hiding to the developer all SOC mechanisms. Using iPOJO in our gateway allow developers to implement applications in terms of Home-Control concept without managing SOC mechanism and dynamism issues.
B. Bridges Generation
As we use OSGi™ which is a centralised service oriented platform, we created bridges to transparently handle the distribution of devices. A bridge aims to hide both distribution and heterogeneity of supporting service oriented technology. A bridge publishes special service allowing interactions between service applications and the represented device. The SOC mechanism provided by OSGi™ is our referential: bridges use the OSGi publication mechanism to publish device’s service, and applications use OSGi™ service discovery and invocation mechanism to interact with devices.
We have already developed several prototypes of bridges for Jini and DPWS, exposing device in OSGi™. These prototypes automatically expose OSGi™ service for the represented device and transform the request coming from OSGi into an understandable request for the device (RMI invocation [14], SOAP [10]). Moreover, these bridges manage the device discovery.
We also have developed a tool, which is able to automatically generate a bridge for a dynamic DPWS device from its WSDL-description [10]. This tool creates the iPOJO component managing both the service discovery and the calls delegation.
C. Example of home-control application
Inhabitants of such smart home want to control their home through very simple interface. For example, when they go on vacation, they want to push a single button near the door in order to close all shutters, to turn off all lights, to arm the alarm system, and to start a presence simulation.
This scenario provides a full and concrete example which has been implemented using our home control gateway (figure 3). We create a scene called “go on vacation”. This scene is design to used two business services: the alarm system service and the presence simulation service. It also directly interacts with devices: lights and shutters.
The house comprises all necessary devices (alarm sensors, internet connection, lights, shutters, and so on). When the inhabitant has installed his alarm sensors in his home, the Gateway Client Client Bridges Delegation Discovery Delegation Gateway Client Client Bridges Delegation Discovery Delegation
system has automatically proposed to the user to subscribe new services using these devices. The inhabitant has chosen one alarm manager service which has been automatically deployed on his gateway with corresponding bridges. This service aims to manage the alarm system of the house by detecting intrusion. If intruders are detected, the service warns inhabitants through a mail service, and calls the user.
He has also subscribed to a presence simulation service which has been deployed on his gateway and is regularly updated by the provider. This service interacts with lights and shutters of the house. It provides a realistic presence simulation by acting on lights and shutters to simulate the inhabitant behaviour.
The implementation of this scenario was quite easy thanks to the use of iPOJO component model which has allowed us to concentrate on the business logic of our service without taking care of dynamics and SOC interactions. OSGi™ has provided us the basic infrastructure to deal with the dynamic deployment of remote services. Finally, our bridges have handled transparently the heterogeneity problem.
Figure 3. “Go on vacation” application model
VI. CONCLUSION
In this paper, we explore the home-control domain. Domain experts have established that dynamism and heterogeneity are unsolved issues in home-control applications. To tackle these problems, we propose to use service-oriented computing concepts to implement home-control applications. The contributions of the paper are twofold:
• proposing a model to implement home-control applications using service-oriented computing
• building communication bridges to dynamically integrate disparate service technologies
The resulting infrastructure takes care of stringent industrial constraints and is being evaluated in an industrial prototype within the ANSO ITEA European research project.
We are currently working on the definition of autonomous solutions which are needed at the gateways level [15]. Our approach falls in the realm of Model Driven Engineering [16] where applications are described in abstract terms and then deployed on the execution platforms. However, in our case, we seek to maintain both specification and implementation models on the execution platforms. This provides the level of variability required to build dynamically adaptable applications.
REFERENCES
[1] Mark Weiser, “The computer for the 21st century”, Scientific American, 265(3):66-75, September 1991
[2] A. Ferscha, “Pervasive computing and communications”, Beyond The Horizon Thematic Group, IST, 2005 (http://www.cordis.lu/ist/fet/id.htm) [3] S. Helal, W. Mann, H. El-Zabadani, J. King, Y. Kaddoura, E. Jansen,
"The Gator Tech Smart House: A Programmable Pervasive Space," Computer, vol. 38, no. 3, pp. 50-60, Mar., 2005.
[4] M. P. Papazoglou and D. Georgakopoulos. Service-oriented computing. Commun. ACM, 46(10):24–28, 2003.
[5] M. N. Huhns and M. P. Singh. Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing,vol. 9:pages 75–81, Jan./Feb. 2005.
[6] K. Arnold et al. “The Jini Specification,” Addison-Wesley, 1999. [7] S. Chan et al., Devices Profile for Web Services, May 2005, Microsoft
Developers Network Library, http://specs.xmlsoap.org/ws/2005/05/devprof/devicesprofile.pdf
[8] The UPnP Forum: http://www.upnp.org
[9] Marc Shapiro “Structure and Encapsulation in Distributed Systems: the Proxy Principle”, Int. Conf. on Dist. Comp. Sys. (ICDCS), Cambridge MA (USA), May 1986.
[10] L. F. Cabrera, C. Kurt, D. Box, An Introduction to the Web Services Architecture and its Specifications, Version 2.0, October 2004,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/introWSA.asp
[11] Microsoft. “Web Services Dynamic Discovery,”
http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-Discovery.pdf, April 2005.
[12] OSGi Alliance. “OSGi Service Platform Core Specification Release 4,” http://www.osgi.org, August 2005.
[13] C. Escoffier and R. Hall, “iPOJO : A service-oriented Component Framework”, unpublished in International Conference on Service-Oriented Computing, December 2006.
[14] Sun Microsystems. “Java Remote Method Invocation,” http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html, 2003. [15] P. Lalanda and J. Bourcier, “Towards autonomic residential gateways”,
IEEE International Conference on Pervasive Services (ICPS 2006), June 2006.
[16] OMG Model Driven Architecture. http://www.omg.org/mda/ Go on Vacation<<Scene>>
Light <<Device>>
Shutter <<Device>>
Presence detector<<Device>> Presence Simulation<<Business Service>>
Alarm Service <<Business Service>> Mail Sender Service <<Business Service>> 1 * * * * 1 1 * user
