days
0
3
hours
1
3
minutes
3
1
seconds
3
9
search
IoT: Lots of opportunities for innovative applications

Building the Internet of Things with OSGi

Tim Verbelen
IoT image via Shutterstock.

In a world where billions of devices are being connected to the Internet, the Internet of Things (IoT) becomes an increasingly important domain. IoT offers a lot of opportunities for new and innovative applications, for example turning your home into a smart home, or turning cities into smart cities, by intelligently connecting sensor input data to various actuators.

However, with the multitude of available IoT platforms, device management protocols, wireless communication protocols, etc. it becomes hard to see the forest for the trees. In this article we will illustrate how OSGi can help us build the next generation of IoT applications.

Building the Internet of Things with OSGi

The Internet of Things (IoT) will have a huge impact on the way we live and work. As billions of devices are connected to the Internet, a myriad of new and innovative applications become possible. By intelligently processing sensor inputs and turning these into proper actuation, things can become truly ‘smart’, taking autonomous decisions based on their context and their users.

However, developing such IoT applications is challenging at best. With the emergence of a multitude of (wireless) device connectivity protocols, it becomes hard to support the wide range of devices on the market. As a developer, you will have to cope with, and adapt to, the ever changing physical world, where new devices come online while others disappear at runtime. Also, (parts of) your software will have to run on a wide variety of devices, ranging from embedded devices up to high-end servers in the Cloud.

Within the iMinds IoT lab, we are conducting research on a wide variety of IoT related topics, ranging from antenna design and wireless MAC protocols, to software security and distributed computing. In this article, we give an insight on how we benefit from OSGi in developing our proof of concept demonstrators, tackling many of the aforementioned challenges.

The power of OSGi

The OSGi specification describes a dynamic module system and service platform for Java. Originally, OSGi was designed as a service gateway platform, exploiting bundle modularity to allow the framework to run on a variety of devices, enabling to switch service implementation based on the hardware capabilities. Today, this actually makes OSGi well suited to power an IoT gateway, for example as used in the Eclipse Kura project.

More recently, the OSGi Alliance also released enterprise specifications, adding a lot of features to operate in a server environment. This makes OSGi a solid foundation for building an IoT platform, allowing you to deploy bundles on a wide range of devices ranging from embedded devices up to high-end servers in the Cloud. Moreover, the Remote Services specification, that allows you to transparently call an OSGi service on a remote device, hides distributed applications’ complexity from developers.

Thing as a Service

One of the biggest challenges in IoT application development is addressing the huge amount of different devices, the different APIs and protocols to interact with them, and dealing with their lifecycle, as devices can come online or disappear at runtime. In fact, the OSGi service model offers an elegant and easy way to use solution. By abstracting each thing as an OSGi service interface, the device-specific access protocol is implemented by an adapter bundle, and the IoT application only has to deal with the higher level abstraction. The dynamics of things coming online or going offline is transparently handled by the OSGi service lifecycle.

Figure 1: By abstracting away a physical lamp behind an OSGi lamp service interface, the device-specific access protocols are hidden to the developer, and the lifecycle is managed by OSGi.

Figure 1: By abstracting away a physical lamp behind an OSGi lamp service interface, the device-specific access protocols are hidden to the developer, and the lifecycle is managed by OSGi.

For example in Figure 1, the physical lamp is abstracted by a lamp service that is used by the IoT application bundle. The actual lamp could talk REST, CoAP, ZigBee, or even a manufacturer specific protocol. As long as there is an adapter bundle available, the IoT application should be able to interact with the lamp. Of course this approach stands or falls with the availability of device interfaces and device adapters. Currently various standardization efforts are ongoing for specifying device interfaces such as OneM2M, and also various Eclipse projects are active in this area. For example the Eclipse Vorto project aims at creating abstract device descriptions, while the Eclipse SmartHome specifies things in the smart home domain.

Besides using services that give you access to query a device, a lot of things also communicate by sending out events. For example, the event-centric MQTT protocol is often used in IoT applications, allowing to connect arduino-based devices to the Internet. OSGi already has eventing APIs specified via the EventAdmin service. Again, this service can be used to abstract away any IoT eventing protocol.

Figure 2: By using the EventAdmin service, an IoT application bundle can be totally agnostic about the underlying eventing protocol.

Figure 2: By using the EventAdmin service, an IoT application bundle can be totally agnostic about the underlying eventing protocol.

