Bild 1: Marktanteile der industriellen Netzwerke: Die Studie beinhaltet Einschätzungen von HMS für 2018 auf Basis neu installierter Knoten im Jahr 2017 im Bereich der Fabrikautoma­tion. Ein Knoten ist definiert als eine Maschine oder ein Gerät, das mit einem industriellen Netzwerk verbunden ist.

© HMS Industrial Networks

Die erste Generation der Feldbus-Technik wurde in den 1980er-Jahren entwickelt und die Anforderung an ein Automatisierungsgerät war, dass es seine Prozessdaten über verschiedene Feldbusse wie Profibus, Interbus, CAN oder Devicenet übertragen konnte. Mit den Echtzeit-Ethernet-Protokollen wie Profinet, Ethercat und Ethernet/IP folgte in den 2000er-Jahren die zweite Generation der industriellen Netzwerke, die zusätzlich und simultan zu den Prozessdaten weitere Informationen über die aus der IT-Technik stammenden TCP/IP-Protokolle auf demselben Kabel übertragen konnten. Automatisierungs­geräte müssen seither wahlweise Feldbusse oder Industrial-Ethernet-Standards unterstützen, denn Feldbusse haben auch rund zehn Jahre nach Einführung der Ethernet-Technologie noch einen sehr hohen Marktanteil in der Fabrikautomation (Bild 1).

Aktuell zeichnet sich erneut ein Technologie-Umbruch ab: Mit TSN (Time Sensitive Networking) gemäß IEEE 802.1, MQTT und OPC UA schicken sich neue, aus der IT-Welt stammende Protokolle an, das nahtlose Zusammenwachsen der IT-Systeme mit den Fertigungslinien – die IT/OT-Integra­tion – zu ermöglichen. Ziel ist es, über ein einziges Ethernet-Kabel die Prozessdaten – einschließlich der sicheren Signale (Safety) in Echtzeit – sowie die für die industrielle IT relevanten Daten – einschließlich der Informationen für die Anbindung in die industriellen Cloud-Systeme – zu übertragen. Neben den funktionalen Anforderungen wird der Schutz der Automatisierungsgeräte vor unberechtigten Zugriffen über das Netzwerk immer wichtiger und es gilt bereits auf der Feldebene Security-Maßnahmen in Hardware und Software beim Design der Kommunikationsschnittstelle zu berücksichtigen. Damit werden die Anforderungen an die Kommunikationsschnittstelle eines Automatisierungsgeräts vielfältiger und die Kommunikationsschnittstelle mutiert mehr und mehr zum Multitalent. 

Gängige Praxis: Ein Gerät, zwei IP-Adressen

Um alle Anforderungen zu erfüllen, ist es heute gängige Praxis, ein Automatisierungsgerät mit zwei Netzwerk-Schnittstellen auszustatten: Eine für die Prozessdatenübertragung über Industrial Ethernet oder Feldbusse und eine zweite Schnittstelle für die Abwicklung der auf TCP/IP basierten IT-Funktionen wie Visualisierung, Parametrierung, Diagnose und Qualitätsdaten-Erfassung. Dadurch ist ein Automatisierungs­gerät mit Industrial-Ethernet-Schnittstelle oftmals mit zwei IP-Adressen im Netzwerk vertreten. Bei diesem Ansatz entstehen höhere Entwicklungs- und Hardwarekosten sowie zusätzliche Aufwendungen für die Verwaltung und Netzwerk-Planung.

Ein weiterer Nachteil ist, dass so die Anforderungen der Automobilindustrie nicht erfüllt werden. Denn die Automatisierungsinitiative Deutscher Automobilhersteller (AIDA) fordert, dass alle Kommunikationsfunktionen eines Automatisierungsgerätes über eine einzige Ethernet-Schnittstelle und über eine einzige IP-Adresse abgewickelt werden. 

Ziel: Eine IP-Adresse für alles

