Schlüsselwörter

1 Einleitung

Mit der Industrie 4.0 Initiative geht die Wandlung industrieller Netze und Maschinen hin zur flexiblen und wandelbaren Produktion einher. Die Nutzung und Verknüpfung interoperabler Maschinendaten ermöglicht neue Geschäftsmodelle [1]. Dies betrifft unter anderem die Administration Shell (AS) der Produktionsgeräte, das industrielle Netzwerk und die Erweiterung der Produktion um z. B. künstliche Intelligenz und maschinelles Lernen. Mit dem Wandel zu Industrie 4.0 werden auch die aktuell getrennten Paradigmen Operation Technology (OT) und Information Technology (IT) zu einer konvergenten Kommunikation weiterentwickelt (Abb. 1). Mit OT werden alle Systeme und Geräte bezeichnet, die bisher in der Automatisierungspyramide in den beiden unteren Ebenen angeordnet waren und die mittels Feldbussen oder proprietären (Echtzeit)-Ethernet basierten Protokollen wie EtherCAT, Ethernet/IP und PROFINET kommunizieren. Ziel ist es, eine einheitliche deterministische IP-basierte Kommunikation zu etablieren, welche IT- und OT-Eigenschaften unterstützt [2].

Abb. 1
figure 1

Automatisierungspyramide im Wandel zu Industrie 4.0 und IIoT

Full size image

Um das sogenannte Industrial IoT (IIoT) umzusetzen, werden semantische Gerätebeschreibungen zusammen mit robuster deterministischer Echtzeitübertragung eingesetzt, was sich mit den Technologien OPC UA und Time-Sensitive Networking (TSN) realisieren lässt [3]. OPC UA ermöglicht standardisierte, sichere und plattformunabhängige Kommunikation. Es gibt Bestrebungen, Produktionsgeräte mit OPC UA auszustatten [3, 4].

Bei der Migration klassischer OT-Kommunikationstechnologien zu IIoT mit TSN und OPC UA gibt es Herausforderungen. Während IPCs, Steuerungen und Gateways leistungsoptimiert sind und mit entsprechender Hardware ausgestattet werden, sind viele zu migrierende Produktionsgeräte, wie Sensoren und Aktoren, energie-, platz- und kostenoptimiert. Auch finden sich in der OT-Welt eine Vielzahl von Geräten, die eine Fusion aus Netzwerkinfrastruktur und Gerätefunktion sind. Um Netzwerkinfrastrukturkosten zu minimieren, werden diese Switched-Endpoint genannten Geräte als Daisy-Chain in einer Reihe verbunden. In der OT finden sich vornehmlich Protokolle, die Daten effizient im Binärformat austauschen, während in der IT textbasierte Protokolle vorherrschen. Diese textbasierenden Protokolle stellen eine Herausforderung für die ressourcenlimitierten Produktionsgeräte, welche auf Feldebene eingesetzt werden, dar.

Diese Arbeit betrachtet die Aspekte der IIoT-Kommunikation und deren Integration in bestehende Produktionsgeräte. Die Forschungsfrage beschäftigt sich mit dem Ermitteln einer gemeinsamen Beschreibung, welche die Umstände von industriellen Netzwerken und deren Geräten in Bezug auf Ressourcen und Struktur berücksichtigt, deterministische und zeitsensitive Kommunikation unterstützt und eine Schnittstelle anbietet, mit der industrielle Daten einfach angefordert werden können. Ziel ist die Definition eines kommunikationsbezogenen Konzeptes einer AS aus Sicht von Produktionsgeräten. Produktionsgeräte werden mit dieser AS ausgestattet, um TSN-Fähigkeiten erweitert und im Zusammenspiel mit TSN in einer Demonstrationsanlage umgesetzt.

