Introduction.
It is very common to read about MQTT protocol that it is very lightweight in terms of network traffic:
MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth.
(Quote from MQTT home page).
At the same time, OPC UA is often considered heavier than MQTT.
For me, this was not something obvious and expected. Because the most popular encoding used in OPC UA is TCP binary, which usually is more efficient and lightweight than free text formatting used in MQTT payloads.
When I found this report by Johnathan Hottell, about OPC UA and MQTT benchmarks and saw that the MQTT payload is JSON formatted (in which each data value transferred includes multiple key-value pairs, for the values itself and for the timestamp), I thought, how come this can be lighter than OPC UA binary formatted payload? And decided to reproduce these tests myself.
Test methodology.
OPC UA Server and Variables.
In the initial tests, I picked the same number and type of data variables. And later decided to re-run tests, in a more controlled setup. I thought that for easier reproducing, it is worth using a popular and easily available OPC UA server as a data source, which can provide simulated data. OPC UA C++ Demo Server from Unified Automation was the obvious choice. The set of default variables does not have a number of variables of types used in the tests run by Johnathan Hottell, therefore I had to select a different set of variable types, but still, the total number of variables is 24. Their node identifiers can be found in the Excel file with test results.
MQTT Broker.
EMQX broker running as a Docker container was chosen, because of easy deployment and use, and support for secured connections out of the box, without generating and installing the SSL certificate.
Test applications generating OPC UA and MQTT traffic.
2 applications that can convert OPC UA data to MQTT were used:
- ogamma Visual Logger for OPC, the product of our company. For tests, you can use its Free Community Edition. For instructions on how to install it and use it, please refer to its online User Manual. Version 2.1.4 was used.
- Cogent DataHub from Skkynet.From this link, you can download the trial version. Used version 9.0.10.747.
Using OPC UA to MQTT converter applications makes sure that the same data values are collected over OPC UA connection, and then published to the MQTT broker, as well as received by the subscriber application.
As MQTT Subscriber, MQTT Explorer version 0.4.0 Beta-1 was used.
Measuring network traffic.
To capture OPC UA and MQTT packets, WireShark was used. 2 instances - 1 for OPC UA traffic on port 48010 was running, and the second for MQTT traffic on port 1883 for non-secure connections, and 8883 for secured connections.
For each test case, 4 metrics were collected:
- Size of file, where captured packets are saved from WireShark, in Kb.
- The number of captured frames.
- Total frames size - the sum of all network packets sizes. This includes all protocols, can be viewed in Wireshark via menu Statistics / Protocol Hierarchy, line Frame, column Bytes, converted to Kb.
- OPC UA payload size - as shown in line OPC UA Binary Protocol, column Bytes in Wireshark, dialog window opened by menu Statistics / Protocol Hierarchy, converted to Kb.
- MQTT payload size - as shown in line MQTT Telemetry Transport Protocol (in non-secure mode), or Transport Layer Security (on secured mode), column Bytes in Wireshark, dialog window opened by menu Statistics / Protocol Hierarchy, converted to Kb.
Configuration of test applications.
Each test application is configured to collect data from the OPC UA Server for selected 24 variables and log data to the MQTT broker. For configuration steps, please refer to the documentation of the product.
In the OPC UA side, both Sampling interval and Publishing should be set to 1 second.
MQTT Topics for variables in ogamma Visual Logger for OPC were set to Test24/[VariableDisplayName]. For example, for the variable with browse path Objects/Demo/001_Dynamic/Scalar/Boolean it is set to Test24/Boolean.
In Cogent DataHub, topics were a little bit longer, set to Test24/[Browse Path]. For example, Test/Demo/Dynamic/Scalar/Boolean.
The MQTT payload was set to the variable value, converted to a string (not JSON format, to keep payload size smaller).
Running tests.
Test applications should be shut down before starting tests.
First, 2 Wireshark instances should start. They should not detect any packets yet. Then one of the test applications starts. Wireshark should display captured packets. After 5 minutes, the test application stops, and no more network activity should be seen in Wireshark. Capturing stops, and packets saved into files. And then metrics can be taken: file size and data displayed in the dialog window Statistics / Protocol Hierarchy.
For each application used (ogamma Visual Logger for OPC and Cogent DataHub), tests run 4 times:
- Both OPC UA and MQTT communication is in non-secure mode, and there is no subscriber connecting to the broker (the MQTT Explorer does not run).
- Both OPC UA and MQTT communication is in non-secure mode, and MQTT Explorer runs, with a subscription to the topic Test24/#. That is, data is delivered from Publisher to the Subscriber.
- Both OPC UA and MQTT communication is in secured mode, and there is no subscriber connecting to the broker (the MQTT Explorer does not run).
- Both OPC UA and MQTT communication is in secured mode, and MQTT Explorer runs, with a subscription to the topic Test24/#. That is, data is delivered from Publisher to the Subscriber.
Test Results
Zip file with all captured packet files and test results in Excel file can be downloaded from here.
The summary of collected test results is given in the table below.
Conclusion
Total network traffic in the case of using MQTT protocol is multiple times (from 3.76 to 7.91 depending on the test case) higher than in OPC UA. Which does not correlate with results published by Johnathan Hottell.
Next Steps
It would be interesting to see what the metrics would look like if the MQTT payload is formatted in SparkPlugB, especially in compressed format. We did not have such an application converting from OPC UA to SparkPlugB (not implemented yet in our application, but it is in the roadmap, so stay tuned!). Perhaps in this case results will correlate with the results published by Johnathan Hottell.
If you can reproduce such tests, please share them with us!
Recently, the Open Letter to OPC Foundation from a Manufacturing End User was published on LinkedIn. The letter then was discussed in this YouTube video, with the participation of his author.
As my company is an independent software development company with a specialization in OPC UA, I was touched by this letter and the video and wrote my thoughts in the comments section to the video. But for unknown to me reason it disappeared, and I decide to publish it here in my company's Blog section:
I am not sure, should I laugh here or cry. If so many difficulties in understanding of the OPC UA can be observed, you might be right that there is more to do by the OPC Foundation in delivering core principles of the OPC UA to the mass audience, the end-users particularly. Although OPC Foundation is busy organizing events and presentations, like recent OPC Days International, and there is a new initiative: OPC UAcademics (https://opcfoundation.org/resources/opcuacademic/), still a long way ahead to go I guess.
My company is an independent software development company, and a member of the OPC Foundation. But I am here not representing this organization, just my personal feedback.
I do have experience participating in the OPC UA Working Group, not PubSub though. From my experience, I can tell that representatives from any member company, be it as large as Microsoft or as small as my tiny company, have the same rights to bring ideas, write/edit specifications and participate in shaping this standard. I think almost any major industrial automation software and hardware vendor have a member in a Working Group they are interested in (there many groups there, for main parts and for companion specifications). And while it is in a draft, working document state, the specification (or rather some its part/edition) is reviewed by members of the User Group, everyone can evaluate, how will it work with their product which is either released product or just in design/prototype state. And then if there are concerns, or suggestions, or proposals to change/edit/propose a completely different version of the draft, all of them are discussed, and if makes sense and supported by the majority, accepted.
So I would say that specifications are created in a fair and democratic way, taking into account any member organization's needs.
In my strong opinion, not possible that one large corporation comes and starts to dictate course/adopt specifications to fit their product line, and block others.
Therefore, if you have a strong belief that SparkPlug is a much better and more efficient format than PubSub to convey data from OPC UA servers to the Clouds, I think you will be welcome to join and change the world of OPC UA. I cannot find Cirrus in the members' list, and not aware of their experience. To my knowledge, yes, Microsoft was among those who came with an initiative to add support for PubSub, and AMQP was considered as a protocol. I haven’t heard of Cirrus in this regard. BTW, AMQP is very similar to MQTT, and Rabbit MQ broker is open source, so I would say even if AMQP was chosen, it would not mean being locked to the single vendor of the broker.
In my opinion, the consequence of this way of creating the specification (democratic and open to all members) is why the specifications are so big and might look too wide, multiple parts, because they are designed to cover almost any use case members (and their customers) might encounter, now or in the foreseeable future. And part 14 PubSub was born as a result of this openness as I understand. Walker, maybe you know more than I know though.
And here is when we have so many OPC UA profiles and facets. And Matthew, you are right, it might be complicated and confusing, hard to understand.
Therefore, I would not recommend the end-users start reading specifications, understand all those profiles, facets, etc.
Let me ask you: do you use any USB device, like a mouse, or keyboard? Do you know, what version they support: 3.1, 3.0, Type-C, 2.0? And did you read USB specifications before connecting your mouse to your laptop? BTW, right now I did a search and found the one for USB 3.1, and it is 631 pages (including appendixes). Not going to read it, thank you! Usually, I just try to plug in USB, and 50% of the time I have to turn it around (which is not a big deal for me) and it works, and then I forgot about it. I think the same with OPC UA.
If you are on the OPC UA client-side like you have SCADA or HMI, or maybe software like our ogamma Visual Logger for OPC, you don't need to worry about what is in the server-side, what profile it conforms to, etc. Because usually all kinds of variations you can observe exist only on the server-side - some devices have too small resources and can have just one subscription, with only 10 monitored items (tags) or no support for subscriptions at all, only read. Or they can only allow 2 sessions to be opened at a time. But clients usually don't have all those limitations, they have no limits like I need at least 100 variables to read, cannot read just 3 or 99. If the server can offer you only 10 tags, no problem for the client.
BTW – the common misunderstanding of the OPC UA is that it does not report by exception, only with PubSub you can get the report by exception feature. Wrong – regular OPC UA data access subscriptions (without PubSub) provide you report by exception. And almost any OPC UA server supports it. And it is lightweight and performant – currently, I am running my application collecting data for 200,000 variables changing every second with no problem at all, in a regular workstation, with all 3 parts – server, client, and database in the same box.
Or another case: if you a Developer of some existing software, and want to add support for OPC UA (client or server, or both) - I would not say don't read the specs at all, I would say: go through (note: not read, just go over headlines and see what is the structure) the part 1, and part 4, but do not spend longer than 1 day. Why - because there are available OPC UA SDKs for most popular programming languages, open or close source, pick one, and they will save your time. No need to understand exactly the whole specs.
In my case, for our product, I did select OPC UA as the single protocol to collect industrial data from all kinds of sources, because, first, many PLCs support it built-in. Example - Siemens PLCs. And second, with available in-the-market wrappers, you can connect to a wide range of classic OPC servers. And with OPC UA Server for Modbus, you can connect to a wide range of legacy devices. So the reason for choosing OPC UA as a major protocol for our product – not having some special relations with OPC Foundation or Microsoft, but because it is universal.
I did have some connectivity issues with other OPC UA Servers (our customers’ as well vendors’ at OPC Workshops), but all these were implementation errors on our side, and once they were fixed, have no issues with connecting to any OPC UA Severs our customers have. Works just like a USB.
On the destination database side, we currently support regular MQTT among a whole bunch of other time-series databases, like InfluxDB, variations of SQL, Apache Kafka. In the roadmap - add support for more flexibility in the MQTT payload format: from current just decimal/numeric values to template-based JSON payload, as well as OPC UA PubSub JSON format and hopefully SparkPlug too.
So, Matthew, if you cannot find other solutions that support PubSub or SparkPlug, check out with us later.
Definitely, I see that OPC UA has a bright future. And I don’t think it will have this future on the expense / taking place of other protocols or standards like SparkPlug. Just like as Walker mentioned in one of his videos that multiple religions can co-exist in peace because in the end all of them about the same God.
