Saturday, October 19, 2013

A Modular Open Source Platform for Web Scale IoT Interoperability

A Modular Open Source Platform for Web Scale IoT Interoperability

Michael J Koster
October 19th, 2013

Interoperability for the Internet of Things

Previous articles in this series discussed architectures and approaches to provide meaningful interoperability. Protocol interoperability allows any application to interact with any connected thing using any M2M protocol.

Interoperability also provides for reuse of software components, allowing a common platform and tool set across diverse use cases. It should be easy to integrate data and things from diverse sources into a single application. Diverse UI platforms and new UI/UX models should be enabled to be easily integrated into systems.

Figure 1 shows how a platform for interoperability would allow applications to discover and connect to diverse things using a choice of M2M protocols.

Figure 1 - Interoperability

Data models enable machine understanding independent of M2M protocols

Data models describe connected things to applications, driving discovery and linking,
and allow abstraction of M2M protocols. The effect is similar to the separation of the data plane from the control plane in software defined networking.

In figure 2, a Semantic Proxy provides a common representation of data models that originate in different catalogs and repositories. Because each application or resource endpoint is using a common data model, any M2M protocol can be used to update the sensor or thing data. The common data model describes enough about the endpoints to allow abstraction of the transport mechanism.

Figure 2 - Data Models enable M2M abstractions enable M2M Interoperability

It should be noted that the semantic proxy consists of mainly agreed-upon bindings of relations (predicates) and attributes (objects) and representation formats that allow each application to conveniently use it’s favorite catalog and representation format while interoperating with others.

Open Source Software for IoT is becoming common

Recent developments in open source IoT components are starting to enable an ecosystem as well as a modular open source IoT software stack.

  • The Mosquitto MQTT broker and client are robust, full featured components.
  • Node-RED is a new visual programming tool for event-driven software composition.
  • CoAP stack software is available in several forms to integrate into different endpoints.
  • RDFLib provides a robust linked data endpoint.
  • Neo4J is a graph database that provides a full SPARQL endpoint with scalable discovery potential.
  • The Dojo UI toolkit is aligned with HTML5 and can provide robust multi-context multi-screen UI models.

IoT Toolkit can provide a common object model and data model framework to enable endpoint discovery and transport abstraction as outlined earlier.

There are now enough components to enable IoT Toolkit to be a component of a larger system based on an Open Source IoT Stack, and focused on Interoperability and Web Standards.  

Model-View-Controller Structure in IoT Applications

The Internet of Things includes systems of feedback control, where observations of key attributes provide information that eventually creates a change in the system through actuation.

This cycle of Observation => Information => Actuation creates a feedback control loop where the observed property is controlled in a system known as a closed loop.

Figure 3 shows the typical structure of some closed feedback loops in IoT systems. There are autonomic feedback loops which involve only software making decisions. An example of this is a motion sensor turning on a light.

Figure 3 - IoT Control Loops and the Model-View-Controller macro-pattern

There are also cybernetic feedback loops, which involve a person in the loop participating in making decisions. In this example, the person in the cybernetic loop is updating settings of an autonomic loop controller.

In the above example, the Model is a representation or an abstraction of the physical things and their attributes, which informs a Controller. The Controller is a piece of software which makes actuation decisions based on the information, and sends actuation commands to the thing using it’s modeled affordances. The software goal is to maintain a desired state of the thing through it’s model.

In the above example, people interact with the system through a View, which is constructed based on information from the model. By observing information presented in views, people make conclusions about the state of the things and consequently make control decisions from which they update the controller.

Some basic mapping of components to a M-V-C macro pattern are shown in figure 4.

IoT Toolkit provides an object encapsulation of the data models and event models in the Smart Object API, and enables connection to physical objects. IoT Toolkit provides scalable resource discovery, adapts to diverse data formats and protocols, provides storage and persistence of objects and data streams, and facilitates a model-driven binding of physical objects to URLs.

Node-RED allows resources from IoT Toolkit Smart Objects to be wired directly to software handlers and other resources, for example actuators, displays, and analyzers. The internal event model of Node-RED roughly corresponds to MQTT, and as such makes a natural connection to the MQTT Observer resource of the Smart Object API.

Figure 4 - Mapping of Software Components to the M-V-C Macro Pattern

The Node Builder is a new component that will discover Smart Object and other resources and data sources, and create Node instances from them that can be wired into Node-RED flow graphs. The Node Builder can use the Semantic Proxy to search and link information from multiple diverse catalogs and repositories into event driven applications. The Node Builder will also provide APIs to facilitate the automatic and run-time use of discovery and linkage to build ad-hoc graphs based on real-time context.

Dojo Toolkit is an open source UI and application system that builds Web scale and mobile application components based on a UI toolkit. The Dashboard builder is another new component that enables Widgets and controller components based on Dojo Toolkit to be wired into Node-RED flows and organized onto user screens. Information from the data models of things will provide units, scale and qualititative interpretation metadata for controlling the presentation on diverse devices and for different use cases.

Model-View-Controller Workflow in the creation of application graphs is depicted in Figure 5.

