Towards autonomic residential gateways Philippe Lalanda and Johann Bourcier Laboratoire LSR-IMAG, 220 rue de la Chimie Domaine Universitaire, BP 53 F-38041 Grenoble, Cedex 9, France {philippe.lalanda, johann.bourcier}@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 pervasive services is still far from easy. In this paper, we present an open architecture and service oriented gateways facilitating the development of home services. Key words: Service oriented computing, home services.

1. Introduction The connection of business and industrial processes is today of major importance for a wide range of manufacturers. The main challenge is actually to seamlessly integrate application software supporting business activities and industrial devices implementing field applications. Such computing elements have been separate until recently, primarily because of technical issues, including incompatible programming paradigms, network heterogeneity, differing time scales, and the lack of appropriate integration tools. With the Internet’s emergence and the proliferation of smart communication devices, stronger coupling between previously autonomous activities is now possible. This trends towards increasingly ubiquitous network-enable devices is known under the name of pervasive or ubiquitous computing [1,2]. Many believe that linking devices and business services stands to profoundly change the way we interact with our computing environment [3,4]. Networks of devices will assist us in our daily activities using the notions of goals, context and knowledge to autonomously decide on the best actions to be undertaken. In many cases, goals will be derived from higher level objectives set by the business services. For instance, devices will cooperate to provide a secure and adpated environment to a disabled person. The execution context of a device contains current

information about its location, its physical and computing environment, and its human users. Indeed, in order to enable natural and meaningful interactions, devices have to be aware of the humans’ activities, desires, whereabouts, needs, etc. Numerous manufacturers are already using, or planning to use, electronic devices to provide pervasive services to their customers; especially in the home context. Many houses are already covered by wireless and wired network technologies and filled with a plethora of 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, for example, or whether manufacturers should go the marketplace alone or with specialized partners. The second concern is technical. Putting pervasive services in place is a challenging task. It requires to implement the cooperation between heterogeneous, autonomous devices in complex environments in which topologies, communication protocols, security policies, and such are dynamic and differ from one customer to the next. The purpose of this paper is to present ongoing work in the area of residential gateways carried out in cooperation with Schneider Electric1. Specifically, this work deals with the design of an open computing infrastructure for the development of home pervasive services, including autonomic service-oriented gateways. The paper is organized as it follows. Next section presents domain requirements and existing computing architectures in the home domain. Then, section 3 focuses on the notion of smart gateways and the use of the OSGi standard to implement home control gateways.

1

This work is partially supported by the French Ministry of Industry.

2. Smart home computing architecture

2.2. Current architectures

2.1. Requirements

One of the main challenges to realize the vision of smart houses is to define an open computing infrastructure for homes. Manufacturers and operators have already proposed various architectures. Current infrastructures’ limitations generally impede their ability to handle large numbers of clients, devices, or services.

Home is the place where people invest most of their money, time and energy. This is also the place where pervasive services are likely to be heavily used. However, we believe that the vision of pervasive home services is not achievable today for several reasons. Specific architectures and techniques are necessary to meet stringent requirements, including: 











Heterogeneity. Devices and networks that are currently found in a house are very diverse. Uniform and compatible implementations are not foreseen: today, more than 50 candidate protocols, working groups and standard specifications for home networking already exist, providing communication and interoperation between access and indoor networks. Security. Security policies (regarding children safety for instance) are different from one customer to the other and are very changing over time. In addition, most homeowners will not change their security policies in order to suit a given service. Scalability. As environmental smartness grows, so will the number of electronic communication devices. The mere number of computing elements will raise challenging software issues regarding the development, installation, and maintenance of scalable in-house services. Flexibility. In the home context (as in the telecommunication one), services regularly evolve in order to stick to users desires and new technologies. Also, homeowners must be able to freely change their installations, despite the presence of pervasive services. Dynamism. Evolutions regarding pervasive services must be done without stopping the execution platforms nor the services that are not affected by the modifications. Autonomy. The computing environment should be almost invisible. Automatic techniques will be needed to dynamically configure services, networks and devices. Human intervention should be very limited and part of a continuous learning cycle.

In addition to these non functional properties, it is also clear that many functional requirements are difficult to meet. For instance, context awareness and autonomy are very challenging goals that will require researchers to focus on domain-specific issues. Resolving these problems in general seems too distant today.

Most systems are based on an architecture like the one illustrated in Figure 1, in which an Internet server is connected to Internet gateways through HTTP or other protocols over IP. The purpose of a home gateway is to link Internet networks and in-house local networks connecting various home devices. Services are implemented as distributed applications run on the server side and on the devices. Several gateways provided by different actors (telecom or media operators, utilities actors) can reside in the same house.

