Databus vs. Database:Die 6 Fragen, die sich jeder IIoT-Entwickler stellen muss

ht wirklich darin, dass alte Daten in einer (wahrscheinlich zentralisierten) Datenbank gespeichert sind, und zukünftige Daten, die von einem verteilten Datenraum direkt an die Anwendungen gesendet werden.

Frage 4:"Die Infrastruktur versteht und kann die Daten daher gezielt filtern." Gilt das nicht für alle Pub-Sub, wo Sie sich für "Events" anmelden können, die Sie interessieren?

Die meisten Pub-Sub ist sehr primitiv. Eine Bewerbung "meldet Interesse", und dann wird einfach alles an diese Bewerbung gesendet. So könnte beispielsweise ein Kreuzungskollisionserkennungsalgorithmus "Fahrzeugpositionen" abonnieren. Die Infrastruktur sendet dann Nachrichten von jedem Sensor, der Positionen erzeugen kann, ohne die Daten in dieser Nachricht zu kennen. Selbst die "Inhaltsfilterung" von pub-sub bietet nur sehr einfache Spezifikationen und erfordert, dass das System vorauswählt, was für alle wichtig ist. Es gibt keine wirkliche Kontrolle des Flusses.

Ein Datenbus ist viel ausdrucksstärker. Diese Kreuzung könnte sagen „Ich bin nur an Fahrzeugpositionen innerhalb von 200 m interessiert, die sich mit 10 m/s auf mich zubewegen. Wenn ein Fahrzeug in meine Spezifikationen fällt, muss ich 200 Mal pro Sekunde aktualisiert werden. Sie (der Datenbus) müssen mir garantieren dass alle Sensoren, die diesen Algorithmus speisen, versprechen, Daten so schnell zu liefern ... nicht langsamer oder schneller. Wenn ein Sensor 1000 Mal pro Sekunde aktualisiert, dann schicke mir nur jedes 5. Update. Ich muss auch wissen, dass du aktuell tatsächlich in Kontakt bist - Live-Sensoren (die ich so definiere, dass sie in den letzten 0,01 Sekunden produzieren) bei allen möglichen Straßenanflügen zu jeder Zeit. Jeder Sensor muss in der Lage sein, 600 alte Proben (im Wert von 3 Sekunden) zu speichern und mich bei Bedarf mit diesen alten Daten zu aktualisieren es." (Dies sind einige der über 20 QoS-Einstellungen im DDS-Standard.)

Beachten Sie, dass eine abonnierende Anwendung im primitiven Pub-Sub-Fall stark von den tatsächlichen Eigenschaften ihrer Produzenten abhängt. Es muss irgendwie darauf vertrauen, dass sie leben (!), dass sie genügend Puffer haben, um die möglicherweise benötigten Informationen zu speichern, dass sie sie nicht mit Informationen überfluten oder zu langsam bereitstellen. Wenn 10.000 Autos 1000x/sec erfasst werden, aber nur 3 innerhalb von 200m, muss es jede Sekunde 10.000*1000 =10m Samples empfangen, nur um die 3*200 =600 zu finden, auf die es achten muss. Es muss jeden einzelnen Sensor 100x/Sekunde pingen, nur um sicherzustellen, dass er aktiv ist. Wenn redundante Sensoren auf verschiedenen Pfaden vorhanden sind, muss es alle unabhängig pingen und irgendwie sicherstellen, dass alle Pfade abgedeckt sind. Bei vielen Anwendungen müssen alle alle Sensoren unabhängig voneinander pingen. Es muss auch das Schema der Produzenten kennen usw.

