DESIGN AND IMPLEMENTATION OF AN EMBEDDED HOME-GATEWAY FOR REMOTE MONITORING BASED ON OSGI TECHNOLOGY

Transcription

1 DESIGN AND IMPLEMENTATION OF AN EMBEDDED HOME-GATEWAY FOR REMOTE MONITORING BASED ON OSGI TECHLOGY Ying-Wen Bai and Jui-Po Hsu Department of Electronic Engineering, Fu Jen Catholic University Taipei, Taiwan, 242, R.O.C. ABSTRACT In this paper, we use OSGi (Open Service Gateway Initiative) technology to design and implement a remote monitor system in an embedded. For the integration of all kinds of existing communication protocol, OSGi technology has the potential to conform with numerous standards. Because OSGi has a defined external protocol services interface, it provides compatible services to control the devices of different protocols. To reduce power consumption and operation costs, we select the embedded system as the implementation of the home gateway. Because the embedded is a customized system, we can focus on our special requirements to design it. We also use an SMF (Service Management Framework) kit to design and implement the embedded based on OSGi technique. SMF is an implementation tool which follows OSGi specifications. The operating system of our embedded development board uses Windows CE.NET (WinCE) which has interfaces with which most people are relatively familiar, and it cooperates with a touch panel for easy operation. KEY WORDS OSGi, Home-gateway, Embedded System, Camera 1. Introduction In recent years there is a trend towards digital home networks because of both the popularization of the Internet and the spread of PCs and a variety of electronic consumer products. Therefore interaction among various information appliances (IA) and various devices of different specifications is needed. The lack of interconnection among information appliances reduces the convenience of operation for the user. For the digital family of the future, we hope that information appliances with their highly communicable and compatible characteristics will be a very important factor in the integration of home networks. Multimedia home applications, remote-imaged monitoring and digital information appliance integration are the goal of a typical. Founded in March 1999, OSGi (Open Service Gateway Initiative) is an alliance of several network service manufacturers. The purpose of OSGi technology is to offer complete point-to-point service delivery to local devices and also to provide service to remote devices. The OSGi Alliance specifies, creates, develops and promotes the wide use of an open service delivery and management platform. If a service provider designs a required bundle according to OSGi specifications, the user can download the required bundle to the target device, and it will be installed dynamically for further use [1]. A home gateway provides the link to WAN and LAN. As the key device linking service provider and home network devices, it is the medium for their communication with each other. For the a great deal of research has been carried out to improve the performance of existing technology. Much of this has focused on protocol developed for home networks [2, 3]. In this paper we focus on the design of a suitable upper level protocol. However, we do not probe into the numerous transmission specifications of the physical layer. Service lookup and discovery are our chief objectives. We choose OSGi to build home network technology [4-6]. Some other designers have also used this technology to develop an embedded. Table I shows differences between the OSGi techniques and others. The advantage of OSGi is independence from both the OS and the hardware platform. Further, by using OSGi we can integrate other techniques to reach the connectible devices in a home network. For these reasons we select OSGi to design and implement the embedded. Table I. Comparison of the shared service techniques in a home network Name Jini HAVi OSGi Transferred fundamental Provides services Applicable range Limitation JVM Discovery lookup Simple data exchange JVM effect performance IEEE1394 High speed Multimedia information Limited distance Based on current techniques Integrates/Manages Jini, UPnP and other services Data exchange and multimedia None (high compatibility)