Kap. 2 ,,Industrieller Use Case“ stellt einen industriellen Use Case vor, dessen Produktionsgeräte im Verlauf des Beitrags mit der AS und TSN ausgestattet werden. In Kap. 3 wird auf den Stand der Technik und in Kap. 4 ,,Related work“ auf verwandte Arbeiten eingegangen. Das Konzept und die Umsetzung der kommunikationsbezogenen AS (Communication Administration Shell – CAS) folgen in Kap. 5. So werden Produktionsgeräte, die bisher in der OT verwendet wurden, mit der CAS und TSN-Fähigkeiten ausgestattet und in den industriellen Use Case integriert. Im anschließenden Kap. 6 wird die Implementierung und Kommunikation der Produktionsgeräte validiert. Kap. 7 schließt mit der Zusammenfassung der vorliegenden Arbeit.

2 Industrieller Use Case

In einer industriellen Anlage befinden sich Produktionsgeräte, die Daten über ein industrielles Netzwerk austauschen. Die Anlage (in Abb. 2 als Demonstrationsanlage umgesetzt) überprüft Bauteile auf Qualität und besteht aus Produktionsgeräten wie Sensoren, Aktoren und einer Steuerung. Die Geräte sind über ein industrielles Netzwerk verbunden, welches zeitsensitive Übertragungsmechanismen unterstützt. Die Produktionsgüter werden mit einem Förderband transportiert und von einer Kamera zur Qualitätssicherung überprüft.

Abb. 2
figure 2

Demonstrationsanlage zur Qualitätssicherung

Full size image

Der Lichtschrankensensor dient der Objekterkennung und erzeugt ein Signal, mit dem der Auslöser der Kamera über das industrielle Netzwerk angesteuert wird. Dieses Signal muss in Echtzeit übertragen werden, damit die Kamera im richtigen Moment auslöst. Der Antrieb des Förderbands wird nicht-zeitsensitiv über eine Soft-SPS angesteuert. Die SPS erhält den Vorgabewert der Antriebsgeschwindigkeit von einem Gerät in der Anlage. Weiter bereitet die SPS mittels eines Dashboards die Daten der Aktoren und Sensoren auf.

An verschiedenen Punkten der Anlage werden Daten erzeugt und anderen Geräten in Form von Datenservices angeboten. Durch diese Services sind die vorliegenden Daten der Anlage bekannt und können unmittelbar durch andere Geräte angefordert und verwendet werden. Durch die Datenangebote und -anforderungen sind zusätzlich die Kommunikationsbeziehungen im Netzwerk bekannt, sodass das Netzwerkmanagement des industriellen Netzwerks die Geräte miteinander verknüpfen kann. Das Netzwerkmanagement nimmt Rücksicht auf zeitsensitive Datenströme. Datenangebote und -anforderungen der Anlage ermöglichen es beispielsweise mit Hilfe von maschinellem Lernen die Effizienz der Anlage zu steigern oder diese mittels Predictive Maintenance zu überwachen.

3 Stand der Technik

In diesem Kapitel werden die Technologien TSN und OPC UA erläutert, um in späteren Kapiteln darauf Bezug nehmen zu können.

3.1 Time-sensitive Networking

Mit der Arbeit der TSN-Task Group entstehen Standards und Erweiterungen, um Ethernet um Echtzeitfunktionalitäten zu ergänzen. Ziel ist es, Paketverluste zu minimieren, Latenz zu begrenzen und Jitter zu reduzieren. Je nach Anwendungsfall werden verschiedene Standards kombiniert. Eine vielversprechende Möglichkeit für die Verwendung von TSN im Bereich von Produktionsgeräten ist die Kombination aus den Erweiterungen Time-Aware-Shaper (IEEE 802.1Q), der Zeitsynchronisation von TSN-Komponenten (IEEE 802.1AS) und TSN-Konfigurationsmöglichkeiten, beschrieben in IEEE 802.1Qcc. Ein TSN-Netzwerk besteht aus Endpoints und Switches. Endpoints sind Geräte, die zeitsensitive Streams senden (Talker) oder empfangen (Listener).

