Service-based Access to Distributed Embedded Devices through the Open Service Gateway

Transcription

1 Service-based Access to Distributed Embedded Devices through the Open Service Gateway Michael Ditze, Guido Kämper, Isabell Jahnich, Reinhard Bernhardi-Grisson C-LAB, Fürstenallee 11, Paderborn, Germany Abstract In search of a common digital infrastructure increasing convergence trends require to interoperate devices and services in heterogeneous network environments throughout various application domains, e.g. home domain. Home networks usually feature embedded devices with sparse resources and low processing power as e.g. in home automation devices. As a consequence, traditional solutions for the seamless interoperability of these devices like web services or network coprocessing prove to be unsatisfactory as they put high demands on the embedded devices. Low-level gateway solutions that are mainly responsible for protocol translation have been discussed for a long time. We propose to use the Open Service Gateway as specified by the Open Service Gateway Initiative (OSGi). Rather than performing protocol translation, the OSGi framework provides means to offer device capabilities as well-defined services to any other service registered with the framework. Even further, OSGi likewise allows to easily interoperate heterogeneous (Plug and Play) networks. This paper introduces OSGi as a promising service framework for the seamless operation of heterogeneous networks. Furthermore, it will present OSGi Control Services that allow to propagate native signaling events and error messages to the framework, and hence build the foundation for the seamless operation of complementary middleware solutions. 1. Introduction Increasing convergence trends in home networking requires to interoperate various devices in heterogeneous networks. Typically, home network devices are mainly embedded devices connected to heterogenous types of networks. Currently, these networks range from IP-based networks like Ethernet or WLAN and IEEE1394 that are mainly used for the timely transmission of high volume data as in audio- or video streaming applications to inexpensive low bandwidth technologies like LON or EIB that are mainly exploited for remote appliance repair, energy management or security monitoring in building automation. The demand for control and access to the respective devices requires supporting technologies like embedded Web Servers, Network Coprocessors, Distributed Middleware or Gateways for e.g. protocol translation. Each of these approaches, however, exhibits its own advantages and disadvantages. The implementation of Web Servers is usually paired with increased resource requirements in terms of CPU processing power and memory size. They require huge configuration efforts. Furthermore, Web Servers establish end-to-end sessions to the external access point, and hence they need a more sophisticated run-time environment that supports scheduling and file systems support. Web Services usually rely on SOAP, a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. The interpretation of SOAP messages, however, requires the implementation of a SOAP processor that also imposes additional overhead on the mostly sparse resources of embedded Web Servers in home devices. Distributed Middleware approaches that are nowadays deployed in the home domain are mostly open architectures that allow to control and develop services or devices in scalable, evolvable and flexible environments. Competing approaches include Home Audio Video Interoperability (HAVi), Universal Plug and Play (UPnP) and Jini. Again, each of the approaches comes along with certain disadvantages that exacerbate the deployment in heterogeneous environments, e.g. HAVi relies on IEEE1394 as the underlying communication media and supports respective protocols only. Jini and UPnP on the other hand are mainly IP-based solutions. Low-level gateways on the other hand act as an intermediary broker, supporting communication with external networks by protocol translations. They usually require a more powerful environment than it is provided by 8-bit or 16-bit microcontroller environments. Network Coprocessors are part of the hardware design of the embedded device and interface with its microcontroller. They contain a TCP/IP stack and potentially a Web Server or other configuration items. Functionality not included in the hardware design has to be supplemented by the applications in the embedded device. There is no possibility of a dynamic upgrade of the system-on-chip software. In order to overcome most of the drawbacks of separate solutions, we propose a joint solution that accommodates Distributed Middleware in Service Gateways. The aim of the service gateway is to represent devices connected to heterogeneous home networks as unified services in terms of a service proxy that can be accessed by any other service or device implemented in the gateway. Service requests are propagated to the Distributed Middleware that administrates the implementation of the service. On the other hand, middleware events and messages are passed to the gateway to allow for a seamless operation of the connected devices. We developed native Control Services on the gateway that fulfill this task. The benefit of coupling distributed middleware with a service gateways is that any middleware can be deployed on devices where it proves most suitable while it simultaneously offers services to other devices in a unified manner trough a well

