Extending the Internet of Things to Brownfield Devices

Suhas D. Joshi, Director, Enterprise Architecture, Honeywell International [NYSE:HON]

The Internet of Things (IoT) is all about unlocking business value that is locked up in data generated by “things.” Consider a smart industrial pump that is used in an oil refinery. The pump generates useful data regarding speed, volume of fluid passing through as well as vibration and noise level of the pump itself. If this data is collected from the pump and sent to an application for analysis, it will be possible to gain insight into data patterns that show the behavior of the pump. Certain anomalies, for example, a high degree of vibration and noise with normal fluid speed and volume, may suggest that the pump needs to be serviced. If not serviced quickly, it will lead to a disruptive failure. A single averted disruption can save millions of dollars. Because of IoT related technologies such as networking, cloud technology, data storage and analytics, it is now possible to collect and analyze device data at a large scale and generate significant business value.

Extending the IoT to legacy devices may appear as a daunting task but the right architectural choices will definitely pave the way for success

IoT is a relatively recent development. But there are millions of devices, sensors and controllers that were developed long before IoT came along. These devices generate data for “things” such as pumps, rooms or air handlers. Such devices have been already deployed in the field and use proprietary or standard protocols to communicate with other local devices or local applications. The local application resides in physical proximity of the devices, receives data generated by the devices and performs command and control. See the figure below as an illustration of how legacy devices are connected.

The automation and control protocols implemented in legacy (or brownfield) devices are designed for a local “site” level communications and control, as opposed to communicating with a remote application that is accessed through Internet. For example, a water leak detector may communicate through a ModBus protocol, a temperature sensor communicates through BACnet protocol and an air handler unit may use LonWorks. Operations, Administration and Maintenance (OA&M) is performed locally and not remotely through the public Internet. Finally, security design assumes a friendly, local, “site” based communication as opposed to communications over the public Internet. Thus, connecting brownfield devices to the IoT imposes formidable challenges.

Now let us review the building blocks of the IoT architecture. A key IoT component is an on-premise or off-premise cloud infrastructure. The benefits of such an infrastructure include scalability, elasticity and availability. Services to authenticate devices, ingest and store data generated by devices and tools for data analytics and cloud-resident applications reside in the cloud. Cloud resident, customized applications process data generated by devices. The scalable infrastructure lends itself to access data from devices in the entire enterprise and not just a specific site. Also, device OA&M application(s) are hosted in the cloud. Data transfer between the cloud resident applications and devices goes via the Internet. Internet Protocol (IP) is commonly used for connectivity. A secure data link between devices and cloud resident applications is a key requirement for the IoT. Security considerations include restricting access based on user role, encryption of data at rest and in transit. Finally, there is a cloud resident human-machine interface component which enables remote administration and managing of devices.

There are several challenges in integrating legacy devices with an IoT. To name a few, the automation and control protocols mentioned earlier such as BACnet cannot be extended to reach a software application in the cloud. Secondly, many legacy protocols use a synchronous approach for communications and in talking to cloud applications, an asynchronous approach is preferred. Finally, the security techniques implemented in legacy devices may not be suitable for protecting data as it traverses the public Internet. To overcome these challenges, a few solutions are proposed as follows.

One possible solution is the introduction of an “IoT Device Computing Platform (IoT DCP)”. The IoT DCP will be a scalable software platform and run on an operating system such as RTOS, Linux or Windows. It will be co-located with legacy devices. IoT DCP should support protocol drivers such as BACnet, ModBus or LonWorks which allows it to interoperate with legacy devices. To a BACnet device, the IoT DCP appears as another BACnet node. Additionally, the IoT DCP implements Transport Layer Security (TLS) protocol to establish a secure data link with the cloud based data ingestion service. Once the link is established, IoT DCP uses AMQP, MQTT protocols or the OPC/UA standard to send data to cloud resident services. See the figure below.

Another possible solution besides IoT DCP is to upgrade the firmware in each brownfield device so that each device is capable of maintaining a secure link with the cloud based data ingestion service. Then the device has to support a protocol such as AMQP, MQTT or OPC/UA to send data to the cloud based data ingestion service. This option could turn out to be quite expensive depending upon the number of devices to be upgraded. A third possible solution is a hybrid approach in which firmware is updated for some of the devices while other devices connect through the IoT DCP.

The IoT DCP option is less disruptive and could be less expensive compared to upgrading firmware in each legacy device. Regardless of whichever approach is chosen, there is cost involved in migrating the site based application(s) to the cloud. Extending the IoT to legacy devices may appear as a daunting task but the right architectural choices will definitely pave the way for success.