Der Time-Aware-Shaper (TAS) wird in Geräten mit Switch-Funktionalität eingesetzt. Dort verändert er das Verhalten beim Weiterleiten von Frames. Vor dem Weiterleiten von Frames werden diese in eine von bis zu 8 Queues einsortiert. Die Queues können zu definierten Zeitpunkten einzeln oder gemeinsam geöffnet und geschlossen werden. Somit ist es möglich, Netzwerktraffic unterschiedlich zu priorisieren oder einem Zeitslot zuzuweisen.

Die Zeitsynchronisation wird in Kombination mit dem TAS benötigt, um ideales Weiterleitungsverhalten über mehrere Hops zu garantieren. Die Switches müssen synchronisiert sein, es empfiehlt sich auch Endpoints zu synchronisieren. Die Zeitsynchronisation hilft Latenzgarantien durch das Durchplanen des Netzwerks auszusprechen.

Durch die Konfiguration von Switches und Endpoints kann das Netzwerk geplant werden (Abb. 3). Dafür bieten Talker ihre Streams im Netzwerk an, während Listener einen Stream anfordern. Jeder Stream lässt sich über eine eindeutige StreamId identifizieren. Die Centralized Network Configuration (CNC) ist eine Konfigurationseinheit, welche die Switches im Netzwerk konfiguriert. Dies macht sie auf Basis des zeitsensitiven Bestrebens der Endpoints, die sie als User/Network Configuration Information von der Centralized User Configuration (CUC) erhält. Die CUC ist eine zentrale Stelle, welche die TSN-Informationen von den Endpoints (Talker-, Listener Groups) sammelt und an die CNC weitergibt. Das Feedback der CNC in Richtung Endpoints erfolgt über die Status Groups. Der Informationsinhalt zwischen Endpoints und CUC ist definiert, die Art des Austausches jedoch variabel.

Abb. 3
figure 3

Voll-zentralisierte TSN-Konfiguration

Full size image

3.2 OPC UA

OPC UA ist ein service-orientiertes Framework, mit dem plattformunabhängig Daten zwischen Systemen ausgetauscht werden können. Während OPC UA zunächst in der IT Verwendung fand, wird es mittlerweile vermehrt in der OT angewendet [2]. Mit den Kommunikationsparadigmen Client-Server und Publish-Subscribe unterstützt OPC UA zustandsbehaftete TCP- und zustandslose one-to-many UDP-Kommunikation. Für die Client-Server-Kommunikation wird eine Session aufgebaut und Daten mittels Lese- und Schreibservices ausgeführt. Authentifizierung und Verschlüsselung ermöglichen eine sichere Kommunikation. OPC UA unterstützt das objektorientierte Erstellen von Informationsmodellen, mit denen Daten mittels Objekten und Variablen hierarchisch strukturiert, mit Datentypen versehen und mittels eines OPC-UA-Servers zur Verfügung gestellt werden können. So lassen sich Geräteinformationen, Selbstbeschreibung und (fallbezogene)-AS über einen OPC-UA-Server zur Verfügung stellen [2, 5, 6]. Durch Methodenaufrufe lassen sich Gerätefunktionen abbilden und Aufgaben auf Geräten ausführen.

4 Related Work

4.1 Administration Shell

Mittels der Administration Shell bekommen industrielle Geräte eine digitale Repräsentation, um Geräteinformationen, Gerätefunktionen und Fähigkeiten abzubilden [6]. Sie ist zentrale Anlaufstelle zum Austausch von Informationen und wird genutzt, um Interoperabilität zwischen den Applikationen und den Produktionsleitsystemen auf der Prozessebene herzustellen. Mit der Administration Shell können auch kommunikationsbezogen Informationen zwischen Industrie-4.0-Komponenten beschrieben werden, wie die Autoren in [5] folgern. Weiter stellen sie fest, dass schon viele AS-Konzepte existieren, es jedoch wenige detaillierte Implementierungen gibt. Zudem beziehen sich diese meistens auf eine spezifische Technologie bzw. einen Anwendungsfall. Implementierungen dieser Anwendungsfälle nehmen z. B. die Perspektive einer Steuerung [7] oder das Engineering einer solchen ein [8] und sind applikationsspezifisch.

