How to unlock the power of MQTT for real-time data exchange and brownfield connectivity
What is MQTT?
Message queuing telemetry transport (MQTT) is a protocol. It has a broker and a client and can run over Ethernet. It was created by IBM in 1999 and was used in oil and gas. The idea was that it required low bandwidth and low power. It was standardized as an open protocol in 2014. How does it apply to automation and machine building?
Broker and client
First, let's understand that MQTT simplifies communications, because it decouples the subscriber/publisher idea. There is space decoupling, in which the clients are unaware of each other and only communicate to the broker. There is time decoupling, in which clients can publish and subscribe at different times. And there is synchronized decoupling, in which clients can operate asynchronously, without needing to wait on a response from each other.
What does that mean in simplified terms? If you, the client, are in a crowded room, being spoken to by a broker, and you have a question, then you don’t have to raise your hand or wait your turn. You just say it to the speaker, and the speaker will hear you. Or, at least, that is the idea. The broker must know you are out there and have continuity.
Clients must be configured as a subscriber, publisher or both. Brokers mediate all client-to-client communications. Brokers make sure the communication is routed properly. OT networks and machine builders are reliant on flexibility, scalability and real-time data exchange. MQTT allows this to happen. The beautiful thing is that MQTT can be leveraged to integrate old and new platforms, if brokers are used efficiently.
Gateway connection
One example is that if a factory or plant does not have a good infrastructure for a network, it may utilize a broker to get process areas connected without wiring. Gateways can bring OPC UA, OPC DA, Modbus, DNP3, Ethernet/IP, Profinet, SQL, MQTT and Representational State Transfer (ReST) to a centralized data hub. There is also the capacity to do OPC UA over an MQTT broker. The gateway selected and the architecture are key. Creating an MQTT namespace configured on the server may move the data quickly.
Keys to success include mapping the MQTT payload, mapping MQTT topics and implementing transformation logic.
Get your subscription to Control Design’s daily newsletter.
Network interface
What is the big deal? It’s important as integrators to understand that, when you set up a new machine with older machines, the chances of having to work with old protocols increase.
MQTT allows for a reliable convergence and manageable network interface in a brownfield environment, according to “Brownfield Devices in IIoT,” a white paper published by Fortiss. This means creating an intent-driven network with interactions of property affordance, action affordance and event affordance. In short, the data is merged at the network level using namespace and multi-party synchronization. A web of things (WOT) is used to bring protocols of different devices to a central location.
Understanding that network levels can equate to time helps to support operational optimization. For instance, field devices are at level 0 and communicate in microseconds. Field to programmable logic controllers communicate in seconds at Level 1. Level 2 is at process management and requires minutes for a supervisory control and data acquisition (SCADA)/human-machine interface (HMI). Manufacturing execution system (MES) devices track on Level 3, in hours, and function as operational maintenance. Business planning is Level 4 and has a time factor of days. Using MQTT to gather and convert gives more control, from the floor to the cloud. HiveMQ puts the goals of the smart factory at agile software delivery, faster mean time to recovery, centralized command and control, and consistent but flexible software architecture. MQTT is a main tool to accomplish this. Why? Bi-directional connectivity, interoperability and OT security.
