Ein Angebot von

Die Wirren der IIoT-Konnektivität: Connectivity-Frameworks im Vergleich

| Autor / Redakteur: Reiner Duwe* / Sebastian Gerstl

Das Industrial Internet Connectivity Framework (IICF) ist eine Ressource für das Verständnis von IIoT-Konnektivitätsanforderungen.
Das Industrial Internet Connectivity Framework (IICF) ist eine Ressource für das Verständnis von IIoT-Konnektivitätsanforderungen. (Bild: IICF)

OPC UA, DDS, oneM2M: Im industriellen Internet of Things (IIoT) existieren zahlreiche Konnektivitätsstandards. Doch welcher eignet sich für das eigene Projekt am Besten?

Es gibt viele Missverständnisse und Fehlinterpretationen rund um die Digitalisierung, Industrie 4.0, Industrial Internet of Things (IIoT), Technologie-Empfehlungen und den tatsächlichen Anwendungsfällen. Verstehen Sie die unterschiedlichen Ansätze, erkennen Sie die für ihr Projekt relevanten Kriterien und treffen Sie eine solide Entscheidung für die Zukunft im IIoT.

Der größte Feind einer schnellen Realisierung des industriellen Internets der Dinge (IIoT) ist die derzeitige Unsicherheit und Konfusion. Wie finde ich als Produkt- / Systemverantwortlicher die richtige, zukunftssichere Technologie? Wie lassen sich Offenheit, funktionale- und Datensicherheit effizient und flexibel implementieren? Das Spektrum im IIoT ist so groß, dass sich die Technologien im Endeffekt kaum überschneiden. Deshalb besteht die Herausforderung bei den IIoT-Architekturen heute darin, die Technologien zu verstehen, die beabsichtigte Anwendung mit der Technologie zu vergleichen und die für den konkreten Fall bestgeeignete zu wählen.

Das IIC Konnektivitäts-Framework

Das Industrial Internet Connectivity Framework (IICF) ist eine umfassende Ressource für das Verständnis von IIoT-Konnektivitätsanforderungen. Ein internationales Team von Experten entwickelte das IICF speziell, um Klarheit in die oft verwirrende Landschaft der IIoT-Konnektivität zu bringen. Es ist die erste umfassende Arbeit eines großen Konsortiums, eine greifbare und praktische Anleitung für diejenigen, die IIoT-Lösungen heute zukunftssicher und effizient entwickeln müssen.

Sicherlich lässt sich eine Technologie so verändern, dass sie überall funktioniert. Aber das verursacht viel zusätzliche Arbeit und hat ein umständliches Design zur Folge. Vor dem IICF dachte man oft, dass konkurrierende Standards für IIoT-Konnektivität Anforderungen erfüllen, die sich überschneiden. Es stellt sich jedoch heraus, dass sich diese Standards kaum überlappen. In jedem Fall sollte die Anwendung bzw. die Systemanforderungen die Technologie bestimmen und nicht eine einfache Zuordnung nach Marktsegmenten. Also kein Automatismus wie Automotive -> Technologie A, Medizin-Technik -> Technologie B, usw.

Letztlich bewegen alle Konnektivitätstechnologien Daten. Dennoch sind sie sehr unterschiedlich und daher besteht für die Fälle keine freie Auswahl zwischen den Technologien. Das mag auf den ersten Blick ernüchternd klingen, in Wirklichkeit aber macht die fehlende Überlappung im IIoT die Aufgabe eines Architekten viel einfacher. Im Grunde gibt es ein paar einfache Fragen zu jeder Technologie, mit denen sich die Auswahl schnell eingrenzen lässt.

Vorstellung / Vergleich verschiedener „Connectivity-Frameworks“

OPC UA
OPC UA ist ein von der OPC Foundation verwalteter Standard, der auch als IEC 62541 dokumentiert ist und auf die Geräte-Interoperabilität abzielt. Anstatt direkt auf Geräte über proprietäre APIs zuzugreifen, definiert OPC UA Standard-APIs, die eine Änderung des Gerätetyps oder Herstellers erlauben. Auf diese Weise können auch Anwendungen auf höherer Ebene, z. B. Human Machine Interfaces (HMI), die verschiedenen Geräte in Fabriken finden, sich mit ihnen verbinden und diese steuern.

OPC UA teilt Systemsoftware in Clients und Server ein. Die Server befinden sich in der Regel auf einem Gerät oder einer übergeordneten speicherprogrammierbaren Steuerung (SPS). Sie bieten eine Möglichkeit, über ein Standard-„Gerätemodell“ auf das Gerät zuzugreifen. Diese gibt es für Dutzende von Gerätetypen, von Sensoren bis hin zu Rückkopplungssteuerungen. Jeder Hersteller stellt den Server bereit, der das generische Gerätemodell dem jeweiligen Gerät zuordnet. So stellen die Server eine standardisierte objektorientierte, remote aufrufbare API bereit. Clients können über das generische Gerätemodell eine Verbindung zu einem Gerät herstellen und Funktionen aufrufen. Somit ist die Client-Software unabhängig von den tatsächlichen Geräteinterna und Fabrikintegratoren können Hersteller oder Modelle nach Bedarf wechseln.

