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.

http://www.slideshare.net/michaeljohnkoster/open-source-stack-for-io-t

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:

IoT Toolkit and the Smart Object API - Architecture for Interoperability

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 http://smartobjectservice.com, 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

Event Models for RESTful APIs

Event Models for RESTful APIs

Adding event-driven processing to REST APIs is an important concept for the emerging Internet of Things. REST APIs provide for high level system interoperability and software usability, while event driven processing is needed for autonomic capability and efficiency.

An event is a significant change in the state of some element of a system. Events are asynchronous, that is they occur at arbitrary times relative to other operations in the system.


REST APIs enable web scale resource interaction and simplify application programming. The state of the system and values of observable properties can be easily discovered and operated on using GET and SET operations in URI addressable end points that have memory-like semantics. Metadata can easily be added to functional data to enable linking resources into composite horizontal applications.

Event driven systems process real time data efficiently. These systems are often based on asynchronous messages sent between end points that invoke software at the end points. Application programming is generally more difficult because of the need to interact using a stateful communication protocol. One example is the difference between programming for sockets and messages (asynchronous) vs. memory-like read/write semantics (synchronous).

The Internet of Things needs to be an event driven system for efficient real time response and processing, and needs REST APIs for resource discovery and programming efficiency, and to support rich metadata for interoperability in horizontally integrated applications.


In the context of a REST API, an event occurs when a resource in the API is updated and/or it's value is changed, or changed significantly. Events can be any updates, or filtered updates that meet some criteria, for example temperature too high, temperature too low, or temperature changed by more than 2 degrees since the last update. Typically, Client-Server REST systems don't provide for asynchronous events, instead software would need to perform periodic GET operations to sample the state of a resource.

We propose to add event driven processing to REST by introducing a common set of patterns and abstractions that provide a well defined event model. The event model will enable asynchronous event processing and message oriented communications to be configured and controlled through the REST API. 

Many of these patterns and abstractions are familiar and in use today in various forms. For example, CoAP has support for both synchronous and asynchronous REST operations, there are message brokers with REST endpoints (Qest, Xively), and there are hooks for instrumenting RESTful endpoints to add callbacks on updates (Real Time REST hooks). This will summarize the fundamental patterns and build a complete event model based on these patterns.


REST endpoints as event sources

An event occurs when some resource is updated or changes. To support events in a REST architecture, there needs to be some means to detect and generate events when resources are updated, a means to propagate the events and direct them to the proper destination, for example to update another REST endpoint, and a means of acting on the event, by storing a record of the event or invoking event handler software to respond to the event.

The diagram above shows an example event processing graph:

(1) sensor data are updated when the sensor endpoint makes an observation and sends an update to the Smart Object Observable Property, which is a REST resource. 

(2) an Observer resource associated with the Observable Property informs the system to notice updates and forward them according to routing instructions contained in the Observer resource.

(3) The event is routed to the destination resource

(4) The Observable Property at the destination Smart Object is updated

(5) A handler is invoked based on an observer associated with the local resource. This updates a physical actuator endpoint.

HTTP provides for asynchronous operations from Client to Server using POST, PUT, or CREATE. By arranging to have a server endpoint at each resource location, as is the case in with the Smart Object API shown above, asynchronous updates can be propagated using standard HTTP protocol operations POST, PUT, and CREATE. 

Other protocols like MQTT can also be used to send events between resources. The Observer resource can program the topic, broker, service, QOS, etc. in it's stored representation. 

Using MQTT, the topic can be a representation of the URL and the data can be the representation of the data, e.g. JSON. This way, the URLs can be send between endpoints whilst tunneling through MQTT, preserving the semantics of REST updates and, more importantly, preserving the granular resource access control system based on capabilities that REST enables.

We will use MQTT as an example asynchronous protocol for this document, but we could also use HTTP POST, websockets, CoAP, XMPP, AMQP, Dbus, MODBUS, RS-232, WSNs, or any other asynchronous communication mechanism.

Observers and Subscribers in a general REST event model

The Observer is a graph resource that is associated with a data resource. The Observer informs and programs the system to generate events on updates of the associated resource. When the observed resource is updated, the system performs the actions specified by the Observer's graph end points, either propagating a representation of the resource update to another endpoint or invoking a handler. Graph endpoints can be added to describe the action, for example to specify the QOS of an MQTT publish operation.

This example above shows an Observer associated with a REST resource (Observable Property) that programs the endpoint to publish updates to a specified MQTT broker endpoint whenever the Observable Property is updated. The protocol, IP address, QOS, and topic are all specified as local graph relationships that the endpoint uses to program it's behavior when the Observer is created. 