2 defined interface in the service gateway. Further, the gateway allows to implement services accessible to complementary distributed middleware solutions and hence may add added-value services such as security services that are currently mainly disregarded in many middleware solutions. We will use OSGi (Open Service Gateway initiative) as a service gateway to connect HAVi compliant IEEE 1394 devices to Controller Area Network (CAN) devices. Though CAN devices currently play a very restricted role in the home environment, the aim of this approach is to demonstrate how heterogeneous networks can be connected through OSGi at the service level. Furthermore, we will describe methodologies that allow to propagate HAVi and CAN messages and events to the OSGi framework and hence allow for a seamless operation and connection of these heterogeneous devices. The rest of the paper is organized as follows: Section 2 will give a short introduction on OSGi, HAVi and CAN. Section 3 will then present Related Work. The enhanced OSGi architecture that includes Control Services is introduced in Section 4, followed by a description of the testbed and the implementation. Section 6 summarized our work. 2. Introduction to OSGi, Havi and CAN This section gives an overview of the most important principles of OSGi. It will furthermore summarize important features of HAVi and CAN relevant for this work Introduction to OSGi We propose to use OSGI (Open Service Gateway Initiative) [1] as a framework for the delivery of managed services to networked environments trough a service gateway. The latter allows service providers to access local, mostly residential networks over WANs. Typical such local networks relate to home-, vehicle-, mobile and other environments. OSGi consists of a services platform and a deployment infrastructure. The service platform mainly supports the interaction among services through a registry that contains service descriptions published by service providers. Once the service description is published it becomes available for other services registered with the framework. The registry allows service requesters to discover and bind published services. Services in OSGi are Java classes or interfaces that are collected as functional and deployment units referred to as bundles in OSGi terminology. The deployment infrastructure provides the execution environment and allows for continuous deployment activities as the e.g. installation, start or stop of a bundle. OSGi provides a standard set of services such as the Log and HTTP service and the Device Access service. While the Log service allows other services to write and read entries to and from a log, the HTTP service acts as a simple HTTP Server. The Device Access service provides means for the automatic detection and attachment of devices. It supports hot-plugging and un-plugging of new devices and coordinates the process of installing and downloading new device drivers through a refinement process. The refinement process tries to attach the most appropriate drivers to a Device Service according to a device description as indicated in the Device Category of the Device Service. The interaction between drivers and devices is the skeleton of the architecture which can be extended by e.g. servlets and hence provide new driver code to be downloaded. The resulting OSGi specification is based on Java s capabilities to permit dynamic installation of pieces of functionality. It contains the above mentioned features and can be used as a building block for a middleware supported embedded networking environment Introduction to HAVi Home Audio Video Interoperability (HAVi) [2],[3] is known as a home network standard that allows for the seamless interoperability between digital audio and video consumer devices across IEEE 1394 networks. HAVi provides means to control these devices by offering standard programming interfaces written in Java or native code referred to as Device Control Modules (DCM) that may be hosted by arbitrary HAVi devices. Functions of the DCMs are presented through Functional Control Modules (FCMs) that allow access to specific functions of a device. The Device Control Manager (DCM) ensures that at least one DCM per device is installed in the HAVi network. HAVi comes along with a set of components implemented as software elements that provide services within the HAVi network. These services form the foundation for building distributed systems. All HAVi elements are hosted by devices and are executed within their software execution environment. Their provided services include messaging, events, device discovery, lookup functionality, and configuration of streaming connections. The underlying network technology for HAVi is IEEE 1394 that features several characteristics that make it attractive for interconnecting AV devices. These features include current date transfers of up to 400 MBit/s, bandwidth reservations that allow for a timely transfer of isochronous realtime data and hot plug and play that enables an automatic network reconfiguration when a device is added or removed. State changes in the network or Havi environment is reflected to the HAVi Event Manager which notifies subscribed elements Introduction to the Controller Area Network The CAN protocol in its current version 2.0B [4] is an international standardized scalable serial bus communication system originally developed for automotive in-vehicle networks that allows peer stations like controllers, sensors or actuators to connect to one another. It is increasingly deployed in embedded control environments, e.g. factory automation as well as medical and railway control. The major benefits of CAN that explain its widely spreaded use are its reliability, real-time behavior, multimaster capabilities, broadcast messaging and most significantly, its cost effectiveness. CAN uses a message oriented communication protocol that allows for broadcast communication. Messages are identified through a unique 29-bits extended header that serves as a message identifier that simultaneously defines the content and the priority of the message. Whereas the priority of a message is required for bitwise deterministic CSMA/CA arbitration in case of multiple simultaneous sending entities, the receiving devices require the content description for message filtering. Likewise, CAN transmission occurs in broadcast mode to any node in the subnet that then filters messages according to their content description. The deterministic arbitration mechanism makes CAN real-time capable [5].

