Stabilitätstests in PROFINET Netzwerken

Stabilitätstests in PROFINET Netzwerken Roland Heß, Markus Schumacher, Sergej Gamper OWITA GmbH Langenbruch 6 32657 Lemgo roland.hess@owita.de Fraunhofer IOSB-INA Langenbruch 6 32657 Lemgo markus.schumacher@iosb-ina.fraunhofer.de sergej.gamper@iosb-ina.fraunhofer.de Abstract: In Ethernet-basierten Feldbussen besteht zunehmend ein Bedarf an zuverlässigen Testsystemen zur Analyse der Qualität der eingesetzten Geräte. Hieraus ergibt sich für den Anlagenbauer die Schwierigkeit, die Robustheit einer gesamten Anlage zu bewerten. Diese Untersuchung zeigt Testmetriken auf, die zur Einschätzung der Qualität der Geräte herangezogen werden können und über die spezifizierten PROFINET Lasttests hinausgehen. 1 Einleitung Die zweite Generation der industriellen Echtzeit-Kommunikation basiert, nach Einführung der Feldbustechnik in den achtziger Jahren, auf Ethernet. Eine Einführung in die Prinzipien und der Standardisierung von RTEs ist in [1][2][3] zu finden. Derzeit sind 31 unterschiedliche Verfahren für RealTimeEthernet (RTE) Systeme bekannt [4]. Die meisten RTEs sind für einen spezifischen Anwendungsfall optimiert und können in drei Klassen eingeteilt werden (siehe Abbildung 1). Die Klassen unterscheiden sich im Hinblick auf die erreichbare Performance und die notwendigen Erweiterungen zum Standard-Ethernet [5]. Erweiterungen zu IEEE802.3 Performance 1 2 3 Realtime Realtime Besteffort Besteffort Besteffort Realtime TCP/UDP TCP/UDP TCP/UDP IP IP IP Prioritizing Scheduling MAC MAC MAC e.g. ModBus/TCP, FF HSE e.g. PROFINET RT, Ethernet/IP e.g. PROFINET IRT, Powerlink, EtherCAT Abbildung 1: Klassifizierung von Echtzeit-Ethernetprotokollen