Observers can use HTTP POST, websockets, XMPP, or any asynchronous event notification method available in the underlying platform.

The Subscriber is a graph resource associated with a destination resource endpoint which is to be updated. The Subscriber programs the destination endpoint to subscribe to a data source, such as a MQTT broker or a Smart Object Observable Property that uses HTTP POST. This creates a graph link from destination to source, and could be used to create an Observer resource at the source endpoint.

This example shows an MQTT subscriber that creates a subscription with a broker to publish updates to the associated REST resource (Observable Property). This creates a graph link back to the data source. This pattern can be used to control HTTP POST, CoAP extended GET, and other asynchronous notification mechanisms from the destination endpoint.

Note that Observers and Subscribers are ways of controlling asynchronous updates from either the source or the destination endpoints, or both. If both are used between 2 endpoints, there is a 2 way resource graph connection established.

Message broker with REST endpoints

Another set of abstractions is to enable the configuration and of existing message systems such as MQTT using REST endpoints. There are two interfaces, a message interface and a REST interface, to shared stored resources. 

There are two message operations supported, to enable  clients or brokers to publish updates to REST endpoints through a message interface, and to publish updates of REST endpoints to brokers or clients subscribing through a message interface. There is also a subscribe operation using the message interface. Incoming messages update resources, and resource updates send outgoing messages.

The convention is to use URIs as topics that allow the system to construct URLs for the REST resource endpoints. The payload consists of the resource representation, e.g. JSON. This handles incoming and outgoing publish operations and acts as a message broker with REST access to topics and, if there is storage, topic history storage. 

REST Message Broker allows message clients to publish to REST endpoints and subscribe to REST endpoints. An application can monitor an MQTT endpoint by observing the REST resource it publishes to, and an application can publish to an MQTT client by updating to the REST endpoint the MQTT endpoint is subscribed to. For example, sensors could connect with MQTT and publish updates for application software to read, and application software could update a REST endpoint, resulting in the system publishing the update to a sensor that is subscribed to the URL as topic.

The above example shows how an MQTT broker endpoint can be added to a REST server to enable REST clients and MQTT clients to share data by mapping URLs to topics. When either a REST client updates a resource an MQTT client publishes to a topic, the corresponding resource update is published to any subscribers. 

A General Event Model for REST APIs and architectures

In summary, a complete event model is presented for adding event driven real time capability to RESTful architectures. The event model enables RESTful abstractions for event sources and destinations, message broker endpoints, client and server endpoints, and asynchronous software event handlers. 

Through the Observer, Subscriber, and REST Message Broker abstractions, and associated graph resource definitions, a general facility is created that can abstract the functions of common event and message passing systems to provide high level REST API control of the low level protocols, for example QOS control for MQTT endpoints. These high level models provide a consistent API for software interoperability, while allowing diverse protocols to be used in the underlying platform.

What is the Internet of Things?

What is the Internet of Things?

Michael J Koster 4/29/2013

So far in these articles, I’ve discussed in broad terms, and in relative depth, some ideas around architecture for the Internet of Things. This time I want to take up a specific question that helps to frame the differences between various standards and platforms. That question is about the fundamental distinction between Machine to Machine communication, known as M2M, and where I think we are going with the Internet of Things

What is M2M and what is IoT?

Of course I don’t have a hard definition, but I’m going to offer a broad contrast, based on what I see to be different, complementary optimization points. Let’s start with what we expect to get out of IoT as our context for the discussion. What is it we expect IoT to do for us?

IoT Value Proposition and Value Model

IoT will be a lot of things to a lot of people. Rather than try to list them all, I think there are some common patterns that define the basic value model delivered by the Internet of Things.

First, connecting things to software results in a big gain in the manageability of things and starts to enable the life cycle management of everyday objects. For business this means that capital assets are converted to managed services. The value begins to shift from a scarcity model to a usage model, with huge incremental increase in the return on investment (ROI).

Next, and even more exciting, is the network effect. As more and more things are connected and made available as managed services, whole collections of resources can be managed as systems. It’s clear that this enables the smart home and smart city convenience scenarios that many use to portray IoT. Beyond that, there is another, more exponential, increase in created value when resources are managed together as a system. This is the network effect applied to the physical world, and what I think generates the ultimate value of the Internet of Things.

To realize the full value of the IoT, then, things need to be connected to software, and they also need to be made available to be used together as a system. This is an important distinction that helps frame the discusion of the original question around M2M vs. IoT.