3 The CAN 2.0B protocol allows to send payloads at a maximum data-rate of 1 Mbit/s. CAN divides into three different layers: The physical layer, the CAN transfer layer and the CAN object layer. The latter defines the interface to the application. The protocol corresponds to the data link layer of the ISO/OSI reference model and is completely driven in hardware. CAN is not foreseen for plug-and-play scenarios, nevertheless CAN devices can be added dynamically by exploiting the message-oriented communication. 3. Related Work Recently, a lot of attention has been drawn to solutions that allow to interconnect CE devices in heterogeneous environments. This section emphasizes on the most significant approaches as related work. Wills et al. define a new framework for device discovery and and device description, called 3DF [6]. It has been implemented using OSGi and UPnP and handles the device discovery. In contrast to this approach, we also address the issue of interconnecting devices across heterogeneous networks and provide OSGi services to do so. Baier et. al introduce an approach that allows to control CE devices, connected within a HAVi network, via a HAVi/IP gateway [7]. For IP support the UPnP architecture is used. The approach is fixed to UPnP and HAVi. Baier rather concentrates on Controlling and interacting with HAVi-devices. In contrast to this approach, we present the OSGi Control Services that allows us to control non-havi devices through OSGi and connect them in a service-based manner. In [8], Zhang proposes an OSGi based infrastructure for context awareness with a residential gateway. Event-triggered rules define the context-aware behavior. The main focus of this paper is, however, the context awareness. Ahmed et al. implement a so called Home Manager Broker to connect a home network to the internet [9]. It installs OSGi Bundles to control devices from the internet through a web browser. Their approach is meant to be as an exmaple for OSGi functionality and, unlike our approach, does not offer interoperability and interaction of several devices. In difference to these projects we connect the CAN bus on ISO/OSI network layer to offer its functionality to the higher levels. 4. Availing the OSGI Service Gateway for interoperating heterogeneous networks The interoperability of devices and services plays a significant role in many heterogeneous networks. While this issue has been addressed by a variety of approaches like Web Services, Network Coprocessors, Distributed Middleware and service gateways, a combination of the latter seems to be the most promising solution. We use OSGi as a service gateway solution. In particular, the most obvious benefits of combining Distributed Middleware and service gateways like OSGi include: 1. Application services: The Service Gateway provides services that are common to all applications. For example, an authentication module in the framework could allow all applications to authenticate against a single password database 2. Self-contained applications: Applications run inside the framework are self-contained with portable code and the necessary configuration files. The interdependence of applications and library components can be managed by the framework. 3. Life cycle management: By calling the life cycle methods defined in the framework and implemented by all applications, the framework can install, start, stop, update, and delete any application programmatically or through an interactive console. 4. Interface services: The framework allows applications to offer services to each other. This encourages code reuse and prompts architectures for layered and modularized applications. 5. Increased Robustness: In case devices are detected as erroneous or temporarily unavailable, the service gateway may handle a field reconfiguration if the system is constructed multiple-redundant. The service gateway may identify similar services offered by different devices and use them alternatively. For building such advanced environments, high level standard interfaces are an important key factor that allow to reduce manufacturing and development costs. In order to effectively support these Application Programmer Interfaces (APIs) the usage of middleware components in the distributed embedded environment is inevitable. While this list is not meant to be exhaustive, it clearly states the advantages of a joint approach. A combination of OSGi with a Distributed Middleware approach like HAVi, however, requires an efficient architecture that accommodates the use of devices with sparse resources in terms of processing power and storage capacity. Crucial to the development of such a joint approach is that both approaches need to be aware of one another, e.g. HAVi messages and events need to be adapted to OSGi events such as each device that accesses HAVi services through OSGi is notified about state changes. Similarly, HAVi devices shall be released in case their service is no longer required by any service registered with OSGi. In order to guarantee a complete interoperability of the approaches, and hence of the services provided by each device, the following requirements need be covered: New devices need to be discovered in a Plug and Play fashion and corresponding drivers or service interfaces must be made available to requesting services transparent access to each device attached to the gateway from the application point of view, i.e. an suitable abstraction of the network specific differences management of events and errors that occur in the different networks maintaining a consistent description of a device object In our approach we exploit OSGi to interconnect HAVi and CAN devices and their respective services through the service gateway, thus enabling new enhanced and combined services. Hence, we introduce new OSGi services, so called Control Services (CS), that represent a separate service interface between OSGi and the HAVi and CAN network, respectively. These control services are responsible for tracking native, i.e. non-osgi, events and propagating them to the OSGi framework and vice-versa. Additionally, we provide OSGi driver services that allow for the access to the native device. In case of HAVi, the driver service encapsulates HAVi DCMs and corresponding FCMs that represent HAVi service interfaces. For