Die Kategorie 1 übernimmt Ethernet und die TCP/IP-Protokoll-Familie ohne jede Veränderung. Lediglich auf der Applikationsebene wird ein automatisierungsspezifisches Protokoll hinzugefügt. Zu dieser Klasse zählen z.b. die Protokolle ModBus/IDA [6] und High Speed Ethernet (HSE) der Fieldbus Foundation [7]. Mit diesem Ansatz können Echtzeitanwendungen realisiert werden, die eine Zykluszeit zwischen 10 ms 100 ms voraussetzen. In der Kategorie 2 wird von der Priorisierung des Switched Ethernet nach IEEE 802.1Q/D Gebrauch gemacht [8,9]. Zusätzlich werden die signifikanten Laufzeitanteile der Endgeräte an der gesamten Ende-zu-Ende- Laufzeit durch Umgehung des TCP/IP-Stacks für die Echtzeitdaten optimiert. In [10] wurde gezeigt, dass mit diesem Ansatz in einer Linientopologie mit 50 Teilnehmern worst-case-latenzzeiten von 10 ms für die hochprioren Daten garantiert werden können. Für eine optimale Performance sind in diesem Schritt anspruchsvolle Schicht-2 Hardware-/Softwarekonzepte erforderlich, die die Eigenschaften des jeweiligen Ethernet-Controllers berücksichtigen. PROFINET RT [11][12] und Ethernet/IP [13] sind zwei prominente Vertreter dieser Klasse. Die Kategorie 3 greift direkt in das Scheduling von Switched Ethernet ein und stellt damit die größte Erweiterung des Standard-Ethernets dar. Hierbei werden Zeitschlitzverfahren (engl.: Time division multiple access, TDMA) benutzt, die wie bei dem hub-basierten Ethernet Powerlink [14] zentral durch ein Master/Slave-Verfahren oder wie bei PROFINET mit IRT durch die Verwendung spezieller Switches realisiert werden. Beim EtherCAT-Protokoll [15], das ebenfalls dieser Klasse zuzuordnen ist, wird das unter anderem von dem Feldbus Interbus [16] her bekannte statische Summenrahmenverfahren auf Basis eines Master-Slave-Prinzips genutzt. Nur mit den Ansätzen der Klasse 3 wird das Problem gelöst, dass ein Echtzeittelegramm durch niederpriore Telegramme verzögert werden kann. Daher sind nur hier Latenzzeiten im Sub-Millisekundenbereich, sowie ein Jitter im Sub-Mikrosekundenbereich erreichbar. In diesem Beitrag bewerten wir die Stabilität des Echtzeitverhaltens, wenn zu dem Echtzeitdatenverkehr zusätzlich Office/Multimedialer Datenverkehr in das Netzwerk eingespeist wird. Hier werfen wir ein besonderes Augenmerk auf Traffic, der hochprior ist und so den Datenaustauch am wahrscheinlichsten beeinträchtigen kann. Ein Use-Case für ein solches Szenario stellt z.b. eine Webcam dar, die mit einer hohen Datenrate hochpriore Frames in ein Netzwerk einspeist. 2 PROFINET Varianten und deren Eigenschaften Der Einsatz von Feldbussen in der Automatisierungsindustrie hat bereits vor über 30 Jahren mit den bekannten Arten Profibus, Interbus und anderen Formen begonnen. Im Gegensatz zu den heutigen Ethernetbasierten Feldbussen gehörte den Feldbussen das Medium allein. Dadurch war, abgesehen von äußeren Störeinflüssen wie der EMV, das Verhalten deterministisch. Echtzeitbedingungen waren durch den Buszyklus gegeben der mit den Datenrahmenlängen und Bitraten des Busses zusammenhing. Bei der Entwicklung der Ethernet-Varianten der Feldbusse wurde versucht, die historisch gewachsenen Feldbus-Eigenschaften auf das Ethernet-Medium zu migrieren. Die entstandenen neuen Formen unterscheiden sich durch Funktionalität und Komplexität, aber eben auch durch Stabilität bei hoher Auslastung des Mediums. Das Medium Ethernet macht heute die Nutzung von Mehrwertdiensten und Feldbus-Fremde Kommunikation über die gleichen Netzwerkpfade, wie der zyklische Datenaustausch zur Steuerung, erst möglich. Dies hat aber auch zur Folge, dass in manchen Fällen die benötigte Bandbreite des Mediums nicht ausreicht um alle Services vollständig zu bedienen. Wird z.b. von azyklischen Services, wie einer Webcam oder einem FTP- Server, eine hohe Netzlast generiert, steht dem zyklischen Datenverkehr unter Umständen nicht mehr genügend Bandbreite zur Verfügung. Wenn von einem Ethernet-basierten Feldgerät keine spezielle Behandlung der Echtzeitdaten erfolgt, wie z.b. einer Priorisierung, kann eine Überlastsituation letztlich zum Ausfall einiger I/O-Geräte oder ganzer Pfade führen. Hersteller von Ethernet-basierten I/O-Geräten und Steuerungen sind deshalb bemüht, die Geräte neuerer Generationen auf lastbedingte Schwachstellen zu testen. Es lassen sich in solchen Tests aber nur bedingt Szenarien aus dem realen Leben in der Anlage nachstellen. Der Grund hierfür ist die sehr unterschiedliche Ausprägung von Netzwerktopologien und Diensten, die neben der RT-Kommunikation aktiv sind. In dieser Untersuchung wird der Unterschied zwischen den PROFINET -Netzwerken PROFINET IRT (Isochrone Echtzeit) und PROFINET RT (nicht synchrone Echtzeit) in einer Anlage verglichen.