M2M enables connection of objects to software

Machine to Machine communication has been used for decades, in experimental form since the days of Tesla, and in practice since teletype. Nowadays, M2M connects sensors or connected objects to software services and to each other. Industrial automation has been handled by computer software since the 1970s.

M2M standardization has been a goal of industry for most of this time. M2M standards are focused on protocols and message formats, and recently, to some extent, software APIs. They provide for vertical integration, end-to-end, of systems. M2M standards allow for message level connectivity between endpoints in systems.

What’s missing from M2M is the high level mechanisms to build out horizontally and connect diverse resources together as a system to create and exploit the network effect.

The result is silos, which are separately controlled platforms and standards that are incompatible with one another, making it difficult to integrate devices and services from multiple providers.

The Internet of Things connects M2M systems together

M2M communication provides the essential underlying mechanism for IoT. But simply creating one standard for M2M is not sufficient. We think of IoT as adding a layer of discovery, interoperability, and autonomy on top of M2M communication services, using open internet-style standards. The focus is on data models and APIs that enable horizontal integration across different M2M systems. IoT standards enable collections of sensors and other connected objects using different M2M protocols to be managed as larger systems, creating and exploiting the network effect. IoT is built on M2M. An IoT platform connects across silos and discourages separate data models that lead to the creation of silos.

What about MQTT and other M2M Standards? How do they relate to IoT?

MQTT is at it's heart a message transport protocol. It moves messages from one endpoint to another, through a message queue. A publish/subscribe interface is provided to associate endpoints. An endpoint having data to send publishes the availability of the data stream, and any interested endpoint registers a subscription. After that any messages or, in the case of sensors, updates are pushed from the publisher to all the subscribers.

The value for IoT is efficient data push to potentially a large number of subscriber endpoints. Also, the MQTT service can itself be responsible for guaranteed delivery in the case of lossy networks. There are some different QOS models you can specify.

MQTT is a standard protocol that can be used to send data messages or updates from one endpoint to another. I have seen XMPP and PubSub also proposed to do this. There are some advantages to MQTT that make it a very good M2M standard.

HTTP and CoAP can also be used for M2M communication, based on RESTful interfaces at the endpoints. Efficient data push is native to CoAP using an extended GET operation, and for small systems and low data bandwidth, can easily be done in HTTP based systems with websockets and webhooks. RESTful interfaces have their own advantages.

RPC based systems based on .NET and SOAP are also being promoted as M2M standards, and getting some adoption. So as I see it, there are many ways to accomplish M2M communication with different strengths and weaknesses.

CoAP is a good example of both M2M and IoT, as it can be run on different sensor net radio stacks, while still providing interoperable APIs and data models across them all.

The open source platform we're building for IoT will be able to use MQTT "under the covers" to update exposed RESTful endpoints. The idea is to provide standard abstractions for the endpoints that can use different underlying M2M systems as needed to adapt to existing platforms or exploit unique advantages.

So, you can build systems with MQTT as the M2M layer. But MQTT is one component of many that will make up the Internet of Things.

Broad Interoperability has other benefits

Lack of interoperability tends to lead to distorted business models that attempt to monetize the basic connectivity and communication channels, creating a "fat middle" ecosystem full of multiple incompatible competing information pipes, and distracting developers from the human touch points where real value is created.

The Interoperability problem also makes it difficult to reuse and repurpose existing sensing capabilities in new applications. Much of the value will be created from repurposing existing data, as in the well-known example of using GE turbine and commercial aircraft sensor data for real-time weather forecasting. Existing sensors need to be made available for use in new systems.

IoT is an Internet

Just as the Internet is made of many platforms, standards, and networks, so is IoT made of many Sensor Nets, M2Ms, Application platforms, user platforms, and so on, creating a community ecosystem.

Meaningful IoT standards will be build in the manner of Internet standards, based on community process and open contribution, drawn from diverse use cases brought by participants from industry, research, the DIY and Maker community, and others.

We already have common internet languages and protocols, including HTTP, CoAP, MQTT, XMPP, and more. There are plenty of M2M options, but there is not yet a well known architecture for interoperability, discovery, and autonomy. This is, by definition, something we will all use and will need to build together.

Building a shared common platform will create a richer ecosystem for everyone, by enabling development of new systems to focus on the value-added human physical touch points of connected objects and the services that manage them. New services based on high value horizontal integration of resources will be enabled.

It will accelerate the deployment of the IoT at scale, leading to near term economic and human social benefits for all.