4 Figure 1. Extending OSGi through Control Services for seamless operation of Devices CAN this will be a native driver that accesses the CAN Object layer for transmission and reception of broadcast messages. The new OSGi service architecture is depicted in Fig.1. It consists of an OSGi service registry and the OSGi Device Access methods that are centered around the OSGi Device Manager, Driver Locator and the Driver Selector. The Control Services (CS) interact with the respective framework through the Java Native Interface (JNI). The JNI is required for native interaction as e.g. in CAN. If the Control Service would be implemented as a HAVi FAV which contains the HAVi stack along with a JVM, the JNI is no longer required. In the following we will explain how new native devices may be added to the OSGi framework at run-time and their services get accessible through remote access. Upon OSGi startup, the framework resolves and installs the native control services. Further, we assume that driver bundles that host the HAVi DCMs and the CAN native driver are accessible within the framework and are listed as specific HAVi and CAN drivers. Each driver bundle represents a separate native device. a) Whenever a new device is attached to the IEEE1394 HAVi network the HAVi control service catches the respective Havi New-Device event through the JNI. For CAN, which does not exhibit Plug and Play capabilities, the CS must perform an active scan of the network. The CS registers the Device Service that contains a Device Category specification. For HAVi this will require a call that delivers the FCMs available inside a HAVi device. The latter contains an interface that all devices belonging to this category must implement along with a set of service registration properties along with a device ID that exactly identifies the resepective device in the HAVi network. The Device Manager detects the new Device Service and initiates the Device Access, i.e. it associates the device service with a corresponding driver service. b) The Device locator fetches the device driver required for a specific device based on the device category or any other supplied property as declared in the HAVi or CAN device service. In case multiple appropriate drivers are available, the Driver Selector picks the most appropriate driver according the the specified device category. As in our architecture there will usually just one driver bundle per installed HAVi device, the driver selector may mainly be disregarded. However, the Driver Selector may play a vital role in case similar services are provided by different devices. In that case the Driver Selector may chose the driver or the respective device that best fits optional Quality of Service parameters as provided by the requesting service. c) Once the device driver has been attached to the CS, the CS becomes available in the framework and the service is published along with a service description and a service interface. Further, device driver implement an Event Listener for the CS in order to intercept translated native events. These events may notify the device driver in case a native device temporarily gets unavailable or is removed from the network. In that case the driver bundle will be stopped or removed and hence the service is deleted from the OSGI service registry. d) Application Bundles now have the possibility to query published services according to a service description contained inside an XML file. For CAN networks such a service may include sensor monitoring, for HAVI networks typical services are multimedia oriented are video recording or playback. e) Once services have been located, service binding allows for service access. 5. Testbed and Evaluation We emulated a house monitoring system as an application use case to demonstrate the seamless operation of heterogenous devices represented as OSGi services. Whenever a house monitoring sensor is activated, e.g. in case of glass breakage, a notification that contains the position of the sensor is generated and sent as a CAN broadcast message. The receiving CAN node interprets the messages and passes it to the CAN CS through the JNI. The CAN CS notifies the CAN device driver Bundle that calls back the application. The latter then seeks the OSGi service registry for a video monitoring service offered by a HAVI device at a certain position. If available, the service gets binded, and the HAVi camera starts recording. We implemented, tested and evaluated the above mentioned use case on a Linux open-source system. As OSGi [1] plat-