2.1 PROFINET RT PROFINET RT (Realtime) ist eine Basis-Variante von PROFINET und stellt keine speziellen Anforderungen an verwendete Netzwerkkomponenten. Bei der Verwendung von PROFINET RT wird die Priorisierung basierend auf IEEE 802.1Q/D genutzt. 2.2 PROFINET IRT PROFINET IRT (Isochronous Realtime) ist eine PROFINET Variante, die für harte Echtzeitanforderungen entwickelt wurde. Durch den Einsatz eines TDMA-Verfahrens wird sichergestellt, dass in der geplanten Zeit für die Echtzeitkommunikation keine NRT-Daten (Non-Realtime) gesendet werden. Das PROFINET TDMA-Modell besteht aus 3 Phasen (siehe Abbildung 2) in denen zum einen nicht Echtzeit Daten (grüne/gelbe Phase) und zum anderen die Echtzeit Daten (rote Phase) übertragen werden. Der Echtzeitdatenaustausch ist komplett geplant, so dass keine Kollisionen bei der Übertragung der Frames entstehen. Auf diesem Wege kann harte Echtzeit garantiert werden. Da in der gelben Phase im Store & Forward Modus weitergeleitet wird, wird garantiert dass keine nicht Echtzeit Daten in die Echtzeitphase hineinragen. Um diese Bedingung zu erfüllen entspricht die gelbe Phase mindestens der Übertragungszeit eines maximallangen Frames. In der grünen Phase werden Frames unter Verwendung des Cut-Through [17] Verfahrens zum Zielport geleitet. Dies erfordert natürlich ein System mit ausschließlich PROFINET IRT-fähigen Komponenten. Nicht Realzeit Daten Realzeit Daten Abbildung 2: PROFINET IRT Phasenmodell 3 Aufbau der Testsysteme 3.1 Lasttests für PROFINET Geräte Lasttests sollten gerade bei Ethernet-basierten Feldbusgeräten für Hersteller zu den Standardtests gehören. Seit 2010 hat auch die PNO mit der Profinet IO Net load - Guideline for Profinet [18] einen Lasttest für PROFINET Geräte spezifiziert. In der Testprozedur wurden drei verschiedene Lastklassen spezifiziert (Net load class I, II und III). Für jede dieser Klassen sind Lastgrenzen von ca. 15 verschiedenen Pakettypen definiert. Um eine Klasse zu bestehen müssen die Geräte die spezifizierten Lastgrenzen mit jeweils drei unterschiedlichen Verhaltensweisen aushalten: Bis zur ersten Grenze muss die normale Funktion des Gerätes gewährleistet bleiben (Normal Operation). Bis zur zweiten Grenze darf die Kommunikation eingeschränkt sein (Limited Communication). Bei der dritten Grenze dürfen Fehler auftreten (Faulty Communication). Die Durchführung dieser Lastszenarien findet dann mit Hilfe von scriptbasierten Testcases auf einem Linux-PC- System statt. Als erster Schritt zur Beurteilung der Stabilität von Geräten und ganzen Systemen ist die Beurteilung der Laststabilität ein bedeutendes Merkmal. Allerdings lassen sich gerade durch PC-basierte Generierung der Netzwerklast keine reproduzierbaren und verlässlichen Ergebnisse erzielen. Daher wurde in dieser Untersuchung auf professionelles hardwareunterstütztes Equipment zurückgegriffen, dass zuverlässig auch 100% Netzwerklast generieren kann. Der Test nach der PROFINET Net-load-Guideline sollte hier aber nicht durchgeführt werden, da die populären PROFINET ASICs diese anstandslos bestehen. Vielmehr steht in dieser Untersuchung die Frage im Vordergrund, bei welchen Lastgrenzen Systeme nicht mehr funktionsfähig sind und ob es Unterschiede zwischen den Realtime-Klassen RTC1 und RTC3 gibt.