Die Anwendung im zweiten Fall erhält dagegen genau die 600 Samples, die ihr wichtig sind, wohl wissend, dass für jeden Pfad mindestens ein Sensor aktiv ist. Die Durchflussmenge ist garantiert. Ausreichende Zuverlässigkeit ist gewährleistet. Der gesamte Datenfluss wird um 99,994% reduziert (wir benötigen nur 600/10 Mio. Samples und die intelligente Middleware filtert an der Quelle). Beachten Sie der Vollständigkeit halber, dass der Kollisionsalgorithmus vollständig unabhängig von den Sensoren selbst ist. Es kann an jeder anderen Kreuzung wiederverwendet werden und funktioniert mit einem Sensor pro Pfad oder 17. Wenn das Netzwerk während der Laufzeit zu stark belastet wird, um die Datenspezifikationen zu erfüllen (oder etwas fehlschlägt), wird die Anwendung sofort benachrichtigt.

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

Kurze Antwort:Ein Datenbus ist ein grundsätzlich verteiltes Konzept, das Daten von lokalen Produzenten auswählt und liefert, die einer einfachen Spezifikation entsprechen. Eine CEP-Engine ist ein zentralisierter ausführbarer Dienst, der viel komplexere Spezifikationen erfüllen kann, aber alle Datenströme an einen Ort senden müssen.

Lange Antwort:Eine Complex Event Processing (CEP)-Engine untersucht einen eingehenden Datenstrom und sucht nach Mustern, die Sie programmieren, um sie zu identifizieren. Wenn es eines dieser Muster findet, können Sie es so programmieren, dass es Maßnahmen ergreift. Die Muster können komplexe Kombinationen vergangener und eingehender zukünftiger Daten sein. Es ist jedoch ein einzelner Dienst, der irgendwo auf einer einzigen CPU ausgeführt wird. Es überträgt keine Informationen.

Ein Datenbus sucht auch nach Datenmustern. Die Spezifikationen sind jedoch einfacher; es trifft Entscheidungen über jedes Datenelement, während es produziert wird. Die Aktionen sind auch einfacher; die einzige Maßnahme, die es ergreifen kann, besteht darin, diese Daten an einen Anforderer zu senden. Die Stärke eines Datenbusses besteht darin, dass er grundsätzlich verteilt ist. Die Suche erfolgt lokal auf potenziell Hunderten, Tausenden oder sogar Millionen von Knoten. Somit ist der Datenbus eine sehr leistungsfähige Möglichkeit, die richtigen Daten aus den richtigen Quellen auszuwählen und an die richtigen Stellen zu senden. Ein Datenbus ist eine Art verteilter Satz von CEP-Engines, eine für jede mögliche Informationsquelle, die von den Benutzern dieser Informationen automatisch programmiert wird. Natürlich hat der Datenbus viele andere Eigenschaften über den Mustervergleich hinaus, wie Schemavermittlung, Redundanzmanagement, Transportunterstützung, ein interoperables Protokoll usw.

Frage 6:Welche Anwendung hat den DDS-Standard und die Datenbusse angetrieben?

Die ersten Anwendungen waren intelligente Roboter, "Informationsüberlegenheit" und große koordinierte Systeme wie das Kampfmanagement der Marine. Diese Systeme brauchten Zuverlässigkeit, selbst wenn Komponenten ausfallen, Daten schnell genug, um physische Prozesse zu steuern, sowie selektive Erkennung und Bereitstellung im Maßstab. Die Datenzentrierung hat den Anwendungscode und die kontrollierten Schnittstellen wirklich vereinfacht, sodass Programmierteams im Laufe der Zeit an großen Softwaresystemen arbeiten können. Der DDS-Standard ist eine aktive, wachsende Familie von Standards, die ursprünglich sowohl von Anbietern als auch von Kunden vorangetrieben wurde. Es wird in vielen Branchen erheblich eingesetzt, darunter Medizin, Transport, Smart Cities und Energie.

Wenn Sie mehr darüber erfahren möchten, wie intelligente Software das IIoT erobert, laden Sie unser Whitepaper zur Zukunft der Automobilindustrie herunter, "The Secret Sauceof Autonomous Cars".