The Node Builder discovers resources and data sources from catalogs and existing data models according to the requirements of the application. For example, if the application is a Smart Thermostat, the data sources would include temperature in the room being controlled, a control for the heating device in the room, information about windows and solar gain, local weather and weather forecast, and current and predicted room occupancy.

The developer then discovers, selects, or creates application software components and UI components to build the application behavior and UI from.

Figure 5 - Application Development Tools and Workflow

The Application developer then creates a graph. The resources and application components can be either wired together manually by drawing arcs with the tool, or components can be automatically assembled by the Node Builder based on a database of models (ML system) or user templates, etc. Outputs are connected to actuators or UI components which can be selected from the Dashboard builder.

At the end of the process, an application graph is deployed by Node-RED which connects the resources, creates a UI instance, and begins operating on the datastreams and events.

The Run-Time Architecture of the deployed system is shown in figure 6.

Diverse protocols are used to apply the most suitable M2M system for a given connection, whether from cloud to cloud, sensor to gateway, sensor to cloud, gateway to cloud, or data models being accessed from a catalog.

Data models from various catalogs are referenced to create a running instance of an application, and are used occasionally by the running application to discover or adapt to new contextual information.

A Local Control Gateway provides an always-on node for low power sensors to connect, and runs local applications for observing and controlling water flow and air movement. Other sensors connect to both gateway and Personal cloud service, and some sensors connect directly to cloud services.

Figure 6 - Example of Run-Time Deployment

An instance of IoT Toolkit is shown deployed as “Gateway-as-a-Service” to connect a service provider, in this case ThingWorx, into the system to observe and expose it’s resources.

User Interface devices can connect to cloud services or directly to gateways, though there is likely more hardware service capability available in services than gateways at present.

IoT Toolkit instances in the cloud service and gateway can both run application software, providing a local backup capability if internet service is disrupted, or for better response time, or for availability of hardware e.g. GPUs for analytics. Many gateways and services can co-operate to provide layers of control and analysis.

Building an Open Stack for the Internet of Things

The components for creating a robust end-to-end Open Source IoT stack, from sensor to web application, are now becoming available. As more of the use cases become understood and addressed, this will build out in several key areas.

By adding a few new components to glue application graphs together from resources, we can create web scale interoperable applications that can be distributed across local application gateways and cloud services.

Existing components can be integrated at web scale, using URIs to bind connections, to create a macro instance of the well-known Model-View-Controller pattern, which allows for parallel autonomic feedback loops and cybernetic feedback loops.

The Model-VIew-Controller macro pattern provides a framework for the structured division of responsibility between people and software in IoT applications. It also provides a framework for high level interoperability between data sources, control elements, and UI elements.

Such a stack can form the basis of a new service infrastructure, which can provide Platform-as-a-Service functionality while avoiding the single points of failure and lock-in typically associated with PaaS. Open Source PaaS can provide the mechanism for fault-tolerant run-anywhere application platform functionality needed by IoT applications as we begin to depend on that functionality more and more in our daily lives.

Friday, October 4, 2013

M2M Protocol Interoperability Using the Smart Object API

M2M Protocol Interoperability Using the Smart Object API

October 4th, 2013

The previous post in this series discussed the concept of adding an event model to RESTful APIs. This is a follow-on to that discussion, describing how the object model and event model implemented in the Smart Object API are used to create a multi-protocol IoT hub, simultaneously exposing MQTT, CoAP, and HTTP/REST interfaces to an instance of a Smart Object.

A connected weather Station demonstrates multiple Smart Object instances, residing in different gateways, servers, and cloud services, connected together and updated in an event-driven network using the different protocols, also updating a live feed on the Xively service.

What is the Smart Object API?
To review, the Smart Object API is a web object encapsulation of the Observable Properties, Data Model, Event Model, and Software Components that make up the virtual representation of a connected object or data source.

Figure 1 shows how a Smart Object encapsulates a set of resources and exposes them as M2M Protocol Endpoints. The endpoints of different M2M protocols can expose a single Smart Object, providing a multi-protocol bridge function with embedded data models, protocol translation, and event forwarding.

Figure 1 - Smart Object Resource Encapsulation

The Observable Property supplies the most recently updated representation of a data source, which can be practically any supported content type, and optionally can provide time and location along with sample history and other metadata. A Smart Object may contain zero or more Observable Properties.

Observers map data to actions, resulting in event driven communication or computation based on updates of Observable Property data or metadata. Observer classes include Subscribers, Publishers, and Event Handlers. These map changing data to common event driven software patterns.

The Description contains the Data Model for the Smart Object, including the structural and taxonomic models for resources and resource configuration, and high level information models for application level discovery and linkage.

The Agent is a container for the software that runs the Smart Object, consisting of locally executed event handlers and background processes (daemons). Event handlers are invoked by the local Observers configured to monitor local Observable Properties.

Figure 2 shows the structure of a Smart Object and the layered encapsulation of Observable Properties, which themselves have Observers and Descriptions as associated properties.

