Databus vs. Database: 6 Schlüsselfragen, die jeder IIoT-Entwickler berücksichtigen muss

Das Industrial Internet of Things (IIoT) führt viele neue Konzepte ein, die oft auf vertrauten Computing-Prinzipien aufbauen, aber neu gestalten, wie Systeme operieren. Unter diesen sticht der „Databus“ als fundamentales Element hervor.

Die kommende IIC Referenzarchitektur v2 führt ein neues Pattern namens „Layered Databus“ ein. Während Details noch unter Review stehen, hat der Dokumentationsprozess Schlüsseldefinitionen und Best Practices geklärt.

Definition: Ein Databus ist eine datenzentrische Informations-Sharing-Technologie, die einen virtuellen, globalen Datenraum implementiert. Softwareanwendungen lesen und aktualisieren Einträge in diesem Raum, und Updates werden via Publish-Subscribe-Mechanismus propagiert.

Kernmerkmale:

1. Anwendungen interagieren direkt mit den Daten, ohne Intermediate-Wrapper.
2. Die Infrastruktur versteht die Daten, ermöglicht selektives Filtern und fortgeschrittenes Tooling.
3. Die Infrastruktur setzt Quality-of-Service (QoS) Garantien wie Rate, Reliability und Security durch.

Diese Eigenschaften führen zu Fragen, die beim Einführen von Databus-Konzepten in eine IIoT-Umgebung aufkommen. Die folgenden sechs Abschnitte adressieren die häufigsten Anfragen.

Frage 1: Wie unterscheidet sich ein Databus von einer Datenbank?

Kurze Antwort: Eine Datenbank speichert historische Daten für späteren Abruf, während ein Databus live, eingehende Daten managt und sie nach Eigenschaften neuer Informationen filtert.

Lange Antwort: Datenzentrik drückt sich durch drei Dimensionen aus:

• Interface: Die Daten selbst sind das primäre Interface; keine künstlichen Wrapper wie Messages oder Files.
• Verständnis: Die Infrastruktur kann die Daten interpretieren, ermöglicht Filterung, Suche und Tool-Integration.
• Governance: Das System setzt Regeln für Datenaustausch durch, etabliert eine Single Source of Truth und managt Datenlebenszyklen, Schemata und CRUD-Semantik.

Eine relationale Datenbank bietet beispielsweise einen strukturierten Storage-Layer, der Konsistenz erzwingt und globale Suche bietet. Sie definiert die „Wahrheit“ des Systems, weil gespeicherte Daten nicht korrupt oder verloren gehen können. Ein Databus hingegen bietet einen virtuellen globalen Datenraum, der Anwendungen das Schreiben und Lesen von Datenströmen erlaubt, während Middleware QoS-Regeln anwendet und nur Informationen liefert, die den Kriterien des Konsumenten entsprechen.

Frage 2: Verhält sich ein Databus wie eine Datenbank, die über ein Pub-Sub-Interface zugegriffen wird?

Kurze Antwort: Nein. Eine Datenbank impliziert persistente Speicherung; ein Databus bietet einen rein virtuellen, globalen Datenraum, der Daten persistieren kann oder nicht.

Lange Antwort: Betrachten Sie einen Kreuzungscontroller, der Fahrzeugpositionen innerhalb 200 m abonniert. Der Controller erhält Updates, die seine QoS-Constraints erfüllen (z. B. < 0,01 s Latenz, 100 Updates/s). Der Databus liefert Daten möglicherweise direkt ohne Speicherung, obwohl temporäres Caching auftreten kann, um Reliability-Anforderungen zu erfüllen.

Frage 3: Was bedeutet es, dass Teilnehmer direkt mit den Daten interfacen?

In message-zentrischer Middleware müssen Applikationen Details über den Peer kennen, wie Schema und erwartete Update-Raten, was Kopplung erhöht und Wiederverwendung behindert. Ein Databus abstrahiert diese Details; Applikationen lesen aus oder schreiben in den Datenraum über ein CRUD-Interface, spezifizieren nur die Daten und QoS, die sie brauchen. Die Infrastruktur handhabt Source Discovery, Filtering, Transport und Garantien.

Frage 4: Wie funktioniert selektives Filtern im Databus im Vergleich zu traditionellem Pub-Sub?

Traditionelles Pub-Sub leitet Messages lediglich an Subscriber weiter, oft ohne Payload-Inspektion. Selbst Content-Filtered Pub-Sub verlässt sich auf einfache Selektoren, die komplexe QoS nicht ausdrücken können. Ein Databus erlaubt einem Subscriber, detaillierte Kriterien zu spezifizieren (z. B. Fahrzeug innerhalb 200 m, bewegt sich > 10 m/s auf Kreuzung zu, 200 Hz Updates). Die Middleware setzt diese Constraints an der Source durch, drosselt, dropped oder buffert Daten, um den Vertrag zu erfüllen, und garantiert Liveliness.

Da Filterung am Producer passiert, erhält der Subscriber nur relevante Samples (z. B. 600 Updates pro Sekunde), was Bandbreite und Processing-Overhead drastisch reduziert bei gleichzeitiger Reliability-Garantie.

Frage 5: Wie unterscheidet sich ein Databus von einer CEP Engine?

Kurze Antwort: Ein Databus ist verteilte Middleware, die Daten basierend auf einfachen Filtern weiterleitet, während eine CEP Engine ein zentralisierter Service ist, der komplexe Event-Pattern evaluiert.

Lange Antwort: CEP Engines analysieren Streams, um benutzerdefinierte Patterns zu detektieren und Aktionen zu triggern, benötigen aber, dass alle Daten zu einem einzelnen Node geroutet werden. Ein Databus führt lokales Filtern an jeder Datenquelle durch und liefert nur matchende Samples an interessierte Konsumenten, skaliert so auf tausende Nodes ohne zentrale Flaschenhälse.

Frage 6: Was trieb die Schaffung des DDS-Standards und Databus-Konzepte an?

Early Adopters in Robotik, Defense und Large-Scale-Koordinationssystemen forderten Reliability, niedrige Latenz und selektive Discovery angesichts Komponentenausfällen. Diese Anforderungen führten zum DDS-Standard, der heute Anwendung in Healthcare, Transportation, Smart Cities und Energy Sektoren findet.

Um mehr über intelligente Software zu erfahren, die das IIoT formt, laden Sie unser Whitepaper The Secret Sauce of Autonomous Cars herunter.