4.2 OPC UA und TSN

Mit OPC UA TSN wird die Kombination der Technologien von OPC UA und TSN bezeichnet. Mittels OPC UA wird der applikative Teil eines Produktionsgerätes abgedeckt, TSN ist vornehmlich für den kommunikationsbezogenen Teil zuständig [9]. TSN wird für die zeitsensitive Übertragung des Kommunikationsparadigmas Publish-Subscribe genutzt. Um Streams zu versenden, wird der TSN-Talker mit dem OPC-UA-Publisher verknüpft, um Streams zu empfangen, der TSN-Listener mit dem OPC-UA-Subscriber. Dies wird auch als PubSub TSN bezeichnet. Mittels eines OPC-UA-Servers mit einem Informationsmodell lassen sich gerätespezifische sowie TSN-bezogene Identifikationsmerkmale abbilden.

Die Autoren in [2] folgern, dass mit der Kombination von TSN und OPC UA eine vielversprechende Lösung für das IIoT existiert, jedoch müssten dafür noch viele Fähigkeiten bestehender industrieller Feldbusse für OPC UA TSN (weiter-)entwickelt und integriert werden. Diese sind nach [2] unter anderem Geräteidentifikation, -konfiguration, TSN-Endpunktkonfiguration und TSN-Netzwerkschedules. Dies ist Voraussetzung um TSN-Kommunikation im Netzwerk etablieren und nutzen zu können und führt vor allem bei Switched-Endpoints zu einer erhöhten Komplexität.

In [3] wird ein kommerzielles, limitiertes und eingebettetes Feldgerät mit OPC UA und TSN ausgestattet und dieses per OPC-UA-Server modelliert. Die Autoren untersuchen die Antwortzeiten der Serverimplementierungen in der Prozessautomatisierung über ein TSN-Netzwerk, folgern jedoch, dass mit PubSub-TSN-Implementierungen für Regelungsanwendungen höhere Performanz erreicht werden könne. Die Autoren betrachten in einem weiteren Beitrag [10] verschiedene TSN-Traffic-Shaping-Mechanismen bei OPC-UA-Produktionsgeräten, um die Kommunikationslatenz zu reduzieren. Dabei fokussieren sie sich auf Client-Server-Kommunikation mit Geräten, die keine spezielle TSN-Hardwareunterstützung haben. Ein Konfigurationsschema inklusive -ablauf für ein TSN-Netzwerk wird in [11] vorgestellt. Dort wird OPC UA als Schnittstelle zwischen Endpunkten und dem CUC genutzt, jedoch wird nicht wesentlich auf den Inhalt des Informationsaustausches eingegangen.

In vorangegangenen Arbeiten wurde von den Autoren eine Architektur entworfen, die eine Konfiguration von TSN-Netzwerken mit Hilfe von Software-Defined Networking (SDN) ermöglicht [12]. Dort enthalten ist eine CNC-Applikation, die über ein OPC-UA-Interface in einer CUC-Komponente von TSN-Endpoints Konfigurationsanforderungen übermittelt bekommt. In [13] wurde dies erweitert, indem unter anderem die zeitsensitive Kommunikation zwischen fEndgeräten im Netzwerk per OPC-UA-PubSub umgesetzt wurde. Der Fokus von [12] und [13] liegt auf dem Netzwerkmanagement.

5 Konzept und Implementierung

5.1 Konzept Communication Administration Shell

Mittels der Communication Administration Shell (CAS) bekommen Produktionsgeräte eine kommunikationsbezogene Schnittstelle zur Geräteidentifikation, -konfiguration und dem Informationsaustausch. Durch die CAS entstehen drei Schnittstellen zur automatisierten und manuellen Interaktion mit Produktionsgeräten. Einerseits ermöglichen die Schnittstellen die Interaktion mit den Daten Services, andererseits die Konfiguration der kommunikationsbezogenen Geräteeigenschaften (Abb. 4).

Abb. 4
figure 4

CAS mit Schnittstelle zum Informationsaustausch und Konfiguration

Full size image