As shown in Figure 2, by using the EventAdmin service the application does not need to know about the underlying eventing protocol. This allows you to easily change the event protocol when required, or support multiple event protocols in your application. It also enables the integration of your OSGi application with devices that only speak this event protocol to the outside world.

OSGi made easy with enRoute

One of the commonly heard excuses not to use OSGi is that OSGi development is hard. Early adopters of OSGi might remember having to flounder with manifest headers and having to deal with NoClassDefFoundErrors. Since then a lot changed, and nowadays nice IDE tooling is available with bnd and Bndtools. The OSGi enRoute project aims to lower the barrier to adoption even further by providing an end to end toolchain that supports the OSGi programming model.

Besides IDE tooling, OSGi enRoute also provides project templates, tutorials, and a common set of services and utilities to facilitate OSGi application development. Among other things various bundles are provided for simplifying web development, allowing you to easily communicate with OSGi services via REST or JSONRPC, as well as IoT-related utility bundles for accessing hardware resources such as GPIO pins on a Raspberry Pi.

Case study: a smart home dashboard

In order to illustrate the outlined approach, we have developed a small OSGi application that manages things in a smart home environment. The application provides a web based GUI that shows a dashboard of all your things and their status, as shown on Figure 3. The user can also configure simple rules to connect these things, for example „toggle the lamp when button is pressed“ or „turn on the camera when motion is detected“.

Figure 3: A web based dashboard showing all discovered things in the environment and their state.

Figure 3: A web based dashboard showing all discovered things in the environment and their state.

The application components are outlined in Figure 4. The core of the application is the Things Repository. Here, all discovered things are saved, together with a human readable name and location that can be set through the GUI. The Rule Engine can also be configured through the GUI, it listens for ‘thing events’ and in case a rule is triggered, actions are executed by calling the corresponding thing service. All these components receive ‘thing events’ via the EventAdmin.

Figure 4: Application components call things via the abstracted thing services, and receive thing events via the EventAdmin. DYAMAND and AIOLOS are used to respectively implement device-specific access protocols and distribute components among a gateway and server device.

Figure 4: Application components call things via the abstracted thing services, and receive thing events via the EventAdmin. DYAMAND and AIOLOS are used to respectively implement device-specific access protocols and distribute components among a gateway and server device.

In order to communicate with actual things and to be able to distribute application components on a gateway and a server, we use two more projects that are developed within iMinds:

  • DYAMAND: This platform provides a device abstraction layer connecting to a wide variety of devices, supporting various protocols such as EnOcean, Z-Wave, UPnP, etc. The core design principle of DYAMAND is zero-conf, as we try to automatically discover and configure devices as much as possible, without requiring human intervention. We have developed a DYAMAND adapter that exposes these devices as OSGi services to be used in our application. In this example, only EnOcean and Philips Hue devices are supported.
  • AIOLOS : The AIOLOS platform allows to transparently distribute OSGi bundles on multiple devices by leveraging the OSGi Remote Services specification. AIOLOS also acts as our event adapter, being able to distribute the events using either remote method calls or by using MQTT.

Both frameworks are actually composed of multiple bundles, but for simplicity these are shown as a single entity on the figure. Of course you can also run all components on a single device, for example your gateway, in which case the AIOLOS bundles can be omitted. You could also develop your own thing adapters to use other devices besides the ones discovered by DYAMAND.

The application bundles are developed using OSGi enRoute. This implies that the project uses the latest OSGi R6 specifications. Especially for the GUI bundle we benefited from OSGi enRoute which facilitates creating REST and JSONRPC endpoints and allows you to listen to OSGi events in the browser using Server Sent Events. For those interested the source code is available on github.

Conclusion

In order to create a sustainable IoT application it is of prime importance to tackle the proliferation of device access and discovery protocols, and handle the dynamics of the real world. We have shown that OSGi offers great value in this space allowing you to abstract away device specific protocols and helping you manage the device lifecycle.

Of course there are still some challenges remaining. For example how should these thing interfaces look like to be truly interoperable? How to guarantee end-to-end security in these applications? Therefore, the OSGi Alliance has recently started an IoT Expert Group where additional IoT-specific RFPs can be submitted to help tackle these challenges.

Author

Tim Verbelen

Tim Verbelen is a Research Engineer at the iMinds IoT Lab, working on middleware for distributed intelligence supporting the next generation of IoT applications. Tim is an Eclipse committer contributing to the Concierge project, and is also active as Invited Researcher of the OSGi Alliance.


Comments
comments powered by Disqus