Building a smart home IoT with OSGi

In the past two to three years, OSGi has gone from being an outdated Java-based connected home specification to a mainstream IoT technology. Here we take a look at the myriad of IoT standards and the most successful examples of OSGi IoT implementations.

Smart home solutions have been on the market for a few years now – and yet, for a variety of reasons, have never found mass acceptance. Many of the solutions have been simply too expensive, or not yet reached full maturity. Over the last few years, industries have made considerable efforts to develop new, cheaper technologies and to keep on improving existing solutions, including numerous communications protocols such as ZigBee, Z-Wave and EnOcean. Thanks to all the hype surrounding the Internet of Things over the past two years, the smart home has also achieved much greater visibility among the general public.

By now, the smart home has established itself as one of the leading markets in the Internet of Things, as a variety of studies indicate, including those by Berg Insight and BITKOM. Berg Insight expects that by 2017, there will be 17.4 million smart home systems installed in European homes, bringing in projected sales of 2.6 billion euros. And according to the BITKOM Connected Home Working Group, by 2020 there could be as many as 1.5 million smart home households in Germany.

Google’s acquisition of Nest and Apple’s announcement of its HomeKit, accompanied by investments from an array of other companies, go to show that the time of the smart home is here at last. Hardly a week goes by without us hearing of new product announcements or new projects on crowdfunding platforms such as Kickstarter or Indiegogo.

A good number of these crowdfunding projects have developed into commercially available products, such as LIFX’s LED lamp or smart home systems by SmartThings, Revolv and Canary. You can get an idea of the complexity of this ecosystem and the related areas by taking a look at an overview of the IoT landscape created by Matt Turck and Sutian Dong (figure 1).

Figure 1: IoT landscape (created by Matt Turck and Sutian Dong)

As positive as this all sounds, many of these products are unfortunately proprietary, designed for one specific task, or have very limited functionality. In many cases, the use of standards is limited to specific communications protocols. Even that does little to help the user, since expanding the system incl. software updates are under the control of the specific manufacturer. User interfaces almost always require a specific iOS or Android app. In the worst-case scenario, devices are connected without a central gateway, which means that users must turn to an array of different apps to be able to operate their various devices.

Many providers of smart home systems are now trying to build up their own ecosystem around their products; but because of the issues mentioned above, they are rarely successful. The success of these solutions does not rely entirely on the size of the company. In the past, a range of companies, including Google, have embarked on testing only to see their efforts come to nothing.

Important preliminary considerations

Lots of small and medium-sized enterprises, as well as start-ups, are now paying increasing attention to the development of smart home systems or equipment. This is a desired development by governments in Germany and Europe as a whole. But because development costs can be so high, it is particularly important for these companies to reflect on some important preliminary considerations before they begin with the actual development work.

In the past, a whole host of companies spent a lot of time trying to find the killer smart home app. I thought from the start that this was the wrong approach to take, as it blocked investment; none of them found the single killer app and they were left without a functioning business model. Economically sustainable smart home systems really do rely on creating an application ecosystem to allow for the largest developer community possible.

The jungle of standards and technologies is another factor that makes it harder for companies to drive their own developments forward. This is particularly true when it comes to connecting devices in the smart home, where there is still an increasing myriad of applicable standards, including technologies such as Bluetooth, EnOcean, ZigBee and Z-Wave.

I’ll now go on to explain how you can get the situation under control by using the guidelines set out in the HGI Open Platform 2.0 and by applying OSGi specifications. Of course, let’s not forget that the smart home is just the beginning. The Internet of Things allows for a whole range of other scenarios involving the smart home (e.g. smart cities), as well as many others in which smart home developments might be reused after a few modifications.

ProSyst Software GmbH has been working to develop 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. We’re now going to take a look at some of the most important standards and their importance.

HGI Open Platform 2.0

HGI (formerly the Home Gateway Initiative) is a standardisation organisation 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. We’ll go into some examples of that later in the article. 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 standardisation bodies, including the OSGi Alliance.

OSGi specifications relevant to the smart home

The principles of OSGi technology have been well documented, both in this magazine and elsewhere, so we will 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 standardised 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 standardised interface for automatically detecting and managing EnOcean devices (RFC 199). Another recurring problem is recognising 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 standardised 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 runtime, for instance changes in the IP address.

A reference architecture based on standards

Figure 2 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.

Figure 2: A standards-based reference architecture

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 synchronisation 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 mBS smart home 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 optimised 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 demonise 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.

Successful examples

When it comes to solutions for the smart home based on OSGi, there is no shortage of successful examples. Companies such as Cisco, devolo, Eaton, Miele and Schneider Electric have been using OSGi for many years in some cases. Here we focus on just two examples from the telecommunications sector.

Deutsche Telekom QIVICON

An alliance originally founded by Deutsche Telekom, QIVICON boasts a growing number of partners. The B2B solution allows its partners to make use of existing hardware and software products so that they can bring their own smart home products to market. It includes a home gateway with ProSyst’s OSGi framework, an SDK for the developer community, a portal complete with shop, a highly complex backend, as well as maintenance and support.

QIVICON partners include companies such as EnBW, eQ-3, Miele, Samsung and the German power generator Vattenfall. Smart home products made by Deutsche Telekom as well as by EnBW and Vattenfall already employ the QIVICON platform. QIVICON is also soon to be marketed in other countries.

AT&T Digital Life

AT&T Digital Life is an extremely successful product in the United States, and has been available since May of last year. It differs from QIVICON in that it targets the end customer directly. Again, an OSGi-based gateway is at the heart of the solution. AT&T offers a variety of packages, including some for security and energy consumption.

The customer pays a one‑time fee for the equipment and a monthly fee for the service. Each package comes with its own software configuration, and packages can be freely combined to avoid the need for multiple home gateways to make use of the various services. AT&T also offers Digital Life to other telecommunications providers, and Telefonica is currently field testing the solution in Spain.

Roundup

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.