Vor ein paar Jahren revolutionierte Apache Kafka die Verarbeitung von Datenströmen im Rechenzentrum. Der Streamingdienst ist ein so genanntes Pub-Sub-Messaging-System. Kafka sammelt Informationen aus unterschiedlichen Quellen (Produzenten) und stellt sie Anwendungen oder Diensten (Konsumenten) einheitlich zur Verfügung. Pub/Sub ist ein asynchroner Messaging-Dienst. Damit werden Nachrichten erzeugende Systeme und Services von den Anwendungen, welche die Nachrichten verarbeiten, entkoppelt.
Mit seinem Ansatz beschleunigte Kafka Entwicklungs- und Innovationszyklen in Unternehmen merklich. Daten mussten nicht mehr aufwendig für bestimmte Anwendungen oder Analysen aufbereitet und bereitgestellt werden. Ein Konsument abonniert einfach die für ihn relevanten Daten von einem oder mehreren Produzenten aus dem Datenstrom.
Legacy zukunftsfähig machen
Mit Diensten wie Kafka lässt sich Altes und Neues verbinden. Silos werden aufgebrochen und die Zusammenarbeit vereinfacht. Eine große Herausforderung in der IT sind nach wie vor die vielen proorietären und Lefacy-Dienste bzw. Protokolle. Schmerzhaft ist das besonders für Branchen, die auf Geschwindigkeit und Sicherheit gleichermaßen angewiesen sind. Eine dieser Branchen ist die Automobilindustrie mit dem Megatrend autonomes fahren. In modernen Autos liefern bis zu 150 Sensoren mehr als ein halbes Terabyte an Informationen – pro Tag. Bei autonomen Fahrzeugen rechnen Experten mit bis bis zu 4 Terabyte am Tag.
Neben den Einträgen im Fehlerspeicher sammelt ein Auto viele weitere Daten inkl. GPS-Position, wie oft sich der Gurt gestrafft oder die Batterie ge- und entladen hat, wie lange das Licht an war und wie oft es an- oder ausgeschaltet wurde, Kilometerstände, Motordaten, u. v. a. m. Beim autonomen Fahren werden eine Vielzahl weiterer Daten gesammelt, verarbeitet, ausgewertet und beachtet.
Security ist nicht Safety
In einigen Bereichen wird bei der Sicherheit zwischen der Sicherheit von Daten oder Systemen und physischer Sicherheit, also der Sicherheit von Leib und Leben, unterschieden. In der Automobilindustrie müssen Daten nicht nur vor Verlust oder Kompromittierung geschützt werden. Das wesentlich größere Risiko ist ein potentieller Personenschaden; z. B. wenn elektromotorische Gurtstraffer oder Airbags versagen, Autos in einer Gefahrensituation falsch oder zu langsam reagieren, Bremsen nicht funktionieren bzw. Fahrzeuge absichtlich in Gefahrensituation gebracht werden. Zu viele und irrelevante Daten sowie Zeit sind erhebliche Risikofaktoren.
Die Verwendung zahlreicher, nicht einheitlich spezifizierter Bussysteme wie CAN, LIN, Flexary und MOST mit all ihren kommunikativen Einschränkungen sowie Sicherheitsvorschriften und zentralistische Ansätze erhöhen die Komplexität und damit auch Fehleranfälligkeit. Komplexe und zentralistische Architekturen sind zudem wenig agil. Das ist nicht nur für die Innovationsfähigkeit kritisch. Änderungen und damit auch Patches und Fehlerbehebungen sind alles andere als trivial. Z. B wird die Konnektivität zwischen den verschiedenen Elementen eines Fahrzeugs zentral verwaltet. Es dauert mehrere Wochen, eine neue Verbindung hinzuzufügen. Die Integration neuer Software kann mehrere Monate dauern. Verzögerung bis zum Start-of-Production auf einen Tag oder gar eine Stunde zu reduzieren, hilft die Kosten von mehreren Milliarden auf eine Million Euro zu reduzieren.
ZettaScale ist ein europäisches Startup mit dem Ziel, jedem vernetzten Objekt – Mensch oder Maschine – zu ermöglichen, uneingeschränkt und sicher zu kommunizieren sowie Daten zu speichern bzw. zu verarbeiten. Dazu setzt das französische ADLINK-Spin-off auf das Eclipse-Inkubationsprojekt Zenoh.
Ein Protokoll verändert alles
Moderne Anwendungen sind Daten-zentriert und stellen neue Herausforderungen an die Datenverarbeitung. Statt immer neuer Overlays und Schnittstellen sollen auf höherer Ebene angesiedelte Protokolle wie MQTT oder DDS Daten und Anwendungen näher zueinander bringen.
Zenoh gilt als das am besten für V2X-Anwendungen im autonomen und assistierten Fahren geeignete Protokoll und unterstützt unterschiedliche Netzwerktechnologie (Ethernet, Time-Sensitive Networking (TSN), Wi-Fi, 4G/5G) sowie verschiedene Topologiekonfigurationen wie Peer-to-Peer, Meshed, Brokered oder Routed. Über einen Plugin-Mechanismus kann Zenoh mit anderen Middlewares wie MQ Telemetry Transport (MQTT), Data Distribution Service (DDS) und Hypertext Transfer Protocol (HTTP) sowie Speichertechnologie wie InfluxDB, RocksDB und MariaDB integriert werden.
Das Pub/Sub/Query-Protokoll stellt Daten sowohl in Bewegung als auch im Ruhezustand standorttransparent über heterogene Systeme hinweg bereit und löst eine Herausforderung der zentralisierten Datenspeicherung. Der sternförmige Nachrichtenfluss zwischen Client und Server in zentralistischen Architekturen kostet Zeit und ist ein Single-Point-of-Failure. Die Unabhängigkeit von der Hierarchie und ein Netz intelligenter Knoten mit einem Bewusstsein voneinander unterscheidet Zenoh von anderen Middlewares (MQTT, AMQP, DDS, CoAP).
Zenoh bietet ein Standard-Kommunikationsprotokoll, mit dem automatisierte und assistierte Fahr Fahrsysteme Sicherheitsdaten veröffentlichen, die vom Sicherheitsüberwachungssystem abonniert werden können. Dabei erreicht Zenoh eine Peak-Performance von bis zu 70Gbps bei 8Kb Nutzlast. Das ist 3,3x höher als DDS, 23x höher als Kafka und 35x höher als MQTT. Die Latenzzeit liegt bei 10us.
Ein Grund für die Unterschiede sind die diversen Headeraufbauten. Bei MQTT steigt der Übertragungsaufwand linear mit der Länge des Topic-Namens. Der Topic-Name ist eine UTF-8 kodierte Zeichenkette. Der minimale Übertragungsaufwand beträgt 6 Byte plus die Länge des Themennamens. Ein MQTT-Topic mit dem Namen com/acme/mysystem/devicekind/id bedeutet 32 Byte. Bei DDS entspricht der Overhead 56 Bytes – und dabei werden noch keine Inline-QoS gesendet.
Zenoh geht einen Frame-basierten Weg. Ein Frame kann mehrere Nachrichten enthalten. Auf diese Weise werden Informationen effizient verpackt und übertragen. Der minimale Overhead bei Zenoh beträgt 3 Byte. Durch den Rahmen werden 2 Byte hinzugefügt, was den Overhead auf insgesamt 5 Bytes erhöht. Durch die Fähigkeit, Nachrichten zu stapeln, ist der Frame-Aufwand vernachlässigbar -> (3N+2)/N.
Vergleich der Header von MQTT, DDS und Zenoh (v. l. n. r.):
Wird über den Zeitraum eines Jahres jede Minute eine Datenprobe gesendet, verursacht DDS einen Leitungsmehraufwand von 1,8 Gbps; Zenoh käme auf 157Mbps. Daten, die von einem Offshore-Sensor erzeugt werden, verursachen in der Regel $8 pro MB. Folglich würden die Kosten für die Übertragung mit dem DDS-Protokoll $14.400 liegen. Die Ersparnis gegenüber Zenoh mit nur $1.256 beträgt mehr als 10k $ pro Jahr. Aber nicht nur die Kosten sind es wert, betrachtet zu werden. Kommunikationsprotokolle können einen großen Einfluss auf den Energieverbrauch haben. Insgesamt müssen immer beide Dimensionen betrachtet werden. Sowohl den ökonomischen als auch den physischen bzw. ökologischen Fußabdruck gilt es zu minimieren.
ZettaScale verspricht Anwendern zudem eine einfache Bedienung entweder über die Konsole oder die graphische Oberfläche.
Zetta (Z) ist eine Platform as a Service. Z-PaaS unterstützt Multi Cloud-Entwicklungen, Public/Private Clouds und kann Z-Router vor Ort verwalten. Der Zenoh-Router von Zetta (Z-Router) kann eigenständig oder integriert mit Z-PaaS verwaltet werden. Die Z-Connectors sind Konektoren zu Protokollen, z.B. DDS oder MQTT und Datenbanken wie RocksDB, InfluxDB, usw. Mit den Z-Tools bietet ZettaScale ein umfangreiches Set an Tools für die Überwachung, Verwaltung, Administration, Debugging, etc. Die Z-API ist eine programmierbare Schnittstelle für eine Vielzahl von Programmiersprachen (u. a. Python, C/C++, Rust) und Targets inkl. Arduino.
Um die Routing-Effizienz einschätzen zu können, wäre es gut, die Anzahl der verbrauchten Watt pro km zu kennen. Diese Information ist unmöglich zu beschaffen. Wir haben Forscher in verschiedenen Institutionen gefragt. Es ist nicht festzustellen.
Angelo Corsaro, CEO & CTO bei ZettaScale
