Bridging Device Protocols to ARM mbed Device Server with

Bridging Device Protocols to ARM mbed Device Server with

Bridging Device Protocols to ARM mbed Device Server with

In a previous post we demonstrated how the operating environment can be used to translate between a number of different message protocols.

Today, we will build on that with a concrete example demonstrating how the protocol bridging capabilities and device management integrations of can actually be used to extend the capabilities of device management platforms to encompass those other protocols!

In particular, we'll show how to take devices that only speak MQTT, manage them with ARM mbed Device Server, which does not speak MQTT, all while maintaining the ability to route notification data to and from the usual full complement of data services on the data service exchange™. Just for grins, we'll even subscribe to the notification data over a WebSocket connection to show that the protocol conversions can be performed on the "inlet" or the "outlet" side of the data flows.

IoT/M2M Interoperability Middleware for the Enterprise

While the problem statement above may not sound all that interesting at first blush, consider that:

  • the devices are speaking MQTT
  • potentially, to a separate message broker
  • MQTT is a stateful, connection-based protocol that runs over TCP/IP
  • ARM mbed Device Server expects devices to speak CoAP*
  • CoAP is a stateful, connectionless protocol that runs over UDP by default
  • WebSocket is a stateful, connection-based protocol that runs over TCP/IP
  • that gets upgraded from the stateless HTTP protocol that runs over TCP/IP