5 + ) 0 ) 8 E. H = A M H, A L E? A )?? A I I, = J = 8 = L = = J E L A 1 J A H B =? A + ) E >! ' " E > H = H O E K N 5, H E L A H I ! ' " + ) Figure 2. OSGi Service Gateway Architecture with corresponding HAVi and CAN Services Figure 4. The HAVi Camera Driver Service form we chose the Java Embedded Server [10], being compliant with Version 2 of the OSGi specification. The Java Embedded Server requires a Java Run Time environment. In our demonstrator we use JURE 1.4 running under Linux with the kernel version Further, we used a Linux-based HAVi stack implementation provided by dmn. The SJA 1000 serves a CAN controller that is connected to the sensor. Further, we implemented the HAVi and CAN Control Services and the Device Driver as OSGi bundles. The HAVi Driver consists of a DCM and corresponding FCMs that allow to call Havi services. The CAN Driver implements the CAN Object Layer that controls access to the CAN node. Fig. 3 describes the realization of the HAVi Control Service in UML notation. In this case we use a native HAVi implementation which hence requires the JNI. The functions are defined as native functions in the Impl Class and programmed in C through the JNI. The used interface HAVi listener tracks all HAVi events. Whereas HAVi system events are processed directly, the device specific events are forwarded to the Control Service following the listener concept. Figure 4 illustrates the realization of a camera driver DCM that is represented as a OSGi driver service. Here, the camera service and camera Impl describe the device functional- ity available for OSGi-registered services. The device driver will be loaded and started after it has been resolved by the Device Locator. In order to allow the Device Locator to find the HAVi-Camera Driver server, a XML file is necessary that describes the driver and the devices the driver is compatible with. As example of such an XML file is shown below: <?xml version=?1.0? encoding=?utf-8??> <bundle> <component class=?de.clab.cam.camera_impl?> <provides service=?de.clab.cam.camera_service?/> <property name=?provider? value=?c-lab Paderborn? type=?string?> <requires service=??? filter=?(version=*)? policy=?static?... /> </component> </bundle> From that point the device functions are available for all other devices and applications. It registers itself in the HAVi CS with an announcement of its HAVi-listener, so that every event targeted at the device is forwarded to the driver and the connected application. 6. Summary Figure 3. The HAVi Control Service This paper evaluated and proposed the use of the Open Service Gateway as a promising solution for the seamless operation of heterogeneously connected devices in the home environment. We presented an extended OSGI architecture that introduced Control Services as OSGI services that allow to propagate native events and messages to the OSGi environment. Using Control Services along with respective Device Driver enables the interopearation of native devices and their offered services through OSGi. Further, we described Control Services for HAVi and CAN devices and presented an

6 use-case driven approach to make their service interoperable. In future we will integrate XML-based device- and service description formats. These formats will allow services to precisely identify device capabilities and service properties, and hence help to select the most appropriate sercice option. 7. Acknowledgment This work was supported by the Sirena project within the Europe s premier cooperative R&D e ITEA. References [1] Open Service Gateway Initiative: The OSGi Service Platform Specification, Release 3. March, 2003 [2] HAVi Consortium: HAVi Specification(ver 1.1): Specification of the Home Audio/Video Interoperability(HAVi) Architecture. May, 2001 [3] Lea, R., Gibbs, S., Dara-Abrams, A., Eytchson, E.: Networking Home Entertainment Devices with HAVi. In IEEE Computer, Vol 33, No.9, 2000 [4] International Organisation for Standardisation I SO Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication 1993 [5] Tindell,K., Burns,A., Wellings,A.: Calculating Controller Area Network (CAN) Message Response Times, Control Engineering Practice, vol. 3, no. 8, pp , [6] Wils, A., Matthijs, F., Berbers, Y., Holvoet, T. and De Vlaminck, K.: Device Discovery via Residential Gateways ICCE 2002 Digest of technical papers (Rowe, W.A., ed.), pp , 2002 [7] Baier, R., Gran, C., Scheller, A., Stolp, R.: Control of CE Devices Through a HAVi/IP Gateway International Symposium on Consumer Electronics, Erfurt, August, 2002 [8] Zhang, D., Wang, X., Leman, K., Hunag, W.: OSGi Based Service Infrastructure for Context Aware Connected Homes 1st International Conference on Smart Homes and Health Telematics (ICOST2003), September 24, 2003, Paris, France. [9] Ahmed, F., Madisetti, V., Jiao, Y., Dasigi,V.: Web- Enabled Information Appliances for Broadband Residential Networks [10] Sun Micorsystems, Inc.: The Connected Home Powered by the Java Embedded Server USA, 2001