3.2 Typische Topologien Grundsätzlich sind beim Aufbau von PROFINET Netzwerken diverse Topologien denkbar. Dies ist zum Teil auch von den verwendeten Komponenten abhängig. Da die Kommunikationsstruktur der Konstruktionsweise der Maschinenanlage i.d.r. folgt, wird in diesem Segment üblicherweise die Linientopologie verwendet. Diese Topologie ähnelt durch die busähnliche Struktur den früher eingesetzten Feldbussen. Dafür sind allerdings zwei Ethernet-Ports am Gerät notwendig. Die Ringtopologie kann in dieser Untersuchung auf die Form der Linientopologie zurückgeführt werden, da der Ringschluss eine logische Unterbrechung darstellt. Andere verwendete Formen der Topologie wären die Stern- und Mesh-Topologie. Diese Formen bedingen allerdings den Einsatz von Switches und stehen nicht im Fokus dieser Untersuchung. Die Abbildung 3 zeigt beispielhaft einen typischen Aufbau einer Produktionszelle in der Automatisierungstechnik. Backend Switch/ Router SPS I/O- Device I/O- Device I/O- Device Abbildung 3: Typische Automatisierungszelle In diesem Beitrag werden Last-Szenarien innerhalb einer Automatisierungszelle mit mehreren I/O Devices betrachtet. Dabei wurden bewusst Geräte mit unterschiedlichen PROFINET ASICs verwendet. 3.3 Test Topologie Bei der untersuchten Topologie wurden die Geräte so gewählt, dass die Lastszenarien sowohl für PROFINET Class 1 als auch für PROFINET Class 3 getestet werden konnten. Des Weiteren wurden keine Geräte im Prototypen -Status verwendet, sondern Geräte mit aktueller Firmware die von den Herstellern als stabil gelten und bereits vertrieben werden. In allen verwendeten Komponenten sind Profinet-spezifische ASICs verbaut, was Voraussetzung für den Betrieb von RTC3 ist. Durch die Verwendung von RTC3-fähigen Komponenten ist die Umstellung der Geräte von RTC1 auf RTC3 durch die Anpassung der Projektierung einfach möglich. Die gleiche Netzwerkstruktur des RTC1 und des RTC3 Testnetzwerks erlaubt einen Vergleich zwischen den Realtime-Klassen. Es wurden hierzu für die Abbildung eines realistischen Szenarios Standard-Einstellungen bezüglich Akzeptanz von Paketausfällen gewählt. Typischerweise liegt die Einstellung dieses Watchdog-Faktors im Default bei 3 aufeinander folgenden Paketen die ausfallen müssen, bevor ein Busfehler auftritt und die zyklische Kommunikation als ausgefallen gilt. Die Einspeisung der Last erfolgte mit dem Lastgenerator FLEXEGEN [19] (OWITA GmbH). Mit der entsprechenden dazugehörigen Software können sowohl gleichverteilte Lasten als Burst-Lasten reproduzierbar abgespielt werden. Die Erstellung der Lasten kann durch spezifische Skripte erfolgen, bei denen das Gerät den Teststream selbständig generiert, als auch durch PCAP-Dateien [20] die dann mikrosekundengenau abgespielt werden. Die Lasten wurden in den Einzeltests mindestens für eine Dauer von 30 Sekunden eingespeist. Nach dieser Zeitdauer ist zu erwarten, dass ein stabiler Zustand erreicht ist oder im Fehlerfall die zyklische Kommunikation eingebrochen ist und ein Busfehler erscheint. Es wurden Netzslastszenarien geprüft in denen die Last entweder über den ersten Teilnehmer (PLC CP319) oder den letzten Teil (TPS-1) eingespeist wurden. Es stand dabei nicht im Fokus ein bestimmtes Gerät am Ende der Topologie zu testen, sondern die Stabilität des Gesamtsystems zu beurteilen.