2 In Section 2 of this paper, we provide a architecture of a home network. Section 3 shows the software and hardware design of our embedded system. Section 4 provides the implementation results of our embedded. Section 5 compares the performance of an embedded and a PC from the point of view of the user and the platform. Section 6 draws the conclusions from the remote monitor embedded. 2. Home network architecture Fig.1 shows the home network architecture in which the integrates the existing information appliances at the home. For 24-hour operation of a home network we must consider not only good performance but also low power consumption. Hence the embedded system is one of the choices for the. To enable our selection to follow the specifications of other manufacturers of developers, the embedded home gateway currently adopts the OSGi 3.0 specifications to set up a bundle server and develop a camera bundle. In addition we use the SMF (Service Management Framework) bundle developer kit which is hung outside in the WebSphere Studio Device Developer [7, 8]. very important advantage, especially since the embedded system has a limited memory. To provide easy operation of the embedded system for the user, we use the highly popular Windows CE.NET which has a friendly interface. The platform tool which sets up the OS is platform builder 4.2 [9]. Utilizing this tool we set up the customized embedded OS, which is comparatively simple. After installing SMF runtime on the embedded, we install a bundle according to the bundle s life cycle. In OSGi all services are bundled, and they import or export services to each other. By using this characteristic we develop a required bundle through the module design. Because OSGi has provided many standard interfaces, we import existing services to the bundle we are developing. The method is very effective; our bundle can also provide services to other developers. Fig. 2 shows the bundle register which provides service to the service registry via the OSGi framework. Other bundles can also get supporting services from the service registry to install other exporting services to the framework. Because the service registry is a connectible bridge, all bundles are not only service providers but also service users [4]. Install, start, stop, resolve, active, uninstall OSGi service framework Register Bundle A Service registry Service Get Get Bundle B Bundle C Register Java Virtual Machine Platform (OS and hardware) Fig. 2 Bundle collaboration through the service registry 3. The Hardware and Software Design of the Embedded Home-gateway System Fig.1 Home network architecture In the OSGi structure the device must have OSGi runtime so that we can download a specific bundle that we need to install. As OSGi is based on Java, it must be running on the Java Virtual Machine (JVM). The OSGi alliance defines a bundle as developed services or software based on OSGi specifications. A bundle is used for a jar (Java Archive) file that we write. A java file including all classes and resources is usually a single class-path. Under the management of OSGi all bundles are installed or uninstalled dynamically; moreover, they provide a supporting package of services for each other. The more effective method is to dispose of a number of Java files, so that we can reduce the memory space to start the JVM repeatedly. Reducing waste of memory space provides a (A) Software Design The API (Application Program Interface) of OSGi can be implemented on different OS and hardware platforms with the features of a cross-platform. In a traditional factory A provides service that is not necessarily applicable to products of factory B. However, services transmitted need not be used by the other factory, which means more convenience and advantages as follows [1]. (1) Co-existence with other standards OSGi is compatible with many protocols and provides the connection between both the local area network and the wide area network. (2) Platform-independent OSGi provides API that can be implemented on each kind of hardware platform and OS, and our satisfies that condition. (3) Application-independent 64

3 Based on API of OSGi, developers can provide applications that are independent from platforms. (4) Multiple Services Using OSGi technology to develop a we can install different services in the that provide multiple services. (5) Multiple Local Network Technologies At present a typical home network already has many network specifications and standards of data transmission, like HAVi, Bluetooth, Lonworks and others; but as many of them have limitations and disadvantages, OSGi technology compensates for the limitations and disadvantages of these standards. (6) Multiple Device Access Technologies OSGi technology provides device access API which can be integrated with UPnP, Jini and other service functions used in OSGi specifications. (7) Security OSGi specifications integrate many system safety features based on device control access from download digital signatures. Table II illustrates the software architecture of the embedded. From among the OSGi bundle development tools we select the SMF Bundle Development Kit [7] which includes (1) SMF Runtime (2) SMF Bundle Server (3) SMF Bundle Developer Kit Table II. System software list of the embedded Software architecture Name Memory space Operating system Windows CE.NET 9.55MB Java Virtual Machine J9 VM for foundation profile MB OSGi technology SMF Runtime KB We use J9 VM which is the core of WebSphere Everyplace Micro Environment (WEME); it implements the VM by Java Virtual Machine Specification 1.3. WEME supports many OS, including Windows, Linux, PalmOS and Symbian, and it also supports most hardware platforms, including ARM, xscale, MIPS, SH4 and x86. Fig. 3 (a) shows the installation of J9 VM on a device. We load and start the OSGi runtime (SMF Runtime 3.7) on the embedded, which can be installed by the dynamic bundle we are developing. Fig. 3 (b) shows the bundles that export our services to support and start the camera bundle. SMF runtime shows that this service has registered in the service registry, and that the camera bundle is really working on that time. We need to load SMF files into the root directory of the device as below: smf.jar: Provides the implementation classes for the OSGi specifications smfconsole.jar: Provides a command-line management smf.properties: Specifies the runtime configuration Loading OSGi Runtime (a) (b) Fig. 3 (a) Loading OSGi Runtime (b) Registering our Camera Bundle Fig. 4 illustrates the system block diagram of the homegateway from which we learn the operation functions of each part of the embedded system. From bottom to top, the embedded development board, device driver, embedded OS (Windows CE.NET) and J9 VM are all used for construction on the OS. J9 VM is a customized virtual machine. To fit the embedded platform we link the upper level to the lower level and start the SMF runtime. On the platform we design the bundle according to OSGi specifications and install the required bundle dynamically. Packages exported by other bundles are used to support our developed Camera Bundle (here called the Mycam bundle). As the Mycam bundle is transmitted to the embedded, SMF runtime exports other supporting services at the same time. For example, the http-services bundle allows the user to view a camera image by means of a browser, and the servlet bundle provides the function of a Web-server on the target device. The user can use various kinds of smart devices, for example, PDA, NB or PC, to obtain the exporting services of the http-services bundle by means of a browser which connects with the Mycam bundle to receive the image information in the home. B R O W S E R Http service Mycam bundle Java runtime (IBM J9 VM) Embedded OS (WinCE.NET) Driver Driver Driver Device hardware (ARM 9) Launching Camera bundle Servlet SMF runtime Tracker Log service Fig. 4 System block diagram of the embedded 65

