Echtzeitdatenuebertragung in Automatisierungsumgebungen
Werbung
Literaturarbeit EchtzeitdatenübertragunginAutomatisierungsumgebungen Bearbeiter: Eike Björn Schweißguth Matrikelnummer 209204206 Studiengang Elektrotechnik 8. Fachsemester Universität Rostock 1 2 Inhaltsverzeichnis Abkürzungsverzeichnis ............................................................................................................................ 4 1 Einleitung ......................................................................................................................................... 6 1.1 Echtzeit .................................................................................................................................. 6 2 Standard‐Ethernet und Echtzeitanforderungen .............................................................................. 7 3 Hard Real‐Time Kad Network (HaRTKad) ........................................................................................ 8 4 Echtzeitfähige Industrial Ethernet‐Systeme .................................................................................... 9 5 4.1 Ethernet Powerlink ................................................................................................................ 9 4.2 EtherCAT .............................................................................................................................. 11 4.3 TCnet ................................................................................................................................... 14 4.4 TTEthernet ........................................................................................................................... 16 4.5 CC‐Link IE Field .................................................................................................................... 18 4.6 Profinet IO ........................................................................................................................... 20 4.7 Vergleich der vorgestellten IE‐Systeme .............................................................................. 21 Protokolle auf Anwendungsebene ................................................................................................ 22 5.1 Übertragungsprotokolle ...................................................................................................... 22 5.1.1 Constrained Application Protocol (CoAP) ............................................................... 22 5.2 Fehlerüberprüfung .............................................................................................................. 26 5.2.1 Reed Solomon ......................................................................................................... 26 6 Zusammenfassung ......................................................................................................................... 27 I. Abbildungsverzeichnis ................................................................................................................... 30 II. Tabellenverzeichnis ....................................................................................................................... 30 III. Literaturverzeichnis ....................................................................................................................... 31 IV. Selbstständigkeitserklärung ........................................................................................................... 33 3 Abkürzungsverzeichnis ACK: Acknowledgement ARP: Address Resolution Protocol ASend: Asynchronous Send BE: Best Effort CLPA: CC‐Link Partner Association CN: Controlled Node CON: Confirmable CoAP: Constrained Application Protocol CoE: CANopen over EtherCAT CoRE: Constrained RESTful Environment CSMA/CD: Carrier Sense Multiplexed Access/Collision Detection DHT: Distributed Hash Table EoE: Ethernet over EtherCAT EPSG: Ethernet Powerlink Standardization Group ESC: EtherCAT Slave Controller FoE: File over EtherCAT HTTP: Hyper Text Transfer Protocol HaRTKad: Hard Real‐Time Kad Network I/O: Input/Output IE: Industrial Ethernet IEEE: Institute of Electrical and Electronics Engineers IETF: Internet Engineering Taskforce IRT: Isochronous Real‐Time M2M: Machine‐to‐Machine MN: Managing Node MTU: Maximum Transmission Unit NDP: Neighbor Discovery Protocol NON: Non‐Confirmable OSI: Open Systems Interconnection P2P: Peer‐to‐Peer PDO: Process Data Object PReq: Poll Request PRes: Poll Response RC: Rate Constrained 4 REST: Representational State Transfer RST: Reset SCNM: Slot Communication Network Management SDO: Service Data Object SLMP: Seamless Message Protocol SNMP: Simple Network Management Protocol SoA: Start of Asynchronous SoC: Start of Cycle SoE: Servodrive over EtherCAT SPoF: Single Point of Failure TT: Time Triggered URI: Uniform Ressource Identifier 5 1 Einleitung Diese Arbeit soll einen Überblick über verschiedene Möglichkeiten zur Echtzeitdatenübertragung über Ethernet liefern. Die besondere Herausforderung dabei ist, dass der ursprüngliche Ethernet Standard nach IEEE 802.3 nicht für Echtzeitdatenübertragung vorgesehen ist und daher auch die darauf aufbauenden Protokolle auf höheren Schichten im OSI‐Referenzmodell, wie z.B. TCP, UDP und IP, typischerweise keine Rücksicht auf die Anforderungen für eine Echtzeitkommunikation nehmen. Daher sind Anpassungen auf mehreren Schichten des OSI‐Referenzmodells nötig, damit das Gesamtsystem die Anforderungen harter Echtzeit erfüllt. Hierzu gibt es bereits eine Vielzahl existierender Ansätze, die die Probleme von Standard‐Ethernet und TCP/IP‐ bzw. UDP/IP‐ Kommunikation auf unterschiedliche Art und Weise lösen und verschiedene Vor‐ und Nachteile mit sich bringen. Viele dieser Ansätze zur Anpassung von Ethernet an Echtzeitanforderungen stammen dabei aus industriellen Anwendungsbereichen. Für Unternehmen ist die Entwicklung von Echtzeit‐Ethernet interessant, um herkömmliche Bussysteme in Produktionsanlagen zu ersetzen. Der Einsatz von Ethernet zur Vernetzung von Feldgeräten bietet dabei bedeutende Vorteile gegenüber etablierten Feldbussystemen. Durch Ethernet ist eine einheitliche Vernetzung auf allen Ebenen des Unternehmens möglich. So können Feldgeräte mit normalen PCs aus dem Büro kommunizieren, ohne dass dafür Gateways zwischen Ethernet und einem proprietären Feldbus nötig wären. Über die Ethernet‐Verbindungen zwischen den Feldgeräten sollen also zeitkritische Prozessdaten übertragen werden, welche Steuerungs‐ und Regelungsaufgaben übernehmen, während gleichzeitig nicht‐ zeitkritische IT‐Daten an verschiedene IT‐Dienste des Unternehmens gesendet werden [1]. Durch diese Art der Kommunikation ist beispielsweise das Auslesen von Statusinformationen oder das Steuern von Feldgeräten aus der Ferne möglich. Für die IT‐Daten können dabei Standardprotokolle wie TCP/IP verwendet werden, während die zeitkritischen Prozessdaten besondere Protokolle benötigen. All diese Kommunikation findet dabei auf einer einheitlichen Hardwarebasis statt, die durch IEEE 802.3 bereits weitgehend standardisiert ist und verschiedene Steckverbindungen und Übertragungsmedien bietet, die an den Einsatzzweck angepasst werden können. Ein weiterer Vorteil von Ethernet ist die hohe Leistungsfähigkeit gegenüber herkömmlichen Feldbussen, welche sich in den letzten Jahren verstärkt zur Schwachstelle zwischen leistungsfähigen Rechnersystemen entwickelt haben. Neben den IE‐Systemen sollen in dieser Arbeit außerdem Protokolle oberhalb von Ethernet (Schicht 1 und 2 des OSI‐Referenzmodells) beschrieben werden, welche Echtzeitdatenübertragung ermöglichen, wenn auf den darunterliegenden Ebenen ein prinzipiell echtzeitfähiges System zur Verfügung steht. Ein besonderer Fokus sowohl bei den IE‐Systemen als auch bei den getrennt betrachteten Protokollen auf Anwendungsebene liegt dabei auf der Verwendbarkeit in Peer‐to‐Peer (P2P)‐Netzwerken sowie zur Übertragung und Speicherung großer Datenmengen. 1.1 Echtzeit Der Begriff Echtzeit bezieht sich im wissenschaftlichen Sinne darauf, dass die Reaktionen bzw. Antworten eines Systems nicht nur logisch korrekt sondern auch zeitlich korrekt eintreffen müssen. Trifft eine Antwort eines Systems z.B. nach dem Ablauf einer vorgegebenen zeitlichen Begrenzung ein, so kann diese in einem System mit Echtzeitanforderungen ebenso wertlos sein wie eine falsche Antwort [2]. 6 Echtzeit kann jedoch nicht so definiert werden, dass das System sehr schnell reagieren muss, da der Begriff „schnell“ relativ ist und es immer von der Art des Systems und seinen Umgebungsbedingungen abhängt, innerhalb welcher Zeit eine Systemreaktion bzw. ‐antwort noch brauchbar ist. Die korrekte Definition von Echtzeitfähigkeit ist daher, dass die Antwort eines Systems zeitlich gesehen innerhalb einer vorgegeben oberen Schranke (Deadline) erfolgt. Bei den Echtzeitanforderungen eines Systems unterscheidet man dabei folgende Typen [2]: Hartes Echtzeitsystem: Das Nichteinhalten der oberen Schranke kann katastrophale Folgen haben und muss unbedingt vermieden werden. Festes Echtzeitsystem: Bei Nichteinhalten der oberen Schranke wird die Reaktion bzw. Antwort des Systems unbrauchbar, ohne jedoch weiteren Schaden anzurichten. Weiches Echtzeitsystem: Bei Nichteinhalten der oberen Schranke ist die Antwort noch brauchbar, allerdings verschlechtert sich die Systemleistung. Das Erfüllen harter Echtzeitanforderungen bedeutet, dass die Antwortzeit deterministisch ist und damit immer unterhalb eines bestimmten Maximalwertes liegt. Ein System kann harte Echtzeitanforderungen nur dann erfüllen, wenn sich für alle Komponenten des Systems eine maximale Verzögerungszeit – auch im Worst Case Szenario – angeben lässt. Diese maximale Verzögerungszeit muss jeweils an den Anwendungsbereich des Systems angepasst sein. Wird in dieser Arbeit vom Erfüllen von Echtzeitanforderungen gesprochen, so ist Determinismus und damit das Erfüllen harter Echtzeitanforderungen gemeint. 2 Standard‐EthernetundEchtzeitanforderungen Standard‐Ethernet, wie es heute in vielen Bereichen eingesetzt wird, bringt verschiedene Mechanismen mit sich, die einen Determinismus bei der Datenübertragung verhindern und so einen Einsatz in Umgebungen mit Echtzeitanforderungen ausschließen. Das erste Problem von Standard‐ Ethernet ist das verwendete CSMA/CD‐Zugriffsverfahren. Durch das mögliche Auftreten von Kollisionen kann es vorkommen, dass die Datenübertragung abgebrochen wird und erst zu einem späteren, unbestimmten Zeitpunkt erfolgen kann. Durch die Verwendung von Full‐Duplex Switched Ethernet kann dieses Problem zwar beseitigt werden, es entstehen jedoch neue Probleme. In Switches findet eine Zwischenspeicherung der Daten in Puffern statt, was zu zusätzlichen Verzögerungen und bei bestimmten Lastsituationen zu Paketverlusten führt. Versuchen beispielsweise mehrere Netzwerkteilnehmer über einen Switch viele Daten an das selbe Ziel zu senden, so ist mit einem Pufferüberlauf und Paketverlusten zu rechnen, was einer deterministischen Datenübertragung widerspricht. Auf der darüber liegenden IP‐Ebene existiert das Problem nicht statischer Routen, sodass der Weg und damit die Laufzeit eines Paketes nicht genau vorhersagbar sind. Auch die Wahl des Transportprotokolls für harte Echtzeit ist schwierig. Während UDP zwar durch das Versenden einzelner, unabhängiger Pakete grundlegend als echtzeitfähig angesehen werden kann, sieht das UDP‐Protokoll keine Kennzeichnung zusammengehöriger Daten oder einer Datenreihenfolge vor, wie es für die Übertragung großer Datenmengen benötigt wird. TCP ist dagegen auf die Übertragung großer Datenmengen ausgelegt und stellt daher eine Kennzeichnung zusammengehöriger Daten sowie eine Datenreihenfolge eintreffender Pakete zur Verfügung. Durch die variable Übertragungsgeschwindigkeit, welche durch Mechanismen zur Überlastkontrolle und zur Fehlerkorrektur verursacht wird, ist TCP jedoch prinzipiell nicht fähig, harte Echtzeitbedingungen zu 7 erfüllen. Aus diesen Gründen müssen auf verschiedenen Ebenen des OSI‐Referenzmodells auf harte Echtzeitbedingungen angepasste Protokolle gefunden werden. 3 HardReal‐TimeKadNetwork(HaRTKad) Bei Kad handelt es sich um eine Implementierung des P2P‐Netzes Kademlia, welches eine Datenspeicherung mittels verteilter Hashtabellen (Distributed Hash Table, DHT) realisiert. Es zeichnet sich dadurch aus, dass es selbstorganisierend ist und somit nur einen sehr geringen Wartungsaufwand besitzt. Ein Beitritt von Knoten in das Netzwerk oder das Austreten aus dem Netzwerk ist möglich, ohne dass eine manuelle Neukonfiguration des Netzwerks nötig ist. Zudem ist es vollständig dezentralisiert. Es gibt also keinen Server oder Master, der einen Single Point of Failure (SPoF) darstellen könnte. Die Suche nach dem für einen bestimmten Hashwert zuständigen Knoten , was eine ausgezeichnete Lookup Performance darstellt [3]. hat die Zeitdauer Bei HaRTKad handelt es sich um eine Version von Kad, die um einen Synchronisierungsmechanismus erweitert wurde. Durch eine einheitliche Zeitbasis aller Knoten im Netzwerk ist es möglich eine echtzeitfähige Datenübertragung zu realisieren. In HaRTKad gibt es die folgenden Phasen der Kommunikation, welche später genauer erläutert werden [3]: 1. 2. 3. 4. 5. 6. Kad‐Netzwerk Initialisierung Bestimmung der Dynamischen Suchtoleranz Erste Synchronisierung Datenaustausch Kad‐Wartungsarbeiten Resynchronisierung Die Phasen 1.‐3. werden einmalig ausgeführt, während 4.‐6. sich zyklisch wiederholen. 1. Kad‐Netzwerk Initialisierung Während der Initialisierung des Kad‐Netzwerks melden sich alle Knoten durch das sogenannte Bootstrapping Verfahren im Netzwerk an. Die Knoten füllen dabei ihre Routingtabellen und speichern zusätzlich die MAC‐Adressen der in ihrer Routingtabelle enthaltenen Knoten, damit im späteren Verlauf keine ARP‐Pakete (in IPv4‐Netzen) bzw. NDP‐Pakete (in IPv6‐Netzen) generiert werden. 2. Bestimmung der Dynamischen Suchtoleranz In dieser Phase wird ein Knoten dazu angestoßen die Suchtoleranz für das Kad‐Netzwerk so zu bestimmen, dass für jeden Hashwert eine Mindestanzahl zuständiger Knoten existiert. Der Knoten, der die Suchtoleranz bestimmt, wird First Triggered (FT) Node genannt. 3. Erste Synchronisierung In der Synchronisierungsphase sendet der FT‐Knoten eine Aufforderung an alle anderen Knoten, keine weiteren Nachrichten mehr zu versenden, um alleinigen Zugriff auf die Ethernet‐Verbindungen zu erhalten, sodass keine unvorhersehbaren Verzögerungen mehr entstehen können. Dann werden alle Knoten in Gruppen eingeteilt und der FT‐Knoten bestimmt Helferknoten, von denen jeder für die Synchronisierung einer Gruppe zuständig ist. Zuerst synchronisieren sich FT‐Knoten und Helferknoten untereinander, anschließend synchronisieren diese wiederum ihre Gruppe. 8 4. Datenaustausch Diese Phase stellt die primäre Phase von HaRTKad dar, da hier die Nutzdaten transportiert werden können. Zeitlich gesehen sollte diese Phase alle anderen Phasen immer deutlich übertreffen. Ein Kommunikationsprotokoll für diese Phase ist durch HaRTKad jedoch nicht vorgegeben. 5. Kad‐Wartungsarbeiten In der Wartungsphase können Mechanismen des Kad‐Netzes ausgeführt werden, die zur Aktualisierung von Routingtabellen und der Aufnahme neuer Knoten in das Netzwerk führen. Dass ein Knoten ein Bootstrapping Verfahren zur Aufnahme ins Netzwerk starten darf, wird ihm in dieser Phase durch eine Nachricht vom FT‐Knoten signalisiert. 6. Resynchronisierung Auf Grund der Ungenauigkeit der Uhren einzelner Knoten muss regelmäßig eine erneute Synchronisierung durchgeführt werden. Wie oft die Resynchronisierung stattfinden muss hängt von verschiedenen Faktoren wie z.B. dem Drift der Uhren, der erlaubten zeitlichen Abweichung und der Synchronisierungsdauer ab. Das gesamte Verfahren wird in [3] genauer erläutert und analysiert. Das Synchronisierungsverfahren ist dabei durch einen Parameter anpassbar, durch den konfigurierbar ist, ob die Synchronisierung länger dauern soll, aber dafür seltener ausgeführt werden muss, oder ob die Synchronisierung sehr schnell sein soll, dafür aber häufiger ausgeführt werden muss. Das System besitzt außerdem einen Mechanismus, der verhindert, dass der FT‐Knoten zum SPoF werden kann. Jeder Knoten im Netz merkt sich hierzu eine maximale Zeitdauer, nach der er zur erneuten Synchronisierung kontaktiert werden sollte. Wird diese Zeit überschritten, so startet er selbst die Resynchronisierung [3]. Ein weiterer Vorteil von HaRTKad ist, dass es vollständig in Software implementierbar ist und daher keine spezielle Hardware benötigt wird. Eine sich derzeit in der Entwicklung befindende Erweiterung von HaRTKad ist außerdem ein Zeitschlitzverfahren, welches in der Phase des Datenaustausches angewendet werden soll und so jedem Knoten für eine begrenzte Zeit exklusiven Zugriff auf die Ethernet‐Verbindung gewährleistet. So ergibt sich ein bis zu den Zeitschlitzen deterministisches System (d.h. die Zykluszeit sowie die Dauer der Zeitschlitze ist vorhersagbar). Die in dieser Arbeit vorgestellten Protokolle sollen u.a. Konzepte aufzeigen, mit denen sich eine echtzeitfähige Datenübertragung innerhalb dieser Zeitschlitze realisieren lässt. 4 EchtzeitfähigeIndustrialEthernet‐Systeme 4.1 EthernetPowerlink Das von Bernecker & Rainer entworfene und von der Ethernet Powerlink Standardization Group (EPSG) weiterentwickelte Ethernet Powerlink ermöglicht Echtzeitkommunikation mit Standard Ethernet Hardware. Die Implementierung des Powerlink‐Protokolls kann vollständig in Software erfolgen. Durch ein zeitlich abgegrenztes Zugriffsverfahren können auch beim Einsatz von Hubs keine Kollisionen entstehen. Für Anwendungen mit besonders hohen Ansprüchen an die Zykluszeiten des Echtzeitdatenverkehrs ist auch eine Implementierung des Protokolls in Hardware möglich [1]. Das Powerlink‐Protokoll befindet sich im Protokoll‐Stack zwischen Ethernet (Schicht 1 und 2) und dem IP‐Protokoll (Schicht 3). Das neu entwickelte, zeitlich abgegrenzte Zugriffsverfahren auf die 9 Ethernet‐Verbindungen basiert auf einem Slot Communication Network Management (SCNM) genannten Master/Slave‐Konzept, welches Übertragungskapazitäten für zyklische Prozessdaten sowie azyklische Service‐ und Überwachungsdaten zur Verfügung stellt. Der Master, bei Powerlink Managing Node (MN) genannt, erteilt den im Netz befindlichen Slaves, hier Controlled Nodes (CN), in jedem Zyklus der Reihe nach die Sendeerlaubnis. Der Powerlink‐Zyklus ist in mehrere Phasen unterteilt. Er beginnt mit der Start Period, in der der MN einen Start of Cycle (SoC) Frame als Broadcast an alle CNs sendet. Der SoC Frame enthält Synchronisierungsinformationen, der eine einheitliche Zeitbasis erzeugt und Powerlink somit geeignet für Motion Control‐Anwendungen macht [1]. In der folgenden Cycle Period erfolgt der zyklische Datenaustausch zwischen den CNs. Hierzu sendet der MN der Reihe nach jeweils einem CN einen Poll Request (PReq) Frame als Unicast, auf die der CN mit einem Poll Response (PRes) Frame als Multicast antwortet. Der PRes Frame enthält die zeitkritischen Prozessdaten. Sie werden als Multicast gesendet, damit alle anderen CNs die Informationen mithören können, falls sie für sie relevant sind. Im Gegensatz zu anderen Master/Slave‐Systemen findet die Querkommunikation zwischen Slaves also nicht mit einem Umweg über den Master statt [1]. Wurden alle CNs zum Senden von Daten aufgefordert, so beginnt die asynchrone Phase. Der Beginn der asynchronen Phase wird durch einen vom MN gesendeten Start of Asynchronous (SoA) Frame signalisiert. Falls beim Master bereits Anfragen zur asynchronen Datenübertragung aus einem der vorangegangenen Zyklen bestehen wird durch den SoA Frame die Sendeerlaubnis an einen CN erteilt. Anfragen zur asynchronen Übertragung können von CNs mit Hilfe der PRes Frames in der isochronen Phase gestellt werden [4]. Andernfalls wird der SoA Frame gesendet ohne einem CN die Sendeerlaubnis zu erteilen und der MN kann die asynchrone Phase nutzen um beispielsweise Statusinformationen von Slaves zu erfragen. Bei den asynchronen Daten kann es sich um beliebige IT‐Daten oder Service‐ und Wartungsinformationen handeln. Abbildung 1: Ablauf eines Zyklus' von Ethernet Powerlink [5] Ist die Datenmenge zu groß für die vordefinierte Dauer der asynchronen Phase, so können die Daten in mehreren Paketen über mehrere Zyklen verteilt werden [5]. Nach der asynchronen Phase folgt eine kurze Idle Period, bevor ein neuer Zyklus beginnt. Abbildung 1 zeigt den Ablauf von einem Zyklus von Ethernet Powerlink. Um die zu Verfügung stehende Übertragungskapazität effizient und bedarfsorientiert zu nutzen, kann der Master so konfiguriert werden, dass bestimmte Slaves nicht in jedem Zyklus abgefragt werden, 10 sondern sich den Zeitslot mit einem weiteren Slave teilen und somit in jedem zweiten Zyklus senden dürfen. Man spricht dabei von Slot Multiplexing. Die Übertragung der Prozessdaten während der isochronen Phase erfolgt direkt im Ethernet Frame unter Verwendung eines eigenen Ethertypes und eines eigenen Protokollheaders mit Powerlink‐ spezifischen Adressierungsinformationen und der Angabe von Powerlink‐Nachrichtentypen (SoC, PReq, PRes, SoA, ASend). In der asynchronen Phase können ebenfalls Powerlink‐Nachrichten verwendet werden, aber auch Standard‐Datenpakete wie TCP/IP und UDP/IP [4]. Zur Adressierung führt Powerlink eigene 8 Bit Adressen ein. Diese sind beispielsweise beim Austausch von Geräten nützlich, da am Austauschgerät einfach die gleiche Adresse wie beim vorigen Gerät eingestellt werden kann, sodass der Master das Gerät ohne Veränderung der Konfiguration adressieren kann. Mit Hilfe von MAC‐Adressen ist dieses Vorgehen nicht möglich, da sich die MAC‐ Adresse von zwei Geräten immer unterscheidet [1]. Wie bei anderen IE‐Systemen ist das Primärziel von Powerlink eine Echtzeitkommunikation innerhalb von einem Subnetz. Über die Grenzen des Subnetzes hinaus kann nur mit Hilfe der asynchronen Nachrichten unter Verwendung des IP‐Protokolls kommuniziert werden. Auf Anwendungsebene setzt Powerlink vollständig auf den CANopen‐Standard. Es wird also mit den gleichen Geräteprofilen gearbeitet und die zyklische Prozessdatenübertragung erfolgt durch Process Data Objects (PDO), während größere Datenmengen zur Konfiguration und Überwachung in Form von Service Data Objects (SDO) übertragen werden [1]. Powerlink stellt also eine echtzeitfähige Datenübertragung zur Verfügung, bietet jedoch kein neues Prinzip der Datenübertragung auf Anwendungsebene. Da Powerlink auf einem Master/Slave‐Prinzip basiert ist das hier dargestellte Kommunikationsmodell nicht für ein P2P‐Netz, in dem es keinen SPoF geben soll, realisierbar. Außerdem widersprechen die eingeführten 8 Bit Adressen der gewünschten Skalierbarkeit eines P2P‐Netzes. Auf Anwendungsebene wird mit CANopen ein auf Prozessdatenkommunikation ausgelegtes Protokoll verwendet, welches nicht zur transparenten Datenspeicherung großer Datenmengen genutzt werden kann. 4.2 EtherCAT EtherCAT ist ein von der Firma Beckhoff entwickeltes IE‐System, das auf einem Master/Slave‐Prinzip basiert und ein neues Verfahren zur Verarbeitung der zyklischen Prozessdaten in den Feldgeräten (Slaves) anwendet. Die Kommunikation zwischen dem Master, welcher Steuer‐ und Regelungsfunktionen für den Prozess übernimmt, und den Slaves erfolgt dabei generell über Full‐Duplex Switched Ethernet mit 100Mbit/s. Full‐Duplex‐Kommunikation mit Hilfe von Switches ist dabei nötig, um das von IEEE 802.3 vorgesehene CSMA/CD‐Verfahren zu umgehen und Kollisionen generell auszuschließen. Die Netzwerktopologie ist nahezu beliebig, da EtherCAT über eine logische Ringstruktur kommuniziert und diese durch den Einsatz von Full‐Duplex Ethernet auch physikalisch automatisch realisiert ist, unabhängig davon, ob die Verkabelung in einer Linie oder sternförmig erfolgt. Auch Kombinationen verschiedener Topologien sind problemlos möglich [6] [1]. 11 Zur Kommunikation wird im Master ein Prozessabbild angelegt, das den Status verschiedener Ein‐ und Ausgänge des aus mehreren Slaves bestehenden Gesamtsystems darstellt. Um den Status bestimmter Ausgänge eines Slaves zu verändern, muss der entsprechende Teil des Prozessabbildes zusammen mit einem Kommando zur Änderung versendet werden. Die Slaves können ihrerseits beim zyklischen Datenaustausch Teile des Prozessabbildes an den Master senden, um Statusinformationen ihrer Eingänge im Master zu aktualisieren. Die Zuordnung dieser Teile des Prozessabbildes zu den Ein‐ und Ausgängen der einzelnen Slaves erfolgt dabei über logische Adressen, welche im EtherCAT Slave Controller (ESC) in physikalische Adressen der einzelnen Geräte übersetzt werden. Der zur Verfügung stehende Adressraum ermöglicht Prozessabbilder von bis zu 4 GB Größe [6] [1] [7]. Versendet werden die Teile des Prozessabbildes sowie die zugehörigen Kommandos zur Änderung von Ausgängen in EtherCAT Frames direkt im Ethernet Frame nach IEEE 802.3. Abbildung 2: Aufbau eines EtherCAT Frames [6] Abbildung 2 zeigt den Aufbau dieser EtherCAT Frames innerhalb des Ethernet Frames. Im Datenbereich befinden sich mehrere Datagramme, von denen jedes einen eigenen Abschnitt des Prozessabbildes repräsentiert und damit unterschiedliche Slaves bzw. deren Ein ‐und Ausgänge adressiert. Jedes der Datagramme besitzt einen eigenen Header (10 Byte), in dem ein Kommando sowie eine logische Adresse stehen [1]. An der Adresse erkennen die Slaves, ob das Datagramm für sie bestimmt ist, und das Kommando gibt an, wie die im Datagramm enthaltenen Daten (n Byte) vom Slave zu verarbeiten sind. Der Vorteil dieser Art, Daten zu versenden, ist der geringe Overhead. Wenn an mehrere Slaves jeweils nur wenige Bytes gesendet werden sollen, erhält nicht jeder Slave ein eigenes Datenpaket mit dem entsprechenden Overhead des Ethernet Frames (Mindestgröße 64 Byte, wenn nötig durch Padding), sondern es reicht ein einziger Ethernet Frame, in dem Datagramme für mehrere Teilnehmer enthalten sind. Dieser Frame passiert die Feldgeräte der Reihe nach, sodass sich jedes die für es bestimmten Daten entnehmen kann [6]. Die Slaves besitzen spezielle EtherCAT Slave Controller (ESC), welche die Zuordnung der logischen Adressen eines Datagramms zu physikalischen Adressen des Slave‐Speichers vornehmen. In der Initialisierungsphase des Systems werden die ESC aller Slaves konfiguriert und es erfolgt eine Zuordnung von logischen Adressen des Prozessabbildes zu bestimmten Slaves sowie deren physikalischer Speicheradressen [1] [7]. 12 Die EtherCAT Frames werden zyklisch vom Master versendet und passieren die Slaves der Reihe nach auf einer Ringstruktur. Wenn mehr Daten versendet werden müssen als in einen Frame passen, werden mehrere Frames hintereinander versendet. Die ESC ermöglichen außerdem einen besonders schnellen Versand in einer Ringstruktur durch eine neu entwickelte Form der Datenverarbeitung. Im Gegensatz zum üblichen Verfahren von Ethernet Controllern, ein ankommendes Datenpaket zwischen zu speichern, zu verarbeiten und ein neues Datenpaket zu versenden, erfolgt die Verarbeitung im ESC im Durchlauf und vollständig in Hardware. Während des Durchlaufs des Datenpaketes kann der ESC sowohl an diesen Slave adressierte Daten entnehmen, als auch neue, an den Master oder andere Slaves gerichtete Daten einfügen [6]. Durch die MAC‐basierte Adressierung von Ethernet Frames kann EtherCAT diese Form der echtzeitfähigen Kommunikation nur innerhalb eines Subnetzes ausführen. Ein Versand von EtherCAT Frames kann wie in Abbildung 2 zu sehen auch in UDP/IP‐Paketen erfolgen, um Befehle von einem anderen Subnetz aus zu senden. Die Zustellung solcher Pakete unterliegt allerdings der normalen Verzögerung durch Router und erfolgt nicht mehr echtzeitfähig. Ist das Ziel‐Subnetz erreicht, wird das UDP/IP‐Paket entpackt und der weitere Versand erfolgt wiederum direkt im Ethernet Frame [1]. Wie für IE‐Systeme üblich soll neben der echtzeitfähigen Kommunikation für Prozessdaten außerdem eine Übertragung weniger zeitkritischer Daten unter Verwendung von Standardprotokollen möglich sein (UDP, TCP, HTTP, FTP). EtherCAT ermöglicht eine solche Kommunikation ohne Einschränkungen bei der echtzeitfähigen Prozessdatenübertragung. TCP/IP‐ und UDP/IP‐Pakete, die Protokolle wie HTTP, FTP oder SNMP enthalten, werden innerhalb von EtherCAT Frames übertragen (Ethernet over EtherCAT, EoE). Hierzu wird das sogenannte Mailbox‐Protokoll von EtherCAT verwendet [1] [6]. Abbildung 3: Protokollaufbau mit EtherCAT [6] 13 Die Mailbox‐Daten werden zwischen den zyklischen Prozessdaten übertragen, sofern zwischen zwei aufeinanderfolgenden Zyklen noch Zeit zur Verfügung steht. Die Übertragungsrate von Mailbox‐ Daten hängt also von der Auslastung des EtherCAT‐Busses durch zyklische Prozessdaten ab [8]. Neben vollständigen Ethernet Frames können über die EtherCAT Mailbox auch Pakete anderer bekannter Protokolle aus der Automatisierungsindustrie übertragen werden. Die Mailbox unterstützt die Übertragung von Servodrive‐Profilen (SoE), CANopen‐Profilen (CoE) und von Dateien (FoE). Die Übertragung in EtherCAT erfolgt für die höheren Protokollschichten transparent (Abbildung 3). Für Anwendungen. in denen besonders hohe Anforderungen an die zeitliche Präzision gestellt werden (Motion Control), kann außerdem eine Synchronisierung verteilter Uhren verwendet werden. Dabei wird ein EtherCAT Frame durch den kompletten Ring an Feldgeräten hin und wieder zurück geschickt. Sowohl auf dem Hinweg als auch auf dem Rückweg tragen alle Geräte einen Zeitstempel in das Paket ein. Aus den so gewonnenen Daten kann der Master die Übertragungsverzögerung zwischen den Geräten bestimmen und jedem Gerät einen Befehl zum Nachstellen der Uhr senden, der diese Verzögerung mit einbezieht [6]. Darauffolgend müssen Steuerungsbefehle nicht mehr zu einem exakten Zeitpunkt beim Feldgerät eintreffen, sondern können mit Zeitstempeln zum Ausführen einer bestimmten Aktion versehen werden. EtherCAT stellt eine sehr leistungsfähige Form der Echtzeitdatenübertragung über Ethernet zur Verfügung. Durch die schnelle Datenverarbeitung im ESC sind und den geringen Overhead sind Zykluszeiten von weit unter 1ms möglich. Eine Umsetzung von EtherCAT oder einem ähnlichen System in einem P2P‐Netz wie HaRTKad ist jedoch nicht sinnvoll, da im P2P‐Netz kein Master existieren sollte, der die Verwaltungsaufgaben und die Speicherung aller im Netzwerk vorhandenen Daten sowie deren Adressen übernimmt. Auch die Skalierbarkeit ist durch einen Mechanismus wie das logische Prozessabbild nicht mehr gegeben. Die Organisation der Daten auf Anwendungsebene kann also im P2P‐Netz nicht durch ein Protokoll wie EtherCAT gelöst werden. Der Vorteil des geringen Overheads durch das Zusammenfassen von Daten an verschiedene Adressaten würde sich außerdem stark minimieren, sobald das Netzwerk für den Versand größerer Datenmengen verwendet wird. Dies wäre bei einem Einsatz für andere Daten als Prozessdaten voraussichtlich der Fall. 4.3 TCnet Das von Toshiba entwickelte TCnet soll ähnlich wie andere IE‐Systeme einen parallelen Betrieb von Echtzeitkommunikation und nicht‐zeitkritischer Datenübertragung ermöglichen. Hierzu erweitert TCnet das von IEEE 802.3 vorgesehene Zugriffsverfahren auf die Ethernet‐Verbindungen und führt 4 verschiedene Kommunikationsklassen mit unterschiedlicher Priorität ein. Die vier Kommunikationsklassen sind (nach der Übertragungspriorität sortiert): Zyklische Daten mit hohen zeitlichen Anforderungen Zyklische Daten mit mittleren zeitlichen Anforderungen Azyklische Daten Zyklische Daten mit niedrigen zeitlichen Anforderungen Die zyklische Datenübertragung wird von Echtzeitapplikationen genutzt und kann nur innerhalb eines Subnetzes stattfinden, da sie direkt im Ethernet Frame (Abbildung 4) erfolgt. Ebenso wie andere IE‐ Systeme besitzt auch TCnet einen eigenen, von der IEEE zugewiesenen Ethertype. 14 Abbildung 4: TCnet Frame zyklischer Daten [9] Normale Netzwerkanwendungen ohne Echtzeitanforderungen verwenden dagegen azyklische Nachrichten, welche unter Verwendung von Standardprotokollen wie TCP/IP und UDP/IP übertragen werden und damit auch über das Subnetz hinaus gesendet werden können [9]. Um das neu entwickelte Zugriffsverfahren zu ermöglichen, benötigt jeder TCnet Teilnehmer spezielle TCnet Ethernet Controller. Vor der Inbetriebnahme des Systems wird in allen Teilnehmern eine Stationsnummer konfiguriert, durch die die Sendereihenfolge bei der zyklischen Datenübertragung festgelegt wird. Die Datenübertragung wird zyklisch durch den Broadcast eines SYN Frames ausgelöst. Die Station mit der Nummer eins beginnt nach Empfang des SYN Frames die Übertragung. Die vier genannten Nachrichtentypen werden dabei in der oben genannten Reihenfolge versendet [9]. Nach der Datenübertragung sendet die Station eine Broadcast‐Nachricht, die die eigene Stationsnummer enthält und andere Stationen über die abgeschlossene Datenübertragung informiert. Nach dieser sogenannten Completed Message beginnt die Station mit der nachfolgenden Nummer mit dem Senden von Daten. Jede Station hat dabei nur für eine begrenzte Zeit das Recht zum Senden von Daten, bis dieses Recht durch den Broadcast der Completed Message weitergegeben werden muss [10]. Nur durch diese zeitliche Begrenzung kann der Determinismus aufrecht erhalten werden. Ein weiteres Prinzip, das TCnet verwendet, ist ein gemeinsamer Speicher der an der Echtzeitkommunikation teilnehmenden TCnet‐Stationen. Jede Station hat eine eigene Kopie des gemeinsamen Speichers und kann somit jederzeit auf alle Prozessdaten zugreifen. Abbildung 5: TCnet Prinzip des gemeinsamen Speichers [9] Der gemeinsame Speicher ist unterteilt in Blöcke, wobei jeder Block eine Zugehörigkeit zu einer bestimmten TCnet‐Station hat. Die Zugehörigkeit legt fest, dass die entsprechende Station dafür zuständig ist, anderen Stationen den aktuellen Inhalt des Blocks zuzusenden. Zum Versand dieser Blockinhalte werden die zuvor beschriebenen zyklischen Nachrichtentypen verwendet, wobei jeder Block eine eigene Priorität erhalten kann. Um sicher zu stellen, dass alle Teilnehmer ihren gemeinsamen Speicher aktualisieren können, werden die zyklischen Nachrichten als Broadcast versendet (Abbildung 5) [9] [10]. 15 Neben der Integration von Geräten, die mit einem TCnet Ethernet Controller ausgestattet sind und somit an der zyklischen, echtzeitfähigen Kommunikation teilnehmen können, ist auch eine Integration von nicht TCnet‐fähigen Geräten möglich, welche sich an der azyklischen Kommunikation beteiligen können, da diese vollständig mittels Standard‐Protokollen stattfindet. Zur Verbindung von Standard‐Ethernet‐Geräten werden TCnet‐Bridges oder ‐Switches benötigt, welche wie andere Stationen regelmäßig Daten versenden dürfen [9]. Die azyklischen Daten werden solange zwischengespeichert, bis der Switch bzw. die Bridge das Senderecht erhält. Auch TCnet hat den Nachteil proprietärer Hardware. Hinzu kommt die Auslegung der echtzeitfähigen Kommunikation auf die Übertragung von Prozessdaten, was sich auch an der von Toshiba vorgesehenen Größe des gemeinsamen Speichers von 256KB zeigt. Ein solcher gemeinsamer Speicher, der zwischen allen Teilnehmern abgeglichen wird, ist bei deutlich größeren Datenmengen allerdings nicht mehr praktikabel, sodass die Prinzipien von TCnet auf Anwendungsebene nicht für ein P2P‐Netz zur verteilten Datenspeicherung geeignet sind. Neben der limitierten Größe stellt außerdem die Verteilung der Zuständigkeiten ein Problem dar, wenn das P2P‐Netz flexibel bleiben soll. Bezüglich der Zugriffsmethode ähnelt TCnet jedoch stark einem Zeitschlitzverfahren, welches auch für HaRTKad implementiert werden soll. 4.4 TTEthernet TTEthernet ist ein von der TTTech Computertechnik AG entwickeltes echtzeitfähiges Ethernet System, dass sich vollständig mit Standard‐Ethernet‐Systemen kombinieren lässt und so eine Vielzahl von Anwendungsbereichen ermöglichen soll. So soll es zum Beispiel in der Fabrikautomation eine Verbindung von Büro und IT‐Bereich mit Produktionsanlagen in einem Subnetz ermöglichen, oder im Automobil‐ und Flugzeugbau eine Vernetzung von Entertainment‐ und Navigationssystemen mit zeitkritischen Steuerungssystemen erlauben. Um Systeme mit so unterschiedlichen Anforderungen an die maximale Übertragungsverzögerung in einem Netzwerk zu verbinden, müssen Nachrichtentypen mit unterschiedlicher Priorität eingeführt werden. Im Falle von TTEthernet handelt es sich um folgende Nachrichtentypen [11]: TT – Time Triggered: RC – Rate Constrained: TT‐Daten haben die höchste Priorität im Netzwerk. Sie werden zyklisch zu vordefinierten Zeitpunkten gesendet. Innerhalb des Zeitfensters zur Übertragung von TT‐Daten kann es nicht zu Verzögerungen kommen, da die Übertragungskanäle für diesen Nachrichtentyp reserviert werden. Durch die vorige Konfiguration kann verhindert werden, dass mehrere TT‐Datenpakete auf dem gleichen Weg versendet werden und durch Zwischenspeicherung in den Switch‐Puffern verzögert werden. RC‐Daten haben niedrigere Priorität als TT‐Daten, können allerdings jederzeit und nicht nur zu vorbestimmten Zeitpunkten versendet werden. Sollen sie zur gleichen Zeit wie TT‐Daten versendet werden, so werden sie bis zum Ende des TT‐Zeitfensters verzögert. Eine Überlastung des Netzes durch RC‐Daten ist ausgeschlossen, da jeder Teilnehmer nur eine bestimmte Anzahl an RC‐Datenpaketen in einer gewissen Zeit senden darf. So wird sichergestellt, dass es 16 BE – Best Effort: nicht zu einem Pufferüberlauf in einem Switch kommen kann, bei dem Daten verworfen werden. BE‐Daten haben die niedrigste Priorität im Netzwerk und werden immer erst dann übertragen, wenn weder TT‐Pakete noch RC‐Pakete auf eine Übertragung (aus dem Puffer des Switches) warten. Der Übertragung sind keine Grenzen gesetzt, es gibt jedoch keinen Determinismus und es kann zu Paketverlusten bei Überlastung kommen. Die Nachrichtentypen TT und RC besitzen deterministische Übertragungseigenschaften, wobei TT für besonders zeitkritische Anwendungen konzipiert ist, da im Gegensatz zu RC keine Verzögerungen auftreten können. Um Daten mit den gegebenen Nachrichtentypen zu versenden, wird bei TTEthernet spezielle Hardware eingeführt. Es werden Switches benötigt, die das TTEthernet‐Protokoll unterstützen und im Slave kann die TTEthernet‐Implementierung durch zusätzliche TTEthernet Controller erfolgen, oder durch eine Implementierung des TTEthernet‐Protokolls im Software Stack unter Verwendung von Standard‐Ethernet Controllern. Der Nachteil der Softwarevariante sind höhere Ungenauigkeiten bei Übertragung von TT‐Daten sowie größere Verzögerungszeiten durch die Laufzeit im Software Stack. Werden Geräte ohne Implementierung von TTEthernet an das Netzwerk angeschlossen, so werden deren Daten als BE‐Daten behandelt, sie unterliegen also nicht deterministischer Kommunikation [11]. Um TT‐Pakete zum richtigen Zeitpunkt zu versenden und die Übertragungskanäle während dieses Zeitfensters für andere Nachrichtentypen zu sperren ist eine gemeinsame Zeitbasis der Switches und der angeschlossenen Geräte nötig. Diese wird durch Synchronisierung verteilter Uhren erreicht. Dabei können bei der Konfiguration des Netzwerkes ein oder mehrere Mastergeräte definiert werden, die die Synchronisierung der Uhren übernehmen. Neben der Synchronisierung der Uhren müssen die Übertragungszyklen von TT‐Daten den beteiligten Geräten mitgeteilt werden, damit diese keine anderen Datenpakete innerhalb dieses Zeitfensters übertragen. Auch die maximale Häufigkeit von RC‐Paketen muss durch das TTEthernet‐Protokoll zwischen allen TTEthernet‐Geräten ausgehandelt werden [11]. Für die höheren Protokollschichten ist die Übertragung durch TTEthernet vollständig transparent und es gibt keinerlei Vorgaben, welche Art von Daten mit Hilfe von TTEthernet übertragen werden. Auch die Ethernet Frames der Nutzdaten bleiben unangetastet. Der Protokoll‐Overhead von TTEthernet, z.B. zur Synchronisierung von Geräten oder zur Kennzeichnung der Nachrichtentypen TT und RC wird in separaten Frames, den sogenannten Protocol Control Frames, übertragen [11]. Dies stellt einen entscheidenden Unterschied zu den bekannten IE‐Lösungen dar, da diese immer auch auf die Übertragung bestimmter Inhalte, wie z.B. das Prozessdatenabbild bei EtherCAT, ausgelegt sind. Auch IT‐Daten werden von anderen IE‐Systemen häufig nicht unverändert in ihren ursprünglichen Ethernet Frames versendet, sondern um den Header des proprietären Protokolls erweitert und so durch das entsprechende Protokoll getunnelt. TTEthernet stellt dagegen ein deterministisches Übertragungsverfahren auf den untersten zwei Protokollschichten des OSI‐Modells zur Verfügung, ohne in die Art der Nutzdaten einzugreifen. Das Protokoll übernimmt nur die zeitliche Abwicklung der Übertragung [11]. 17 Von den betrachteten Lösungen zur Echtzeitdatenübertragung über Ethernet ist TTEthernet die einzige Lösung, die eine zum P2P‐basierten HaRTKad System ähnliche Zielsetzung hat. Ein Nachteil von TTEthernet ist die Notwendigkeit spezieller Switches, während seitens der Endgeräte bei beiden Systemen (TTEthernet und HaRTKad) spezielle Software oder Hardware benötigt wird. Beide Lösungen streben eine echtzeitfähige Datenübertragung über Ethernet an, ohne den durch höhere Protokollschichten organisierten Datenverkehr einzuschränken. Beide machen sich außerdem das Prinzip synchronisierter verteilter Uhren zu Nutze, um den zeitlichen Ablauf der Datenübertragung zu regeln, ohne dass es zu Verzögerungen durch Zwischenspeicherung von Ethernet Frames kommt. Das P2P‐basierte System ist allerdings flexibler, da keine Routen und Übertragungszeitpunkte vordefiniert werden müssen, wie es bei TT‐Nachrichten der Fall ist. Auch eine Konfiguration von Master‐Stationen entfällt bei HaRTKad, da es sich nach der Einstellung weniger Parameter größtenteils selbst organisiert und bei Veränderung der Netzwerkteilnehmer aktualisiert. Ein Vergleich der Leistungsfähigkeit der beiden Systeme wäre interessant, da beide u.a. für den gleichen Einsatzzweck und unter Verwendung identischer Protokolle auf den höheren Schichten des OSI‐Modells genutzt werden können. 4.5 CC‐LinkIEField CC‐Link wurde 1996 von Mitsubishi Electric als Feldbus zur Vernetzung von Industrieanlagen entwickelt und wird seit 1999 vermarktet und von der CC‐Link Partner Association (CLPA) weiterentwickelt und verbreitet. CC‐Link IE ist ein auf diesem Feldbus aufbauender IE Standard der 2007 veröffentlicht wurde. Zu CC‐Link IE zählen das CC –Link IE Control Netzwerk zur Vernetzung mehrerer Anlagen sowie das im Folgenden behandelte CC‐Link IE Field Netzwerk, welches zur echtzeitfähigen Kommunikation von Geräten einer Anlage über Gigabit Ethernet verwendet wird. Da CC‐Link IE Field auf Full‐Duplex Gigabit Ethernet aufbaut, ist die Topologie nahezu frei wählbar. Geräte können sternförmig mit Hilfe von Switches miteinander verbunden werden oder durch 2 Ethernet Ports mit integriertem Switch in jedem Feldgerät in einer Ring‐ oder Linientopologie. Zur Verkabelung werden Standard Ethernet Kabel mit RJ45 Stecker genutzt. Die Adressierung von Feldgeräten erfolgt durch Stationsnummer von 1 bis 254 [1], wodurch die Anzahl der Geräte begrenzt wird. Ähnlich wie andere IE‐Systeme verwendet auch CC‐Link IE Field ein Master/Slave‐Prinzip. Dabei sind 5 verschiedene Stationstypen definiert [1]: Master: Local Station: Intelligent Device Station: Der Master ist für die Initialisierung des gesamten Netzwerks zuständig und kontrolliert die gesamte Datenübertragung. Er speichert außerdem den Zustand aller Ein‐ und Ausgänge der Geräte im Netzwerk. Als Informationsspeicher stehen dabei 32768 Bits und 16384 Worte (1 Wort entspricht 2 Byte) für das gesamte Netzwerk zur Verfügung. Eine lokale Station kann Bit‐ und Wortdaten mit dem Master austauschen und zusätzliche Nachrichten versenden. Dabei kann es sich z.B. um eine SPS oder einen PC handeln. Eine intelligente Station kann beispielsweise Daten aus seriellen Eingängen wie einer RS232‐Schnittstelle oder von einem A/D‐Wandler entgegennehmen und die gewonnenen Informationen in Form von Bits und Wörtern mit dem Master 18 Remote Device Station: Remote I/O Station: austauschen. Zusätzlich können Nachrichten versendet werden. Dieser Stationstyp tauscht mit dem Master Informationen von digitalen Ein‐ und Ausgängen in Form von Bits und Worten aus. Eine Remote I/O Station kann Informationen von digitalen Ein‐ und Ausgängen nur über Bits mit dem Master austauschen. Der im Master zur Verfügung stehende Informationsspeicher von maximal 32768 Bits und 16384 Worten ist eine Zusammenfassung aller im Netzwerk befindlicher Gerätespeicher. Eine Local Station und eine Intelligent Device Station können jeweils 4096 Bits und 2048 Worte speichern, eine Remote Device Station kann 256 Bits und 128 Worte speichern und eine Remote I/O Station kann 128 Bits speichern [1]. Die Bits und Worte tragen beim CC‐Link IE Protokoll spezielle Bezeichnungen, wie in Tabelle 1 dargestellt. Eingangsbit Eingangswort Ausgangsbit Ausgangswort RX RWr RY RWw Tabelle 1: CC‐Link IE Field Prozessdatentypen Die Bits und Worte im Speicher der Feldgeräte repräsentieren dabei immer physikalische Ein – und Ausgänge. Ein Beispiel für ein Eingangsbit RX ist zum Beispiel ein am Gerät befindlicher Schalter, der auf „An“ oder „Aus“ stehen kann und so das entsprechende Bit auf „0“ oder „1“ setzen kann. Ein Eingangswort kann beispielsweise der Eingang eines A/D‐Wandlers sein [1]. Die Übertragung dieser Daten erfolgt zyklisch mit Hilfe eines Token Passing‐Mechanismus. Dabei wird, angefangen beim Master, ein Token im Netzwerk weitergegeben, der es dem aktuellen Besitzer des Tokens erlaubt, Daten zu senden. Das Token wird dabei logisch auf einem Ring weitergegeben, sodass innerhalb von einem Zyklus jeder Netzwerkteilnehmer das Token einmal erhält und Daten senden darf. Der Besitzer des Tokens sendet zuerst zyklische Prozessdaten (RX, RWr, RY oder RWw) und hat anschließend die Möglichkeit zur azyklischen Datenübertragung, im Falle von CC‐Link IE Field als transiente Übertragung bezeichnet. Hierbei können Nachrichten zwischen Stationen ausgetauscht werden, die IT‐Daten enthalten oder Parameter einer Station aktualisieren. Um den Determinismus der Übertragung zu gewährleisten, wird die transiente Übertragung durch eine maximale Anzahl an Datenrahmen zur transienten Übertragung begrenzt. Diese maximale Anzahl ist konfigurierbar und wird pro Gerät und pro Zyklus vergeben. Nach dem Senden zyklischer und azyklischer Daten wird das Token an die nächste Station weitergegeben. Die Übertragungsdauer zyklischer Daten ist durch die Speicherbegrenzung der verschiedenen Stationstypen ohnehin limitiert und ermöglicht somit eine deterministische Kommunikation. Geräte, die das Token nicht besitzen, können nur Daten empfangen [1]. Bei der Übertragung zyklischer Daten sendet die Master Station RY und RWw Datenrahmen an Slave Stationen, um deren Ausgänge zu aktualisieren. Slave Stationen wie eine Remote Device Station oder Remote I/O Station senden RX und RWr Datenrahmen an den Master, wenn sie durch eine Nachricht vom Master dazu aufgefordert werden. So wird der Status der Eingänge im Informationsspeicher des Masters aktuell gehalten. Wenn nötig, werden diese RX und RWr Rahmen vom Master im 19 darauffolgenden Zyklus an eine Local Station, die eine Steuerung enthält, weitergeleitet. Stellt eine Steuerung fest, dass Ausgänge geändert werden müssen, so sendet sie RY und RWw Datenrahmen an den Master, der diese Information im nächsten Zyklus an die entsprechenden Stationen weitersendet, welche die Daten übernehmen und die Ausgänge entsprechend ändern. Sind die Stationen physikalisch in einer Ring‐ oder Bustopologie angeordnet, so erkennen die Geräte an Hand der adressierten Stationsnummer, ob die Nachricht für sie bestimmt ist, oder ob die Nachricht weitergeleitet werden muss [1]. Neben der zuvor beschriebenen Kommunikation mittels Token Passing‐Mechanismus, gibt es noch weitere Kommunikationsphasen zur Organisation des Netzwerks. Dies umfasst die Erstkonfiguration bei der Inbetriebnahme des Netzwerks (Initialisierung), sowie die Aktualisierung von Konfigurationsdaten bei der Veränderung des Netzwerks bzw. von dessen Teilnehmern [1]. In der Initialisierungsphase bestimmt der Master die Netzwerkstruktur und erhält Informationen über die angeschlossenen Geräte. Basierend auf diesen Informationen sowie benutzerdefinierten Konfigurationsinformationen versendet der Master Einstellungen an die anderen Geräte. Dies umfasst z.B. die Route des Token Passing sowie die Parameter zur transienten Kommunikation. Nach der Initialisierung kann die zyklische Kommunikation ausgehend vom Master gestartet werden. Nach jedem Zyklus hat der Master die Möglichkeit die zyklische Kommunikation zu unterbrechen und neue Einstellungen an die Feldgeräte zu senden. Dies ist zum Beispiel nötig, um neu angeschlossene Geräte in die Token Passing Route aufzunehmen [1]. CC‐Link IE Field lässt sich aus verschiedenen Gründen nicht auf einem P2P‐Netz zur Datenübertragung größerer Datenmengen anwenden. Zum einen wird auch bei diesem IE‐System entweder proprietäre Hardware in den Slaves (Mitsubishi CP220 Chip) [12] oder eine Implementierung des Seamless Message Protocols (SLMP) [12] [13] benötigt, zum anderen weist CC‐ Link IE Field Limitierungen auf, die den Prinzipien des geplanten HaRTKad P2P‐Netzes nicht gerecht werden. So widerspricht die maximale Anzahl von 254 Netzwerkteilnehmern der gewünschten Skalierbarkeit des Netzwerkes und der Datenbereich von 32768 Bits und 16384 Worten ist wesentlich kleiner als in einem Netzwerk zur verteilten Datenspeicherung nötig. Diese Limitierungen stammen daher, dass CC‐Link IE Field auf die Übertragung von Prozessdaten ausgerichtet ist, in der die gegebene Anzahl an Teilnehmern und die Menge an Daten ausreichend sind. Auch die Verwaltung der Daten über einen gemeinsamen Informationsspeicher im Master ist im P2P‐Netz nicht realisierbar. Einzig die Idee der Zugriffskontrolle über Token Passing ist auch im P2P‐Netz umsetzbar und stellt eine Alternative zum Zeitschlitzverfahren dar. Da die Verwaltung von Daten jedoch nicht über einen gemeinsamen Informationsspeicher und die damit verbundene Adressierung in den Slaves erfolgen kann, wird weiterhin ein spezielles Protokoll auf Anwendungsebene benötigt, um Daten im Netzwerk speichern und wiederzufinden. 4.6 ProfinetIO Wegen der weiten Verbreitung in der Industrie soll hier außerdem das von Siemens entwickelte Profinet IO kurz vorgestellt werden, wobei es sich um ein IE‐System handelt, welches auf die Synchronisierung verteilter Uhren setzt und somit isochrone Echtzeitkommunikation ermöglicht. An der Kommunikation bei Profinet IO nehmen 3 Geräteklassen teil [1]. IO Devices sind typische Feldgeräte, welche Sensordaten liefern und ihre eigenen Ausgänge steuern können. IO Controller sind Steuerungen, wie z.B. SPS, welche die Daten von IO Devices entgegennehmen und diesen 20 Steuerbefehle senden. IO Supervisor sind temporär angeschlossene Geräte zur Konfiguration des Profinet‐Systems. Die Kommunikation erfolgt zyklisch und in mehreren Phasen. Jeder Zyklus beginnt mit der isochronen Phase, in der die Isochronous Real‐Time (IRT) Frames übertragen werden. Die Übertragung von IRT Frames wird bereits zum Zeitpunkt der Installation des Netzwerks konfiguriert. Durch die synchronisierten Uhren kann in allen Geräten genau festgelegt werden, wann sie einen IRT Frame senden dürfen. Trotz der Übertragung im Ethernet Frame findet keine Adressierung durch MAC‐ Adressen statt, sondern die Frames werden bedingt durch den Zeitpunkt der Übertragung auf einer festen Route durch die Switches geleitet. Hierzu sind spezielle Profinet Switches notwendig. Nach der isochronen Phase folgt die Phase der Echtzeitdatenübertragung, in der nur Datenframes mit hoher Priorität gesendet werden dürfen. Für diese Phase ist jedoch kein Zeitplan mehr erforderlich und die Übertragung erfolgt an Hand von MAC‐Adressen. Abschließend folgt die Phase für nicht‐zeitkritische IT‐Daten. Hier können normale UDP/IP‐ und TCP/IP‐Pakete übertragen werden [10]. Profinet verwendet auf Anwendungsebene die bereits durch Profibus eingeführten Gerätebeschreibungsdateien, mit deren Hilfe ein Gerätehersteller spezifizieren kann welche Ein‐ und Ausgänge an einem Gerät zur Verfügung stehen bzw. steuerbar sind [1]. Ähnlich wie andere deterministisch arbeitende IE‐Systeme benötigt auch Profinet spezielle Hardware um eine deterministische Kommunikation innerhalb eines Subnetzes zu ermöglichen. Außerdem findet die Synchronisierung über einen Master statt und die deterministisch arbeitenden IRT Frames müssen bei der Installation konfiguriert werden [1]. Um den Installationsaufwand zu verringern kann in Anlagen mit geringen Echtzeitanforderungen auf die isochrone, deterministische Datenübertragung verzichtet werden und eine nur durch VLAN Tags in Prioritäten eingeteilte Kommunikation verwendet werden. Wird der Datenverkehr priorisiert, aber unsynchronisiert durchgeführt, so können außerdem Standard‐Switches eingesetzt werden [1]. Um Profinet‐Geräte nach ihrer Unterstützung der verschiedenen Kommunikationsmöglichkeiten einzuordnen, gibt es dabei verschiedene Konformitätsklassen, die in [1] näher erläutert werden. 4.7 VergleichdervorgestelltenIE‐Systeme In Tabelle 2 werden die vorgestellten IE‐Systeme hinsichtlich einiger Kriterien verglichen, welche besonders relevant für eine Implementierung des Systems oder von Teilen des Systems in einem P2P‐Netz zur verteilten Datenspeicherung unter Verwendung von Standard‐Ethernet Hardware sind. IE‐System Ethernet Powerlink EtherCAT TCnet TTEthernet CC‐Link IE Field Verwendete Anwendungsprotokolle bei RT‐Kommunikation CANopen CANopen, Servodrive TCnet Common Memory beliebig CC‐Link/SLMP Profinet IO Profibus Erfordert spezielle Hardware Besitzt SPoF: Master o.ä. optional Ja, ESC Ja, TCnet Controller Ja,TTEthernet Switches optional Ja, MN Ja, Master Keine Angabe Nein Ja, Token‐ Master Ja, Profinet Switches für Ja, Clock IRT‐Kommunikation Master für IRT‐ Kommunikation Tabelle 2: Übersicht über die vorgestellten IE‐Systeme 21 Tabelle 2 zeigt, dass keins der IE‐Systeme alle gewünschten Kriterien erfüllt. Die durch die IE‐Systeme eingeführten oder verwendeten Protokolle auf Anwendungsebene sind auf Grund der Herkunft und Zielsetzung der Systeme auf die Übertragung von Prozessdaten optimiert und bieten keine Lösung zur transparenten Speicherung beliebiger, großer Datenmengen. Nur TTEthernert erlaubt auch bei der deterministischen Datenübertragung beliebige, durch den Anwender vorgegebene Protokolle, liefert jedoch auch keine eigenen Protokolle die sich zur verteilten Datenspeicherung eignen. Weiterhin bietet keine der vorgestellten Lösungen eine deterministische Datenübertragung ohne spezielle Hardware und gleichzeitig keinem SPoF. Abschließend lässt sich sagen, dass nur TTEthernet für vergleichbare Zwecke wie das zuvor vorgestellte HaRTKad‐Netz verwendet werden kann, wenn auch mit höherem Konfigurationsaufwand und unter Verwendung spezieller Hardware. Die anderen IE‐Systeme unterliegen Limitierungen, die (ohne größere Veränderungen am System) keine verteilte Datenspeicherung in einem flexiblen und gut skalierbaren Netzwerk ermöglichen. In Kapitel 5 wird diskutiert, welche Protokolle zur verteilten Datenspeicherung in einem System wie HaRTKad oder TTEthernet verwendet werden können. 5 ProtokolleaufAnwendungsebene 5.1 Übertragungsprotokolle Das Ziel eines Übertragungsprotokolls auf Anwendungsebene ist es, bei gegebener Echtzeitfähigkeit der darunter liegenden Protokolle, den Determinismus auf höherer Ebene fortzusetzen. Als Beispiel sei hier wieder ein P2P‐Netz genannt, welches die Kommunikation über Ethernet um ein Zeitschlitzverfahren erweitert und somit deterministisch arbeiten kann. Für die Kommunikation innerhalb der Zeitschlitze wird ein Protokoll benötigt, welches Befehle zum Versenden und Speichern von großen Dateien (Dateien, die nicht in einem Ethernet Frame transportiert werden können) sowie zum Wiederauffinden und Abrufen der Dateien so realisiert, dass die Anzahl der benötigten Datenpakete (und damit Zeitschlitze) an Hand der Dateigröße vorab bestimmt werden kann und die Übertragung daher deterministisch erfolgen kann. Die Übertragung eines solchen Protokolls kann innerhalb eines Subnetzes direkt im Ethernet Frame oder in UDP/IP‐Paketen erfolgen. Ein weiteres Kriterium für die oberhalb von Ethernet arbeitenden Protokolle ist außerdem die Möglichkeit einer effizienten Implementierung in Hardware oder Software, sodass auch die im Endsystem benötigten Datenverarbeitungszeiten des Protokoll‐Stacks den Determinismus nicht verhindern. Das Constrained Application Protocol (CoAP) ist ein existierender Ansatz, der diese Anforderungen erfüllt. 5.1.1 ConstrainedApplicationProtocol(CoAP) CoAP befindet sich derzeit in der Entwicklung durch die Constrained RESTful Environments (CoRE) Arbeitsgruppe der Internet Engineering Taskforce (IETF). REST steht für Representational State Transfer und bezeichnet die derzeit übliche Arbeitsweise von Internetdiensten. Eine bekannte Umsetzung der REST Architektur ist das Hyper Text Transfer Protocol (HTTP). Das Ziel bei der Entwicklung von CoAP ist ein Protokoll, das besonders für weniger leistungsstarke Geräte mit geringem Stromverbrauch verwendbar ist. Gebäudeautomation und die Kommunikation zwischen Geräten (Machine‐to‐Machine, M2M) stehen im Mittelpunkt. Aus diesem Grund strebt CoAP einen besonders geringen Overhead an, während gleichzeitig ein Großteil der Möglichkeiten von HTTP erhalten bleiben soll. Ein geringer Overhead wird durch die Verwendung eines kurzen Headers sowie durch die Verwendung von UDP statt TCP als unterlagerte Protokollschicht erreicht. Eine Verwendung von TCP und anderen Protokollen der Transportschicht ist zwar möglich, ist jedoch nicht 22 Ziel der Entwicklung von CoAP. Die Verwendung von UDP bietet durch die Unterstützung von Multicast einen weiteren Vorteil bei der Gerätekommunikation. Viele Funktionen von CoAP sind in ähnlicher Art und Weise ebenfalls in HTTP vorhanden, sodass eine Übersetzung zwischen den Protokollen durch Proxy Server realisierbar ist und eine Kommunikation zwischen Geräten mit CoAP und HTTP möglich ist. Obwohl es sich bei CoAP um ein einziges Protokoll auf der Anwendungsschicht handelt, so arbeitet es logisch auf 2 Ebenen. Bei der unteren Ebene handelt es sich um die Nachrichtenebene. CoAP ermöglicht 4 Nachrichtentypen, die im Header entsprechend gekennzeichnet werden. Nachrichten können als zu bestätigende Nachrichten (Confirmable; CON), nicht zu bestätigende Nachrichten (Non‐Confirmable; NON), Bestätigungsnachricht (Acknowledgement; ACK) und Abweisungsnachricht (Reset; RST) versendet werden. Jede Nachricht erhält dabei eine ID, sodass ACK, RST und CON Nachrichten einander zugeordnet werden können. Ähnlich wie bei einer TCP‐Verbindung werden CON Nachrichten erneut versendet, wenn nicht vor Ablauf eines Timers eine ACK oder RST Nachricht mit der gleichen ID erhalten wurde. Eine ACK‐Nachricht bestätigt das Eintreffen der Nachricht und signalisiert, dass diese verarbeitet wird. Dagegen gibt eine RST‐Nachricht an, dass die Nachricht eingetroffen ist, jedoch nicht verarbeitet werden kann (beispielsweise wegen fehlendem Kontext) Bei NON‐Nachrichten wird die ID weiterhin zur Erkennung von Duplikaten verwendet, ohne dass eine Bestätigungsnachricht versendet wird. Abbildung 6: Ein erfolgreiches und ein gescheitertes GET Request mit "piggy‐backed" Response [14] Oberhalb der Nachrichtenebene ist im CoAP‐Protokoll eine Request/Response‐Ebene angesiedelt. CoAP basiert ähnlich wie HTTP auf einem Client/Server‐Modell, bei dem ein Request vom Client ausgeht und eine bestimmte Ressource des Servers anfragt. Der Client versendet zunächst eine Nachricht, die eine bestimmte Zugriffsmethode enthält und die angefragte Ressource des Servers an Hand einer URI (Uniform Ressource Identifier) identifiziert. Auf eine solche Anfrage antwortet der 23 Server mit einem Response Code und wenn möglich mit den entsprechenden Daten. Wurde der Request mit einer CON Nachricht gesendet, kann die Antwort im ACK enthalten sein (piggy‐backed Response). Abbildung 6 zeigt zwei Requests, von denen der erste erfolgreich beantwortet werden konnte und der zweite nicht. Bei “2.05” und “4.04” handelt es sich um die Response Codes. Die Hexadezimalzahlen [0xbc90] und [0xbc91] geben dabei die zuvor angesprochenen Nachrichten IDs an. Die Token‐Nummern sind unabhängig von der Nachrichtennummer und identifizieren einen Request und die zugehörige Response. So ist es z.B. möglich, dass der Server das Eintreffen einer CON Nachricht mit einem leeren ACK Paket bestätigt und die Response erst später in einer neuen Nachricht versendet wird. Die Response wird dann durch das Token zugeordnet. Abbildung 7 zeigt dieses Verfahren. Abbildung 7: GET Request mit separater Antwort [14] Neben den bestätigten Nachrichten kann die Request/Response Kommunikation auch vollständig mit NON Nachrichten erfolgen. Zusammengehörige Nachrichten werden dann über die Token‐Nummer erkannt, während die Nachrichtennummern unabhängig voneinander sind. In CoAP sind die Zugriffsmethoden GET, PUT, POST und DELETE verfügbar: GET: PUT: POST: DELETE: Durch die GET‐Methode wird eine Repräsentation der Informationen angefragt, die derzeit unter der ebenfalls in der Anfrage enthaltenen URI verfügbar sind. Durch das Anfügen einer „Accept“ Option kann das bevorzugte Dateiformat der Antwort angegeben werden. Mit Hilfe von PUT können Informationen, die durch die übermittelte URI identifiziert werden, aktualisiert oder hinzugefügt werden. Hierzu muss eine Repräsentation der übermittelt werden. Die „Content – Format“ Option kann dabei verwendet werden, um Dateityp und Codierung der übermittelten Repräsentation anzugeben. Die Behandlung von POST hängt vom Server ab und kann zur Modifikation, zum Hinzufügen, oder zum Löschen von Ressourcen auf dem Server verwendet werden. Durch die DELETE‐Methode werden die Informationen, die durch die angegebene URI identifiziert werden, vom Server gelöscht. 24 Wie bereits angesprochen ist der Header von CoAP darauf ausgelegt möglichst wenig Overhead zu erzeugen, um auch in Anwendungsbereichen, in denen nur wenig Ressourcen (Speicher, Rechenleistung und Übertragungskapazität) zur Verfügung stehen, eine effiziente Übertragung von Daten zu ermöglichen. Der Header beginnt mit stationären 4 Byte, gefolgt von einem Token variabler Länge und einer flexiblen Anzahl an Optionen. Die flexible Anzahl an Optionen ermöglicht es, zusätzlich zur Nutzlast nur Informationen zu übertragen, die in diesem Paket auch benötigt werden. Es entstehen keine ungenutzten Felder. Abbildung 8 zeigt das Nachrichtenformat des CoAP Protokolls, welches im Folgenden erläutert wird. Abbildung 8: Aufbau des CoAP Protokolls [14] Version (Ver): Type (T): Token Length (TKL): Code: Message ID: Token: Integer‐Wert zur Angabe der CoAP‐Version Integer‐Wert zur Angabe des Nachrichtentyps: Confirmable (0) Non‐Confirmable (1) Acknowledgement (2) Reset (3) Längenangabe des Tokens in Byte. Kann Werte von 0 bis 8 enthalten Gibt an, ob die Nachricht einen Request (1 – 31) oder eine Response (64 – 191) enthält. Im Falle eines Requests geben die verschiedenen Werte die Zugriffsmethode (GET; PUT; POST; DELETE) an. Im Falle einer Response ist der Response Code enthalten. Nachrichtennummer zur Identifizierung von Duplikaten und zur Zuordnung von CON/ACK/RST‐Nachrichten. Wird zur Zuordnung von Requests und Responses verwendet. Nach dem Token folgen Optionen und Nutzdaten. Die zur Verfügung stehenden Optionen sind durchnummeriert und werden mit Hilfe ihrer Nummer, einer Längenangabe und ihrem Wert angegeben. Die Nummern werden dabei nicht relativ, sondern mit einem Deltawert zur vorigen Optionsnummer angegeben. Da nur positive Deltawerte unterstützt werden, müssen die Optionen in der Reihenfolge ihrer Nummern im Datenpaket auftreten. Der Startwert der Optionsnummern ist 0. Ist die erste auftretende Option beispielsweise die Option 3, müsste ein Deltawert von 3 angegeben werden. Folgt darauf Option 12, muss hierfür ein Deltawert von 9 angegeben werden. Optionsdelta und Optionslänge werden normalerweise mit jeweils 4 Bit angegeben, es ist jedoch eine Erweiterung dieser Angaben auf jeweils 2 Byte möglich. Auf Deltawert und Länge folgt der Wert der Option. Nach einer Option können weitere Optionen folgen oder das Byte 0xFF, welches den Anfang der Nutzlast angibt. Da die Nutzlast die restlichen Daten bis zum Ende des UDP Paketes ausfüllt, wird hierbei keine Länge angegeben [14]. 25 Das vorgestellte Constrained Application Protocol ist prinzipiell für eine Echtzeitdatenübertragung in einem P2P‐Netz geeignet, da sich durch die verbindungslose Übertragung von unbestätigten Datenpaketen ohne mehrere Versuche eine maximale Übertragungsdauer bestimmen lässt. Auch die benötigten Grundfunktion wie das Speichern (PUT), Lesen (GET) und Löschen (DELETE) von Daten sind bereits definiert. Der grundlegende Entwurf von CoAP sieht zwar eine maximale Paketgröße vor, die den Versand der Pakete auf der zu Grunde liegenden Schicht 2 des OSI‐Modells ohne Fragmentierung zulässt (im Falle von Ethernet also Pakete von maximal 1500 Byte einschließlich CoAP, UDP und IP Header), allerdings sind bereits Entwürfe verfügbar, die CoAP Optionen zum Transfer größerer Dateien hinzufügen [15]. Dabei werden die Daten bereits vor der Einbettung in CoAP‐Pakete zerteilt und blockweise übertragen. Eine Limitierung der maximalen Übertragungsgröße durch die MTU (Maximum Transmission Unit) der unteren Schichten ist damit nicht mehr vorhanden. 5.2 Fehlerüberprüfung Durch zufällig auftretende Fehler bei der Übertragung können Daten beschädigt oder verloren gehen. Ein weit verbreiteter Ansatz bei der Datenübertragung ist es, Fehler durch die Verwendung von Überprüfungscodes wie dem Cyclic Redundancy Check (CRC) Code (in jedem Ethernet Frame enthalten) erkennbar zu machen und Paketverluste durch Nummerierung (z.B. bei TCP) zu identifizieren. Wurde ein Problem erkannt, können die betroffenen Daten nochmals übertragen werden. Diese Vorgehensweise ist jedoch bei Echtzeitanforderungen problematisch. Da nicht vorhersehbar ist, wann oder wie oft Fehler bei der Übertragung passieren, wäre der angestrebte Determinismus bei der Übertragung nicht mehr sichergestellt. IE‐Systeme verzichten daher bei der Echtzeitkommunikation ebenfalls auf eine erneute Übertragung der Daten. Eine erneute Übertragung wäre bei den meisten Anwendungen auch nicht zweckmäßig, da verspätet eintreffende Daten bei Steuerungs‐ und Regelungsaufgaben oft bereits wertlos sind. Dennoch muss bei IE‐ Systemen eine Fehlererkennung und ‐behandlung vorhanden sein. In der Regel werden die Fehler protokolliert und Diagnosemechanismen gestartet, die den Benutzer mit Informationen zur Problembehebung versorgen. Je nach Anlagentyp werden die betroffenen Maschinen in einen sicheren Zustand gebracht. In einigen Anwendungsgebieten kommt es jedoch auch vor, dass der Fehler protokolliert wird, jedoch keine sofortige Reaktion hervorruft. Dies ist z.B. beim zyklischen Prozessdatenaustausch möglich, wenn die Anlagen tolerant gegenüber einzelnen Zyklusausfällen sind. Mehrfache Zyklusausfälle, die in relativ geringen Abständen auftreten, können hingegen eine Reaktion hervorrufen, wie in [4] beschrieben. Soll eine verteilte Datenspeicherung mit Echtzeitdatenübertragung realisiert werden, so sind neue Überlegungen notwendig. Auf Grund des Widerspruchs zur Echtzeitdatenübertragung kann keine Wiederholung fehlerhafter Datenpakete stattfinden, andererseits dürfen auch keine Daten unwiederbringlich verloren gehen. Die Lösung hierfür sind fehlerkorrigierende Codes, mit deren Hilfe die Daten vor dem Versenden so kodiert werden können, dass bei der Wiederherstellung alle Daten vollständig wiederhergestellt werden können, obwohl Pakete verloren gegangen sind oder auf Grund von CRC‐Fehlern verworfen wurden. Dies wird durch eine Datenredundanz erreicht, sodass größere Datenmengen versendet werden müssen. Die im Folgenden vorgestellten Reed Solomon Codes sind ein Beispiel solcher fehlerkorrigierender Codes. 5.2.1 ReedSolomon Bei Reed Solomon Codes werden Binärdaten als eine Reihe von b‐Bit Symbolen aufgefasst. Zu einer gegebenen Anzahl von m Symbolen werden durch ein mathematisches Verfahren zusätzlich k Symbole bestimmt, die Paritätssymbole. Insgesamt stehen also n = m + k Symbole zur Verfügung, 26 welche übertragen bzw. gespeichert werden. Man spricht hierbei von einem RS(n, m) Code. Die Anordnung der Ursprungsdaten im n Symbole umfassenden Codewort hängt vom verwendeten Codierungsverfahren ab. Bei der systematischen Codierung [16] bleiben die Ursprungsdaten unverändert und die Paritätssymbole werden angehängt. b m k n Anzahl der Bits pro Symbol Symbolanzahl der Nutzdaten Anzahl der Paritätssymbole Gesamtanzahl der Symbole Tabelle 3: Reed Solomon Bezeichner Ob die Ursprungsdaten durch einen Decoder wiederhergestellt werden können hängt von der Anzahl und der Art der Fehler ab. Bei Reed Solomon Codes hängt die Wiederherstellbarkeit der Daten nicht von der Anzahl der Bitfehler ab, sondern von der Anzahl der fehlerbehafteten Symbole. Weiterhin muss unterschieden werden, ob ein Symbol unbekannterweise beschädigt wurde, oder ob es verloren gegangen ist bzw. bekannt ist, dass es fehlerhaft ist. Ob ein einzelnes Bit oder mehrere Bits in einem Symbol falsch sind, ist nicht relevant. Solange höchstens k Symbole bei einer Übertragung verloren gegangen sind bzw. bekannter weise beschädigt wurden können die Ursprungsdaten sicher wiederhergestellt werden. Ebenfalls sicher wiederherstellen kann der Decoder die Daten, solange höchstens k/2 Symbole fehlerhaft sind, ohne dass dies bekannt ist. Treten fehlerhafte und verlorene Symbole gleichzeitig auf, so muss gelten [16]: 2 ; , Treten mehr Fehler auf, so können die Originaldaten nicht wiederhergestellt werden. Da die Anzahl k der Paritätssymbole variabel gewählt werden kann, ist es möglich die Redundanz und somit die Fehlertoleranz auf Kosten eines höheren Overheads zu steigern. Die Berechnungen zum Codieren und Decodieren mit Hilfe der Paritätssymbole basieren auf der Theorie von Galois‐Feldern, wobei besonders das Dekodierverfahren sehr rechenintensiv ist und daher in Hardware implementiert werden sollte. 6 Zusammenfassung Die untersuchten Protokolle zeigen, dass bei den IE‐Systemen ähnliche Grundprinzipien vorherrschen, welche auf unterschiedliche Art und Weise umgesetzt werden. So findet sich bei mehreren Lösungen das Prinzip des gemeinsamen Speichers wieder und alle Systeme benötigen einen Master oder ein vergleichbares Management‐System, welches die Kommunikation regelt. Der zusätzliche manuelle Konfigurationsaufwand am Master, der beim Austausch von Geräten oder der Integration neuer Geräte anfällt, unterscheidet sich je nach IE‐System, wobei generell angestrebt wird diesen Aufwand gering zu halt und im laufenden Betrieb zu ermöglichen, um Produktionsanlagen flexibel zu halten. Gemeinsam haben die Lösungen jedoch, dass eine Erkennung neuer Geräte seitens des Masters erfolgen muss, um den Kommunikationsmechanismus anzupassen und die neue Station in Zeitschlitz‐, Polling‐ oder Token‐Verfahren aufzunehmen. Ein Netzwerk, in dem sich die Endknoten selbständig verwalten, wie es beim Kad‐Netzwerk angestrebt wird, existiert bei den echtzeitfähigen Ethernet Lösungen noch nicht. Eine weitere Gemeinsamkeit der Lösungen ist die Optimierung auf Prozessdaten, was sich besonders an einer relativ geringen Gesamtdatenmenge zeigt, welche jedoch möglichst oft aktualisiert wird. Diese Gesamtdatenmenge wird zudem in einer 27 oder mehreren Stationen vollständig gespeichert. In einem System zur verteilten Datenspeicherung werden dagegen wesentlich größere Datenspeicher benötigt und das Speichern aller Daten auf einer Station ist nicht mehr realisierbar, sondern jeder Knoten des Netzwerks kann nur für einen Teil der Daten zuständig sein. Das Adressierungsprinzip dieses Datenspeichers über logische Adressen (EtherCAT) oder Stationsnummern und Wort‐ und Bitadressen (CC‐Link IE Field) ist außerdem in einem P2P‐Netz nicht möglich, da die Anzahl der Netzwerkteilnehmer stets flexibel sein soll und kein Netzwerkteilnehmer die Speicherressourcen aller anderen Teilnehmer kennt. Auf Anwendungsebene bieten die IE‐Systeme weiterhin kein Protokoll, das zur verteilten Datenspeicherung verwendet werden kann. Stattdessen setzen die Systeme auf Protokolle der früheren Feldbussysteme, wie z.B. CANopen oder Servodrive. Aus diesen Gründen ist bei den IE‐Systemen nicht die nötige Flexibilität gegeben, um sie für ein P2P‐Netz bzw. zur verteilten Datenspeicherung zu verwenden. Eine Ausnahme stellt TTEthernet dar, welches es sich zum Ziel gesetzt hat, eine Echtzeit‐Ethernet Lösung zu bieten, ohne dabei die Art des Datenverkehrs auf den darüber liegenden Schichten einzuschränken. Es führt auf Anwendungsebene keine neuen Protokolle ein, sodass auch in diesem Fall keine verteilte Datenspeicherung vorgesehen ist. Eine Implementierung des TTEthernet Protokolls auf einem P2P‐Netzwerk ist auf Grund der nötigen Verwaltungsaufgaben (Master/Slave‐ basierte Synchronisierung, TT‐Zeitplanung) nicht möglich. Diese Arbeit zeigt, dass sich unter den derzeit bekannten Echtzeit Ethernet‐Technologien keine P2P‐ basierte Lösung befindet, und dass keines der bestehenden Systeme eine Lösung zur verteilten Datenspeicherung großer Datenmengen bietet. Mit Hilfe des CoAP‐Protokolls und der Reed Solomon Codes ist es jedoch möglich, ein echtzeitfähiges P2P‐Netzwerk wie HaRTKad, für das sich eine Datenübertragung in Zeitschlitzen in der Entwicklung befindet, so zu erweitern, dass es zur verteilten Datenspeicherung geeignet ist. Abbildung 9 zeigt den vorgesehenen Protokoll‐Stack eines solchen Systems. Abbildung 9: Protokoll‐Stack eines HaRTKad‐Systems mit CoAP‐Implementierung und Zeitschlitzen Das Kad‐ bzw. HaRTKad‐Protokoll sowie das CoAP Protokoll und Reed Solomon befinden beide auf der Anwendungsebene, da sie zu unterschiedlichen Zeitpunkten verwendet werden sollen und für unterschiedliche Funktionen zuständig sind. Das HaRTKad‐Protokoll organisiert das P2P‐Netzwerk und übernimmt die normalen Kad‐Wartungsaufgaben sowie die durch HaRTKad hinzugefügten Synchronisierungsmechanismen. Diese Aufgaben finden in den dafür vorgesehenen Phasen (siehe Kapitel 3) statt und sind daher nicht an Zeitschlitze gebunden. Andere Kad‐Operationen wie z.B. der Lookup sollen in der Phase des Datenaustauschs stattfinden und sollen daher ebenso wie die Übertragung der Nutzdaten mit Hilfe von CoAP und Reed‐Solomon die Zeitschlitze nutzen. CoAP ist 28 dabei ein effizientes Protokoll auf Anwendungsebene, dessen Funktionen an etablierte Protokolle (z.B. HTTP) angelehnt sind, welches zur Organisation der Daten im Netzwerk verwendet werden kann. Die Reed Solomon Codes bieten zudem eine zuverlässige Methode der Datensicherung durch Redundanz, welche sich bereits in den Bereichen Audio CDs, DVDs, DAB, DVB und Mobilfunk bewährt hat. 29 I. Abbildungsverzeichnis Abbildung 1: Ablauf eines Zyklus' von Ethernet Powerlink [5] ............................................................. 10 Abbildung 2: Aufbau eines EtherCAT Frames [6] .................................................................................. 12 Abbildung 3: Protokollaufbau mit EtherCAT [6] .................................................................................... 13 Abbildung 4: TCnet Frame zyklischer Daten [9] .................................................................................... 15 Abbildung 5: TCnet Prinzip des gemeinsamen Speichers [9] ................................................................ 15 Abbildung 6: Ein erfolgreiches und ein gescheitertes GET Request mit "piggy‐backed" Response [14] ............................................................................................................................................................... 23 Abbildung 7: GET Request mit separater Antwort [14] ........................................................................ 24 Abbildung 8: Aufbau des CoAP Protokolls [14] ..................................................................................... 25 Abbildung 9: Protokoll‐Stack eines HaRTKad‐Systems mit CoAP‐Implementierung und Zeitschlitzen 28 II. Tabellenverzeichnis Tabelle 1: CC‐Link IE Field Prozessdatentypen ...................................................................................... 19 Tabelle 2: Übersicht über die vorgestellten IE‐Systeme ....................................................................... 21 Tabelle 3: Reed Solomon Bezeichner .................................................................................................... 27 30 III. Literaturverzeichnis [1] F. Klasen, V. Oestreich und M. Volz, Industrielle Kommunikation mit Feldbus und Ethernet, Berlin: VDE Verlag GmbH, 2010. [2] G. C. Buttazzo, Hard Real‐Time Computing Systems, New York: Springer Science+Business Media, LLC, 2011. [3] J. Skodzik, P. Danielis, V. Altmann und D. Timmermann, „Time Synchronization in the DHT‐based P2P Network Kad for Real‐Time Automation Scenarios,“ University of Rostock, Rostock, 2013. [4] Ethernet Powerlink Standardization Group, „Powerlink Communication Profile Specification V1.1.0,“ [Online]. Available: http://www.ethernet‐ powerlink.org/index.php?id=12&tx_abdownloads_pi1[action]=getviewclickeddownload&tx_abd ownloads_pi1[uid]=48&no_cache=1. [Zugriff am 2 Mai 2013]. [5] Ethernet Powerlink Standardization Group, „Ethernet Powerlink,“ [Online]. Available: http://www.ethernet‐powerlink.org. [Zugriff am 2 Mai 2013]. [6] EtherCAT Technology Group, „EtherCAT Technical Introduction and Overview,“ [Online]. Available: http://www.ethercat.org/en/technology.html. [Zugriff am 25 April 2013]. [7] EtherCAT Technology Group, „EtherCAT ‐ the Ethernet fieldbus,“ [Online]. Available: http://www.ethercat.org/pdf/ethercat_e.pdf. [Zugriff am 9 Mai 2013]. [8] Beckhoff Information System, „EL66xx und Ethernet‐Transport über Mailbox‐Kommunikation,“ [Online]. Available: http://infosys.beckhoff.de/index.php?content=../content/1031/EL6601_EL6614/HTML/Bt_EL66 01_EL6614_RealtimeNo.htm&id=. [Zugriff am 6 Mai 2013]. [9] Toshiba, „TCnet Technology,“ [Online]. Available: http://www.toshiba.co.jp/sis/en/seigyo/tcnet/technology.htm. [Zugriff am 1 Mai 2013]. [10] M. Felser, „Real ‐ Time Ethernet ‐ Industry Prospective,“ [Online]. Available: http://www.control.aau.dk/~ppm/P7/distsys/01435742.pdf. [Zugriff am 1 Mai 2013]. [11] TTA ‐ Group, „TTEthernet ‐ A Powerful Network Solution for All Purposes,“ [Online]. Available: http://www.ttagroup.org/ttethernet/doc/TTEthernet_Article.pdf. [Zugriff am 30 April 2013]. [12] CC‐Link Partner Association, „CC‐Link IE Field Brochure,“ [Online]. Available: http://www.cclinkamerica.org/functions/dms/getfile.asp?ID=045000000000000001000009146 100000. [Zugriff am 9 Mai 2013]. [13] CC‐Link Partner Association, „ CC‐Link IE Field White Paper (CLPA‐2327),“ [Online]. Available: http://www.cclinkamerica.org/functions/dms/getfile.asp?ID=045000000000000001000007488 300000. [Zugriff am 9 Mai 2013]. 31 [14] IETF CoRE Working Group, „ Constrained Application Protocol (CoAP),“ [Online]. Available: http://datatracker.ietf.org/doc/draft‐ietf‐core‐coap/?include_text=1. [Zugriff am 29 April 2013]. [15] IETF CoRE Working Group, „Blockwise transfers in CoAP,“ [Online]. Available: http://tools.ietf.org/html/draft‐ietf‐core‐block‐11. [Zugriff am 29 April 2013]. [16] M. Riley und I. Richardson, „An introduction to Reed‐Solomon codes: principles, architecture and implementation,“ [Online]. Available: http://www.cs.cmu.edu/afs/cs.cmu.edu/project/pscico‐ guyb/realworld/www/reedsolomon/reed_solomon_codes.html. [Zugriff am 2 Mai 2013]. [17] B. Sklar, „Reed‐Solomon Codes,“ [Online]. Available: http://hscc.cs.nthu.edu.tw/~sheujp/lecture_note/rs.pdf. [Zugriff am 2 Mai 2013]. [18] EtherCAT Technology Group, „EtherCAT Introduction,“ [Online]. Available: http://www.ethercat.org/pdf/english/EtherCAT_Introduction_EN.pdf. [Zugriff am 6 Mai 2013]. 32 IV. Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt habe und keine anderen als die angegebenen Hilfsmittel verwendet habe. Die aus Quellen direkt oder indirekt übernommenen Teile der Arbeit sind als solche kenntlich gemacht. Diese Arbeit wurde bisher nicht veröffentlich oder in gleicher oder ähnlicher Form einer anderen Prüfungsbehörde vorgelegt. Ort, Datum Unterschrift 33