IoT/IoTServerPlatform

Introduction

At EclipseCon NA 2015 a number of IoT WG members meet to discuss the definition of an open source IoT Server Platform. The general view was that a lot of the open source technology has been focused on the devices and edge but not the server and enterprise middleware. The long-term goal of this discussion would be to determine what open source technology need to be created to support an open source IoT server platform.

Out of this meeting, the main feature/components of an IoT Server platform would include:

• Communication/Protocol adapters
• Device Management
• Data storage (in raw form)
• Event Management/Rules Engine/BPM
• User Management/Identity/Security
• API

The next steps for this discussion needs to be to

1. add detail to each feature/component,
2. map how this integrates and extends the existing open source middleware that exists in many server solutions, and
3. map this to cloud computing solutions.

Context

Following the Arc42 approach, we start with some simple context views to illustrate the surrounding actors and components an IoT server platform needs to deal with.

Business Context

The diagram shows how multiple (potentially millions) Devices are connected to the Iot Server Platform. The devices upload (sensor) data to the back end while the functions/services they expose can be invoked from the back end.

Business Applications use the Iot Sever Platform as a proxy for accessing the devices' data and functionality. Applications can subscribe to particular events like notifications about data changes or device life-cycle events. This way the applications do not need to deal with the technical and semantical specifics of the devices and their particular data models and communication protocols. Both of these aspects are abstracted away by the IoT Server Platform.

The data gathered from the devices can (optionally) be persisted in third party Data Stores. Arbitrary persistence strategies are possible, e.g. flat file, relational database, document store etc. The IoT Server Platform does not provide any means to store data out-of-the-box because it is expected that Business Applications will usually implement a their own, domain specific persistence layer anyways.

The IoT Server Platform uses an Identity Provider to authenticate incoming requests from Business Applications. (Note: The Identity Provider should probably also be used to get a user's authorities as well).

Technical Context

TBD

Building Blocks

The top level building block view provides a white box view of the overall IoT server platform. All of its components are shown as black boxes only, i.e. at this level their internal structure is not relevant (yet) but instead the focus lies on responsibilities and relationships. If necessary, the internal structure of each of the components (the white box view) can be documented in subsequent sections, thus forming an alternating row of black box/white box views providing a drill down into the inner workings of the system.

Current Draft Building Block View

The draft diagram below provides an overview of the (logical) components of the IoT Server Platform. As a main difference to the previous building blocks view, the former IoT Hub has been renamed to IoT Connector while at the same time its relevance for the overall architecture has been stressed out by placing it at the very center of the system, serving as the central messaging infrastructure for connecting all of the other components with each other. Please note that the implementation of the Iot Connector is not subject of the current discussion. Instead, the focus currently should be on the IoT Connector's role, purpose and responsibilities. It might very well turn out that we end up with multiple implementations for the IoT Connector's exposed interfaces, specifically targeted at the requirements of the use case at hand, e.g. we might want to have a lightweight implementation for use cases where only a limited number of devices will be connected and only a moderate number of messages need to be exchanged whereas we would also want to have a horizontally scalable implementation targeted at cloud scenarios as well.

Previous Draft Building Block View

Blackbox LWM2M Connector

Purpose	Provides transparent access to LWM2M based devices. Maps data structures exchanged with LWM2M devices (based on LWM2M Object definitions) to/from Vorto Information Model instances. Serves as a gateway to data and services provided by connected devices for Business Applications.
Provided Interfaces	LWM2M Server (as defined by the LWM2M spec) LWM2M Bootstrap Server (as defined by the LWM2M spec) Device Access
Required Interfaces	InfoModel Repository Event Consumer (for notifying subscribers)
Quality Attributes	Supports horizontal scale-out

Blackbox Event Hub

Purpose	Provides means for Business Applications to subscribe to data from devices and thus getting notified about events produced by devices De-couples data producers (Devices) from data consumers (e.g. Business Applications)
Provided Interfaces	Subscription Management Event Consumer (for receiving notifications from Protocol Adaptors)
Required Interfaces	Event Consumer (representing the event consumers, e.g. Business Applications or the Device Management component)
Quality Attributes	Data from Devices is only forwarded to authorized consumers High throughput Support for dozens (hundreds?) of parallel consumers Scales out horizontally

Black Box Device Management

Purpose	Provides uniform access to data and services of all types of devices regardless of communication protocol and location Keeps a registry of all device meta-data like manufacturer, model, serial number, location, Information Model etc.
Provided Interfaces	Device Access Device Administration Event Consumer (for receiving notifications from devices) Access Control
Required Interfaces	InfoModel Repository Identity Provider (for authenticating and authorizing requests) Device Access (for accessing a Device's data and services)
Quality Attributes	Enforces device data privacy

Communication/Protocol adapters

• Which protocols should be supported?
• Authentication? authorization?
• Encryption?

white box view (TBD)

Event Hub

white box view (TBD)

Device Management

• Which protocols should be supported?
• Provisioning
• Bootstrapping

white box view (TBD)

Data storage (in raw form)

• Pure key-value store vs. time-series database?
• What querying capabilities are needed?

white box view (TBD)

Event Hub

• TBD

white box view (TBD)

Identity Provider

• TBD

white box view (TBD)

External Interfaces

• Existing (standard) APIs to leverage?

Meetings

The IoT Working Group members will be having regular meetings to discuss the requirements and action items to establish an open source IoT server platform. Participation to these meetings is for Working Group members only, but minutes are public.

Relevant Technology Components

• Communication, Device Management, API
  • ECF's implementation of OSGi Remote Services.
    • As demonstrated by commercial adoption/usage of Remote Services, by OSGi Alliance efforts in IoT and by various tutorials, Open implementations of OSGi standards are already being heavily used in both server development and in IoT.
      • Communication - ECF's RS impl protocol-independence is ideal for dealing with a heterogeneous IoT networking/communication/integration environment. Further ECF's impl already has MQTT/Paho-based and websockets-based Remote Service providers and we or others can easily add others based upon other IoT protocols.
      • Device Management - Remote Services provides a standardized, open, elegant, and simple solution (persistence is another orthogonal aspect to device management).
      • API - The use of OSGi Services and Remote Services provides an open, elegant, time-and-use-tested, dynamic, version-enabled approach to IoT API definition.