FLEXEGEN Lastgenerator CP319 Ertec 200 I/O- Ertec 400 Device TPS-1 FLEXEGEN Lastgenerator Abbildung 4: Verwendetes Testnetzwerk 3.3.1 IP-Traffic Es wurde beim ersten Szenario davon ausgegangen, dass eine IP-Camera an das Ende der Linie angeschlossen wird und einen gerichteten Traffic mit 100% Netzlast (Unicast) an einen unbekannten Empfänger sendet. Dazu wurde eine Serie mit minimallangen Frames (64-Bytes) und maximallangen Frames (1522 Bytes) in beide Seiten der Linie eingespeist. Die 802.1Q-VLAN-Priorität wurde dazu auf 7 gesetzt, welches der höchsten Priorität entspricht. Da PROFINET RTC1 Pakete ebenfalls die Priorität 7 im VLAN- Header nutzen, wurde als Ergebnis erwartet, dass ab einer bestimmten Last-Grenze die zyklische Kommunikation gestört wird und einbricht. Dies konnte jedoch nicht beobachtet werden und es wurde nacheinander auf beiden Seiten erfolgreich 100% Fremdlast eingespeist, ohne dass die zyklische Kommunikation gestört wurde. Dies ist darauf zurückzuführen, dass die Hersteller offensichtlich nicht nur nach der VLAN-Priorisierung Filtern, sondern zusätzlich ein weiteres Filterkriterium nutzen. Hier fiel das Augenmerk auf eine Filterung des Ethernet-Typs, der im Fall von PROFINET 0x8892 entspricht. Tabelle 1: Ergebnisse für IP-basierte Last mit VLAN Priorität 7 Fremdlasteinspeisepunkt PLC TPS1 VLAN Priorität 7, IP-Frames, RTC1 Ok Ok 64-Byte Paketlänge RTC3 Ok Ok VLAN Priorität 7, IP-Frames, RTC1 Ok Ok 1514-Byte Paketlänge RTC3 Ok Ok 3.3.2 PROFINET Traffic In diesem Szenario wurde die Konfiguration der Netzlast aus Kapitel 3.3.1 angepasst und der IP Ethertype 0x0800 wurde durch den PROFINET Ethertype 0x8892 ersetzt. Auf diesem Wege wird die Störlast von den Teilnehmern als PROFINET Datenverkehr interpretiert. Hierbei wurde zunächst eine PROFINET-Frame- ID (0x1122) aus dem reservierten FrameId Bereich gewählt. Der Test konnte von der Seite der PROFINET- Devices mit 100% der Netzwerklast sowohl für minimallange als auch für maximallange Frames ohne Beeinträchtigung der Funktionalität im Fall von RTC3 durchgeführt werden. Bei Einspeisung auf der Seite der Steuerung brach die Kommunikation zusammen. Daraus schließen wir, dass eines oder mehrere ASICs auf den reservierten FrameID Bereich reagieren und ihn auswerten. Der Betrieb von RTC1 ist in diesem Szenario nicht mehr stabil. Im nächsten Schritt passten wir die FrameID auf 0xC000 an, so dass sie der RTC1 Klasse entspricht und die Frames nun eindeutig einer Netzlastklasse zugeordnet werden können. Die Testdurchführung erfolgte wieder mit minimallangen Frames (64-Bytes) und maximallangen Frames (1514-Bytes) und wies in diesem Fall bei der Verwendung von RTC3 (IRT) keinen Abbruch des Kommunikationszykluses auf. Bei der Verwendung von RTC1 können die Teilnehmer die gewollten Echtzeitdaten aufgrund des identischen Ethertypes nicht von der Störlast unterscheiden und die Verbindungen brechen auch bei einer korrekten FrameID ab.