and it should start to become apparent pretty quickly how impressive a feat this actually is. (* the newest version of ARM mbed Device Server appears to also support HTTP bindings in addition to CoAP, but it's still a protocol impedance mismatch either way)

Because the real world is made up of multiple device types from multiple vendors. Making sense of that in an interoperable way is the problem facing enterprises and the Industrial IoT. It is also what separates real IoT/M2M solutions from mere toys.

the real world is made up of multiple device types from multiple vendors. Making sense of that in an interoperable way is the problem facing enterprises and the Industrial IoT. It is also what separates real IoT/M2M solutions from mere toys.

In fact, it would be extremely uncommon for enterprises not to have devices tied to multiple device management platforms. Managing them all separately in their individual silos and performing separate integrations from each of those device management platforms to data services representing analytics or business logic would be an absolute nightmare.

Let's see how's composable operating environment makes it possible to solve complex, enterprise-grade interoperability problems.

Building Automation and Instrumentation with B+B SmartWorx Devices

Recently, one of our partners were showing off how they had outfitted their office with a bunch of IoT devices. And of course (as always happens any time you get more than one engineer together), it wasn't long before we had their devices connected up to the operating environment so they could analyze with their IoT data to make it actionable.

The actual devices they were using were a collection of Wzzard Wireless Sensor nodes connected to Spectre Industrial Routers acting as gateway devices. These devices from partners B+B SmartWorx not only comprise a rock-solid, industrial-grade IoT platform, but they also speak MQTT—a common IoT/M2M device level communication protocol. As such, they were perfect candidates for our protocol interoperability demonstration.


The following diagram represents a high-level overview of our interoperability demonstration:

  • device [1] is located outside our partner's engineering area, and has a thermocouple, voltmeter, and x,y,z-axis motion sensor
  • device [2] is located in our partner's server room, and has a thermocouple, voltmeter, and two analog inputs corresponding to ambient temperature and relative humidity
  • device [3] is located in our partner's front conference room and has a thermocouple, voltmeter, and two digital inputs corresponding to motion sensors

For demonstration purposes, we have only modeled a few of the many devices and sensors that are installed on our partners' premises. All three of these physical devices communicate with a local MQTT broker [4] to which our MQTT adapter [5] is subscribed. An example message looks something like

TOPIC: BB/0013430F251A/data,  
PAYLOAD: {"s":6,"t":"2015-11-30T15:18:33Z","q":192,"c":7,"do2":false,"tempint":48.2}  

In addition, we have simulated a fourth device, [6], just to demonstrate how the operating environment can also act as an MQTT broker [7] in order to support scenarios where a separate broker does not already exist.

Irrespective of the originating device, sensor data from these devices is routed through a series of adapters that ultimately:

  • model the data as logical resources on the message bus,
  • register "virtual devices" in ARM mbed Device Server [14] to represent the original devices
  • close the loop by subscribing to notifications for the new "virtual devices"
  • route data to data services like

Modeling Device Data

One of the more powerful capabilities of the operating environment is its ability to model device data streams as one or more loosely-coupled logical layers of connected data resources. These data resources form a directed graph of nodes and edges representing the sources/destinations as connected device data streams, and the processes (or data services) that operate upon them. One data resource is transformed by a data resource into another resource which can, in turn, serve as the input for one or more other data services.

A result of this architecture is that one can target any data resource as the source of any data service.

For our present demonstration, this means, for example, that we can represent the physical devices [1-4] as "virtual devices" in a device management platform of our choosing—ARM mbed Device Server in this case—whether or not it even supports devices of that make and manufacturer.

In fact, at a high level we will perform the following mappings between different representations of the device topology:

  • physical device data represented as MQTT topics of the form BB/<deviceId>/data are mapped to
  • logical data resources of the form /bb/<deviceId> which are further mapped to
  • logical data resources of the form /bb-data/<deviceId>.<sensorType>.<virtualDeviceId> which are registered and managed as
  • ARM mbed Device Server endpoints and resources of the form <deviceId>, <sensorType> which are then subscribed to and made available again to data services as
  • data resources of the form /bb-stream/<deviceId>.<sensorType>

Now that's some serious interoperability. Let's zoom in even a little closer, still.

Managing Virtual Devices with ARM mbed Device Server

Recall that earlier we described significant impedance mismatch between the protocols involved in this interoperability exercise. Let's examine the other adapters involved and see how they can be cleverly combined to resolve our impedance issues and allow us to manage virtual devices in ARM mbed Device Server.

Picking up where we left off earlier in reference to our architecture diagram,

  • adapters [9], [10], and [11] compose and send messages requesting the creation of new logical data resources. The adapter [9] maintains or references a mapping of virtual CoAP endpoints (more on these later) provisioned for each device. Specifically, an example message sent to the HTTP request adapter [10] might look like this
  { "Authorization": "Bearer <token>" }
  • the same messages emitted from [8] that are used to create new resource bindings are also routed to a simple controller [9] that composes a message for the CoAP adapter [13] to send to ARM mbed Device Server [14]. This CoAP message registers a virtual device and supplies a custom UDP context endpoint [15] as the location of said virtual device. (Notice that in actuality, our virtual CoAP device is actually spread across several different adapters in the operating environment!) An example CoAP pseudo-message (since CoAP is a binary protocol, I'll save you the raw tcpdump output) is basically
POST: /rd?ep=0013430F251A&et=BBSmartWorx%20Sensor&con=coap://  
BODY: </tempint>;obs  

In order to maintain the registration, [13] will also send CoAP registration update messages as required by ARM mbed Device Server once the initial registration has occurred.

With just these few adapters, we have successfully used CoAP to registered virtual devices to represent our real MQTT-based devices in ARM mbed Device Server. You can see they now appear in the endpoint directory of mbed Device Server's administration interface:

Subscribing to Virtual Device Notifications

Now that our devices have been virtualized in our device management platform of choice, we can treat it as any other fully integrated data service. That is, we could choose to subscribe to notifications for one or more of the device resources and route them to one or more data services.

  • first, we would need to subscribe to mbed Device Server notifications by sending a message to the mbed Device Server adapter [17]. For our example, we just used a curl call [16] to the HTTP adapter [11] for simplicity.
  • the mbed Device Server adapter [17] will subscribe to the indicated endpoint and resource
  • in response, ARM mbed Device Server [14] will send a CoAP GET message to its registered endpoint (which you will recall is one of the CoAP adapters [15] that were provisioned by [9] and registered by [12]). These CoAP messages between mbed Device Server [14] and the CoAP adapter [15] look something like this (again resorting to pseudo-code to convey the binary message details):
GET /tempint  
OBSERVE=0, TOKEN: <token>  

NB: observe=0 means observable is true! Also, notice that the device identifier is missing and only the resource name is specified. This is because back in [9], we mapped the stateful, UDP-based endpoint for a specific physical device to a specific virtual CoAP adapter [15]--the one that is receiving this GET request.

The response sent back to ARM mbed Device Server [14] from the CoAP adapter [15] would look something like this:

CODE: 2.05  
TOKEN: <token>, OBSERVE=<observationSequence>  
BODY: 42.1  
  • next, ARM mbed Device Server sends these notifications to its registered callback: namely, the HTTP adapter [11]
  • after we route the messages through one more simple transformation [18] to return the deviceId and sensorId metadata to the logical resource path,
  • we can consume the device notifications through the WebSocket adapter [19] using and/or route it on to other data services like [22] for further transformation or analysis.

Routing to Data Services

Now that our notification data is once again represented as a data resource, we can route it to any of the services in the data service exchange™.

For example, if we create a "bip" in the web API workflow automation tool, we can pick off specific attributes and send them to any of a number of other 3rd party service integrations. For example, see the steps below to append rows to a Google Sheet spreadsheet where still more analysis and data interaction can occur. For example, column D in our spreadsheet contains a custom base64 decoding function written in JavaScript.


Today, we have demonstrated an extremely powerful capability afforded by the operating environment whereby we can combine a several protocol and data service adapters to extend device management services from IoT platforms like ARM mbed Device Server to devices that speak unsupported protocols like MQTT.

In a future post, we will build on this concept and show how we can turn any data resource into a "virtual device" managed by a device management platform—even ones that don't originate from devices at all!

It is through powerful capabilities like these that can truly claim to offer real-world IoT/M2M interoperability middleware for the enterprise.!