Schlüsselwörter

1 Einleitung

Industrie 4.0 beschreibt eine dynamisch vernetzte Produktion mit dem Ziel der individuellen Massenfertigung und den dafür notwendigen häufigen Rekonfigurationen von Maschinen und Anlagen sowie die Nutzung von datenbasierten Services zur Effizienzsteigerung [1]. Dies erfordert eine flexible und von der Feldebene (Sensoren und Aktoren) bis in das Internet durchgängige Kommunikation, welche von verschiedenen Applikationen einfach genutzt werden kann [1]. IEEE 802.1 Ethernet TSN (Time-Sensitive Networking) wird als Netzwerktechnologie gesehen, welche dies leisten kann, da verschiedene zeitsensitive und nicht-zeitsensitive IT- und OT-Protokolle gleichzeitig und flexibel (stoßfreie Re-Konfiguration) genutzt werden können. In Kombination mit entsprechenden Physical Layer-Technologien wie z. B. Single Pair Ethernet (SPE) und Pover over Data Line (PoDL) wird weiterhin eine einfachere Installation mit integrierter Spannungsversorgung bei Bandbreiten von 10 MBit/s bis 10 GBit/s möglich [1]. Zu den Protokollen, die auf Basis dieser skalierbaren Ethernet-Netzwerke genutzt werden können oder genutzt werden gehören u. A. Profinet [2] und OPC UA. Für Profinet over TSN ist der Standard bereits 2019 verabschiedet worden [2, 3].

Um eine nahtlose Kommunikation zwischen der Prozesssteuerung und den Feldgeräten zu ermöglichen, stellt sich die Frage ob, und wie diese Protokolle ebenfalls skaliert werden können. Das liegt u. A. daran, dass ein SPE-fähiges Gerät sehr begrenzte Rechen- und Speicher-Ressourcen besitzen kann und nur mit wenigen kByte Speicher auskommen muss [4]. Bei einem solchen System spielt einerseits der Preisfaktor eine sehr große Rolle, andererseits darf das Gerät aufgrund der Anforderungen und oft kompakten Bauweise sehr begrenzte Wärmeabgabemenge produzieren bzw. möglichst wenig Energie aufnehmen [5].

In dieser Arbeit wurde ein für ein ressourcenbeschränktes System optimierter Profinet-Stack analysiert (TPS-1) und die Funktionalität im Sinne eines kleinstmöglichen Speicherbedarfs optimiert. Es werden die Möglichkeiten zur Optimierung des Profinet over TSN-Kommunikationsprofils gegenüberbestellt und ein Ausblick auf eine Profinet-SPE-(10 MBit/s)-Sensorschnittstelle gegeben und die Nutzung des OPC UA Nano-Profil betrachtet.

2 Stand der Technik

2.1 Entwicklung der Anforderungen an die Industriellen Kommunikation

Die IT-Systeme in der industriellen Automation sind heute hierarchisch organisiert. Die sogenannte Automatisierungspyramide umfasst dabei die Feldebene mit Maschinen, Sensorik und Aktorik sowie Echtzeitsteuerungssysteme wie z. B. Speicherprogrammierbare Steuerungen (SPS) [3]. Diese Ebene wird international als OT – Operation Technology bezeichnet. Höhere Ebenen der Pyramide enthalten Funktionen zur Auftrags- und Fabriksteuerung (ERP, MES, SCADA). Die Ebenen werden mit Hilfe von Gateways miteinander verbunden. Industrie 4.0 beschreibt aber eine automatisierte Massenproduktion für individuelle Produkte über kurze Lebenszyklen bis hin zur Losgröße 1 (Unikatproduktion) [6]. Dafür ist eine sehr flexible und wandelbare Produktionstechnik notwendig, in der auch die IT-Systeme entsprechend flexibel sein müssen [3]. Per Plug-and-Play sollen sich Anlagenteile neu zusammenstellen lassen und Services einfach mit den Maschinen verbinden um z. B. Diagnose und Optimierungen auf Basis von Daten zu ermöglichen. Die Vernetzung muss dafür sehr viel durchgängiger und einheitlicher werden, da die Konfiguration sonst zu komplex wird (Gateways) und die Daten an Qualität (Latenz: alte Daten, Synchronität, Vollständigkeit, Verfügbarkeit, Abtastraten) verlieren [8]. Die dafür in der Fachwelt diskutierte Architektur ist das Industrielle Internet of Things IIoT. Das IIoT sieht die Virtualisierung von Services und eine durchgängige Vernetzung ohne Gateways bis zum Sensor vor [5].