Die Anforderungen an die IT-Funktiona­lität der Automatisierungsgeräte sind unterschiedlich. Für einfache Geräte wie E/A oder Ventile sind IT-Basisfunktionen ausreichend. Anders bei komplexen Geräten wie Roboter, Schweiß- oder Schrauber-Steuerungen. Diese Geräte stellen typischerweise weit mehr Daten als die reinen Prozessdaten bereit. Sobald diese Geräte über die Möglichkeit der Einbindung in industrielle IT-Systeme verfügen, können sie sinnvoll in datenbasierte Geschäftsprozesse – etwa in die vorausschauende Wartung – eingebunden werden und so ihr volles Potenzial entfalten.

Für die Realisierung einer zeitgemäßen Kommunikationsschnittstelle, die über einen Netzwerk-Anschluss mit einer IP-Adresse für schnelle Echtzeit-Kommunikation, Safety- und IT-Funktionen abwickeln kann, bieten sich zwei grundsätzliche Lösungsvarianten an: 

• All-In-One: Multi-Netzwerk-Schnittstelle mit Real-time-Protokollen und IT-Basisfunktionen mit einem speziellen Netzwerk-Prozessor.
• Splitted-Operation: Multi-Netzwerk-Schnittstelle, bei der Real-time-Protokolle und IT-Funktionen auf getrennten Prozessoren abgewickelt werden.

Die All-In-One Lösung

Die Schnittstelle mit IT-Basisfunktionen und speziellem Netzwerk-Prozessor ist für Automatisierungsgeräte interessant, die nur wenige IT-relevante Informationen bereitstellen, wie etwa Ventilinseln oder Geräte, bei denen der Mikroprozessor der Hauptapplikation aus Performancegründen nicht mit IT-Funktionen belastet werden darf – zum Beispiel bei einem Antrieb. In diesen Fällen wickelt der Prozessor der Schnittstelle zusätzlich zu den Echtzeit-Funktionen des Industrial-Ethernet-Protokolls die TCP/IP-basierten IT-Protokolle wie http, FTP, OPC UA oder MQTT ab. Diese Lösung birgt viele Vorteile, denn alle Kommunikationsfunktionen sind an einer Stelle konzentriert, laufen auf einem Prozessor und können über eine geeignete Software-Schnittstelle weitgehend von der Applikations-Software des Automatisierungs­gerätes entkoppelt werden. 

Bild 2: Module mit IT-Basisfunktionen wickeln zusätzlich zu den Echtzeit-Protokollen auch TCP/IP-basierte IT-Protokolle ab.

© HMS Industrial Networks

Die Realisierung einer solchen Kommunikationsschnittstelle erfolgt meist in Form eines Optionsmoduls, wie beispielsweise das Anybus-Kommunikationsmodul von HMS (Bild 2). Bei einem solchen modularen Design findet eine Aufgabenteilung statt: Das Kommunikationsmodul übernimmt alle Kommunikationsfunktionen und der Hauptprozessor des Automatisierungsgerätes kümmert sich ausschließlich um die Gerätefunktionen. Eine so ausgeprägte Kommunikationsschnittstelle stellt auch eine erste ‚Verteidigungslinie‘ für die Security-Funktionen des Automatisierungsgerätes dar. Die Entkopplung von Kommunikation und Applikation bietet weitere Vorteile, denn bei Änderungen der Protokollspezifikationen oder der Notwendigkeit zur Kopplung an andere industrielle Protokolle, muss lediglich die Kommunikations-Schnittstelle geändert werden. Die Applikations-Software des Automatisierungsgerätes kann meist unverändert bleiben. Auch Hersteller, die keine oder nur wenig Erfahrung mit IT-Funktionen haben, profitieren hiervon. Sie können bei dieser Form der Implementierung ohne zusätzlichen Aufwand die IT-Basisfunktionen des Kommunikationsmoduls wie FTP- und Web-Server, TCP/IP Socket Interface und E-Mail-Client nutzen. Eine weitere Anwendergruppe sind Hersteller, für die IT-Funktionen eher zweitrangig sind.

Die Splitted-Operation-Lösung

Für Gerätehersteller, die sehr hohe Anforderungen an die IT-Funktionen haben, ist es sinnvoll, die Umsetzung der IT-Funktionen und die Abarbeitung der IT-Protokolle auf den Applikationsprozessor zu verlagern und nur die Echtzeit-Protokolle durch das Kommunikationsmodul abarbeiten zu lassen. Auch bei dieser Gerätekategorie ist es im industriellen Umfeld wichtig, die AIDA-Forderung nach Abwicklung aller Kommunikationsfunktionen über eine einzige Ethernet-Schnittstelle und eine einzige IP-Adresse am Netzwerk abzuwickeln. 

