DDS

DDS (Data Distribution Service Standard) 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 – Datenbank und Datenbus – 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 Software-Modulen. Somit ermöglicht das datenzentrische Paradigma eine einfache Software-Integration.

Bei der Entscheidungsfindung, ob DDS für eine Anwendung infrage kommt, helfen folgende fünf Fragen. Werden drei Fragen mit ‚ja‘ beantwortet, macht die Nutzung von DDS Sinn.

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?

OPC UA

OPC UA (Open Platform Communications Unified Architecture) 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, etwa 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ück­kopplungssteuerungen. 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äte-Internas, und Fabrik-Integratoren 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 Software-Entwicklern?
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

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 ‚IKT‘ steht, und beschreibt es meine Arbeit? Die Informations- und Kommunikationstechnik (IKT) gilt als wichtigste Zielbranche von oneM2M.
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 – 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

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?

Die Technologien im Vergleich

Vergleicht man diese Technologien miteinander, werden große Unterschiede deutlich und es ist erkennbar, 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 Software-Integration durch Software-Teams ab. Wird intelligente Software wichtig, bietet DDS die von Software-Teams 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 zielen auf komplett andere Bereiche ab. oneM2M bietet gemeinsame Dienste zur Integration mobiler Geräte. Keine der anderen Technologien fokussiert diese Applikation.

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‘. Durch einen vorgeschriebenen Feldbus, ein anzuwendendes Protokoll oder ähnliches sollte man sich nicht einschränken lassen. Offenheit, Zukunftssicherheit, Safety- und Security-Aspekte sollten letztlich den Ausschlag geben.

Autoren:
Dr. Stan Schneider ist CEO von Real-Time Innovations;
Reiner Duwe ist Sales Manager EMEA von RTI.