Data Service Providers

In part 1 of this series, we went over the various ARM devices that were combined with open data from the London Datastore to represent the connected device side of our demo. In part 2, we described how to use employ one or more device management platforms like Stream Technologies IoT-X Platform or ARM mbed Device Server to manage devices and send their sensor readings onto the wot.io data service exchange™.

Now, let's see how we can route all that valuable device data to some data service providers like scriptr, ThingWorx, and Elasticsearch to extract or add business value to the raw IoT data streams.

Dataflow Review

Recall that back in part 1 we started with the MultiTech model car, modified to include a MultiConnect® mDot LoRaWAN module with an accelerometer sensor. The sensor sent the accelerometer data to a MultiTech MultiConnect® Conduit™ gateway using the Semtech LoRa™ low-power, long-range wireless RF interface. The Conduit was registered with Stream's IoT-X platform.

Since wot.io is fully integrated with IoT-X, making the device data available on the wot.io exchange where it could be sent to any of the data services was as easy as setting up the data routes.

scriptr for Business Logic

Part of the reason for measuring the accelerometer readings in the smart vehicle was to detect if it has been involved in an accident. Some of the numerous and obvious opportunities for such intelligence include insurance, emergency response dispatch, traffic routing, long term traffic safety patterns, etc.

However, in order to translate the raw sensor readings into that business intelligence, we have to determine whether there was a sufficiently rapid deceleration to indicate an accident.

Of the many wot.io data services that could be employed, scriptr is an excellent choice for embodying this type of business logic.

scriptr is a cloud-based, hosted JavaScript engine with a web-based Integrated Development Environment (IDE). Since we can route wot.io data streams to specific scriptr scripts, we can use it to write our simple deceleration filter:

Notice that the script receives our messages containing the raw X,Y,Z-plane acceleration readings. After parsing these parameters, we do a simple check to determine whether any of them exceed a given threshold. If so, we return a cheeky message back onto the wot.io data service exchange.

Notice that the the message we returned is a simple JSON object (although it could have been anything--XML, plain text, or even binary data). Furthermore, it does not contain any information about the destination. It simply returns a value.

That is, our script does not need to know where its response will be routed. Indeed, it may be routed to multiple data services! Loosely coupling data services together in this fashion makes for a much more flexible and resilient architecture.

bip.io for Web API Automation

Next, we chose to route any warning messages returned from our scriptr script to a bip.io workflow (known as a "bip") that we named tweet so that we could notify the appropriate parties of the "accident". Although we called it tweet, bip.io bips can easily perform complex workflows involving any of its 60+ data service integrations (known as "pods").

For the demo, we kept our bip simple, consisting of only twitter and email pods. But you can readily imagine how, given the conditional logic and branching capabilities of bip.io, much more complex and interesting workflows could be created with ease. For example, device events could be stored and visualized in keen.io, sensor data could be appended to a Google spreadsheet involving complex functions and charts, or SMS messages could be composed into a template and texted via SMS through Twilio.

Since we authenticated the Twitter pod through our wot.io developer account @wotiodevs, whenever the data from the accelerometer is determined by scriptr to have exceeded the safety thresholds, we can see our tweets!

ThingWorx as an Application Enablement Platform

ThingWorx is a full-featured IoT platform that enables users to collect data from a variety of sources and services and build out applications to visualize and operate on that data.

In our case, we took the real-time location data originating from the mobile devices being managed by Stream's IoT-X and ARM's mbed Device Server platforms and routed them through the wot.io data service exchange to our visualization, or mashup application, in ThingWorx.

We also routed traffic camera and traffic sign data from the London Datastore through wot.io and into the same ThingWorx mashup.

To make the data useful, in our mashup we included a Google Map widget and then in real-time, we plot each mobile device, camera, sign with a different icon based on their current locations.

Users can interact with any of these data points: clicking on a camera icon, for example, will display an image of what is actually being captured by that traffic camera at the given intersection. Below, I selected a camera that is located on the River Thames and has the Tower of London with Big Ben in its view!

While it's fun to sight see around London, in a Smart City, we can also imagine ways to use these cameras and digital signs to help us efficiently move assets (usually vehicles!) through a congested downtown area. For example, if we zoom into a traffic heavy portion of London, we can view the camera feeds and digital roadsigns in an area. Here, we can see that this sign's text currently displays a message that this route is closed for resurfacing.

And the camera in the area even shows how traffic cones are being set up to move traffic away from the roadwork!

And since we already know that with wot.io, messages can be routed to multiple data services as easily as to a single service, displaying the messages on a map is hardly the end of the story. Just as one trivial example, imagine correlating the timing and text and locations of digital signs with the resulting traffic disruptions to optimize how best to announce construction work.

Elasticsearch & Kibana

Finally, we also routed the telemetry messages from all those cellular, satellite, and LPRN-based mobile devices embedded in vehicles traveling around the city of London through wot.io and into an instance of Elasticsearch and Kibana to create a real-time heatmap visualization of the number of managed devices by geographic region.

Elasticsearch is a powerful, distributed, real-time search and analytics engine. Traditionally applied to numeric or textual data (as we have discussed previously), Elasticsearch also shines in geospatial indexing scenarios as well. In this case, our histogram is colored based on the number of devices currently reporting in each geographic subregion.

Conclusion

As London and other major cities begin to connect, open, and share all the data their IoT devices collect, wot.io allows for the creation and extraction of real, actionable business value from that data.

Whether through its many options for device management platforms from the likes of ARM and Stream Technologies, or its support for any of the hardware devices through numerous protocol adapters, or its support for web-based data feeds like the London Datastore, or its ability to flexibly route data to multiple data services like scriptr, bip.io, ThingWorx, or Elasticsearch, wot.io is clearly the data service exchange™ for connected device platforms.

London Knightsbridge Street Photo Credit: By Nikos Koutoulas [CC BY 2.0], via Flickr