OPC UA kann so ein System aus austauschbaren Teilen aufbauen und verwalten. Dabei gilt es zu beachten, dass das Gerätemodell auch eine Stufe der „semantischen“ Interoperabilität bietet, da es die generischen Objekt-APIs in bekannten Units und angegebenen Referenzpunkten definiert.

Bei der Entscheidung für OPC UA helfen folgende Fragen:

  • 1. Arbeite ich in der diskreten Fertigung?
  • 2. Stehe ich mit dem Programm der Plattform Industrie 4.0 in Verbindung?
  • 3. Baue ich ein Gerät, das von Steuerungs- oder Prozessingenieuren oder Technikern integriert wird, und nicht von Softwareentwicklern?
  • 4. Wird mein Produkt in verschiedenen Anwendungen in unterschiedlichen Systemen verwendet, im Gegensatz zu einem System(-typ), bei dem man die Architektur steuert?
  • 5. Baue ich Geräte für eine „Arbeitszelle“?

DDS – Data Distribution Service Standard
DDS wird von der Object Management Group (OMG) verwaltet und definiert einen Datenbus. Ein Datenbus ist eine datenzentrische Informationsflusskontrolle, vom Konzept her ähnlich einer Datenbank, bei der es sich um einen datenzentrischen Informationsspeicher handelt. Der Hauptunterschied besteht jedoch darin, dass eine Datenbank nach alten Informationen sucht, indem sie die Eigenschaften der gespeicherten Daten in Beziehung zueinander setzt.

Ein Datenbus hingegen findet zukünftige Informationen, indem er die Eigenschaften der ankommenden Daten filtert. Beide verstehen die Inhalte und lassen Anwendungen direkt mit und durch die Daten agieren, anstatt miteinander. Applikationen, die eine Datenbank oder einen Datenbus verwenden, haben keine direkte Beziehung zu anderen Anwendungen. Der Datenbus nutzt die Kenntnisse über Struktur, Inhalt und Anforderungen an die Daten, um den Datenfluss zu verwalten. Er kann z.B. Redundanzen auflösen, um mehrere Quellen, Datensenken und Netzwerke zu unterstützen. Er kann die Quality of Service (QoS), wie Aktualisierungsrate, Zuverlässigkeit und garantierte Benachrichtigung über die Lebendigkeit der Daten, steuern. Datenflüsse erkennt und sichert er dynamisch. Diese Punkte definieren die Interaktion zwischen Softwaremodulen und so wird durch das datenzentrische Paradigma eine einfache Softwareintegration möglich.

Diese fünf Fragen helfen bei der Entscheidung für DDS:

  • 1. Stellt es ein großes Problem dar, wenn mein System kurzzeitig ausfällt?
  • 2. Sind Millisekunden in meiner Kommunikation von Bedeutung?
  • 3. Beschäftige ich verschiedene Software-Entwicklungsteams oder mehr als zehn Software-Entwickler?
  • 4. Sende ich Daten an viele Orte statt nur an einen, wie eine Cloud oder Datenbank?
  • 5. Implementiere ich eine neue IIoT-Architektur?

Werden drei der fünf Fragen mit ja beantwortet, macht die Nutzung von DDS Sinn.

oneM2M
OneM2M bietet eine gemeinsame Service-Schicht, die zwischen den Anwendungen und der Connectivity-Transportschicht liegt. Der Schwerpunkt liegt hier auf der Bereitstellung gemeinsamer Dienste auf der Grundlage verschiedener Konnektivitätsstandards.

OneM2M resultiert aus der Zusammenarbeit vieler Mobilfunkanbieter. Es zielt auf die Netzwerke mobiler Geräte ab, die größtenteils oder nur über die Infrastruktur der Basisstation kommunizieren.

Bei der Entscheidung für oneM2M helfen folgende Fragen:

  • 1. Weiß ich, wofür „ICT“ steht, und beschreibt es meine Arbeit?
  • 2. Ist das Mobilfunknetz meine primäre Verbindungstechnologie?
  • 3. Setzen sich meine Zielapplikationen weitestgehend aus beweglichen Komponenten zusammen?
  • 4. Tolerieren die Komponenten des Systems intermittierende Verbindungen und locker gesteuerte Latenzen?
  • 5. Wird das System die Dienste eines Kommunikationsanbieters, z. B. eines Telekommunikationsanbieters, nutzen?

RESTful HTTP
REST (Representational State Transfer) über HTTP ist die gängigste Schnittstelle zwischen Consumer-Anwendungen und Web-Services. Es stellt ein Architekturmuster zum Zugreifen auf ein Objekt oder eine Ressource und deren Änderung dar. Ein Server steuert in der Regel das Objekt, andere fordern eine „Repräsentation“ an und können dann Anfragen zum Erstellen, Ändern oder Löschen des Objekts senden.

