Standards: smart home using OSGi

Read here part one of Kai Hackbarth’s introduction to smart home standards

I work for ProSyst Software, where we have been working on the development of smart home solutions for many years now. Lots of companies take our products as a basis for developing their own solutions. In my opinion, one of the most important reasons for that is that our products are based on industry standards. In this post I want to talk a little about some of the most important standards and their importance.

HGI Open Platform 2.0

HGI (formerly the Home Gateway Initiative) is a standardization organization founded in 2004 by a multitude of telecommunication companies and device manufacturers (particularly of routers and home gateways). Revenues from telephony and internet services are shrinking, which is why many telecommunications companies in particular are looking into the development of smart home systems. As a result, HGI got involved early on and defines aspects such as the requirements for an open and modular software architecture for smart home gateways. These requirements are brought together in the publicly accessible HGI Open Platform 2.0 document. This document details generic, platform-independent requirements relating to reliability, security, lifecycle management, installation, uninstallation, and remote management. It also defines OSGi-specific conditions: requirements for the JRE, the OSGi specification the framework used must follow, the standardized OSGi services that must be employed, and how they ought to be configured. Once a year this is accompanied by test events, in which test cases reflecting the defined requirements have to be run on a home gateway or router. So far, no other platform apart from OSGi has been tested.

HGI is also currently working on a smart device template (SDT) that is to serve as the basis for describing device profiles consistently throughout the industry. This work is being undertaken in collaboration with many other standardization bodies, including the OSGi Alliance.

OSGi specifications relevant to the smart home

A lot has been written in description of the principles of OSGi technology, so I would like to focus here on the work of the Residential Expert Group, which focuses its efforts on specifications for the smart home. Perhaps the most important specification at the moment is the Device Abstraction Layer (RFC 196), which will be released with the upcoming specification in the summer. The goal of the Device Abstraction Layer is to make every possible device accessible within the OSGi environment via one single standardized interface, no matter the communication protocol employed. This also covers access control based on user and application permissions. What’s more, the solution benefits from the existing flexibility of the OSGi security model.

In addition to all that, the Device Abstraction Layer also supplies notification mechanisms that can be used to monitor the status of devices, the data model, and operations. It solves the general problems faced by developers of smart home services; developers need only program with a view to a single interface and don’t have to deal with protocol-specific problems and details. There’s no longer a need for stop-gap solutions to handle these sorts of problems or for developers to build their own proprietary abstraction layers. Taken together with the device profiles based on the smart device template, the OSGi Alliance’s specified Device Abstraction Layer is a vital component for developing open and economically sustainable smart home systems.

The upcoming OSGi residential specification contains a lot of other extremely useful services, including a standardized interface for automatically detecting and managing EnOcean devices (RFC 199). Another recurring problem is recognizing equipment such as USB dongles for connecting smart home devices. This has been solved with the help of the Serial Device Service (RFC 213) for the standardized connection of serial interfaces as well as the USB Information Device Category (RFC 202) for defining missing device categories. The Residential Expert Group has also been working on a specification to monitor resource usage (RFC 200). The Network Interface Information Service defines currently missing functions in the world of Java for monitoring changes in the network interface during run time, for instance changes in the IP address.

A reference architecture based on standards

The graphic below shows how a standards-based reference architecture might look. Of course, this is an extremely simplified diagram, but it does describe other key components that we consider vital to developing a smart home ecosystem that is open, expandable, and attractive to the developer community. The core of the system is of course the home gateway, based on OSGi and in accordance with the guidelines of the HGI Open Platform 2.0. In addition to that, further components are required to allow the user to interact with the smart home via TV, tablet, or smartphone.

A standards-based reference architecture:

Neues Bild (7)

The backend can be as complex as you like. Above all, a remote management system is a must here, so that users can install new applications and update/uninstall existing ones. Attention must also be paid to the use of industry-wide standards such as TR-069 (CPE WAN Management Protocol) and TR-157 (Component Object for CWMP) from the Broadband Forum. The remote management system usually assumes responsibility for a whole range of other functions as well, for instance data synchronization and tech support. Of course it’s not enough on its own; in bigger systems you also need to integrate it with other backend services, e.g. an app store and OSS/BSS infrastructure. A development and test environment is also a must in order to build up the biggest developer community possible.

Open source vs. commercial software

I’m well aware that many of you reading this will probably be coming from an open source background. Still, I think it’s well worth comparing the open source and commercial software routes with regard to the OSGi framework. In the past, a good number of our customers started off by going down the open source route. For a variety of reasons, these companies ended up coming to us in the course of development to license our smart home gateway software. It’s true that open source solutions come free of license fees – but that doesn’t mean they’re cost-free. Very often, you need to implement missing functionalities. Many open source OSGi solutions are not optimized for use in embedded systems. There can also be legal problems implementing open source solutions, particularly when these draw on various licenses. Lots of our customers want somebody who will take responsibility for maintenance and ongoing development. As a user of open source solutions, you may not get much say in the future direction of open source projects. When you add it all together, using open source software can end up being more expensive than licensing a ready-made solution.

I’m not looking to demonize open source solutions as fundamentally bad or wrong, but you should be adequately informed before you decide to take either the open source or commercial software route.


Most people have no doubt heard of OSGi, although probably in a different context. In 1999, OSGi launched into working toward its original goal of developing Java-based specifications for the connected home. Since then, OSGi has found a high level of acceptance in many other areas. Even though there were OSGi-based smart home solutions even back then, it is only in the past two to three years that OSGi has really established itself. That doesn’t necessarily depend on just the technology itself, but also the fact that the smart home market is only just getting going. In spite of its broad spectrum of development work and superiority over other technologies, OSGi naturally still has some problems to be solved. In the SmartLive project sponsored by the German Federal Ministry for Economic Affairs and Energy, ProSyst Software is working together with the University of Siegen, devolo, the peak lab., and the ASEW (a working group for economical energy and water supply for public utilities) to find solutions to some of these problems. The ultimate aim of the project is to provide a framework for a “living lab as a service.” It’s hoped that the living lab will help small and medium-sized enterprises in particular to develop smart home solutions without having to invest in their own living lab infrastructure. The project is also addressing the ergonomic guidelines for designing user interfaces and seeking to simplify collaboration between developers and design agencies.

Please join us in the effort of defining new IoT relevant requirements and specifications in the coming IoT Expert Group. More information about IoT EG can be found at the OSGi Alliance website.


The full article was initially published in German on


About the author

Kai Hackbarth

Kai Hackbarth

I joined ProSyst in 2001. Since then, I have been deeply involved in the technical standardization activities of the OSGi Alliance. I have been co-chairing the OSGi Residential Expert Group since 2008 and actively participating in many major national and international research programs in various IoT domains to coordinate all our research project activities. My key areas are smart homes, automotive, and the Internet of Things in general, where I actively support the current developments and strategic positioning of ProSyst's product portfolio.