An Observable Property may have zero or more Observers, in any combination of Publishers, Subscribers, and Event Handlers.

Figure 2 - Smart Object Structure

For more information about the SmartObject, with demo and code examples, see the online presentation at Slideshare:

M2M protocols mapped onto the Smart Object resource and event models

The Publish/Subscribe model used in MQTT and many other M2M systems is very easily mapped to resource observers. Figure 3 shows a diagram of an MQTT Observer associated with a Smart Object Observable Property such that it can publish updates to the MQTT broker that result from PUT operations and subscribe to the MQTT broker updates and apply them to the Observable Property .

Figure 3 - MQTT Observer

The underlying binding that makes this work is using the REST resource path as the MQTT Topic. This way, the topic can be used to create and update REST endpoints, and REST updates can be mirrored to similar paths in other Smart Object instances. This also facilitates association of Description metadata with MQTT topics at endpoints.

Figure 4 shows the Observer-Publisher publishing the update resulting from an HTTP PUT ot CoAP POST to update the resource. In general, a Create operation could also result in the publishing of a topic, either on the create itself or on the first update.

Figure 4 - Publication of REST updates

Figure 5 shows how the Observer-Subscriber creates a subscription in the broker, which updates the REST endpoint when a message is published from the broker on the topic corresponding to the resource path.

Figure 5 - MQTT Subscriber-Observer

Figure 6 shows how the Publisher and Subscriber can be used together to create an MQTT REST bridge. Topics published by the broker update the REST endpoint, and REST updates publish the topic to other subscribers.

Figure 6 - MQTT REST Bridge

Figure 7 illustrates that multiple Smart Object instances can connect to a broker and participate in read-write sharing of REST endpoints across MQTT (or other protocol) connections.

Figure 7 - Multiple REST endpoints with shared updates

CoAP Bridge using the object model and a semantic proxy

The CoAP protocol also includes a REST resource model with events and a rudimentary data model. The core-link-format (RFC6990) provides a link-format encoding and namespace for a simple semantic graph. The IPSO Application Framework builds on the basic vocabulary of core-link-format to describe home and building automation concepts.

The CoAP Event model is based on an Observe extension to the GET operation that subscribes the client to changes in the Observed resource. these changes are best-effort communicated back on the return socket connection to the client in a similar fashion as websockets but using UDP.

The Object model of CoAP is a subset of the resource model of the Smart Object API, allowing the Smart Object Observable Properties to be exposed as CoAP endpoints.

Figure 8 shows how the CoAP interface exposes RDF triples that are stored in the Description graph as link-format relations through a Semantic Proxy.

Figure 8 - Smart Object Resources exposed through
the CoAP Interface and Semantic Proxy

The function of the semantic proxy is to provide a binding of the predicates in one namespace to and from the predicates in the other namespace, allowing a common RDF representation of concepts in both namespaces.

M2M Protocol Interoperability Demonstration based on a Weather Sensor

These concepts are demonstrated in concert in figure 9, which depicts our live on-line demonstration system involving multiple Smart Object instances in gateways, servers, and cloud instances communicating with each other through various M2M protocols.

FIgure 9 - Connected Weather Sensor
Demonstration of Multi-Protocol Interoperabilty

The Arduino reads the hardware sensors and updates Observable Properties in the gateway (single board computer e.g. Raspberry Pi) using CoAP POST or HTTP PUT.

AN MQTT Observer in the gateway relays updates to a SmartObject instance in the PaaS at, which operates an MQTT broker and HTTP + CoAP REST bridge.

A second Smart Object instance at the PaaS subscribes to the MQTT broker and updates itself. These updates are filtered and aggregated to reduce load on the 3rd part API and sent to Xively to update the data feed for storage, viewing, and sharing.

Another Smart Object instance in a user’s personal cloud (here an Amazon EC2 t1.micro instance) also subscribes to the MQTT broker and provides a local Smart Object and MQTT broker to supply weather data to weather forecasting services and other data users for a small monthly compensation. This instance provides CoAP, HTTP, and MQTT access to live weather data from the weather sensor.

Node-RED integration

Node-RED provides an event-graph programming model that is a natural fit for the Smart Object Event Model.

Node-RED instances are easily connected over the network interface by subscribing to MQTT topics and publishing back to the REST broker using existing I/O nodes.

For local integration, there will be nodes that connect to Smart Object event handlers directly and publish back to Observable Properties through a Node-RED Observer.

Roadmap for IoT Toolkit

IoT Toolkit is the reference implementation of the Smart Object API and related tools. The API is nominally complete and relatively stable. The roadmap going forward is to add useful features and create a developer release that can be installed as a Python library and hosted on Pypi.

Some examples of roadmap items are:
– Object model, Data model: create namespaces and ontologies
– Programming model UI: Node Red integration
– Graph-based resource access control
– Harden code, exception handling, API Tests
– Scalable server, multi-tenancy, TLS everywhere
– XMPP endpoint and proxy for XEP-0060, XEP-0323, XEP-0325
– Web UI for debug and demo, applications including Navigator, Dashboard, Analytics, Graphs and Charts