4 (B) Hardware Design We use the embedded development board to implement the. Table III illustrates the specifications of the embedded which has an ARM 920T kernel and a rich peripheral, which comprises a 10M Ethernet port, a USB host/device, two RS232, an EXI bus and an audio in/out. The system is managed by a customized OS and a 3.5 inch touch panel display to provide low power consumption and easy operation. Table III. Hardware specification of the embedded CPU ARM 920T 203 MHz Memory Cache NAND Flash 64 MB SDRAM 32 MB 2 Instruction 64 KB Data 64 KB (C) Software Operational Flowchart Figs. 5 and 6 show the operational flowchart of the embedded software. At Fig. 5, by means of the dynamic detection of the front end, the system adjusts to the greatest tolerance value. If there is an image that is rocked violently it will capture such image immediately and store it into the jpeg image. We note that time and date succeed at the same time in encapsulating the bundle further. At Fig. 6 we transmit the bundle to the embedded. Then we install the bundle on the bundle server and import other bundles that support each other at the same time. At this moment we can utilize various kinds of device connected to the embedded by means of a browser and see the monitoring image in the home from the remote site. In addition we obtain more information, such as time and date of the image. Even if we only have portable devices that can connect to the Internet, by using our design we can still see the monitoring image in the home from the remote site. In addition we can set a regular time to capture the image and thereby obtain more information in the home. The embedded system has shown a stable and low-power operation, so this design is suitable for the. B Download and install bundle Show home-state Select device Camera 1 Camera 2 Camera 3 Show Camera 1 state Show Camera 2 state Show Camera 3 state Fig. 6 Operational flowchart of the embedded 4. Implementation Results Capturing of the image by using our design method is shown in Fig. 7. On the right is the touch panel of the embedded. By using a pocket IE we see the capturing of the image by the camera bundle which has already been loaded into the bundle server. The middle part of Fig. 7 shows the image of the home state using a PDA. When we key in the IP of the embedded we get the monitoring image in the home. Wireless network card Showing home state by PDA Start A Dynamic detecting Record date and time Detect motion Save jpg image A Finish record Build a bundle Send home gateway B LAN port Showing home state on Fig. 7 System implementation of the embedded Fig. 8 shows the service interface of the camera bundle of our design. It includes choosing different cameras, selecting the date or time, and further detailed information. Fig. 5 Operational flowchart of capturing the camera bundle 66

5 Fig. 8 Home state user interface by browser 5. Performance Comparison Key in IP of Home state button Before measuring we have to arrange all devices and connect to a local area network. Because we use as our measuring tool the MicroAnalyzer tool by TCP/IP, the host connects to the target which includes a PC and an embedded. Fig. 9 shows that the host runs the remote MicroAnalyzer tool [8], that the target launches both the VM and the SMF runtime, and that thus we get the measurement information on the host immediately. Fig.10 shows that we need to set the parameters of the embedded. Using this parameter setting the target device starts the SMF runtime which connects to the embedded, the IP host and the proper port at the same time. When both host and target device have connected to each other we obtain the information about the target device immediately by tracing. // Run MicroAnalyzer to analyze target device -Xalwaysclassgc -analyze:ia=localhost,hp=4821,st=true,tt=tcp -Xalwaysclassgc: dynamic-class uninstall in starting GC -analyze: starting Microanalyzer parameter on the target ia: manage TCP/IP or host of the MicroAnayzer tool hp: host port port of the MicroAnalyzer tool listen data st: start machine tracing true or false tt: transmitted type UDP or TCP Fig. 10 Setting parameters of starting the target MicroAnalyzer Fig. 11 show MicroAnalyzer has started on the embedded which links to the measurement platform (Host) by the MicroAnalyzer tool on SMF runtime. When loading and installing the bundle we learn the operational state of the memory, the CPU time and the garbage collection time as shown in Table V. Starting MicroAnalyzer on SMF Runtime Fig. 9 Measuring environment for our embedded We use the MicroAnalyzer tool as the analytic tool of the embedded that we developed. By using this tool we can access the operational state of the memory on the target device and the CPU time used in loading the bundle dynamically. Table IV illustrates the library required by the in running the MicroAnalyzer tool. We install the library on the target device, and the MicroAnalyzer tool runs on SMF runtime. Table IV. Required library to start MicroAnalyzer on J9 VM File Illustration j9vmall22.dll All Core DLL Includes j9hook22 support to hang MicroAnalyzer lib j9prf22.dll Supports MicroAnalyzer on target Fig. 11 MicroAnalyzer installed on SMF Runtime When the user uses the services of the embedded homegateway he needs to wait for the service response times. Under the same environment we adopt the Webserver Stress Tool [10] to analyze and compare the service response times of two s. For gathering information we use this tool to measure the average response time for the s as shown in Table V. Table V illustrates that the VM maps out different sizes on different platforms. The embedded system has a limited memory space, so the VM maps out 8MB to install the bundle dynamically. 67