Mittels der Client-Server-Schnittstelle können die von einem Gerät aggregierten Daten ausgelesen oder mit zu konsumierende Daten beschrieben werden. Zusätzlich ist es möglich, den Datenservice zu konfigurieren, sodass die Daten neben Client-Server entweder per OPC PubSub oder deterministisch über OPC PubSub TSN mittels Multicast im Netzwerk versendet bzw. empfangen werden. Die PubSub-TSN-Konfigurationsmöglichkeit ist nur vorhanden, wenn das Gerät TSN-Mechanismen unterstützt.

Wird in einem Datenservice deterministische Kommunikation aktiviert, wird automatisch ein TSN-Endpoint in der CAS erzeugt. Zusätzlich wird im Datenservice eine Referenz auf den neuen TSN-Endpoint angelegt. Die Talker-Listener-Schnittstelle wird benötigt, um die Aspekte der TSN-Endpoint-Kommunikation extern konfigurierbar zu machen. Sie enthält die Talker-, Listener-, und Statusinformationen, die nach IEEE 802.1Q gefordert sind. Über die Schnittstelle können Talker und Listener von der in [12, 13] genutzten CUC-Komponente automatisch konfiguriert werden.

Die Switch Schnittstelle der CAS definiert Beschreibungen und Fähigkeiten und ermöglicht die Konfiguration der Switch-Netzwerk-Ports eines Gerätes. Hier sind unter anderem die in 802.1Q geforderten TAS-Konfigurations-Parameter zu finden.

5.2 Implementierung der CAS und Datenservices für Produktionsgeräte

Das Konzept der CAS wird auf zwei Geräten implementiert. Die erste Implementierung erfolgt auf einem Hilscher netX 90 Multiprotokoll-SoC Evaluationsboard, die zweite Implementierung auf einem industriellen Raspberry Pi 3 (netPI CORE 3).

Der netX 90 wird häufig als Switched Endpoint eingesetzt und beinhaltet eine ARM Cortex M4 MCU bei 100 MHz Systemtakt sowie eine programmierbare Hardwarearchitektur. Auf dieser ist ein Zwei-Port-TSN-Switch sowie ein TSN-Talker implementiert, der die Fähigkeit des zeitakkuraten Versendens von Endpoint-Frames besitzt. Durch die Hardware-Zeitstempel-Einheit eignet er sich für hochsynchrone und deterministische industrielle Anwendungen. Auf dem netX 90 SoC stehen TSN-Implementierungen von 802.1Qbv, 802.1AS, 802.1Qbu und 802.3br zur Verfügung. Der netPI wird in industriellen Anlagen als SoftSPS und zur Datenakquise eingesetzt und besitzt einen QuadCore Prozessor mit 1,2 GHz. Er besitzt keine Hardware-Zeitstempel-Einheit, wodurch er nicht als synchronisierter TSN-Endpunkt eingesetzt werden kann.

Zur Implementierung der CAS und der Datenservices wird die Open Source OPC-UA-Implementierung open62541 genutzt, welche OPC-UA-Server, -Clients und -PubSub unterstützt. Die CAS, also die virtuelle Repräsentation des Produktionsgerätes, wird durch ein Informationsmodel auf dem OPC-UA-Server umgesetzt (siehe Abb. 5). Über das Informationsmodel sind die Gerätefähigkeiten und Konfigurationsmöglichkeiten sowie die Datenservices angebunden und können von extern per Client abgefragt und konfiguriert werden. In Abb. 6 wird bei einem netX 90 der Datenservice PhotoelectricSensor für eine PubSub-TSN-Datenübertragung konfiguriert. Dabei wird der grau hinterlegte Teil im Bild automatisch angelegt und im Backend die in Data hinterlegten Daten per Stream zeitsensitiv mit eingestelltem PublishingInterval im Netzwerk versendet. Der Stream selbst wird über die Talker und Status Nodes im Talker0 konfiguriert, hier lassen sich die StreamId, der PublishingOffset und weitere Optionen einstellen. Die Implementierung auf dem netPI erfolgt analog zur netX 90 Implementierung, jedoch können TSN- und Switch-Funktionalitäten nicht implementiert werden, da diese nicht vom netPI unterstützt werden.