Um zu sehen, ob RESTful HTTP zu einer Anwendung, fragen Sie:

  • 1. Verbinde ich unabhängige Geräte mit einer einzelnen Web-Service-API?
  • 2. Baue ich eine HMI-Schnittstelle zu einem IoT-Gerät oder Service auf?
  • 3. Muss meine Anwendung nur schnell genug für die menschliche Interaktion sein?
  • 4. Muss mein Datenfluss Firewalls kreuzen, die ich nicht kontrolliere?

Die Technologien im Vergleich

Vergleicht man diese Technologien miteinander, werden große Unterschiede deutlich und man erkennt, dass sich die Ansätze nicht überlappen.

Beispielsweise ist OPC UA objektorientiert (OO), während DDS datenzentrisch ist. Dies sind diametrale Gegensätze. Objektorientiert bedeutet hier „Daten zu verkapseln und Methoden offenzulegen“. Bei der Datenzentrierung geht es ausschließlich um die Datenoffenlegung und es gibt keine benutzerdefinierten Methoden. Die einzigen Methoden werden durch den Standard definiert.

OPC UA zielt auf die abschließende gerätezentrische Integration durch Anlagenkonstrukteure ab. Es bietet eine einfache Interoperabilität zwischen den Geräten verschiedener Hersteller. Im Gegensatz dazu zielt DDS auf die endgültige datenzentrische Softwareintegration durch Softwareteams ab. Wird intelligente Software wichtig, bietet DDS die von Softwareteams benötigte Schnittstellenkontrolle von Datenabstraktion und Datenfluss.

OneM2M und RESTful HTTP zielen auf die Verbindung von Edge und Cloud-Services ab. Im Gegensatz zu DDS oder OPC UA wird beides nur selten für die Kommunikation zwischen Geräten verwendet. OneM2M bietet gemeinsame Dienste zur Integration mobiler Geräte. Keine der anderen Technologien fokussiert diese Applikation.

Fazit

Anhand dieser Unterschiede wird klar, dass diese Technologien in der Praxis nicht miteinander konkurrieren. Dennoch ist die „Verwirrung“ durch den Wettbewerb groß. Verschiedene Anbieter und Standardisierungsorganisationen verwenden oftmals ähnliche Worte für sehr unterschiedliche Konzepte. Hinter gängigen Begriffen wie „Publish subscribe“ verstecken sich deshalb große Unterschiede bzgl. Informationstypen, Erkennung, Auswahl von Daten und QoS-Kontrolle. „Echtzeit“ ohne die Angabe von Millisekunden oder Minuten ist bedeutungslos. Und das Internet der „Dinge“ hinterlässt dem Nutzer eine riesige Auswahl an „Dingen“. Die meisten Anwendungen passen jedoch zu einem der gängigen Standards. Lassen sich drei Fragen zu einer der oben genannten Technologien mit „Ja“ beantworten, sollte man damit beginnen. Ist dies nicht der Fall, empfiehlt es sich, die engste Übereinstimmung zu wählen und Anpassungen der Architektur vorzunehmen.

Was ist MQTT?

Was ist MQTT?

19.06.18 - MQTT hat sich in den letzten Jahren zum Standardprotokoll für die IoT- bzw. M2M-Kommunikation von Geräten und Applikationen entwickelt. Doch was hat es mit dem Protokoll auf sich und wie setzt man es ein? lesen

IoT ohne Internet: Pragmatischer Ansatz für Konnektivität

IoT ohne Internet: Pragmatischer Ansatz für Konnektivität

27.08.18 - Thingstream bietet eine IoT-Konnektivitätslösung für das vorhandene GSM-Netz – ohne Einsatz von TCP/IP. Entwickler von Hardware für Anwendungen im Internet of Things brauchen sich nicht um Netzbetreiber oder Datenverträge kümmern. Möglich macht dies das verwendete MQTT-Protokoll. lesen

Quellen

RTI Real-Time Innovations www.rti.com
https://www.rti.com/products/what-is-a-databus

Industrial Internet Consortium https://www.iiconsortium.org/index.htm

IIoT Connectivity Framework (IICF) https://www.iiconsortium.org/IICF.htm

OMG DDS Portal https://www.omgwiki.org/dds/

OPC UA https://opcfoundation.org/about/opc-technologies/opc-ua/

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

* Reiner Duwe leitet den Vertrieb EMEA bei RTI Real-Time-Innovations International. Aufgrund seiner großen Erfahrung aus mehr als 20 Jahren in der embedded Industrie baut er die RTI Präsenz in Europa erfolgreich aus. Er ist aktives Mitglied des Industrial Internet Consortium (IIC) und Verfasser verschiedener Fachartikel und Vorträge.

Kommentar zu diesem Artikel abgeben
Wer darüber einer Praxisimplementierung sucht, der sollte sich mal die Firma IB-Embedded.de...  lesen
posted am 25.03.2019 um 16:27 von Unregistriert

Ja, endlich mal wieder eine hilfreiche Übersicht. Dankeschön! Perfekt wäre der Artikel mit einer...  lesen
posted am 20.03.2019 um 16:59 von Unregistriert

Schöne Aufbereitung des Sachverhalts - Daumen hoch.  lesen
posted am 20.03.2019 um 10:59 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45794552 / IoT)