There has been a lot of discussion lately about the Internet of Things (IoT) and how connected endpoints can help revolutionize the way businesses collect and process information from Operational Technology (OT) systems, but there are huge challenges in accessing the information and making it accessible to your other business systems, employees and business partners.

While IoT is a fairly new term, businesses have been deploying systems and devices that collect information and manage processes since the early days of microprocessors and networks. These devices record everything from temperature, location, motion, status and much more. The problem with these legacy systems is they almost always send their information in a proprietary format that must be learned and re-learned for every application developer in order to use the information effectively.

Some of these proprietary protocols date back to the old AT Modem command sets. Most of this is ancient history to today's web application developer and certainly no inducement to building new applications and integrated systems.

So even though the device may have a way to report the information it is collecting, it's really not connected in a way that an application or other business IT system could consume the data and use it in operational or business decisions.

There are several industry groups, such as the Industrial Internet Consortium (IIC) and the AllSeen Alliance, that are working to resolve the issue with device protocols and working to define a set of standards that almost any device could use for communications. There is also the concept of agent software that could be installed on a device to force it to communicate using a known protocol. The problem with both of these approaches is there are millions of existing devices already deployed that have no capability to be upgraded in either firmware or protocol.

New technologies and advances in microprocessor technology allow for the newest devices to use the latest web standards, like RESTful web services, to expose the information. Unfortunately, very few of these devices have been deployed compared to the multitudes already in the field.

But the approach of the newer devices is correct. Modern application developers almost always use API's or web services to create their applications. In fact, they may use a wide variety of these API's in their application to display items such as Google Maps on their web page. The concept of using web services is not a foreign concept, like the idea of having to learn antiquated AT command sets.

One idea gaining momentum is the concept of device translators or connectors, which could potentially convert the older protocols into something that would simulate a web service. These translators would need to understand the protocol, but once it was done, any web application could potentially gain access to the device and its information using this new web service.

However, there are issues with this approach. Some of the considerations:

How does the new connector service represent the device in a way that the application can understand its capabilities and/or limitations? Generally, you should be able to define this easily from the original protocol or the specification of the device. One way to approach this might be through the use of JSON or name/value pairs to define a capabilities matrix.

If your device is not on a dedicated network, how will you communicate with it? Many of the legacy devices will "call home" on either an event occurring or based on a time interval. This works well for the normal case, but what if you need to change one of these parameters. You might consider having a back channel protocol like possible SMS messaging to send a signal to the device to force it to "call home" and ask for new information.

Security should also be a consideration. Unfortunately, older devices have limited security capabilities. Very few have any sort of encrypted data or even the capability to use SSL techniques to transfer their data. Because of this issue, you must consider if the information you are getting from the device can be trusted. Use of firewalls and secure networks may help in this regard but you must take precautions in your connectors to prevent service attacks.

Managing IP and Port addresses is critical. As many of the legacy devices do not handle DNS lookup and most only communicate over a standard TCP socket, you have to dedicate an IP address and Port combination to those devices. In addition, you may be forced to have multiples of these addresses for the various versions of the protocols. Over time this can be a large management and deployment issue.

As IoT matures, devices become more capable, and as standards emerge it is expected that many of these issues will begin to disappear. Unfortunately, we will still have a tremendous legacy of older devices to manage for years to come. However, taking an approach to disaggregate the proprietary protocols from the actual useful information of the device can be a way to collect useful operational technology information and apply it to specific business processes and decisions.

Greg Jones is Chief Technology Officer at MachineShop. MachineShop provides the on-ramp to the Internet of Services where trillions of transactions will occur between billions of physical things and their interactions with other systems, applications and people. MachineShop's public or private Services Exchange allow customers to subscribe to thousands of unique, managed API-centric services regardless of whether they are developed by MachineShop, its customers or other third parties. For more information, visitwww.machineshop.ioor@MachineShopIO

Copyright 2015 IDG Communications. ABN 14 001 592 650. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.