Tabelle 2: Ergebnisse für Profinet-basierte Last mit verschiedenen Frame-IDs Fremdlasteinspeisepunkt PLC TPS1 VLAN Prio 7; -Type = 0x8892; 1514-Bytes, FrameID 0x1122 VLAN Prio 7; -Type = 0x8892; 64-Bytes, FrameID 0x1122 VLAN Prio 7; -Type = 0x8892; 1514-Bytes, FrameID 0xC000 VLAN Prio 7; -Type = 0x8892; 64-Bytes, FrameID 0xC000 RTC1 FAIL FAIL RTC3 FAIL Ok RTC1 FAIL FAIL RTC3 IFG<40µs >40µs Ok RTC1 FAIL FAIL RTC3 Ok Ok RTC1 FAIL FAIL RTC3 Ok Ok 3.3.3 Test spezifischer Protokolle In diesem Test wurde das Testnetzwerk mit Management-Paketen belastet. Die ausgewählten Pakettypen haben die Eigenschaft, dass die CPU der Geräte diese Pakete analysieren bzw. beantworten muss. Daher ist eine hohe Last dieser Pakete ein gutes Kriterium zur Einschätzung der Stabilität einer PROFINET Linie. Bei ARP-Paketen (Address Resolution Protocol) wird das Paket als Broadcast durch die ganze Linie gesendet. Die Pakete müssen von jedem (IP-basierten) Gerät beantwortet werden. Dies betrifft auch die PROFINET Geräte da sich die NRT-Kommunikation (Non-Realtime) auf UDP/IP abspielt. LLDP (Link Layer Discovery Protocol) und DCP (Discovery Control Protocol) sind Layer-2 Multicastpakete. LLDP-Pakete dienen der Erkennung von Nachbarn, die an den entsprechenden Port angeschlossen sind. Sie werden im Fall von PROFINET typischerweise mit einer Rate von einem Paket pro 5 Sekunden gesendet. Wird über den Zeitraum von 20 Sekunden kein LLDP-Paket empfangen, dann gilt der Linkpartner als nicht mehr vorhanden und das IRT Phasenmodell wird für diesen Port deaktiviert und die Kommunikationsbeziehung wird abgebaut. Das DCP-Protokoll dient der Erkennung von PROFINET- Teilnehmern und der Vergabe einer IP-Konfiguration und des Stationsnamens. Tabelle 3: Ergebnisse für Broadcast- und Multicast-Last Fremdlasteinspeisepunkt PLC TPS1 ARP RTC1 Ok Ok IFG >2µs RTC3 Ok Ok ARP RTC1 FAIL Ok IFG<2µs RTC3 FAIL Ok DCP RTC1 Ok Ok RTC3 Ok Ok LLDP RTC1 Ok Ok RTC3 IFG>200µs <200µs Ok Bei der Durchführung der Tests wurde beobachtet, dass mindestens ein Teilnehmer die Einspeisung von nahezu 100% ARP-Last über den PLC nicht übersteht. In einem weiteren Schritt wurde die Inter-Frame-Gap Zeit auf 2 µs gemessen. Dieser Wert stellt die Grenze dar, ab dem die Echtzeitkommunikation nicht

