Connectivity im IIoT Welcher Konnektivitätsstandard passt zu welcher IoT-Anwendung?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

Real-Time Innovations GmbH

RTI Real-Time Innovations

Für IIoT-Anwendungen existieren diverse Konnektivitäts-Standards zur Kommunikation via Internet, die eigene Vor- und Nachteile bieten. Mittels 5 Fragen lässt sich die jeweils passendste Technologie leicht finden.

Das IIoT ist so groß, dass sich die Technologien im Endeffekt kaum überschneiden – jedenfalls bei einem nur oberflächlichem Blick. Deshalb besteht die Herausforderung bei den IIoT-Architekturen heute nicht darin, zwischen sich überlappenden Standards zu wählen, von denen jeder ein anderes Problem lösen könnte. Vielmehr kommt es darauf an, die Technologien zu verstehen, die beabsichtigte Anwendung mit der Applikation zu vergleichen und diejenige auszuwählen, welche dem speziellen Fall am besten entspricht.

Ein Überblick über Konnektivitäts-Standards für IIoT-Anwendungen

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. Betrachtet man die Situation realistisch, sieht diese eher wie das Venn-Diagramm in Bild 2 als wie in Bild 1 aus.

Vor dem IICF (Industrial Internet Connectivity Framework) war man der Annahme, dass konkurrierende Standards für IIoT-Konnektivität Anforderungen erfüllen, die sich überschneiden. Eine Anwendung (X) passte zum Standard B oder C, beide würden funktionieren. Es stellt sich jedoch heraus, dass sich die Konnektivitätsstandards nicht überschneiden. Die meisten Anwendungen werden nicht perfekt zu einem Standard passen und müssen teilweise angepasst werden.

Bildergalerie

Letztlich bewegen alle Konnektivitätstechnologien Daten. Dennoch sind sie sehr unterschiedlich, weshalb in den meisten Anwendungsfällen keine Auswahlmöglichkeit zwischen den Technologien besteht. 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, womit sich die Auswahl schnell eingrenzen lässt.

DDS (Data Distribution Service Standard)

DDS stellt eine Reihe an Standards dar, die von der Object Management Group (OMG) verwaltet werden und einen Datenbus definieren. Ein Datenbus ist eine datenzentrische Informationsflusskontrolle, das Konzept funktioniert ähnlich wie bei 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 beispielsweise Redundanz auflösen, um mehrere Quellen, Datensenken und Netzwerke zu unterstützen. Zudem kann er die Quality of Service (QoS) steuern, wie Aktualisierungsrate, Zuverlässigkeit und garantierte Benachrichtigung über die Lebendigkeit der Daten. Er kann die Daten in den Updates lesen und ihr Senden optimieren, oder sich gegen das Senden entscheiden.

Auch Datenflüsse erkennt und sichert er dynamisch. All diese Punkte definieren die Interaktion zwischen Softwaremodulen. Somit ermöglicht das datenzentrische Paradigma eine Softwareintegration.

Diese fünf Fragen helfen bei der Entscheidung, ob DDS für eine Anwendung infrage kommt:

• 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.

OPC UA (Open Platform Communications United Architecture)

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 Anwendungsprogrammierschnittstellen (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, zum Beispiel 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 ist dafür verantwortlich, den Server bereitzustellen, der das generische Gerätemodell dem jeweiligen Gerät zuordnet. So stellen die Server eine standardisierte objektorientierte, remote aufrufbare API bereit, die das Gerätemodell implementiert.

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 also ein System aus austauschbaren Teilen aufbauen und verwalten, ähnlich wie standardisierte Druckertreiber die Integration von PC-Systemen ermöglichen. 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.

Eine Entscheidung für OPC UA lässt sich nach folgenden Fragen treffen:

• 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“?

oneM2M (Machine to Machine)

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.

Bei der Entscheidung für die Nutzung von 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, zum Beispiel eines Telekommunikationsanbieters, nutzen?

Diese Fragen unterscheiden sich in ihrem Charakter von den Fragen über die vorhergehenden Technologien. 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.

RESTful HTTP (Representational State Transfer)

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 passt, sind diese Fragen hilfreich:

• 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?

• 5. Gibt es keine Kommunikation zwischen den verschiedenen Geräten?

MQTT (Message Queue Telemetry Transport)

MQTT ist ein sehr simples Protokoll, das hauptsächlich für die Datensammlung entwickelt wurde. Gemäß den IICF-Richtlinien gilt es nicht als „Haupt-Konnektivitätsstandard“, da es hier kein Standard-Typensystem gibt. Ohne Typensystem kann das Protokoll keine Standardfähigkeit für die Interoperabilität auf syntaktischer Datenstrukturebene ermöglichen. Die gesamte Dateninterpretation bleibt der Anwendung überlassen.

MQTT bietet wenig, um die Softwareentwicklung zu erleichtern. Es gibt nur eine QoS-Einstellung (Reliability/Zuverlässigkeit), keine definierten Dienste und keine Daten- oder Gerätemodellierung. Dennoch besteht ein großes Interesse an MQTT. Mit ein paar einfachen Fragen lässt sich herausfinden, ob sich MQTT für ein System eignet:

• 1. Ist meine Anwendung eine Datensammlung?

• 2. Gibt es wenig Kommunikation zwischen den Geräten?

• 3. Ist Interoperabilität nicht relevant?

• 4. Habe ich viele kleine Geräte?

• 5. Stellt meine Software eher einfache Anforderungen?

Die Technologien im Vergleich

Vergleicht man diese Technologien miteinander, werden große Unterschiede deutlich und man erkennt, dass sich die Konnektivitätsansä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. Sie operieren in komplett anderen Bereichen. OneM2M bietet gemeinsame Dienste zur Integration mobiler Geräte. Keine der anderen Technologien fokussiert diese Applikation.

Nicht von Marketingbezeichnungen verwirren lassen

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 in ihrer Positionierung ähnliche Worte für sehr unterschiedliche Konzepte.

Hinter gängigen Begriffen wie „Publish subscribe“ verstecken sich deshalb große Unterschiede in Bezug auf Informationstypen, Erkennung, Auswahl von Daten und QoS-Kontrolle. „Echtzeit“ ohne die Angabe einer Zeitperiode in 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 vorzunehmen.

Hinweis:Der Artikel erschien zunächst bei der „Elektronik Praxis“.

* Dr. Stan Schneider ... ist CEO von Real-Time Innovations (RTI) in Sunnyvale, Kalifornien.

* Reiner Duwe ... ist Sales Manager EMEA bei RTI in München.

(ID:45449206)