We've been doing extensive refactoring of the proof of concept design from our Innovate UK feasibility study. The result is something we've decided to call an 'Internet of Things Micro-Platform'.
When we were developing the proof of concept design for our Innovate UK funded feasibility study into Extending the Internet of Sensors To Remote Locations we were focussed on demonstrating the technical viability of our ideas in a context of a specific use case. Since then, we have been looking at how the lessons learned during that process could be applied to a wider range of scenarios in the Internet of Things arena. This resulted in a significant refactoring of the original design in order to produce a more general purpose solution, which we have chosen to refer to as an Internet of Things Micro-Platform.
To the casual observer, the current Internet of Things landscape represents a vast impenetrable fog of acronyms, competing standards and press releases from various pay-to-play consortia. The main reason for the huge increase in complexity lies in the gold rush mentality which now pervades the Internet of Things space, with both highly funded startups and established IT vendors gambling that they will be crowned the 'Google of IoT'. However, once all the marketing jargon and technical obfuscation is stripped away, most of the platforms and protocols involved can be seen to be functionally equivalent. In short, most of the product differentiation is as a result of trying to achieve vendor lock-in rather than any fundamental difference in capability.
The ability to achieve vendor lock-in is of critical importance to companies which offer a subscription based Platform as a Service solution for IoT data aggregation and processing. This is the model which has been adopted by most of the blue-chip IT vendors which seek to drive early IoT adopters towards their cloud service offerings, so that they can extract recurring revenue in terms of per-device connection charges and data storage costs. An extension to this model acknowledges the scaling issues associated with using highly centralised cloud services by delegating some data pre-processing capabilities to edge nodes and network gateways - yielding what is now being marketed as Fog Computing.
The concept behind the Internet of Things Micro-Platform differs from this approach in that it seeks to be a self contained solution. It should deliver all the features associated with a typical cloud based IoT platform, but scaled down to run on devices as small as a Raspberry Pi single board computer. Interoperability with existing cloud based services can still be supported, but in this case it is an optional enhancement to the standalone functionality.
We have already released some of the support libraries which form the foundations of our IoT Micro-Platform. In particular, the 'Stash' persistent data store is designed for holding conventional key-value pairs as well as acting as a basic time series data store. The default implementation uses a simple file system based backend, but the API is designed to allow any suitable NoSQL database to be used when required. The purpose of the remaining components shown in the following diagram is to provide a mechanism for storing and retrieving IoT data, as well as managing data access permissions for a number of different clients.
One of the biggest challenges with any new IoT project comes from selecting between the many different data transfer protocols that are currently being advocated. Given the uncertainty over which protocols will eventually become the de-facto standards, we took the pragmatic approach of supporting any or all of them. This is only possible because all the mainstream protocols being proposed correspond to one of three basic data transport patterns - these being the commonly used RESTful API conventions, publish/subscribe messaging or simple dataflow model. The implication is that any system which is designed to support these three basic patterns should be able to interoperate with the majority of the proposed IoT data transfer protocols. In the case of the IoT Micro-Platform, this can be achieved by implementing a range of plug-in protocol layer adaptors.
As a legacy of the original proof of concept design, we are currently focussed on implementing support for protocols that use the common RESTful API conventions. The protocols of most interest are those based on IETF standards, such as HTTPS and the Constrained Application Protocol (CoAP) - with the CoAP stack being designed to run over arbitrary datagram based link layers. The IoT Micro-Platform architecture does not place any restrictions on the design of the RESTful APIs, since these are implemented using a set of plug-in resource handlers that can be optimised to specific IoT application domains. An access control mechanism based on bearer tokens is used to determine client access permissions for the various resource handlers. Multiple access managers may be created in order to provide a set of fine-grained access control groups to which the various resource handlers can be assigned.
The existing IoT Micro-Platform code is intended to provide the core functionality that can be used to create customised IoT Micro-Platform configurations for different IoT application domains. The core platform code will be released as a set of open source OSGi modules which can then be augmented with both open source or proprietary plug-in modules to create application specific solutions. For example, these enhancements may come in the form of custom protocol layers, enhanced authentication support, data analysis modules and cloud service interoperability plug-ins.
Development of the IoT Micro-Platform core functionality is already well advanced, and we expect to be providing a beta release in the near future. In the meantime, some early examples demonstrating its use may be found in the 'blue sky projects' part of the website. As always, the best way to stay informed about further developments is to keep an eye on our Twitter feed which can be found here: @Zynaptic.