How Remote Monitoring can be Revolutionized by MQTT
To speak to the issue of telemetry like MQTT, it must first be put into context. Why a protocol can revolutionize an industrial application depends on how industry will be conducted, and what tools will be used in the near and far futures –so as to avoid investment in soon-to-be-outdated control systems.Industry 4.0, a term describing the future of primary, secondary, and even tertiary industrial processes,will heavily rely on leveraging a massive flow of data –between end-users, Industrial & Consumer IoT devices, Intranets, Big Data, and perhaps even Blockchain. This transformation will probably involve Artificial Intelligences (or if not quite that level of machine cognition, at the very least,machine learning), and it will definitely involve machine to machine (m2m) interface and processing.
Machine to machine interface and communication protocols are key to the future of industrial automation, as stringent industrial control system requirements will soon be met by rapidly improving standards in the IoT environment; IoT as applied to industry is now known as IIoT, but we will likely see an integration between the two.Events are the impetus for administrative operators responding to alarm conditions, and for now the actionable response is often left to humans. But soon, IIoT devices will have complex responses to contingencies based on acquired data, and much of SCADA’s supervisory level(and beyond to the production and scheduling levels),can be automated for better efficiency. Such a shift in procedure will free up your operational personnel’s attention–diverting their hands and eyes from HMI terminals, and towards other areas requiring attention. This means rolling with the momentum of the Industry 4.0 Revolution rather than struggling against it or missing out entirely. For the time being, operators are content to remain in control at the supervisory level of industrial control systems. What used to be constant supervision of industrial control systems now requires response only when critical events trigger alarms, at least in a SCADA setting. The role of the human being in this process is now much more meaningful. It makes the operators in charge of event response an executive rather than a sentry, and the automation of datalogging presents the opportunity to ensure that they are not overburdened with Quality Management or Safety Standard documentation as well.
Development of SCADA Hardware and Software
The development of SCADA equipment is varied and few solutions on the market are identical. Multifunctional equipment is a de facto market offering, so products with an initial function in a SCADA setup may often take on complementary functions, rather than having a dedicated function, since fragmenting the required equipment would make clutter for the plant operators. The downside to a wide variation in equipment function is the complexity of the setup, necessitating the consulting services of systems integrators to ensure that equipment from different companies can be utilized, rather than submitting to dependency upon a SCADA equipment sales company to do their customer’s purchase planning for them.But the most exciting benefit of IIoT functionality in a multipurpose device is how it enhances and integrates other digital and physical features into a much broader virtual process. One such IIoT protocol is MQTT, a reliable protocol first developed by IBM. Message Queue Telemetry Transport is a lightweight protocol that can ration the transfer of data packets going over cellular by way of its queuing procedure.Essentially, an MQTT device at a remote site can act as an IIoT Gateway, bridging smart field devices to cloud servers. Minimal transfer from a remote location to a cloud based broker, is further distributed to the edge of the wired network (if the centralized distributed network on the internet is called a cloud, then server computing localized nearer to the IoT field level and control level devices can be called a ‘fog’(i.e. clouds reaching down into a city street),meaning that only essential data is transferred over cellular, and telemetry transports in carefully measured quantities. High priority is fire-and-forget, whereas lower priority data packets will queue for the right network latency, applicable to the purpose of saving on cellular data consumption overall. Lower priority queuing preserves bandwidth by waiting for data bottleneck at the gateway to clear before sending
Data Efficiency and MQTT: Ways this Lightweight Protocol Can save on Cellular Costs Today
1.Queuing: Communication limited to a small code size allows the m2m client to send published values (data points)collected from the m2m server device(such as a sensor)to the cloud-computing broker, where any access or further data processing can be sent to local area networks unconstrained by data restrictions; the m2m part of the telemetry compresses and rations the packets sent out, whereas the machine to cloud, and machine to human portions of the Pub-Sub (publish and subscribe) telemetry can relay back and forth more freely.
2.Actionable Messages: Actionable data sent over MQTT, as with digital or analog I/O for instance,saves enough money to give the operators the choice between using a cell budget to access and reconfigure the setpoints of field bus clients remotely, through VPN for instance, or sending personnel to deal with the remote site if remote access fails to resolve the problem.
3.Telemetry Prioritization: GPS is a data efficient technology when the positioning results are communicated to a networked device over MQTT. If your remote monitoring is on the move, as with a fleet management application, then it’s imperative that positioning data be of the right level of importance, and that it be sent in such a way that keeps cellular data consumption costs low–as there’s no doubt that mobile GSM expenses can hurt a company’s bottom line, especially where less than critical information must consume more bandwidth to reach the MQTT Broker. MQTT as a protocol makes assessments of the event-data’s urgency, and queues events’data for efficient transport.
4.Alarm Conditions Only: With a fieldbus setup like Modbus, polling events communicable over MQTT makes SCADA a low-cost proposition. Rather than sending Modbus read-commands over cellular to the supervisory level client, the Modbus control level client can queue alarm condition data and publish events to the MQTT broker. From the broker, the supervisory level(using devices such as personal computers, smartphones, and tablets)can be notified of subscribed-to topics and can publish new setpoints back to the Modbus client via the cloud broker.
5.Computing on the Edge: At a remote site IIoT integrated via MQTT, multiple sensors and (or) data processing units can communicate with one another, and if necessary, can be formed into a distributed cloud-like processing network that serves as a local extension of the cloud –in essence, fog computing or edge computing. A fog will be able to roll down from the cloud to the remote site, and much of the data processing work that would be done in the cloud (distributed processing over the internet) can be done right there at the remote site; rolling the fog down to your remote site would mean that only the most essential data would be published to client devices via MQTT Broker, which in turn would mean that cellular data consumption would be kept to a minimum.
References:
https://www.pubnub.com/blog/moving-the-cloud-to-the-edge-computing/
https://www.iotcentral.io/blog/Energy-savings-in-smart-factories-altizon