6 Table V. Performance comparison of different platforms running on SMF runtime CPU Time Range for Starting SMF Runtime Using MicroAnalyzer Tool Home-gateway (PC) Embedded 187 ms~343 ms 920 ms~1500 ms Average GC Time ms 0.02 ms Max Memory Space (VM scheme) For Dynamically Installed Camera Bundle 256 MB 8 MB MB 2.51 MB Using Webserver Stress Tool Home-gateway (PC) Embedded Service Response Time 11 ms 54 ms for User GC: Garbage Collection; VM: Virtual Machine In this paper all required bundles are installed in order to start the Camera bundle, which requires 2.51 MB of memory. Because the embedded has a limited memory, it usually also has garbage collection (GC) action. Table V also shows the average GC time of the embedded ; the system operates the garbage collection on the average every 0.02ms. With respect to starting the SMF runtime the embedded homegateway takes three times as long to start as the PC. Table V shows the comparison of the service response time between an embedded and a PC homegateway. Although our embedded has a longer service response time than a PC, sec of service response time is within the acceptable range for our embedded design. Our design not only has customized functions, but it also provides remote monitoring at low power consumption. Fig. 9 shows the setting for measuring of the power consumption. Table VI illustrates that our embedded can save more power, but that the functions of both the PC and the embedded system are close. Our design has lower power consumption and an acceptable service response time, therefore the embedded has definite advantages. Table VI. Power consumption of different platforms running on OSGi runtime Platform Home-gateway (PC) Embedded Clock 2 GHz 203 MHz OS (idle state) power W 3.6 W Running OSGi Runtime 144 W 4.8 W Cost USD $1000 USD $ Conclusion This paper presents a new, modern technology for designing an embedded which provides an application for remote monitoring. We design the embedded according to OSGi specifications which integrate many network protocols. Our design captures remote images which may be encapsulated in a camera bundle which is loaded on an embedded dynamically. We set up the external bundle server on the embedded. Then the user sees the image in the home through using a browser of the smart devices from a remote site. In this paper we also measure and compare the performance, power consumption and cost of the embedded homegateway and the PC. Besides lower power consumption our design, the embedded system, has most compatible specifications of the. In the future, as long as the service provider offers service bundles according to OSGi specifications which can be incorporated into the embedded, we will design more versatile applications. References [1] OSGi Alliance, [2] Takeshi Saito, Ichiro Tomoda, Yoshiaki Takabatake, Junko Arni and Keiichi Teramoto, Home gateway architecture and its implementation, IEEE Transactions on Consumer Electronics, vol. 46, issue 4, Nov. 2000, pp [3] Takeshi Saito, Ichiro Tomoda, Yoshiaki Takabatake, Keiichi Teramoto and Kensaku Fujimoto, Gateway technologies for home networks and their implementations, 2001 International Conference on Distributed Computing Systems Workshop, April 2001, pp [4] Choonhwa Lee, David Nordstedt, and Sumi Helal, Enabling Smart Spaces with OSGi, IEEE Pervasive Computing, vol. 2, issue 3, July-Sept. 2003, pp [5] Haitao Zhang, Fei-Yue Wang and Yunfeng Ai, An OSGi and agent based control system architecture for smart home, Proceeding of the Networking, Sensing and Control, March 2005, pp [6] Taein Hwang, Hojin Park, and Jin Wook Chung, Design and Implementation of the Home Service Delivery and Management System Based on OSGi Service Platform, ICCE, 2006 Digest of Technical Papers, Jan 2006, pp [7] IBM Service Management Framework, May 30, 2003, [8] Using WebSphere Studio Device Developer to Build Embedded Java Applications, April 2004, [9] Windows embedded about Windows CE, dowsce/default.mspx [10] Web server performance software, 68