Figure 1: Early architecture Although this architecture allows the implementation of pervasive home services, it also suffers from several liabilities. To begin, most processing and coordination occurs at the Internet-server level, which affects scalability and flexibility: 



the server must handle the additional load when the number of houses or services increases. Similarly, as more devices connect to a gateway, the communications load between the gateway and the server increases proportionally. The server has to know every devices that are introduced in the house in order to dynamically evolve the services. Devices life cycle has to be managed manually since automatic detection is not feasible in such large scale networks.

2.3. Future architectures

3. Smart autonomic gateways

As illustrated by Figure 2, we are working on innovative architectures where home devices are represented as service providers and requesters [3,4]. Devices are structured into 3 categories:

3.1. Home control gateway



 

Electronic devices incorporated in the house (controlable shutters or lights for instance) providing basic services to sense and act on the environment, Gateways providing computing resources allowing to run high level services agregating 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.).

In the previous architecture, gateways are smart equipments agregating a number of electronic devices. The purpose of a gateway is to coordinate mutiple devices and to ensure natural, sometimes invisible, interactions with the users. These interactions are obviously directed by high level goals that can be set by the user or by Internet services to which the user has subscribed. Some electronic devices can be exclusively connected to a given gateway. For instance, a home control gateway can coordinate the behaviors of specific devices like shutters or heaters. This approach meets proven market constraints which state that most manufacturers won’t provide access to their devices to any operator or device (for safety, security and obviously business considerations). Schneider Electric has already developed a home control gateway enabling occupants to remotely control or configure a set of automated devices by entering a single command. For instance, one can press a single button to arm a home security system, control temperature gauges, switch appliances on or off, control lightning, etc. This is called a scene. In the current implementation, electronic devices are connected to the gateway through wireless networks.

Figure 2: Future architecture Technically speaking, we can differentiate two types of devices in the home. Those that are compatible with a service oriented technology (like Jini or UPnP for instance – see www.jini.org and www.upnp.org) and those which do not integrate SOC capabilities. To be used in a service-oriented architecture, the latter have to be managed by a third party taking care of the publishing and binding processes. Service oriented technologies are however numerous and often not compatible, which raises thorny integration issues.

Current Schneider Electric offer has demonstrated users’ interests for pervasive home services. However several liabilities have been detected. In particular, the autonomy level is currently not sufficient. As previously stated, a home gateway must be able to autonomously operate in a dynamic environment. Specifically, a selfmanaging gateway has to act on its own in order to be efficient and trustworthy and to maximize its functionality and performance given the context. A selfmanaging system must identify failed components, detect impending violations of the service contract (with respect to security, performance or functionality) and affect an appropriate response, such as reconfiguration, task reassignment and isolation of failed components or malicious event sources. Only as a last resort should the system alert human operators, and then provide specific information regarding the anomaly or fault that caused the alert. This requires a level of self-awereness and adaptation not found in the current system. As a remedy to these limitations, we believe that such home gateways should adopt a Service Oriented Computing (SOC) approach and, thus, run dynamic services [5].