Abb. 5
figure 5

Implementierung der CAS und Datenservices auf dem netX 90 und netPI

Full size image
Abb. 6
figure 6

CAS Informationsmodell

Full size image

5.3 Integration in industriellen Use Case

Die CAS wird auf den Produktionsgeräten der Demonstrationsanlage zur Qualitätssicherung (Kap. ,,Konzept und Implementierung einer kommunikationsgetriebenen Verwaltungsschale auf effizienten Geräten in Industrie 4.0 Kommunikationssystemen“) umgesetzt. Die Kommunikationsbeziehungen sind hier exemplarisch und können bei sich ändernden Anforderungen durch eine zyklische Kommunikation ergänzt werden. So kann eine Erweiterung der Client-Server-Beziehung um eine PubSub-Beziehung erfolgen, vorausgesetzt, die beteiligten Produktionsgeräte unterstützen dies. Im Use Case ergeben sich folgende Kommunikationsbeziehungen, die durch die Konfiguration der CAS in den Produktionsgeräten entstehen (siehe Abb. 7):

  • Anwendung Kameraauslöser: DataOffer Lichtschrankensensor→ DataRequest Kameraauslöser: PubSub-TSN-Stream, Publishing Intervall 10 ms

  • Steuerung Antrieb: DataOffer Antriebsgeschwindigkeit→ DataRequest SPS: PubSub, Publishing Intervall 250 ms und DataOffer SPS→ DataRequest Antrieb Förderband: Client (SPS), Server (Antrieb)

  • Dashboard Monitoring: DataOffer Lichtschrankensensor→ DataRequest SPS: Client (SPS), Server (Lichtschrankensensor). Alternative: Aktivierung des Subscribers in der SPS, um Publisher mit Id:1zu empfangen.

Abb. 7
figure 7

Konfiguration und Kommunikation von Produktionsgeräten im industriellen Use Case

Full size image

In der Demonstrationsanlage steuert die Lichtschranke den Kameraauslöser, die SPS übernimmt die Steuerung des Antriebs. Gleichzeitig fordert die SPS alle nicht bekannten Sensorwerte der Anlage an und visualisiert sie auf einem Dashboard. Die Konfigurationen der Produktionsgeräte erfolgt über die CAS und ist in Abb. 7 beschrieben.

Der Geschwindigkeits-Soll-Wert für das Förderband wird der SPS mittels OPC-UA-PubSub zur Verfügung gestellt. Das Versenden des Wertes erfolgt alle 250 ms (Publishing Intervall). Die Verbindung ist zur Identifizierung für die Subscriber (SPS) mit der PublisherId:2 versehen. Die SPS berechnet die Geschwindigkeit des Antriebs und übermittelt die Werte mittels eines Clients an den Server des Antriebs. Der Wert des Lichtschrankensensors wird über einen OPC-UA-PubSub-TSN-Stream alle 10 ms dem Kameraauslöser zur Verfügung gestellt. Hierfür wird die PublisherId:1 genutzt und in beiden Geräten TSN-Talker und -Listener aktiviert. Die Talker StreamId wird im Listener der Kameraauslösung eingetragen. Durch die Talker und Listener Elemente der CAS werden die TSN-Endpoints automatisch von der CUC im IIoT-Netzwerk konfiguriert.

Die Konfiguration der Switches auf den Switched-Endpointgeräten erfolgt manuell über die CAS. Das Netzwerk des in Abb. 7 dargestellten Szenarios wird mit einem TAS-Zyklus von 1 ms betrieben. Für TSN-Streams wird ein Zeitfenster von 500 μs reserviert, anderer Verkehr teilt sich die restliche Zeit im Zyklus. Der Einspeise-Zeitpunkt der Frames vom TSN-Talker ist so gewählt, dass eine direkte Weiterleitung der Frames über die TSN-Switches im Netzwerk erfolgt.

