Eine Frage, die wir uns von Anfang an gestellt haben, war, wie die Anwendungen miteinander kommunizieren sollten. Denn selbst der beste App-Store ist wertlos, wenn die darin befindlichen Apps nur schlecht miteinander kommunizieren können. Diesen Komfort kennen wir bereits vom Smartphone. Jeder weiß, dass man beim ersten Start einer App ein paar Fragen beantworten muss: Darf die App auf Ihre Kontakte zugreifen? Kann die App auf Ihre Fotos zugreifen? Kann die App…? Aber das war nicht immer der Fall. Zu Beginn hatte jede App ihren eigenen Bereich, der Austausch mit anderen Apps war schwierig.
Die Fehler der Vergangenheit vermeiden
Diesen Fehler wollten wir nicht machen und haben uns die etablierten industriellen Anwendungen genauer angesehen. Wie kommunizieren sie heute? Was gefällt den App-Herstellern daran? Gibt es irgendwelche Schwierigkeiten für sie? Wie sollte eine API aussehen, um eine schnelle und einfache Integration zu ermöglichen? Nach zahlreichen Gesprächen hatten wir die notwendigen Daten zusammen. Sie haben alle eines gemeinsam: Jeder kann kommunizieren und jeder verwendet ein anderes Protokoll oder Austauschformat. Einen MQTT-Broker einrichten und alle Probleme sind gelöst – das geht nicht!
In Echtzeit?
Darüber hinaus wollen einige Anwendungen in “Echtzeit” kommunizieren. Was bedeutet “Echtzeitfähig” in diesem Zusammenhang? Sie haben vielleicht schon gehört, dass Echtzeit eine Garantie für deterministisches Verhalten innerhalb eines bestimmten Zeitfensters ist. Garantieren wir Echtzeit? Nein. Niemand kann eine solche Echtzeit garantieren. Jeder, der Ihnen so etwas garantiert, lügt, denn das ist physikalisch nicht möglich.
Warum wollen wir überhaupt “Echtzeit”? Denn es gibt Maschinen, die mit einer unheimlichen Geschwindigkeit produzieren müssen, und dafür müssen sie in einer unheimlichen Geschwindigkeit Daten von Sensoren sammeln und Aktoren ansteuern.
Was können wir tun? Wir können uns dem deterministischen Verhalten durch Tests und Messungen annähern.
Wie können wir das?
Latenz, Durchsatz und Bandbreite müssen durch nachvollziehbare und wiederholbare Messungen innerhalb eines bestimmten Korridors liegen, um Hochgeschwindigkeitsanwendungen realisieren zu können. Wenn wir diese Messungen durchführen, nachdem Änderungen am Programmcode vorgenommen wurden, können wir eventuelle Abweichungen schnell feststellen und beheben.
Und wenn im laufenden Betrieb etwas schief geht? Dazu müssen wir robuste Anwendungen schreiben. So wie (fast) kein Programm mehr einfach abstürzt, sollte in Zukunft keine Maschine mehr abstürzen, wenn einer der Korridore verlassen wird.
Wir haben den Drachen gefunden
Was mit einer einfachen Frage begann, ist schnell komplex geworden, und je tiefer man in die Materie eindringt, desto komplexer wird sie. Wie sind wir also vorgegangen? Wir haben uns dann angeschaut, was der Markt heute schon zu den Stichworten “Datenaustausch” und “Echtzeit” bietet. Dabei stießen wir auf das Open-Source-Projekt Zenoh(Zenoh – The Zero Overhead, Pub/Sub, Store, Query, and Compute Protocol.).
Das Zenoh-Projekt ist ein aktives Open-Source-Projekt mit fast 20 Mitwirkenden und über 150 Verwendungen. Es gibt bereits 80 Forks, was darauf hindeutet, dass bereits im Anfangsstadium ein breites Interesse besteht. Mit der Eclipse Foundation gibt es einen seriösen Eigentümer, dessen Absichten bekannt sind. Daher sind keine Überraschungen wie “Hallo Leute, wir werden Zenoh ab morgen als Closed Source entwickeln” zu erwarten. Gegenwärtig sind die Veröffentlichungen noch sehr unregelmäßig, aber von Zeit zu Zeit gibt es eine neue Version.
Industrieprotokolle im Vergleich
Im Folgenden vergleichen wir Zenoh mit bekannten Protokollen aus dem industriellen Umfeld. Der Vergleich bezieht sich auf Zenoh, MQTT, ZeroMQ, DDS und OPC UA.
| Parameter/Protokoll | Zenoh | MQTT | ZeroMQ | DDS | OPC UA |
|---|---|---|---|---|---|
| Art der Nachrichtenübermittlung | Pub/Sub/Pull | Pub/Sub | Pub/Sub, Request/Reply, Radio/Dish (draft), Client/Server (draft) | Pub/Sub | Pub/Sub, Client/Server |
| Verbindung | TCP/IP | TCP/IP | TCP/IP, UDP/IP | TCP/IP, UDP/IP, Shared Memory | TCP/IP |
Wir haben diese Protokolle miteinander verglichen. Zu diesem Zweck haben wir einige Kriterien ausgewählt, die in industriellen Anwendungen besonders relevant sind.
Kodierung
Die Kodierung beschreibt die Möglichkeit, die Daten so einfach und so genau wie möglich zu beschreiben. 10 bedeutet, dass die Kodierung sehr gut gelöst ist, und der Nutzer es leicht hat, die Daten richtig zu interpretieren, 0 bedeutet, dass die Kodierungsmöglichkeiten grundsätzlich nicht gegeben sind.
Geschwindigkeit
Die Geschwindigkeit bezieht sich auf die Geschwindigkeit einer Nachricht vom Absender zum Empfänger. 10 ist sehr schnell, 0 ist sehr langsam.
Konnektivität
Konnektivität beschreibt die Möglichkeit und Einfachheit der Interaktion mit dem Protokoll. Wenn Bibliotheken und Beispiele verfügbar sind, wie gut das Protokoll in die bestehende Infrastruktur integriert werden kann. 10 bedeutet eine sehr gute Konnektivität, während 0 eine sehr schlechte Konnektivität bedeutet.
Reifegrad
Der Reifegrad beschreibt, wie etabliert das Protokoll heute ist. 10 bedeutet, dass es ein fester Bestandteil vieler Produkte ist und weltweit bekannt und verwendet wird. 0 bedeutet, dass sie noch nicht weit verbreitet und stabil ist.
Komplexität
Die Komplexität beschreibt, wie einfach es ist, die vorhandenen Schnittstellen des Protokolls zu nutzen. 10 bedeutet, dass es nur wenige sehr einfache Schnittstellen gibt, 0 steht für viele Schnittstellen, die sehr kompliziert zu bedienen sind.
Footprint
Footprint ist der Speicher, den das Protokoll im Flash belegt. 10 bedeutet, dass es sehr wenig Speicherplatz benötigt, 0 bedeutet, dass das Protokoll sehr viel Speicherplatz benötigt.
Die Faktoren sind subjektiv und entsprechen den Erfahrungswerten aus der Anwendung dieser Protokolle. Sie stellen daher keine objektiv gemessenen Kennzahlen dar.
Whitepaper zur Performance anfordern
Diese Untersuchung hat uns gezeigt, dass Zenoh die ideale Basis für unsere Datenschicht ist. Mit einfachen Mitteln können wir Brücken zu Protokollen wie MQTT oder OPC UA bauen und für die notwendige Performance gehen wir direkt über die API. Wie bereits erwähnt, handelt es sich hierbei um subjektive Einstufungen, die wir auf der Grundlage unserer Erfahrungen vorgenommen haben. Nach der Integration von Zenoh haben wir dann intensive Leistungstests durchgeführt, um unsere subjektiven Eindrücke mit Zahlen zu belegen. Dies ist uns auf eine beeindruckende Weise gelungen, die Sie überraschen wird.
Sie möchten wissen, welche Latenz, welchen Durchsatz und welche Bandbreite wir mit Zenohs Dragon Power erreichen? Dann schreiben Sie uns und fordern Sie unser kostenloses Whitepaper an.
