Part 5 of Data Communication for Industrial IoT
As discussed previously, the idea of using a cloud service as an intermediary for data resolves the problems of securing the device and securing the network. If both the device and the user make outbound connections to a secure cloud server, there is no need to open ports on firewalls, and no need for a VPN. But this approach brings up two important questions for anyone interested in remote control:
- Is it fast enough?
- Does it still permit a remote user to control his device?
The answer to the first question is fairly simple. It’s fast enough if the choice of communication technology is fast enough. Many cloud services treat IoT communication as a data storage problem, where the device populates a database and then the client consults the contents of the database to populate web dashboards. The communication model is typically a web service over HTTP(S). Data transmission and retrieval both essentially poll the database.
The Price of Polling
Polling introduces an inevitable trade-off between resource usage on the server and polling rate, where the polling rate must be set with a reasonable delay to avoid overloading the cloud server or the user’s network. This polling does two things – it introduces latency, a gap in time between an event occurring on the device and the user receiving notification of it, and it uses network bandwidth in proportion to the number of data items being handled. Remote control of the device is still possible through polling if you are willing to pay the latency and bandwidth penalty of having the device poll the cloud. This might be fine for a device with 4 data values, but it scales exceptionally poorly for an industrial device with hundreds of data items, or for an entire plant with tens of thousands of data items.
By contrast, some protocols implement a publish/subscribe mechanism where the device and user both inform the cloud server that they have an interest in a particular data set. When the data changes, both the device and user are informed without delay. If no data changes, no network traffic is generated. So, if the device updates a data value, the user gets a notification. If the user changes a data value the device gets a notification. Consequently, you have bi-directional communication with the device without requiring a direct connection to it.
This kind of publish/subscribe protocol can support bidirectional communication with latencies as low as a few milliseconds over the background network latency. On a reasonably fast network or Internet connection, this is faster than human reaction time. Thus, the publish/subscribe approach has the potential to support remote control without a direct connection.