Funktionsdurchgängige Kopplung von Industrial Ethernet

Funktionsdurchgängige Kopplung von
Industrial Ethernet-Protokoll-Domänen mit Multi-Layer-Gateways
Carsten Pieper, Daniel Kirschberger, Björn Kroll, Sebastian Schriegel
Fraunhofer IOSB-INA
Anwendungszentrum Industrial Automation
Langenbruch 6
32657 Lemgo
{carsten.pieper; daniel.kirschberger; bjoern.kroll; sebastian.schriegel}@iosb-ina.fraunhofer.de
Markus Schumacher, Eugen Breit
inIT - Institut für Industrielle Informationstechnik1
Hochschule Ostwestfalen-Lippe
Liebigstrasse 87
32657 Lemgo
{markus.schumacher; eugen.breit}@hs-owl.de
Abstract: Die Entwicklung der industriellen Kommunikation hat als Nachfolgetechnologie der
Feldbustechnik 29 Industrial Ethernet-Typen hervorgebracht. Dabei wurde teilweise auf eine zu den
Feldbus-Systemen kompatible Anwenderschicht (APP) geachtet; die Kompatibilität der Industrial
Ethernet-Typen untereinander beschränkt sich i.d.R. auf das physikalische Übertragungsmedium (PHY).
Jedes Kommunikationsprotokoll hat spezifische Eigenschaften wie die kleinste erreichbare Zykluszeit,
Isochronität, Robustheit, Diagnosefähigkeit, Schnittstellenkosten, Durchgängigkeit für IT-Dienste und
Marktverbreitung. Auf Grund dieser Eigenschaften sind die Protokolle für verschiedene Anwendungen
unterschiedlich gut geeignet. Bei der Protokollumsetzung werden häufig Kompromisse eingegangen und
System-Eigenschaften wie zum Beispiel die Diagnosefähigkeit oder die minimale Aktualisierungszeit
verlieren an Performance oder gehen gegeben falls sogar verloren. Dies betrifft auch modulare I/OSysteme die häufig eine Umsetzung der Daten über eine Gateway-Busklemme auf einen Rückwand- bzw.
Stationsbus vornehmen. Welche Eigenschaft in welcher Qualität mit einer Protokollumsetzung erhalten
bleibt oder genutzt werden kann, hängt von der Adaptierungseigenschaft der Kommunikationsprotokolle
und von der Gateway-Architektur ab. Da die unterschiedlichen Systemeigenschaften industrieller
Kommunikation verschiedenen ISO/OSI-Layern zugeordnet sind, ist eine Umsetzung auf verschiedene
Layer notwendig um die Funktionen durchgängig nutzen zu können. Solche Gateways werden als MultiLayer-Gateways bezeichnet.
1 Einleitung
Die Gemeinsamkeiten von Real Time Ethernet-Protokollen (RTE) beschränkt sich oft auf das physikalische
Übertragungsmedium (IEEE 802.3 Ethernet). Jedes Kommunikationsprotokoll hat spezifische Vorteile wie
die kleinste erreichbare Zykluszeit, Schnittstellenkosten, Durchgängigkeit für IT-Dienste, Marktverbreitung,
Synchronität und Medienredundanz. In der Praxis kommen in einer Automatisierungsanlage häufig mehrere
IE-Typen zeitgleich zum Einsatz. Je nach Protokoll können diese (1) auf dem Ethernet-Netz koexistent
betrieben werden oder (2) müssen eigenen abgeschlossenen Domänen bilden (Abbildung 1). Um eine
Kommunikation zwischen RTE-Protokolldomänen zu realisieren, müssen an den Schnittstellen
Protokollumsetzer, sog. Gateways, verwendet werden. Modulare I/O-Systeme nutzen i.d.R. Gateways um die
Kommunikation auf lokale Stations-/Rückwandbusse umzusetzen und bilden damit ebenfalls eine eigene
Kommunikationsprotokolldomäne. Um bei einer Protokollumsetzung System-Eigenschaften nicht zu
verlieren, sind (1) gute Adaptierungseigenschaften der Kommunikationsprotokolle und (2) eine
entsprechende Gateway-Architektur notwendig [V11]. Ein Beispiel für so eine Systemeigenschaft ist die
Synchronisierung des Kommunikationszyklus zum überlagerten RTE-System. Im Bereich durchgängiger ITKommunikation liegt die Adaptivität in der Möglichkeit einer protokolldomänenübergreifenden
Adressierung (z. B. auf Basis von IP- und MAC-Adressen). Für diese Funktionsdurchgängigkeit sind
Gateway-Architekturen mit einer tiefen Verzahnung der Kommunikationsmechanismen notwendig. Eine
Kopplung auf Anwenderschicht wie sie von herkömmlichen Gateways (Layer 7-Gateways) bekannt ist,
reicht nicht aus, da Kommunikationseigenschaften wie Adressierung, Synchronität und Verfügbarkeit
tieferen Schichten des ISO/OSI-Kommunikationsmodells zugeordnet sind. Bei der Entwicklung eines
Gateways müssen somit jeweils spezielle Eigenheiten der RTE-Typen berücksichtigt und in
Architekturdesign des Gateways berücksichtig werden.
Abbildung 1: Gateway vs. RTE-Protokollmedienkoexistenz
Dieses Dokument beschreibt in Kapitel 2 den Stand der Technik zu Systemeigenschaften ausgewählter RTEProtokolle, herstellereigenen Systembusse und gibt eine Taxonomie von Gateway Architekturen. Nach einer
Analyse in Kapitel 3 wie der Einsatz von Gateways mit einhergehenden Funktionsverlusten vermieden
werden kann, werden in Kapitel 4 Adaptionseigenschaften von RTE-Protokollen exemplarisch analysiert und
in Kapitel 5 eine Multi-Layer-Gateway Architektur abgeleitet und bewertet.
2 Stand der Technik
Im Standard IEC 61158 sind verschiedene Protokolle zur industriellen Echtzeitkommunikation mit Ethernet
beschrieben. Dazu zählen zum Beispiel SERCOS III, Powerlink, Ethernet/IP, PROFINET, EtherCAT und
Modbus TCP. Jedes Protokoll hat unterschiedliche Eigenschaften bezüglich Aktualisierungszeiten,
Synchronität, Determinismus, Durchgängigkeit für IT-Dienste, Verfügbarkeit und Applikationsmodell. Aus
diesem Grund sind die Protokolle für verschiedene Anwendungen unterschiedlich gut geeignet. Bezüglich
Echtzeitfähigkeit und Umfang der spezifizierten Erweiterungen zu IEEE 802.3 können die Protokolle in drei
Leistungsklassen eingeteilt werden, wie Abbildung 2 zeigt.
Abbildung 2: Klassifizierung von Echtzeit-Ethernet-Protokollen
In den folgenden Unterkapiteln werden 6 Protokolle, die im europäischen und amerikanischen Markt stark
verbreitet sind, vorgestellt.
2.1
Systemeigenschaften von Echtzeit-Ethernet-Protokollen
2.1.1
PROFINET IO
Der Echtzeit-Ethernet-Standard PROFINET IO definiert für taktsynchrone Anwendungen die synchrone
Kommunikation IRT (Isochrones Real-Time) und ein auf die Kommunikation synchronisiertes
Applikationsmodell [IEC06a] [IEC06b]. Eine weitere Kommunikationsoption ist PROFINET RT (RealTime), welche ohne Synchronisation in der Kommunikation arbeitet aber unabhängig davon gegeben falls
eine Synchronisation zur Applikation realisieren kann. PROFINET IRT bietet Taktsynchronität mit einer
Genauigkeit von 1μs und Zykluszeiten bis zu 250μs. Diese Leistungsfähigkeit ist nur mit Erweiterungen am
Ethernet-MAC-Layer möglich und wird aus diesen Gründen in der Klassifizierung der Abbildung 2 der
Klasse 3 zugeordnet.
PROFINET RT und Ethernet/IP basieren auf Schicht 2 und ändern den Ethernet-Medienzugriff nicht. Sie
werden daher nicht den Klasse 3-Protokollen zugeordnet und verfügen nicht über die maximale Leistung
hinsichtlich erreichbarer Zykluszeiten. Durch die große Übereinstimmung mit dem Ethernet-Standards IEEE
802.1D/Q und 802.3 können die Protokolle aber zu einem hohen Anteil koexistent betrieben werden.
Aufgrund der Nutzung von VLAN-Prioritäten und Multicast-Telegrammen werden bei der Verwendung
eines gemeinsamen Mediums Beeinflussungen auftreten.
Abbildung 3: Priorisiertes Ethernet-Switching: PROFINET RT und Ethernet/IP
PROFINET-Switching erlaubt die Existenz beliebiger weiterer Frametypen und kann damit grundsätzlich
andere Protokolle direkt durchleiten, damit ist eine nahezu transparente Koexistenz ist gegeben. Die
niedrigen Zykluszeiten bei der Verwendung von PROFINET IRT werden erreicht indem parallel zu der
bekannten VLAN-Priorisierung ein Mediumscheduling verwendet wird. Die Abbildung 4 zeigt prinzipiell
das Scheduling von PROFINET IRT hierzu wird zunächst die zur Verfügung stehende Bandbreite in sich
wiederholende Zyklen eingeteilt. In einem Zyklus werden während der roten Phase ausschließlich
realzeitkritische Daten, zu einem geplanten Zeitpunkt, gesendet. In der grünen und gelben Phase wird der
Standard-Ethernet Verkehr gesendet. Während in der grünen Phase die Frames im Cut-Through Verfahren
weitergeleitet werden können, wird in der gelben Phase ausschließlich in Store & Forward weitergeleitet. Die
Dauer der gelben Phase ergibt sich mit der Transferzeit eines maximalgroßen Frames, in Kombination mit
Store & Forward wird auf diesem Wege sichergestellt, dass kein nichtrealzeitkritisches Frame in die rote
Phase hineinreicht.
Damit die verwendete Planung der Phasen effizient funktioniert setzt PROFINET IRT voraus, das die
Teilnehmer einer Netzdomäne zeitsynchron zu einander sind.
Abbildung 4: Scheduling PROFINET-IRT
Von den Echtzeit-Ethernet-Protokollen der Klasse 3 bietet PROFINET IRT durch den Einsatz der non
Realtime Traffic (NRT) Phasen (grün, gelb) die Möglichkeit andere Protokolle auf Schicht 2 koexistent zu
betreiben.
2.1.2
EtherCAT
EtherCAT [IEC07a] [IEC07b] wird in einer (logischen) Ringtopologie betrieben. Die
Weiterleitungsentscheidung geschieht nicht auf Basis von Adressen sondern der Topologie. Die Nutzdaten
werden in einen Summerahmen durch den vollständigen Ring geleitet, wobei die EtherCAT-Slaves innerhalb
der Topologie jeweils im Cut-Through-Modus arbeiten. Dadurch entsteht eine deterministische
Kommunikation, da die Update-Rate (Zykluszeit) durch den jeweiligen Master vorgegeben wird und jedes
Gerät innerhalb der Topologie eine definierte Forwarding-Zeit aufweist. Dies macht das Protokoll für
Echtzeitdaten schnell und effizient. Die erreichbare minimale Zykluszeit liegt bei 50µs. Zusätzlich bietet
EtherCAT ein synchronisiertes Applikationsmodell (Distributed Clocks).
Eine Koexistenz mit anderen Protokollen ist bei EtherCAT im Direct-Mode nicht vorgesehen und
dementsprechend auch nicht zugelassen. Um dennoch die eine Kommunikation normaler IT-Dienste
(TCP/IP) innerhalb eines EtherCAT-Strangs zu ermöglichen, nutzt EtherCAT den Mechanismus des
Einbettens dieser Daten in die EtherCAT-eigenen Echtzeittelegramme. Hierfür werden spezielle EtherCATGeräte benötigt, welche diesen Mechanismus des Tunnelns unterstützen.
Eine weitere, jedoch eingeschränkte, Möglichkeit einer Koexistenz mit anderen Ethernet-basierten
Protokollen ist gegeben, wenn Teile der EtherCAT-Topologie im sog. OpenMode betrieben werden. Hier
werden einzelne EtherCAT-Stränge über spezielle EtherCAT-Geräte gekoppelt, welche die EtherCATTelegramme in UDP/IP kapseln. Die Kommunikation zwischen den einzelnen Stränge und dem Master
erfolgt den mittels klassischer, von IT-Diensten bekannter, Ethernet-Kommunikation, wobei hier auch andere
Protokolle koexistent betrieben werden können.
Abbildung 5: EtherCAT-Forwarding
2.1.3
Sercos III
Ein Master-Slave Prinzip kommt bei SERCOS III zu Einsatz um den Austausch der I/O Daten zwischen
Steuerung und Device durchzuführen. Des Weiteren kann direkter Daten Querverkehr zwischen den Devices
zwischen Steuerungen erfolgen, die sogenannte (Cross Communication).
Neben der Echtzeit-Kommunikation sind auch normale IP Verbindungen möglich. Der Medienzugriff wird in
Zeitschlitze unterteilt um einen RT und NRT Kanal zu bekommen. Die Zykluszeiten können zwischen
31,25µs bis 65 ms gewählt werden. Zur Realisierung des NRT Kanal werden größere NRT Frames
fragmentiert.
2.1.4
ModBUS TCP
ModBUS TCP [MIDA06] nutzt das TCP/IP Protokoll, welches wiederum auch andere Übertragungsmedien
neben dem Ethernet nutzen kann. Durch den Einsatz TCP/IP ist dieser Standard routingfähig und ermöglicht
weltweite Zugriffe auf das Automatisierungsnetz. Ein ModBUS-Master stellt eine Request mit möglichen
Ausgangsdaten und ModBUS-Slave antwortet mit möglichen Eingangsdaten. Prozessdaten werden über eine
IP-Adresse des Gerätes und die Adresse des Applikationsspeichers angesprochen werden. Es können 16-Bit
und 1 Bit Werte geschrieben und gelesen werden. Gerätemodel, Verbindungsüberwachung mit Wirkung auf
die Ausgangsdaten, Isochronität, Diagnosefunktionen und die garantierte Aktualisierungszeit werden in der
ModBUS-Spezifikation nicht beschrieben.
2.1.5
PowerLink
Powerlink nutzt als Medium IEEE 802.3 Kabel, allerdings wird im in Layer 3-7 das CANopen Protokoll
realisiert. Der Medienzugriff wird zentral von der Steuerung, bzw. einem Kommunikationsmaster, über ein
Polling-Verfahren vorgenommen. Durch die Master/Slave-beziehung und durch die zyklische Freigabe, wird
ein Einspeisen weiterer Frames unterbunden, um das Echtzeitverhalten nicht negativ zu beeinflussen. Durch
diese Kapselung können in einem Powerlink Netz Zykluszeiten von unter 200 µs sowie ein Jitter von 1 µs
erreicht werden[EPSG08].
Powerlink-Netze verwenden Hubs oder Switches, wie Abbildung 6 gezeigt (vom Standard werden Hubs
empfohlen).
Abbildung 6: Forwarding bei PowerLink
2.2
Herstellereigene lokale Systembusse
Eingänge
Ausgänge
digital
analog
Weit verbreitet sind modulare I/O-Systeme und modular aufgebaute Servo- und Frequenzumrichter. Diese
nutzten eine lokale Systemkommunikation und eine gemeinsame Echtzeit-Ethernet-Schnittstelle zur
überlagerten Steuerung. Beispiele sind das Inline-System der Firma Phoenix Contact oder der ClicpsyncSystembus in modularen Antrieben der Firma Siemens. Diese Modularität hat das Ziel Teilkomponenten
gemeinsam zu Nutzen und so Kosten einzusparen. Dies wiederum ermöglicht häufig eine Steigerung der
Feingranularität und flexibleren Nutzung und Anpassung von Systemkomponenten auf die Anwendung.
Abbildung 7: Aufbau modulare I/O-Station
Die Umsetzung zwischen der lokalen Systemkommunikation und der Echtzeit-Ethernet-Kommunikation
übernimmt in diesen Systemen ein Gateway. Dies wird häufig auch als Busklemme oder Buskopf bezeichnet.
2.3
Taxonomie Gateway-Technologien
Ein Gateway wird im Allgemeinen als Protokollumsetzer bezeichnet. Kommunikationssysteme sind häufig
heterogenen Charakters, die spezifischen Funktionalitäten können aber auf das generische standardisierte
ISO/OSI-Referenzmodell der Kommunikationstechnik abgebildet werden.
In der industriellen Kommunikation wird das OSI-Referenzmodell i.d.R. auf die Schichten 1, 2 und 7
reduziert (s. Abbildung 8). Auf diesem Weg wird die Komplexität reduziert und damit Echtzeitfähigkeit
verbessert. Da eine Unabhängigkeit von Medium sowie Protokoll erst auf der Schicht 7 gegeben ist, sind aus
technischer Sicht Gateways auf dieser Schicht sinnvoll.
Abbildung 8: IEC 61158/ IEC 61850-Gateway
3 Vermeidung von Gateways
Bei Nutzung von Gateways können die eingangs beschriebenen Funktionsverluste auftreten. Die Vermeidung
von Gateways liegt also nahe. Gateways werden eingesetzt, weil bestimmte Geräte nicht mit allen RTEprotokollen verfügbar sind oder Systemeigenschaften aus unterschiedlichen RTE für bestimmte Anlagenteile
benötigt werden. Es gibt zwei Basisansätze wie auch ohne Gateway in so einem heterogen aufgebauten
Automatisierungsnetzwerk durchgängig kommuniziert werden kann. Diese werden hier beschrieben.
3.1
RTE-Protokoll-Koexistenz auf dem Medium
Die Koexistenz von Protokollen auf einem Medium wird entscheidend davon beeinflusst, auf welcher
Schicht (IOS/OSI-Kommunikationssystem) die Protokolle auf den Standard Ethernet aufsetzen. SERCOS III
und EtherCAT werden grundsätzlich in einer (logischen) Ringtopologie betrieben. Das Weiterleiten von
Telegrammen ist damit trivial, da jedes Gerät nur zwei Ports besitzt und damit faktisch kein Switching
benötigt wird. Es sind aber keine anderen Telegramme auf dem Medium zugelassen. Auf dem Medium ist
eine Koexistenz mit anderen Protokollen also grundsätzlich ausgeschlossen. Powerlink-Netze verwenden
Hubs oder Switches. Der Medienzugriff wird zentral von der Steuerung bzw. einem Kommunikationsmaster
über ein Polling-Verfahren vorgenommen. Das Einspeisen weiterer Frames würde das Echtzeitverhalten
dieses Verfahrens negativ beeinflussen und ist damit ausgeschlossen, Koexistenz ist also nicht möglich.
PROFINET RT und Ethernet/IP basieren auf Schicht 2 und ändern den Ethernet-Medienzugriff nicht. Sie
werden daher nicht den Klasse 3-Protokollen zugeordnet und verfügen nicht über die maximale Leistung
hinsichtlich ihrer Zykluszeiten. Durch die große Übereinstimmung mit dem Ethernet-Standard können die
Protokolle aber zu einem hohen Anteil koexistent betrieben werden. Es können jedoch Beeinflussungen
durch die Nutzung von VLAN-Prioritäten und Multicast-Telegrammen auftreten. PROFINET-Switching
erlaubt die Existenz beliebiger weiterer Frames und kann damit grundsätzlich andere Protokolle direkt
durchleiten, d.h. eine Koexistenz ist gegeben. Die hohe Kommunikationsleistung und die gleichzeitige
Offenheit gegenüber anderen Protokollen ist das Ergebnis eines zeitlich gesteuerten Queuing-Modells
innerhalb der Switches. Von den Klasse 3-Echtzeit-Ethernet-Protokollen bietet PROFINET IRT also als
einziger Standard die Möglichkeit andere Protokolle auf Schicht zwei direkt koexistent zu betreiben.
3.2
Modulare I/O-Systeme mit RTE-Systembus
Eine Alternative zum Einsatz von Gateways für modulares I/O-Station ist die Verwendung Block I/O
Geräten. Hierbei wird die modulare I/O-Station nicht durch einen Buskoppler und angeschlossene I/O
Module realisiert, sondern durch einzelne Block I/O Geräte. Der Vorteil dabei ist es das dabei die volle
Funktionalität des RTE Systems erhalten bleibt. Bei kleinen I/O Stationen kann dies eine Option darstellen,
da sich der Mehrbedarf an Platz und Verdrahtung minimal höher ist.
Modulare I/O Station
Eingänge
digital
analog
Gateway,
Buskopf
Ausgänge
System- /Stationsbus
RTE-Schnittstelle
Block I/O Station
analog
digital
Ausgänge
Eingänge
RTE-Schnittstelle
Abbildung 9: Vergleich Modular- und Block-I/O Station
4 Adaptionspotenzial von Systemeigenschaften der Kommunikationsprotokolle
4.1
Adressierung von Prozessdaten
Bei PROFINET wird ein Slot und Subslot Modell verwendet, wobei jeder Subslot wieder mehrere I/O Daten
beinhalten kann. Die Zuordnung der Position von I/O Daten im RT Frame wird pro Subslot festgelegt. Daher
lässt es keinen Rückschluss vom physikalischen Aufbau des Gerätes, zur Anordnung der Daten innerhalb der
Kommunikation zwischen Master und Slave, zu. Ein Gateway sollte eine flexible Anordnung der I/O-Daten
beherrschen. Die Abbildung 10 zeigt eine Beispiel für die Slot und Subslot Zuordnung eines PROFINET
Gerätes.
Abbildung 10: Slot-/Subslot-Modell eines PROFINET-Gerätes
4.2
Zeitsynchronisation
Echtzeit-Ethernet Systeme nutzen häufig Zeitsynchronisation. Diese wird für die Steuerung der
Kommunikation (Beispiel PROFINET IRT) oder für eine synchrone Applikation verwendet. Die
Protokollvielfalt ist mannigfaltig. Ausgehend vom Standard NTP (Network Time Protokoll) ist PTP
(Precision Time Protokoll IEEE 1588) standardisiert worden. Dieser Standard sieht verschiedene Profile vor.
In der industriellen Automation sind noch weitere Derivate entstanden. PROFINET nutzt zum Beispiel PTCP
und IEEE 802.1AS, EtherCAT nutzt DC (Distributed Clocks) und Ethernet/IP CipSync.
Auf Grund ihrer Ähnlichkeit können die Protokolle PTCP, PTP IEEE 1588 und IEEE 802.1AS direkt in
einander konvertiert werden. Für DC ist eine vollständige EtherCAT-Implementierung notwendig; die
Protokolle sind so unterschiedlich, dass nur die eigentliche
Synchronisationsprotokolldomänen weitergegeben werden kann.
4.3
Zeitinformation
zwischen
den
Synchronisation von Prozessdatenzyklen
Mit Hilfe der Synchronisation von Prozessdaten verbessert sich die Zuordnung der Prozessdaten zu einem
bestimmten Zeitpunkt. Die Abbildung 11 zeigt zum einen in Scenario a) das Verhalten bei einer fehlenden
Synchronisation der Applikation und zum anderen in b) ein Beispiel bei dem die Applikation synchronisiert
ist. Es ist zu erkennen, dass in dem Scenario a) der zeitliche Jitter zwischen senden der Daten auf dem
Medium und dem Zeitpunkt an dem die Prozessdaten übernommen wurden, sich über den gesamten Zyklus
erstrecken kann. Somit ergibt sich bei dieser Betriebsart ein Jitter zwischen den Prozessdaten und dem
Zeitpunkt zu dem die Daten gesendet werden. Im Worst Case ergibt sich daher ein Jitter von bis zu einem
Zyklus.
Im Bereich Motion Control ist es wichtig Sensordaten, z.B. die Achslage eines drehenden Teils, einem
exakten Zeitpunkt zuzuordnen. Um den Jitter des Erfassungszeitpunktes zu verringern, wird zusätzlich die
Applikation synchronisiert. Um eine durchgehende Synchronisation (z.B. zu den Prozessdaten oder
gegebenenfalls auch zu einem Rückwandbus) zu realisieren, muss ein Gateway die
Synchronisationsinformation zwischen verschiedenen Protokollen (z.B. von PTCP -> PTP IEEE 1588)
überführen.
Prozessdaten
Prozessdaten
Applikation
MAC
1
2
3
4
a) Prozessdaten asynchron
Zyklus
1
2
3
4
b) Prozessdaten synchron
Abbildung 11: Synchronisation von Prozessdaten
4.4
Linkredundanz
Redundante Verbindungen bieten bei entsprechendem Protokoll, die Möglichkeit die Verfügbarkeit in
Netzwerken zu steigern. Auch hier ist die Protokolllandschaft vielfältig. Aus der Ethernetwelt bekannt sind
Verfahren wie STP und RSTP (Rapid Spanning Tree Protocol). Diese Protokolle lösen redundante
Verbindungen, die immer zu Ringen oder vermaschten Netzwerken so auf, dass wieder ein Baum („Tree“)
entsteht. Zur Leistungssteigerung in Automatisierungsnetzwerken wurden neue Protokolle definiert, welche
diese Umschaltung entweder schneller vornehmen oder die auch Kommunikation in geschlossenen Ringen
erlauben. Das Protokoll MRP (Media Redundancy Protocol) erlaubt zum Beispiel eine kurze Umschaltzeit
auch in großen Ringen und wird zum Beispiel für PROFINET RT-Kommunikation eingesetzt. Protokolle, die
eine Übertragung in Ringen über mehrere redundanten Verbindungen gleichzeitig erlauben sind zum Beispiel
das Protokoll MRPD (PROFINET) oder HSR. Diese redundante Übertragung gewährleistet, dass bei einer
Linkunterbrechung die Kommunikation erhalten bleibt.
Nun ist die Frage in wie weit ein vermaschtes Netzwerk, zum Beispiel eine Ringtopologie welches aus zwei
RTE-Domänen und entsprechend über zwei Gateways geschlossen ist, betrieben werden kann. Und wie die
Redundanzfunktion über ein Gateway umgesetzt werden kann, oder ob eventuell ein gemeinsames
Redundanzprotokoll im gesamten Ring verwendet werden kann und mit den verwendeten RTE-Derivaten
kompatibel ist.
5 Multi-Layer-Gateway-Architektur für Funktionsdurchgängigkeit
Ein Gateway mit Funktionsdurchgängigkeit, benötigt eine integrierte Architektur auf mehreren ISO/OSISchichten. Abbildung 12 zeigt zwei Beispiele: Die Funktionalität „Synchronisation von
Kommunikationszyklen“ erfordert eine Kopplung des Medienzugriffes (MAC); eine durchgängige
Adressierung mittels IP den Eingriff in die IP-Schicht.
Abbildung 12: Gateway- Architekturen im ISO/OSI-Kommunikationsmodell
Als Beispiel für eine optimierte Multi-Layer-Gateway Architektur soll im Folgenden eine Umsetzung
zwischen den RTE-Protokollen PROFINET (RT/IRT) und EtherCAT aufgezeigt werden.
Bei einem PROFINET zu EtherCAT Gateway sollte der Verbindungsaufbau des Controllers analysiert und
die logische Adressierung der EtherCAT Module entsprechenden der Payload des RT Frame vorgeben
werden. Dies verhindert ein aufwendiges kopieren der I/O Daten bei der Umsetzung zwischen PROFINET
und EtherCAT. Zudem ermöglicht dies ein Transfer im Cut Through Verfahren.
Fehlerhafte Daten und Übertragungen werden durch das Gateway mit dem PROFINET Daten Status und der
Checksumme des EtherCAT Frames abgebildet.
Wird aber das Gateway mit mehreren PROFINET ARs betrieben, führt dies zu dem Problem, dass erst nach
dem letzten Verbindungsaufbau des Controllers die optimierte Anordnung der I/O Daten und somit die
logische Adressierung bestimmt werden kann. Die Abbildung 13 zeigt die Zuordnung der Nutzdaten zweier
PROFINET Verbindungen zur Payload des EtherCAT-Telegramms. Über die logische Zuordnung würde das
Gateway dem ersten Modul Slot 1, zweiten Modul Slot 2, dritten Modul Slot 3 und Slot 4 dem vierten Modul
4 am EtherCAT Strang zuweisen. In der Abbildung 14 wird eine mögliche Sequenz der PROFINET RT
Frames und den EtherCAT Frames dargestellt. Der schnellere EtherCAT Zyklus ist hierbei freilaufend im
Bezug zum PROFINET Zyklus von 250µs, da bei der Betriebsart RT die Ankunft der RT Frames nicht
konstant zum Sendezyklus ist.
Abbildung 13: Zuordnung von PROFINET Slots zu EtherCAT Teilnehmern
Abbildung 14: PROFINET RT Gateway mit 2 PROFINET RT Verbindungen
Bei PROFINET IRT Betrieb sollte der Zyklus des unterlagernden EtherCAT System zum überlagerten
PROFINET System synchronisiert werden. Dies reduziert den Jitter an den I/Os und führt zu bessern Einleseund Ausgabezeiten (TI/TO) im IRT System. Die Abbildung 15 zeigt ein Beispiel für den IRT Betrieb wo
auch die EtherCAT Frames im Bezug TI/TO gestartet werden und somit der EtherCAT
Kommunikationszyklus auf das IRT System synchronisiert wird.
Abbildung 15: PROFINET IRT zu EtherCAT mit TI/TO
6 Literaturverzeichnis
[IEC06a]
[IEC06b]
[V11]
[JSW07]
[S11]
[V11]
IEC: IEC 61158-5-10, Digital data communications for measurement and control - Fieldbus for
use in industrial control systems - Part 5-10: Application Layer service definition - Type 10
elements, 2006.
IEC: IEC 61158-6-10, Digital data communications for measurement and control - Fieldbus for
use in industrial control systems - Part 6-10: Application Layer protocol specification - Type 10
elements, 2006.
Peter Volkmer: Zustandsüberwachung von Rotorblättern an Windkraftanlagen zur Erkennung
von Rotorblattschäden, von Vereisung und von dynamischen Lasten, 2. VDI-Fachtagung
Schwingungen von Windenergieanlagen 2011, Februar 2011
Jasperneite, Jürgen; Schumacher, Markus; Weber, Karl: Limits of Increasing the Performance of
Industrial Ethernet Protocols. In: 12th IEEE Conference on Emerging Technologies and Factory
Automation S.: 17 - 27, Patras, Greece, Sep 2007.
Schwager, Jürgen: Informationsportal für Echtzeit-Ethernet in der Industrieautomation,
www.realtime-ethernet.de, 27.10.2011
Vedral, Andreas: Moderne, modulare IO-Systeme, VDI-Kongress Automation 2011, Baden
Baden 2011
[EPSG08] Ethernet POWERLINK Standardisation Group, Ethernet POWERLINK Communication Profile
Specification, EPSG DS 301 V1.1.0, 2008
[MIDA06] MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b, http://www.Modbus-IDA.org,
28.12.2006
[IEC07a] IEC: IEC 61158-6-12, Industrial communication networks - Fieldbus specifications - Part 6-12:
Application layer protocol specification - Type 12 elements, 2007
[IEC07b] IEC: IEC 61158-5-12, Industrial communication networks - Fieldbus specifications - Part 5-12:
Application layer service definition - Type 12 elements, 2007