IIoT-Lösungen | 6 Industrielle IoT-Kommunikationslösungen

Um zu sagen, dass die Auswahl Ihres Industrial IoT (IIoT ) Kommunikationsinfrastruktur ein sehr komplexes Unterfangen ist, wäre eine Untertreibung. Die Evaluierung der unzähligen kommerziell erhältlichen Lösungen ist sowohl zeitaufwändig als auch teuer. Versuchen Sie, mehrere Lösungen jeder Art von Infrastruktur herunterzuladen und zu evaluieren, und Sie befinden sich schnell mitten in einem Projekt, das mehrere Ingenieure gut sechs Monate in Anspruch nehmen wird. Wir waren alle schon dort und ich möchte Ihnen helfen, wertvolle Zeit zu sparen!

Der Zweck dieses Beitrags ist es, Ihnen die beliebten IIoT-Infrastrukturlösungen vorzustellen, die im Handel erhältlich sind - AMQP, CoAP, DDS, RTI Connext DDS, MQTT und ZeroMQ - und die Fähigkeiten jeder Lösung hervorheben. Die sechs folgenden Bewertungsbereiche werden angewendet:Architektur, Kommunikationsmuster, Transporte, Datentyp und Filterung, Dienstqualität und Sicherheit.

Klicken Sie hier, um die druckfähige PDF-Version herunterzuladen.

1. Architektur

Je nach Architekturmuster einer bestimmten Kommunikationsinfrastruktur variiert die logische Verbindung (siehe Abbildung 1 unten), die Anwendungen verwenden, um mit anderen Anwendungen in der Infrastruktur zu kommunizieren. Die beiden grundlegendsten Architekturen, die in heutigen Middleware-Lösungen verwendet werden, sind (1) Peer-to-Peer- und (2) Broker-basierte Star-Architekturen.

1. Peer-to-Peer-Architekturen Anwendungen ermöglichen, direkt miteinander zu kommunizieren, ohne Daten an ein zwischengeschaltetes Element senden zu müssen. Diese Architekturen sind bei der Datenlieferung von Natur aus effizienter, da nur die sendenden und empfangenden Anwendungen CPU-Ressourcen verbrauchen, um die Übertragung abzuschließen. Daher verbrauchen nur die Anwendungen, die über die Daten verfügen, und die Anwendungen, die die Daten benötigen, CPU-Zyklen; führt somit zu einer effizienten Verteilung der Verarbeitung basierend auf den Anwendungsanforderungen. Der andere Vorteil einer Peer-to-Peer-Architektur besteht darin, dass die deterministische Bereitstellung von Daten viel einfacher zu erreichen ist, da es keinen „Mittelsmann“ gibt, der die Daten zwischen den Hersteller- und Verbraucheranwendungen handhabt.

Abbildung 1. Architekturdiagramme für die verschiedenen IoT-Protokolle.

2. Maklerbasierte Lösungen verlangen, dass alle Anwendungen, die Daten senden, die Daten direkt an den Broker-Server übertragen, wonach er diese Daten umkehrt und diese Daten erneut an die empfangenden Anwendungen sendet. Der Vorteil dieser Architektur besteht darin, dass der Broker die gesamte Komplexität in Bezug auf das Senden/Empfangen von Daten verwaltet. In der Regel verfügen diese Lösungen über integrierte Tools, mit denen Sie genau sehen können, welche Datenpfade aktiv sind, wer Daten sendet und wer Daten empfängt. Broker-basierte Lösungen führen zu Latenzen bei der Datenlieferung und stellen auch einen Single Point of Failure dar, so dass bei einem Broker-Ausfall auch die gesamte Kommunikation fehlschlägt. Um das Single Point of Failure Problem zu lösen, sehen die meisten dieser Implementierungen redundante und hochverfügbare Brokerserver vor.

2. Kommunikationsmuster

Die Unterstützung von Kommunikationsmustern ist für eine Infrastruktur unerlässlich, die Sie während des gesamten Lebenszyklus Ihres Projekts oder Ihrer Produktlinie nutzen können. Das anfängliche Projekt erfordert möglicherweise nur das Veröffentlichen/Abonnieren, aber nachfolgende Projekte oder Produkte benötigen möglicherweise zusätzliche Muster wie Anfrage/Antwort oder Warteschlange. In dieser Hinsicht können nicht alle heute verfügbaren IoT-Lösungen alle erforderlichen Muster unterstützen, die Ihr Projekt benötigt. Für die Vergleichstabelle haben wir die gängigsten Muster identifiziert, die heute verwendet werden, und ob jede Infrastrukturlösung dieses Muster bereitstellt. Dies sind die heute am häufigsten verwendeten Muster:

• Veröffentlichen / Abonnieren :Eine Anwendung (Abonnent) fordert 1 Mal Daten an und dann werden alle nachfolgenden Aktualisierungen der Daten an den Abonnenten „gepusht“. Sie müssen nicht ständig nach Datenaktualisierungen fragen.
• Anfrage/Antwort/RPC (Fernprozeduraufruf ):Eine anfordernde Anwendung sendet Anfragen und eine antwortende Anwendung antwortet auf die Anfrage.
• Warteschlangen (oder Punkt-zu-Punkt ):Daten werden an einen Server gepusht, der die Informationen in einer Warteschlange hält. Daten können dann entweder aus der Warteschlange gezogen oder an Verbraucher gepusht werden. Im Gegensatz zu Publish/Subscribe wird jedes Datenelement nur an eine empfangende Anwendung verteilt.
• Einer für viele :Möglichkeit, dass viele empfangende Anwendungen dieselben Daten aus einer einzigen Quelle erhalten.
• Viele zu Eins :Möglichkeit, Daten aus vielen Quellen in einer einzigen konsumierenden Anwendung zu empfangen.

3. Transporte &Routing/Bridging

Die meisten Kommunikations-Middleware-Lösungen unterstützen TCP als ihr primäres Kommunikationsprotokoll. Die Verwendung von TCP ermöglicht Ihnen eine zuverlässige Übermittlung von Daten mithilfe des integrierten Zuverlässigkeitsmechanismus von TCP. Dies kann ideal für bestimmte Datenflüsse sein, die Zuverlässigkeit erfordern, ist aber übertrieben und fügt einfachen Sensordaten, die keine zuverlässige Bereitstellung erfordern, unnötigen Overhead hinzu. Einige der IoT-Lösungen wie ZeroMQ und DDS unterstützen auch andere Transporte wie Shared Memory. Ein bemerkenswerter Transport ist die Verwendung des UDP-Transports für DDS. Da die Implementierung der Zuverlässigkeit in DDS integriert ist, ist kein zuverlässiger Transport darunter erforderlich. Auf diese Weise können Anwendungen auswählen, welche Datenflüsse zuverlässig bereitgestellt werden und welche Datenflüsse am besten geeignet sind.

Das Routing von Daten zwischen Transporten und über das WAN ist etwas, das alle diese Lösungen auf die eine oder andere Weise bieten. In der heutigen Welt, in der Unternehmenssysteme, die ESB- und Web-Technologien nutzen, auch auf einige der Echtzeitdaten zugreifen müssen, ist es für die Kommunikations-Middleware unerlässlich, auch die Verbindung zu diesen Technologien zu unterstützen. Aus diesem Grund sehen Sie Routing und Bridging als Kernkomponente für verteilte Systemmiddleware.

4. Datentyp und Filterung

Wie Daten gekapselt und auf der Leitung dargestellt werden, ist auch für die jeweilige Infrastruktur einzigartig. Einige Lösungen senden nur unformatierte Datenbytes, und es liegt an der Anwendung, die Daten zu serialisieren und zu deserialisieren. Andere senden nur Text-/String-Daten, damit die Informationen entweder im XML- oder im JSON-Format dargestellt werden können. Dieses Szenario ist heute in Webtechnologien weit verbreitet, kann jedoch sehr ineffizient sein, da das Paket bei jedem Senden von Daten auch die Beschreibung der Daten enthält, wodurch die Paketgröße manchmal mehr als das Dreifache der ursprünglichen Größe beträgt. Größere Paketgrößen erhöhen die Bandbreitennutzung sowie die CPU-Auslastung sowohl auf der Sende- als auch auf der Empfangsseite der Übertragung. Setzen Sie einen Broker dazwischen und Sie verdoppeln jetzt auch die Anzahl der Pakete auf dem Draht.

Andere Lösungen wie DDS ermöglichen die Verwendung stark typisierter Daten, die von der Middleware eindeutig serialisiert und deserialisiert werden. Das Schema wird separat gesendet, was bei XML oder JSON nicht der Fall ist, und Sie zahlen daher keine Strafe pro Nachricht (oder Muster). Dies wird auch für Filteraspekte sehr wichtig. Angenommen, Sie richten einen einzelnen Publisher mit vielen Abonnenten ein. Einige der Abonnenten möchten möglicherweise alle Daten, aber einige der Abonnenten möchten nur einen Teil der Daten. Ohne eine stark typisierte Datenlösung müssen Ihre Anwendungen all diese Filterfunktionen verwalten, was noch mehr Code bedeutet, den Sie schreiben müssen. Bei Lösungen wie DDS, bei denen die Typinformationen stark definiert sind, kann die Middleware die gesamte Filterung für Sie übernehmen. Weniger Code =glücklichere Entwickler :). Tatsächlich verfügt RTI Connext DDS über zusätzliche Funktionen, um diese Filterung auf der Schreiberseite der Datenübertragung bereitzustellen, was zu einer geringeren Bandbreitennutzung auf dem Kabel und zu weniger CPU-Verarbeitung bei Anwendungen führt, bei denen die Daten nicht herausgefiltert werden müssen.

5. Servicequalität

Nicht alle Daten sind gleich. Was bedeutet das? Nun, einige Daten in einer verteilten Echtzeitanwendung sind Streaming-Sensordaten. In den meisten Fällen müssen diese Daten nicht garantiert gelieferte Daten sein. Für einen bestimmten Sensor ka

[1] [2] 下一页