Datentransfer-Standards OPC UA und DDS
»Es wird keinen Weltstandard geben«
Fortsetzung des Artikels von Teil 2
Anforderungen kommen auch vom Endkunden
Aktuell arbeiten Branchen-Schwergewichte im Rahmen der OPC Foundation daran, das OPC-UA-Protokoll mittels Echtzeit Ethernet TSN echtzeitfähig zu machen. Lässt sich auch DDS über TSN übertragen?
Ja, die Übertragung von DDS über TSN ist ebenfalls möglich. Es handelt sich dabei sogar um eine Kombination, die die Komplexität von TSN relativ leicht in den Griff bekommt, weil sich die Quality-of-Service-Settings mit DDS teilweise automatisieren lassen.
Aus Sicht von DDS ist TSN nur ein Protokoll, auf dem es aufsitzt. Prinzipiell lassen sich alle Protokolle oder Busse an DDS anbinden. DDS ist völlig offen, was Protokolle, Busse, Programmiersprachen und Betriebssysteme angeht. Und »RTI Connext DDS« kommt ohne Server und Broker aus, wohingegen bei OPC UA immer Server erforderlich sind.
Eine spezifische Kopplung von DDS auf TSN ist allerdings erforderlich; sie wird künftig Bestandteil des DDS-Standards sein. DDS bietet bereits einige der QoS-Settings, die TSN benötigt, um die korrekte Terminierung für harte Echtzeit-Anwendungen zu ermöglichen. Ziel ist es, TSN-Switches intelligent genug zu machen, um die QoS-Settings zu verstehen und automatisch die Terminierung zu konfigurieren. Dies verringert die erforderliche Konfiguration drastisch und vereinfacht die Integration verteilter Systeme. DDS und TSN zusammenzuführen, ist also letztlich nicht allzu schwierig. DDS wird die Anwendung von TSN sogar vereinfachen, weil man schon in der Middleware viele Einstellungen vornehmen und damit die Komplexität verringern kann.
Ist die Anbindung von DDS an TSN schon Realität?
Momentan ist die Standardbeschreibung für 802.1 TSN / DDS noch nicht abgeschlossen und daher natürlich auch die Anbindung an DDS noch in Arbeit; RTI stellt die Technik derzeit im Rahmen eines Projekts mit einem führenden Kunden her. Sie ist weder proprietär noch kundenspezifisch angelegt und wird für alle Anwender von DDS verfügbar sein. Entscheidend dabei ist, in der DDS-Middleware die Nutzung von TSN und die Konfiguration der Geräte zu vereinfachen.
Lässt sich DDS selbst als Protokoll bezeichnen?
Die Aussage »DDS ist ein Protokoll« wäre zu wenig. Im Grunde müsste es heißen: DDS hat ein Protokoll. Es läuft also auf der Protokollebene ab. Als Middleware ist DDS ein Paket von Funktionen und Diensten, die auf einem Protokoll angeboten werden; es ist mehr als Pub/Sub und mehr als ein reines Protokoll. DDS hat einen Datenbus, an dem die Publisher und Subscriber eines Systems aufsetzen. Durch die Datenzentrierung ist DDS unabhängig von Programmiersprachen. Anwender können Daten vorfiltern und Bedingungen stellen, unter denen der Publisher seine Daten übertragen soll. Sie können Datensätzen Information mitgeben, etwa wie lange sie gültig sind und ab wann sie nicht mehr verwendet werden dürfen, wenn sie ankommen. Letztlich umfassen die Quality-of-Service-Settings von DDS ein konsequentes Pub/Sub-Modell der Datenübertragung und die Vorfilterung der Daten.
Kann bei DDS von einer Service-oriented Architecture (SoA) die Rede sein?
SoA ist bislang ein IT-Thema. Im Zusammenhang mit dem IIoT ist der Begriff noch nicht mit einem eindeutigen Inhalt belegt. Eine SoA erleichtert es Software-Komponenten, zu kommunizieren und zu kooperieren, ohne dass es eines menschlichen Einflusses bedarf.
DDS bietet eine Auto-Discovery-Funktion und kann beispielsweise die Handhabung von Daten beim Ausfall eines Publishers regeln. Viele Interaktionen kann die Middleware schon übernehmen. Insofern lässt sich DDS durchaus als SoA bezeichnen.
Die Entwicklung hin zu Industrie 4.0 ermöglicht neue, datengetriebene Geschäftsmodelle. Inwieweit gibt dies Kommunikationstechniken wie DDS oder OPC UA Schub?
Als Triebfedern für Techniken wie DDS oder OPC UA erweisen sich nicht nur technische Entwicklungen, sondern auch Anforderungen neuer oder veränderter Geschäftsmodelle. Das Stichwort lautet »Product as a Service«: Hersteller von Flugzeugtriebwerken verkaufen nicht mehr die Triebwerke, sondern die Anzahl von Betriebsstunden oder kW Schub. Radiologiepraxen bezahlen nicht mehr das Röntgengerät, sondern einen bestimmten Obolus je Röntgenbild. Möglich sind solche Geschäftsmodelle in vielen Bereichen: von der Industrieautomatisierung über die Medizin bis hin zur Land- und Energiewirtschaft. Für den Transfer der nötigen Daten werden zahlreiche Unternehmen künftig DDS einsetzen. Oder nehmen Sie Smart Grids als Beispiel: DDS kann Smart Grids schneller agieren lassen und für einen rascheren Datenaustausch sorgen.
Es gibt also zahlreiche Beispiele von Anwendungen, die den Einsatz neuer Techniken wie DDS vorantreiben. Viele Anforderungen an Testbeds des IIC stammen nicht von Geräteherstellern, sondern von Endkunden. Generell lässt sich feststellen, dass auch Geschäftserfordernisse technische Veränderungen beflügeln.
- »Es wird keinen Weltstandard geben«
- Thema Security im IIC
- Anforderungen kommen auch vom Endkunden
Lesen Sie mehr zum Thema