beeinträchtigt wird und entspricht ca. 77% ARP-Last. Die durch die PNO [18] geforderte Grenze liegt lediglich bei 20 %, bei der die Echtzeitkommunikation sichergestellt sein muss. Bei LLDP-Paketen wurde beobachtet, dass ein Gerät bei IFG-Zeiten unter 200 µs (7-8% Netzanteil) diese Last nicht bewältigen kann. Es wurde hier ein Ausfall der PROFINET Kommunikation beobachtet. Die Zeit bis zum Ausfall der Kommunikation sank proportional mit dem Anstieg der LLDP-Last. Daher kann angenommen werden, dass die CPU des Geräts die Last nicht bearbeiten kann und keine hardwareunterstützte Filterung besteht. Dieses Verhalten konnte wiederum nur im RTC3 Betrieb beobachtet werden, da nur in diesem Fall die Nachbarschaftserkennung (Bestandteil für aktives Phasenmodell) relevant für die Echtzeitkommunikation ist. Da die geforderte Grenze bei der PNO bei LLDP Last >5% ist das Verhalten im Rahmen der Spezifikation. 4 Ergebnis der Untersuchung Für diesen Beitrag wurden verschiedene Szenarien an Paketlasten in eine PROFINET RTC1 und RTC3 Topologie untersucht. Es wurden Ergebnisse erzielt, die sowohl für Hersteller als auch Anwender von PROFINET Komponenten relevant sind. Als erstes und wichtigstes Ergebnis muss festgestellt werden, dass die Stabilität des getesteten PROFINET Systems die Netzlastanforderungen bei weitem übertreffen und damit deutlich stabiler sind als von der PNO gefordert. Dies ist nicht nur für RTC3 der Fall, bei dem durch das TDMA-Verfahren genügend Bandbreite auf der Leitung für den PROFINET Echtzeit Datenverkehr reserviert ist, sondern auch bei PROFINET RTC1. Es wurde für RTC1 erwartet, dass bei Paketen mit VLAN Priorität 7, was bei Video-Broadcasting oder anderen Realtime-Anwendungen vorkommen kann, die PROFINET Kommunikation eingeschränkt ist. Dies war aber nicht der Fall. Der Grund hierfür ist vermutlich eine weitere Priorisierung der Pakete anhand des PROFINET Ethernet Types (0x8892). Bei allen verwendeten Komponenten handelte es sich um spezielle PROFINET ASICs die für den Einsatz von RTC3 notwendig sind. Sollten in der Linie andere Architekturen eingesetzt werden, die diese Priorisierung nicht unterstützen, dann sind die Lastgrenzen zum Ausfall deutlich niedriger. Dies ist bereits der Fall, wenn ein Standardswitch in der Linie integriert ist, der ausschließlich anhand der VLAN- ID priorisiert. Daher ist auch bei Verwendung von RTC1 der Einsatz von RTC3 fähigen Komponenten zu empfehlen. 5 Literaturverzeichnis [1] J.-D. Decotignie. Ethernet based real-time and industrial communications. Proceedings of the IEEE, 93 issue 6:1102 17, 2005. [2] M. Felser and T. Sauter. Standardization of Industrial Ethernet the Next Battlefield? In 5th IEEE International Workshop on Factory Communication Systems (WFCS 2004), Vienna, Sept. 2004. [3] M. Felser. Real-time ethernet - industry prospective. Proceedings of the IEEE, 93 issue 6:1118ff, 2005 [4] J. Schwager. Realtime Ethernet in Industrial Automation. Website. Available online at http://www.real-timeethernet.de; visited on September 2014. [5] IEEE. Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications. IEEE, New York, 2000. ANSI/IEEE Std 802.3-2000 Edition (ISO/IEC 8802-3:2000(E)). [6] ModBus. MODBUS IDA Users Web Site: www.modbus.org, visited on September 2014. [7] FF. Fieldbus Foundation. www.fieldbus.org, visited on September 2014. [8] IEEE. Virtual Bridged Local Area Networks. IEEE, New York, 1998. ANSI/IEEE Std 802.1Q-1998. [9] IEEE. Media Access Control (MAC) Bridges. IEEE, New York, 1998. ANSI/IEEE Std 802.1D-1998. [10] Kym Watson and Juergen Jasperneite. Determining end-to-end delays using network calculus. In 5th IFAC International Conference on Fieldbus Systems and their Applications (FeT2003), pages 255 260, Aveiro, Portugal, Jul 2003. [11] IEC, IEC 61158-5-10, Digital data communications for measurement and control- Fieldbus for use in industrial control systems - Part 5-10: ApplicationLayer service definition - Type 10 elements, 2006. [12] IEC, IEC 61158-6-10, Digital data communications for measurement and control- Fieldbus for use in industrial control systems - Part 6-10: ApplicationLayer protocol specification - Type 10 elements, 2006. [13] Ethernet/IP. Ethernet Industrial Protocol (EtherNet/IP). http://www.odva.org/home/tabid/53/lng/en- US/Default.aspx, visited on April 2013. [14] Ethernet Powerlink. Ethernet Powerlink Standardization Group. www.ethernet-powerlink.org, visited on April 2013.

[15] EtherCAT. Ethernet Technology Group (ETG). www.ethercat.org, visited on April 2013. [16] IEC, Geneva. Digital data communication for measurement and control Fieldbus for use in industrial control systems, 2001. IEC 61158 Ed.3, Type 8 (INTERBUS). [17] Cisco, Whitepaper: Cut-Through and Store-and-Forward Ethernet Switching for Low-Latency Environments, 2008] [18] PROFIBUS Nutzerorganisation e. V. (PNO), PROFINET IO Security Level 1 Netload, Version 1.1 Date August 2013 [19] http://www.owita.de/downloads/owita_kurzbeschreibung_flexegen.pdf, visited on September 2014 [20] http://www.winpcap.org/docs/docs_412/html/main.html, visited September 2014