Zur Lösung dieser Problematik kommt ein Ethernet-Controller mit RMII-Schnittstelle in Betracht. RMII steht für ‚Reduced Media Independent Interface‘. Über diese Schnittstelle wird der Ethernet-Controller der Kommunikationsschnittstelle direkt von der Gerätesoftware bei der Abarbeitung der IT-Protokolle angesprochen. Das RMII fungiert als Datenweiche, die die Echtzeit-Protokolle – wie Profinet, Ether­net/IP, Ethercat – von den IT-Protokollen trennt. Damit entsprechend schnelle und performante Reaktionszeiten möglich sind, ist die Datenweiche direkt in die Hardware der Kommunikationsschnittstelle zu integrieren. Auch bei dieser Implementierungsmethode gibt es eine klare Aufgabenteilung: Das Kommunikationsmodul bearbeitet die Echtzeit-Protokolle, der Geräteprozessor übernimmt die Gerätefunktionen sowie die Bearbeitung der nicht so zeitkritischen TCP/IP-basierten IT-Protokolle – wie etwa die Darstellung der geräteinternen Webseiten (http), den Filezugriffe (FTP) oder die Kommunikation mit dem HMI über OPC UA.

Bild 3: Anybus-Module mit RMII-Schnittstelle wickeln die Echtzeit-Protokolle ab und reichen die TCP/IP-basierten Protokolle über einen transparenten Ethernet-Kanal an die Hauptapplikation des Automatisierungsgerätes weiter.

© HMS Industrial Networks

Auch für diese Methode der Schnittstellen-Implementierung stellt HMS ein entsprechendes-Kommunikationsmodul zur Verfügung (Bild 3). Wie bei der Variante mit integrierten IT-Basisfunktionen wickelt das Modul mit RMII die Übertragung der Echtzeit-Prozessdaten mit den bekannten Industrial-Ethernet-Protokollen wie Profinet, Ethercat, Ethernet/IP, Modbus und Powerlink völlig eigenständig ab. Die IT-Protokolle werden jedoch über den transparenten Ethernet-Kanal der RMII-Schnittstelle an die Hauptapplikation des Automatisierungsgerätes weitergereicht. Das bietet dem Gerätehersteller größtmögliche Flexibilität und Individualität bei der Realisierung der IT-Funktionen. 

Die Implementierungs-Variante mit transparentem Ethernet-Kanal ist für Hersteller gedacht, die bereits viel Erfahrung im IT-Umfeld besitzen und in ihrem Automatisierungsgerät ein eigenes Betriebs­sys­tem wie zum Beispiel Linux nutzen. 

Meist sind TCP/IP-basierte IT-Protokolle Be­stand­teil des Betriebssystems, sodass die Gerätehersteller die gewünschten IT-Funktionen direkt in ihrer Applikation realisieren können. Eine weitere Anwendergruppe sind Hersteller, die bereits umfangreiche IT-Funktionen für ihr Gerät entwickelt haben und nun vor der Herausforderung stehen, das Automatisierungsgerät an neue Industrial-Ethernet-Netzwerke anzubinden. Dank der RMII-Schnittstelle können diese Hersteller ihre IT-Funktionen weiterhin nutzen und trotzdem von der Multi-Netzwerk-Fähigkeit des Anybus-Konzepts profitieren.

TSN bringt neue Herausforderungen

Bild 4: Im Profinet-Protokoll wird TSN zukünftig die RT-und IRT-Funktionen im Layer 2 ersetzen.

© Profibus Nutzerorganisation