6 Validierung

Zur Validierung der Implementierung und erfolgreichen Konfiguration der Geräte werden die versendeten PubSub und PubSub-TSN-Frames auf Paketebene näher untersucht und die versendeten Daten dargestellt (Abb. 8).

Abb. 8
figure 8

(a) Frame Intervall der TSN- und PubSub-Kommunikation, (b) Dashboard-Ausschnitt mit Datenwerten der Demonstrationsanlage

Full size image

Bei der Analyse der PubSub und PubSub-TSN-Frames auf Paketebene wird das Frame Intervall (FI) betrachtet. Das gemessene FI ist die Differenz zweier aufeinanderfolgenden Frames, bezogen auf den Frameanfang. Es entspricht im Idealfall dem eingestellten Publishing Intervall. Zur Messung wird das Netzwerkanalysegerät netAnalyzer der Firma Hilscher an den in Abb. 7 dargestellten Messpunkten im Netzwerk eingebunden. Mit dem netAnalyzer erfolgt ein passiver Mitschnitt der Datenpakete mit anschließender zeitlicher Untersuchung. Die Auswertung der Messdaten ist in Abb. 8a zu sehen. Das FI des PubSub-TSN-Streams besagt, dass die Frames alle 10 ms versendet werden, was dem eingestellten Publishing Intervall entspricht. Die maximale Abweichung der Messwerte untereinander von 10 ns fällt bereits in die Messtoleranz des verwendeten Netzwerkanalysegerätes. Die hohe Präzision des Streams ist auf die Verwendung der integrierten TSN-Talker-Funktionalität zurückzuführen, welche über die CAS aktiviert wurde. Bei der Betrachtung des FI des zweiten Publishers ist das eingestellte Publishing Intervall von 250 ms zu erkennen. Die Streuung der Messwerte nimmt durch die Inaktivität eines TSN-Talkers zu.

Die erfolgreiche Konfiguration zeigt sich auch durch den Empfang des TSN-Streams in der Kameraauslöseeinheit. Die SPS empfängt die Daten der Produktionsgeräte und steuert den Antrieb. Gleichzeitig werden die empfangenen Daten der SPS über ein Dashboard visualisiert (Abb. 8b). Abgebildet sind die Objektdetektion, die Geschwindigkeitsvorgabe und die berechnete Antriebsgeschwindigkeit. Diese Untersuchungen zeigen die funktionsfähige Implementierung der CAS auf den embedded OT-Produktionsgeräten und validiert das Konzept der CAS.

7 Fazit

Durch die CAS können kommunikationsbezogene Fähigkeiten von Produktionsgeräten mit OT-Leistungsprofil abgebildet werden. Die CAS bietet eine gemeinsame Schnittstelle, über die sich Daten zwischen Produktionsgeräten austauschen lassen. Datenservices lassen sich einfach miteinander verknüpfen und flexibel an die Kommunikation und Gegebenheiten zeitsensitiver IIoT-Produktion anpassen. Durch das flexible Bereitstellen von Datenservices stehen die Daten netzwerkweit zur Verfügung, wodurch Produktionsanlagen erweitert und mit Elementen zur Effizienzsteigerung oder Predictive Maintenance ausgestattet werden können. Die Nutzung von OPC UA zur Umsetzung der CAS ergibt eine effiziente und erweiterbare Schnittstelle zur Konfiguration von OT-Geräten, die Switched-Endpoint Fähigkeiten bereitstellen. Durch die gemeinsame Schnittstelle besteht die Möglichkeiten neben der TSN-Endpoints auch TSN-Switch-Funktionalitäten über OPC UA zu konfigurieren. Ein Ansatz automatischer Switch-Konfiguration wäre, die in [12] beschriebene CNC-Komponente um ein OPC-UA-Interface zu erweitern. Weiter könnte die Integration der CAS in ein Submodel einer z. B. nach RAMI spezifizierte AS untersucht werden. Dies sollte unter Berücksichtigung der Ressourcenlimitierung erfolgen.