2.2 Entwicklung der Industriellen Kommunikation hin zu Ethernet TSN-basierten Systemen

Ab dem Jahr 2000 begann die Entwicklung und Einführung von Echtzeit Ethernet wie z. B. Profinet, EtherCAT, Modbus oder Ethernet/IP. Diese Systeme sind nicht interoperabel und können nur sehr begrenzt in einem Ethernet-Netzwerk koexistieren. In der Maschine-zu-Maschine-Vernetzung und Maschine-zu-Service-Vernetzung werden Protokolle wie z. B. MQTT eingesetzt und OPC UA als Interoperabilitätsframework entwickelt [7]. Die Kopplung zwischen der Echtzeit-Vernetzung wird Gateways (Layer 7) realisiert. In der Entwicklung ist derzeit die Ethernet TSN-basierte Kommunikation [5].

2.3 Single Pair Ethernet

Single Pair Ethernet bezeichnet grundsätzlich die Nutzung nur eines Adernpaares für die Ethernet-Kommunikation. Es gibt verschiedene Varianten und laufende Standardisierungsaktivitäten für die grundlegende Technologie. Grundsätzlich werden die für hohe Datenraten entwickelten Modulationsverfahren für kleinere Datenraten verwendet was letztendlich Vereinfachungen am Übertragungsmedium ermöglicht. Tests zum Einsatz von Single Pair Ethernet für die industrielle Echtzeitkommunikation wurden bereits 2012 unternommen. Zu diesem Zeitpunkt war die Standardisierung noch nicht weit fortgeschritten, die Technologie BroadR-Reach des Unternehmens Broadcom war zu diesem Zeitpunkt aber bereits erhältlich. Das Messergebnis der Signalverzögerung betrug 1,35 μs und stellt bei entsprechender Projektierung z. B. für Profinet IRT-Kommunikation kein Problem dar [9]. Inzwischen ist die Technologie zu großen Teilen in IEEE-Standards eingeflossen und wird für verschiedenen Datenraten angewandt und optimiert. IEEE 802.3bw beschreibt Single Pair Ethernet für 100 MBit/s und IEEE 802.3bp für 1 GBit/s. Ergänzend dazu beschreibt IEEE 802.3bu Power over Data Line (PoDL) eine Lösung um parallel Energie über das Adernpaar zu übertragen. Auch verschiedene Lösungen für 10 MBit/s sind genormt und bieten zunehmend die Möglichkeit Ethernet-Kommunikation auch für einfache und kleine Sensoren zu implementieren.

2.4 Möglichkeiten und Maßnahmen zur Optimierung von Softwarecode

Die Wahl der Programmiersprache wirkt sich auf Charakteristiken des Softwarecodes wie Laufzeit und Ressourcenbedarf aus. Bei interpretierten Sprachen (z. B. Python) und auf virtuellen Maschinen aufgebaute Sprachen (z. B. Java) muss auf der Zielplattform zusätzlich auch ein Interpreter oder eine virtuelle Maschine vorhanden sein. Der Ressourcenbedarf erhöht sich somit indirekt. Die Komplexität der Sprache erhöht in der Regel dem Entwicklungskomfort, geht jedoch oft mit erhöhtem Overhead an Programmkomplexität und Speicherbedarf einher [18].

Compiler bieten Techniken zur automatisierten Codeoptimierung (z. B. Dead Code Eliminierung uvm.) in Bezug auf Laufzeit oder Speicherressourcen. Eine automatische Optimierung von handgeschriebenem Code bietet möglicherweise Potenzial zu Verbesserung der Ressourcennutzung. Unter der Annahme von grundsätzlich hoher Qualität des handgeschriebenen Codes im professionellen Umfeld ist das Potenzial wahrscheinlich gering. Zu evaluieren wären hier die unterschiedlichen Compiler und Techniken.

