As connectivity demands are being taken to new levels, and concepts such as the Industrial Internet of Things and Industry 4.0 start to take a more shape, we are increasingly being asked to assist our customers to solve connectivity demands across the factory floor, the corporate IT network and multiple locations.
The two obvious solutions are MQTT and OPC UA, but what if you have a mixture of both? Both are equally valid, but also distinctly different to each other. MQTT is a lightweight messaging protocol designed for connecting devices that have unreliable or low bandwidth connections especially when the power supply may be limited. OPC UA on the other hand is the modern replacement for OPC DA which only worked on Windows devices and relied on the notorious DCOM to work. OPC UA can use TCP or SOAP and is more or less platform independent so it is possible to run it on either an embedded microprocessor or a Linux server farm.
Both OPC UA and MQTT have built in security which OPC DA lacked, though surprisingly this is often switched off with companies relying on their “fence security” firewalls to secure the network rather than the built-in encryption available from the platform. This could be due to lack of information on the feature, or simply for historical reasons: “it’s just the way we’ve always done it”. With IT security generally getting stronger and more important than ever, it is vital that complacency is not allowed to sneak in alongside the potential threats.
Connecting network devices to a cloud-based web service
Either OPC UA or MQTT can be used depending on a number of factors but essentially it comes down to your own circumstances. Factors such as the amount of data involved and internet connection reliability and speed will have to be taken into consideration. If you have a large amount of data with a good internet connection, then OPC UA will be the best fit.
However, if you are trying to pass telemetry information from a train on the move, power is not a problem but using GSM technology to broadcast through patchy signal areas would be better suited to MQTT.
Other considerations could be whether you have room and power for a PC with a OPC client, or would an embedded device be a better fit, with no Windows updates etc to worry about?
Multiple protocol requirements across one network
If your network has areas where OPC UA is the best fit, and others where MQTT is a better option, then allowing the two to communicate into one hub can bring its own challenges. The Softing dataFEED OPC suite has the ability to read from up to 100 OPC Clients from multiple manufacturers, and then use either the built in OPC UA, MQTT Broker or REST protocol to connect to your Cloud service. It is also possible to enable “store and forward” to recover the data if a connection error causes a pause in communications.
This combined with Softing’s edgeGate or echoCollect gateways in the train example given above, would remove the need for a PC in that instance but would still gather data from Ethernet or Serial interfaces and put them directly into databases both locally and in the cloud. Should the connection be interrupted, they have the same “store and forward” functionality.
