One question we asked ourselves from the beginning was how apps should talk to each other. After all, even the best app store is worthless if the apps you find in it can only communicate with each other poorly. We already know this comfort on the smartphone. Everyone knows that when you first start an app, you have to answer a few questions: Is the app allowed to access your contacts? Can the app access your photos? Can the app…? But that wasn’t always the case. In the beginning, each app had its own area, exchange with other apps was difficult.
Avoid mistakes of the past
We didn’t want to make that mistake, so we took a closer look at the established industrial apps. How do they communicate today? What do the app manufacturers like about it? Are there any difficulties for them? How should an API need to look like to make integration quick and easy? After numerous interviews, we had the necessary data together. They all have one thing in common: everyone can communicate and everyone uses a different protocol or exchange format. Set up an MQTT broker and all problems are solved – no way!
Real-time?
In addition, some apps want to communicate in “real time”. What does real-time capable mean in this context? Now you may have heard that real-time is a guarantee of deterministic behavior within a given time window. Do we guarantee real-time? No. Nobody can guarantee such a real-time. Anyone who guarantees you something like that is lying, because it’s not physically possible.
Why do we want “real time” anyway? Because there are machines that have to produce at an uncanny speed and for that they have to collect data from sensors and commission actuators at an uncanny speed.
What can we do? We can approximate deterministic behavior through testing and measurement.
How can we?
Latency, throughput, and bandwidth must be within a certain corridor through traceable and repeatable measurements in order to implement high-speed applications. If we perform these measurements after changes have been made to the program code, we can quickly identify and fix any deviations.
And if things go wrong in live operation? For that, we need to write resilient applications. Just as (almost) no program simply crashes anymore, in the future no machine should crash if one of the corridors is left.
We found the dragon
What started with a simple question has now quickly become complex, and the deeper you go into it, the more complex it gets. So how did we proceed? We then looked at what the market already offers today for the keywords “data exchange” and “real-time”. In the process, we came across the open source project Zenoh (Zenoh – The Zero Overhead, Pub/Sub, Store, Query, and Compute Protocol.).
Basically, the Zenoh project is an active open-source project with almost 20 contributors, and +150 usages. There are already 80 forks, which indicates a broad interest even in the early stage. With the Eclipse Foundation there is a serious owner whose intentions are known. Therefore, no surprises like “Hi guys, we will develop Zenoh as closed source starting tomorrow” are to be expected. Currently, releases are still very irregular, but there is from time to time a new version.
Industrial protocols in comparison
In the following, we compared Zenoh compared with well-known protocols from the industrial environment. The comparison refers to Zenoh, MQTT, ZeroMQ, DDS and OPC UA.
| Parameter/Protocol | Zenoh | MQTT | ZeroMQ | DDS | OPC UA |
|---|---|---|---|---|---|
| Messaging Type | Pub/Sub/Pull | Pub/Sub | Pub/Sub, Request/Reply, Radio/Dish (draft), Client/Server (draft) | Pub/Sub | Pub/Sub, Client/Server |
| Connection | TCP/IP | TCP/IP | TCP/IP, UDP/IP | TCP/IP, UDP/IP, Shared Memory | TCP/IP |
We have compared these protocols with each other. For this purpose, we have selected some criteria that are particularly relevant in industrial applications.
Encoding
Encoding describes the possibility of describing the data as simply and as accurately as possible. 10 means that the encoding is very well solved, and the user has it easy to interpret the data correctly, 0 means that the encoding possibilities are basically not given.
Speed
Speed refers to the speed of a message from the sender to a receiver. 10 is very fast, 0 is very slow.
Connectivity
Connectivity describes the possibility and simplicity to interact with the protocol. If libraries and examples are available, how well the protocol can be integrated into existing infrastructure. 10 indicates very good connectivity, while 0 indicates very poor connectivity.
Maturity
Maturity describes how established the protocol is today. 10 means that it is a fixed component of many products and is well known and used worldwide. 0 means that it is not yet widespread and stable.
Complexity
Complexity describes how easy it is to use the existing interfaces of the protocol. 10 means that there are few very simple interfaces, 0 indicates many interfaces that are very complicated to use.
Footprint
Footprint is the memory that the protocol occupies in flash. 10 means it uses very little memory, 0 means the protocol uses a lot of memory.
The factors are subjective and correspond to empirical values from the use of these protocols. They do therefore not represent objectively measured key figures.
Request performance whitepaper
This research has shown us that Zenoh is the ideal basis for our data layer. With simple means we can build bridges to protocols like MQTT or OPC UA and for the necessary speed we go directly to the API. As mentioned above, these are subjective classifications we made based on our experience. After integrating Zenoh, we then did intensive performance tests to prove our subjective impressions with numbers. We managed to do this in an impressive way that will surprise you.
You want to know what kind of latency, throughput and bandwidth we achieve with Zenoh’s Dragon Power? Then write to us to get our free whitepaper.