3 Untersuchung des Ressourcenbedarf PROFINET-Profile und PROFINET-Stack

3.1 PROFINET-Stack mit den Profilen RT und IRT

In dieser Arbeit wurde dazu ein für ein ressourcenbeschränktes System optimierter Profinet-Stack analysiert (TPS-1) und die Funktionalität im Sinne eines kleinstmöglichen Speicherbedarfs optimiert. Der TPS-1 besitzt eine integrierte CPU, die den Profinet-Stack ausführt. Der TPS-1 unterstützt die Profinet-Kommunikationsklassen RT und IRT. Der Chip hat zwei externe 100 MBit/s-Ports mit integrierten PHY-Transceivern. Der integrierte IRT-Switch unterstützt 8 Prioritätenwarteschlangen (eng. Queues). Das Bridge Delay des Cut Through-Switch beträgt 3 μs. Das Gehäuse ist ein 15 mm x 15 mm FPBGA (Fine Pitch Ball Grid Array) mit 1 mm Ball Pitch und 196 Pins. Als Applikationsschnittstelle bietet der TPS-1 48 GPIOs, die individuell als digitale Inputs oder Outputs konfiguriert werden können, einen 8 oder 16 Bit-Host-Interface und ein serielles Host Interface (SPI). Neben dem Ethernet-Switching inklusive der von Profinet definierten IRT-Erweiterung für deterministisches Ethernet-Bridging sind also Hardwarefunktionen für die Applikation selbst vorhanden. Der TPS-1 hat eine maximale Leistungsaufnahme bzw. Abgabe von 800 mW und ist damit für sehr kleine Feldgeräte wie z. B. IP 67 besonders gut geeignet. Intern ist der Tiger-Chip aus zwei einzelnen Chips aufgebaut, die durch eine SIP-Lösung (System-in-Package) zu einem ASIC zusammengeführt wurden: Ein 100-MBit/s-Dual-PHY ist in 150-nm-Technologie gefertigt. Beim ARM-Subsystem inkl. der Profinet-Hardware-Unterstützung hingegen wird eine Strukturgröße von 90 nm verwendet. Die ARM-CPU arbeitet mit 100MHz und ist mit einem 768 KB großem ,,Tightly Coupled Memory“ (TCM) als RAM ausgestattet.

Wie bereits erwähnt wird der TPS-1 mit der speziell dafür entwickelten Firmware (Profinet-Stack) ausgeliefert. Diese Firmware bietet Unterstützung für alle Hardware-Funktionen und Konfigurationen des TPS-1. Profinet-Funktionen werden unabhängig von den Einsatzvarianten unterstützt. Hierzu zählen der Einsatz des TPS-1 in einem komplexen Profinet-Device in Kombination mit einer leistungsfähigen Host-CPU und die Verwendung als ,,stand alone“-Lösung für einfache Sensor-Applikationen oder kompakte Geräte. Für diese unterschiedlichen Geräteklassen wird aus Usability-Gründen immer dieselbe Firmware verwendet. Diese Tatsache legt nahe, dass es je nach Verwendung des TPS-1 in der Firmware bestimmte Codebereiche gibt, die für andere Konfigurationen des TPS-1 zuständig sind und die sonst nie während der Nutzungsdauer eines bestimmtes Profinet-Devices verwendet werden. Diese Codebereiche belegen demnach unnötig die ohnehin schon knappen Speicherressourcen (RAM/ROM). Diese Speicherressourcen könnten für eventuelle andere Anwendungen wie OPC UA oder andere Web-basierte Dienste alternativ benutzt werden. Aus dieser Überlegung heraus entstand die Motivation, den minimalen Code- und Speicher-Bedarf (Footprint) für den TPS-1 unter den speziellen Konfigurations-Annahmen und minimalistischen Anforderungen an Profinet-Funktionalität zu ermitteln.

In Abb. 1 ist der Ausgangs-Speicherbedarf der TPS-1-Firmware im ,,Vollausbau“ mit Unterteilung in einzelne Funktionen des PN-Stacks angegeben.