Gerätehersteller, die sich heute mit dem Design der Kommunikationsschnittstelle beschäftigen, sind gut beraten, einen Blick in die Zukunft zu werfen. Denn spätestens seit der letzten Hannover Messe ist klar, dass TSN in den kommenden Jahren Einzug halten wird in die industrielle Kommunikation. So haben alle namhaften Feldbus-Organisationen und viele SPS-Hersteller angekündigt, zukünftig auf TSN als Technologie im Layer 2 ihrer jeweiligen Protokolle zu setzen. So plant beispielsweise die PI-Nutzerorganisation die IRT und RT-Kommunikation bei Profinet zukünftig durch TSN abzulösen (Bild 4). PI hat die Fertigstellung der entsprechend erweiterten Profinet-Spezifikation für Mitte 2019 angekündigt. Spätestens dann stehen Gerätehersteller wieder einmal vor der Herausforderung, die Kommunikationsschnittstelle ihrer Automatisierungsgeräte an die neuen Protokolle anzupassen. Für die Implementierung der Echtzeit-Funktionen von TSN ist eine geeignete Hardware-Unterstützung und damit der Einsatz spezieller Chips zwingend notwendig. Der Hauptgrund dafür liegt in den ausgeklügelten Synchronisations- und Scheduling-Mechanismen von TSN, die ohne spezielle Hardware-Lösungen (Protokollchips) nicht realisiert werden können. Zudem nutzt TSN auch Gigabit Ethernet, während die heutigen industriellen Ethernet-Protokolle überwiegend auf 100-Mbit-Technologie beruhen. Zwar ist davon auszugehen, dass die TSN-Funktionen – ähnlich wie heute CAN – zukünftig in zahlreichen kommerziellen Mikrocontrollern integriert sein wird, für deren Einsatz ist jedoch ein komplettes Re-Design der Hardware und Software der Kommunikationsschnittstelle notwendig. 

TSN einfach nachrüsten

Für den Gerätehersteller ist der Übergang in die neue Kommunikationslandschaft daher entweder mit einem aufwendigen Hardware- und Software- Entwicklungsprojekt verbunden, oder er entscheidet sich für eine modulare Lösung auf Basis einbaufertiger Kommunikationsmodule.

Als Alternative zur Eigenentwicklung einer TSN-fähigen Schnittstelle bietet sich ein Einsatz einbaufertiger Kommunika­tionsmodule, wie etwa die Anybus-Module von HMS an. Solche Module sind einbaufertige Bus-Schnittstellen für Automatisierungsgeräte. Sie beinhalten alle Hardware- und Software-Funktionen einer leistungsfähigen Kommunikationsschnittstelle. Derartige Module gibt es für alle gängigen Feldbus- und Industrial Ethernet Protokolle. Module mit TSN-Integration sind bereits in Entwicklung. 

Der große Vorteil solcher Module liegt in ihrer Austauschbarkeit. HMS erreicht dies durch ein vom jeweiligen Busprotokoll unabhängiges, einheitliches Hardware- und Software-Interface zwischen dem Modul und der Geräte-Elektronik. Automatisierungsgeräte mit einem Modul-Steckplatz können somit neue Technologien wie TSN durch Tausch des Moduls einfach nach­rüsten.

Hightech in drei Varianten

Bild 5: Die Anybus-Technologie gibt es von HMS in den Formfaktoren Modul, Brick und Chip.

© HMS Industrial Networks

Anybus-Module gibt es heute in den drei Formfaktoren Modul, Brick und Chip (Bild 5). Gerätehersteller kommen am schnellsten mit dem einbaufertigen, in sich gekapselten Kommunikationsmodul zum Ziel. Beim Modul ist die komplette Hard- und Software der Kommunikationsschnittstelle einschließlich Netzwerkstecker in ein Kunststoffgehäuse integriert. Das Modul ist als Einschubmodul konzipiert, das in den entsprechenden Steckplatz im Automatisierungsgerät eingesteckt wird. Die Bricks lassen dem Entwickler mehr Freiheitsgrade bei der Auswahl der Steckverbinder und der Positionierung der Kommunikationsschnittstelle. 

Hersteller, die ihre Geräte in sehr hohen Stückzahlen fertigen und daher oft auf Modularität verzichten, können die Anybus-Technologie als Chip nebst Softwarestacks lizenzieren und so die Modul-Kerntechnologie nahtlos in ihre Geräteelektronik integrieren.

Autor: 
Michael Volz ist selbstständiger Unternehmensberater und für HMS als Senior Advisor bei der Entwicklung neuer Geschäftsfelder tätig.