siliconindia | | May 20179Finally, 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 architec-ture. 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 con-nectivity. A secure data link between devices and cloud resident applications is a key requirement for the IoT. Security consider-ations 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 administra-tion and managing of devices. There are several challenges in integrating legacy devices with an IoT. To name a few, the automation and control proto-cols 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 ex-pensive 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 de-vice. 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. Image 1
< Page 8 | Page 10 >