Abb. 1
figure 1

Code- (oben) und Data-Größen aufgeschlüsselt nach Funktionen des TPS-1 PROFINET-Stack im ,,Vollausbau“

Full size image

3.2 PROFINET over TSN

Im Jahr 2019 wurde auf Basis dieser IEEE Ethernet-Weiterentwicklungen Ethernet TSN in Profinet integriert. Der entsprechende Profinet-Standard V2.4 wurde im Jahr 2019 verabschiedet [14, 15]. Es ist der erste Profinet-Standard, der die Nutzung von TSN für Profinet beschreibt. Profinet over TSN wurde dabei an die aktuelle IEC/IEEE 60802-Standardisierung angelehnt und soll dabei in Zukunft so weitergestaltet werden, dass Profinet mit einem IEC/IEEE 60802-Netzwerk funktioniert [PNG20]. Profinet definiert die Nutzung der Kommunikationsklassen. Es gibt drei Kommunikationsklassen für Echtzeitkommunikation: Profinet RT HIGH für synchrone Applikationen, dass kleinste Zykluszeiten erlaubt und Profinet RT LOW für Echtzeitapplikationen, dass Ressourcenschutz und deterministische Übertragungsverzögerung garantiert [PNG20] und Profinet RT, dass dem bereits existierenden Profinet RT entspricht, sicher keiner TSN-Funktionen bedient aber über ein TSN-Netzwerk genutzt werden kann [16].

Der Ressourcenbedarf von PROFINET over TSN wurde auf Basis eines Prototyps analysiert. Es wurden die notwendigen Funktionen von PROFINET IRT denen von PROFINET over TSN gegenübergestellt. Ergebnis ist, dass für eine einfache Feldgeräteklasse der Ressourcenbedarf von IRT dem von TSN sehr ähnlich ist. So ist zum Beispiel die Zeitsynchronisation IEEE 802.1AS anstatt PTCP notwendig. Diese sind von der Komplexität vergleichbar.

4 Protokolle für ressourcenbeschränkte Feldgeräte

4.1 Vorschlag für ein PROFINET Nano-Profil (Sensorprofil)

Für die Optimierung im Hinblick auf ein PROFINET-Nano-Profil (das zum Beispiel auch für die Integration einer PROFINET-Kommunikation in Sensoren und in Verbindung mit Single Pair Ethernet sinnvoll eingesetzt werden könnte) wurden folgende Rahmenbedingungen festgelegt:

  • Nur die Local-IO-Betriebsart soll unterstützt werden

  • Der Profinet-Funktionsumfang soll soweit reduziert werden, dass nur eine RT-Class 1 Verbindung mit einem Controller möglich ist.

Die Nutzung nur einer fest vorgegebener Betriebsart erlaubt es, auf die Konfigurations-Funktionen im Codebereich und zusätzlich auf die Konfigurationsdaten im Flash-Speicher zu verzichten. Die größte Optimierung lässt sich aber mit Einschränkungen des PROFINET-Funktionsumfangs erreichen. So macht z. B. die Einschränkung auf die RT Class 1 alle RT Class 3 spezifischen Funktionen, wie Zeitsychronisation, Kabellängenmessung, Topologie-Erkennung und Topologie-Überwachung sowie Teile der Diagnose- und Alarm-Funktionalität, überflüssig.

Weitere Optimierungen im Databereich (Stack- und Heap-Speicher) lassen sich durch den Verzicht auf die ,,Shared Device“-Unterstützung (gleichzeitiger Betrieb mit zwei Profinet-Controllern) und durch Beschränkung der maximalen Länge der Nutzdaten auf 256 Byte erreichen. Dadurch kann die Anzahl und die Grösse der Sende- und insbesondere Empfangs-Buffer erheblich reduziert werden. Auf diese Weise lies sich der Code des Profinet-Stacks von 147 KByte auf 78 KByte und Data von 165 KByte auf nur 24 Kbyte reduzieren. Abb. 2 zeigt das Ergebnis des auf minimalen Footprint optimierten Profinet-Stacks aufgeschlüsselt nach Codegröße (Instructions) und Funktionalität (links) sowie Datagröße (Stack und Heap) und Funktionalität (rechts).