3.2. Autonomic OSGi gateways SOC promotes loosely coupled applications based on the notion of service. This paradigm relies on the idea that a piece of software - the service - is made available to third parties. For that, services must declaratively define their capabilities and requirements in an agreed (standard) machine-readable format. Based on service descriptions, automated service discovery, selection and binding are then performed at run-time. The OSGi consortium (www.osgi.org) has proposed a framework to implement service-oriented gateways. OSGi is an open service platform defining a minimal component model, a small framework for administering components, and a set of standard services. Components are packaged in bundles, which are the deployment units in the OSGi model. The framework also defines mechanisms that facilitate the dynamic installation, activation, deactivation, update, and removal of bundles. As explained hereafter, we believe that OSGi brings the technical foundations to develop dynamic and autonomic home services making an opportunistic (and optimal) use of the transient home electronic resources. We are currently porting the Schneider Electric gateway on industrial PCs running the Open Service Container Architecture [6] (Oscar; http://oscar.objectweb.org) — the leading open-source implementation of the OSGi framework4 — on top of Linux. The purpose of this work is twofold. To begin, using OSGi provides the level of flexibility required to manage dynamic services at the gateway level. It allows applications to deal with transient services. We also believe that OSGi sets the foundations for more autonomic behaviors. We are today working on representing dynamic applications in such a way that an autonomic manager, embedded on a gateway, could change the services that are used to implement the application. The autonomic manager should also be able to change the functional perimeter of an application if necessary. To do so, we model applications at a high level of abstraction [7]. Applications appear as the composition of services described in an abstract fashion. Services are specified through provided and required interfaces and with a list of non functional properties. This approach facilitates the development of service-oriented applications, which is difficult today because of the diversity of service technologies and the low maturity of most programmers regarding dynamic aspects. The approach also brings some variability: separating business logic and implementation allows autonomic adaptations of the implementations while meeting the

business goals. The approach can be related to recent work on ADL-based reconfigurations [8] (Architecture Definition Language). In order to manage the difference between applications specified with a Domain-Specific Language and the actual implementation on a gateway (which is automatically generated in our case), we maintain both view on the gateway. We are then able to replace services (performing dynamic rebinding) when contextual conditions require it. Our main issue today is to determine the good level of application description allowing dynamic adaptations while maintaining a reasonable semantic gap between specification and implementation.

4. Conclusion We have presented an open computing infrastructure for the development of pervasive home services. In this architecture, we focus on smart gateways running dynamic, adaptative services. We are currently working on the definition of autonomous solutions which are needed at the gateways level. Our approach falls in the realm of Model Driven Engineering 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.

5. References 1 2

3

4

5

6 7

8

Mark Weiser, “The computer for the 21st century”, Scientific American, 265(3):66-75, September 1991 A. Ferscha, “Pervasive computing and communications”, Beyond The Horizon Thematic Group, IST, 2005 (http://www.cordis.lu/ist/fet/id.htm) P. Lalanda, “E-Services Infrastructure in Power Distribution,” IEEE Internet Computing, vol. 9, no. 3, 2005, pp. 52–59. P. Lalanda, L. Bellissard and R. Balter, “ Asynchronous Mediation for Integrating Business and operational Processes,” IEEE Internet Computing, vol. 10, no. 1, 2006, pp. 56–64. 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. Hall, R., “OSCAR, Open Service Container Architecture”, http://oscar-osgi.sourceforge.net C. Marin, P. Lalanda and D. Donsez, “A MDE approach for power services development”, Int. Conf. on Service Oriented Computing, Amsterdam, december 2005. J. Floch, S. Hallsteinsen, E. Stav, F. Eliassen and E. Gjorven, “Using architecture models for runtime adaptability”, IEEE Software, vol. 23, n° 2, 2006, p. 62-69

Towards autonomic residential gateways

The convergence of smart field devices and business services stands to ... Key words: Service oriented computing, home services. 1. ... With the Internet's.

79KB Sizes 0 Downloads 176 Views

Recommend Documents

Towards Policy Decomposition for Autonomic Systems Governance ...
Policy-based management systems use declarative rules to govern their ... definition of goals and constraints for the systems, i.e. defining 'what' the system ...

BRKSPG-2447-Autonomic-Simplify.pdf
Page 4 of 61. BRKSPG-2447 © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public. His Task for the week: Bring up... Core. Metro Ethernet. Cloud.

BRKGEN-2999-Autonomic-Intro.pdf
Autonomic Networking. Intro – How We Got Here. Page 3 of 39. BRKGEN-2999-Autonomic-Intro.pdf. BRKGEN-2999-Autonomic-Intro.pdf. Open. Extract.

autonomic nervous system pharmacology pdf
Try one of the apps below to open or edit this item. autonomic nervous system pharmacology pdf. autonomic nervous system pharmacology pdf. Open. Extract.

Residential Bldg
1 pad certification due at submittal or finish floor elevation certificate due prior to ... 2 pre-engineered truss drawings with hangar hardware called out if used. 5.

Harmony Residential C/O FirstService Residential -
Jun 23, 2015 - ST CLOUD FL 34773 Other - Storage ... The Harmony Residential Board of Directors is dedicated to protecting the investments made in your ...

DOGC 2 Conveni Autonomic 2016-2018.pdf
Page 1 of 30. DISPOSICIONS. DEPARTAMENT DE TREBALL, AFERS SOCIALS I FAMÍLIES. RESOLUCIÓ TSF/92/2017, de 23 de gener, per la qual es disposa ...

Autonomic Management of Clustered Applications
KEY WORDS: Autonomic management, Legacy systems, Self- optimization, Cluster .... database servers [8], JBoss clustering for a cluster of JBoss. EJB servers [6] .... flected at the legacy layer in the worker.properties file used to configure the ...

Knowledge Delivery Mechanism for Autonomic Overlay Network ...
Jun 19, 2009 - KBN broker, termed the Trigger Broker. The Trigger Broker receives incoming subscriptions from the policy server. (dynamically derived from its policy set) and stores these in a local subscription table. When management state (event) m

Natural gas residential and
Feb 8, 2016 - Natural gas residential and business rebate programs continue in 2016. Dayton ... “Energy efficient products and services deliver substantial.

Residential Movers.pdf
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Residential ...Missing:

Harmony Residential C/O FirstService Residential -
Jun 23, 2015 - ST CLOUD FL 34773 Other - Storage. Inspection Date: June 23, 2015 ... Please remove potted plants/personal items from walkways, front ...