Abb. 2
figure 2

Code und Data Größe PROFINET-Nano-Sensorprofil aufgeschlüsselt nach Funktionen eines Profinet-Stacks mit minimiertem Foodprint

Full size image

Eine zukunftsweisende Ergänzung für ein solches Nanoprofil ist eine einfache Integration der PROFINET over TSN-Kommunikationsklassen RT LOW oder RT HIGH. Bei einem Feldgerät mit nur einem Port und z. B. 100 MBit/s Datenrate oder 10 MBit/s SPE können je nach Kommunikationsklasse Vereinfachungen in der Implementierung vorgenommen werden.

4.2 OPC UA Nano-Profil

Ein Profil bündelt eine Anzahl von OPC UA Leistungsmerkmalen und ergibt sich aus der Summe spezifischer Aspekte einer OPC UA Anwendung (Facetten). Ein Full-Featured Profil enthält einen vollständigen Satz von Leistungsmerkmalen um eine vollständige OPC UA Applikation zu ermöglichen. Abb. 3 zeigt das Micro Embedded Device Server Full-Feature Profil. Neben der Embedded DataChance Subscription Facette enthält es das Nano Embedded Device Server Full-Feature Profil, das kleinste vollständige Profil eines Servers für Geräte mit begrenzten Ressourcen. Einige der Leistungsmerkmale der verschiedenen im Nano Profil enthaltenen Facetten sind optional für die Konformität (Tab. 1). So ist beispielsweise das Leistungsmerkmal Adress Space Base der Core Server Facette im Nano Profil als Grundlage des sog. Adress Space von OPC UA stets notwendig. Ein optionales Leistungsmerkmal ist hingegen Attribute Write Values, wodurch die Unterstützung zum Schreiben von Attributwerten auf einem OPC UA Server entfällt [17]. Bei der Implementierung kann somit auch ein weiterer Teil Programmspeicher eingespart werden. Das Kürzen oder der Verzicht weiterer Leistungsmerkmale ist zu evaluieren, geht aber mit dem Verlust der Konformität einher. Für Systeme mit weniger als 1 MB Programmspeicher und 100 kB RAM gilt die Implementierung von OPC UA als herausfordernd, aber als theoretisch möglich [18].

Abb. 3
figure 3

Das Micro Embedded Device Server Full-Featured Profil

Full size image
Tab. 1 Optionale Leistungsmerkmale des Nano Embedded Device Server Profils [17]
Full size table

5 Zusammenfassung und Ausblick

Industrie 4.0 erfordert eine flexible und von der Feldebene (Sensoren und Aktoren) bis in das Internet durchgängige und skalierbare Kommunikationslösung. IEEE 802.1 Ethernet TSN (Time-Sensitive Networking) und Single Pair Ethernet werden als Netzwerktechnologien gesehen, welche dazu einen Beitrag leisten können. Zu den Protokollen, die auf Basis dieser skalierbaren Ethernet-Netzwerke genutzt werden können oder genutzt werden, gehören Profinet und OPC UA. Ein SPE-fähiges Gerät muss mit einem Prozessorsystem mit wenigen kByte Speicher auskommen, da ein solches System sehr preissensitiv ist und aufgrund der sehr begrenzten Wärmeabgabemenge nur wenig Energie aufnehmen darf. Entsprechend muss neben der Netzwerktechnologie auch das genutzte Protokoll skalierbar sein. Sowohl Profinet als auch OPC UA beinhalten bereits heute Skalierungsmöglichkeiten durch Profile. Die Grenzen dieser Profile und Vorschläge zur Erweiterung dieser Grenzen wurden im Beitrag am Beispiel des TPS-1-Chips vorgestellt. Für Profinet wurde zudem ein Sensorprofil mit einem minimalen Footprint vorgeschlagen. Bei einem Feldgerät mit nur einem Port und z. B. 100 MBit/s Datenrate oder 10 MBit/s SPE könnte für die PROFINET over TSN-Kommunikationsklasse RT LOW eine vereinfachte Implementierung vorgenommen werden.