3.4 Echtzeit-Ethernet-Kommunikation

Transkript

1 174 3 Konfiguration und Planung 3.4 Echtzeit-Ethernet-Kommunikation Allgemeine Situation Für die zukünftigen Standards zur Echtzeitkommunikation auf der Basis von Ethernet gibt es unterschiedliche Anforderungen in Bezug auf die Hardware der Steuerungen, der I/O- Endgeräte und auf die zu verwendende Infrastruktur. Dabei ist zu berücksichtigen, dass die verschiedenen Architekturen auch auf unterschiedlichen Techniken der Ethernet-Kommunikation aufsetzen. So setzt EtherNet/IP eine besonders leistungsfähige Switch-Technologie voraus, dafür ist die Umsetzung in den I/O-Komponenten vergleichsweise einfach. Powerlink dagegen verlangt als Infrastruktur die Hub-Technologie, da man davon ausgeht, dass durch die zeitlich geregelte Abfolge der Kommunikation keine Kollisionen auftreten. Bei Ethercat und bei Profinet IRT werden spezielle ASICs in die Netzwerkteilnehmer implementiert, die das Senden der Teilnehmerdaten zu vorher verhandelten Zeitpunkten zulassen, sodass hier harte Echtzeitkommunikation möglich ist. Wann ein System echtzeitfähig ist, ist grundsätzlich abhängig von den Anforderungen der jeweiligen Applikation. Dabei werden die klassischen Feldbusse wie Profibus, Interbus oder DeviceNet / CAN heute als echtzeitfähig bezeichnet. Dabei ist die Echtzeitfähigkeit in allen Fällen eine Frage der Definition. Wenn die Signale und die dabei entstandenen Reaktionszeiten für die Aufgabe ausreichend sind, wird das als Echtzeit bezeichnet. Wenn in dieser Zeit auch noch ein absoluter Determinismus eingehalten wird, bezeichnet man die Systeme als hart echtzeitfähig. Mit einem deterministischen System wie Sercos und Interbus kann ein CPU-Signal bis auf eine systembedingte Abweichung (dem Jitter) auf einige, wenige Mikrosekunden berechnet werden. Gerade in diesem Zusammenhang der Echtzeitfähigkeit und auch dem Determinismus offenbart das Ethernet mit seiner Standard- TCP/IP-Kommunikation seine größten Schwächen. Man kann also sagen, dass die Fähigkeit eines Systems, unter allen Umständen und in allen Betriebsbedingungen auf alle Ereignisse korrekt und rechtzeitig zu reagieren, als Echtzeitfähigkeit bezeichnet werden kann. Üblicherweise übersetzt man die Anforderung nach Echtzeit-Fähigkeit mit einer garantierten Antwortzeit. Außerdem wird häufig zwischen harten und weichen Echtzeit-Anforderungen einer Anwendung unterschieden. Dabei wird eine Anforderung dann als harte Echtzeit-Anforderung eingestuft, wenn deren Verletzung eine Fehlfunktion in der Anwendung verursacht. Dagegen führt die Verletzung einer weichen Echtzeit-Anforderung lediglich zu einem Verlust der Leistungsfähigkeit. In einem System aus verteilten Komponenten spielen nicht nur die Eigenschaften der Komponenten, sondern auch die Eigenschaften des verwendeten Busses zwischen den Teilnehmern eine wichtige Rolle. Als anzurechnende Größen sind Parameter des Kommunikationssystems zu betrachten, wie Netto-Durchsatz (Bandbreite), Latenzzeit, Abweichung der Latenzzeit (Jitter) und Synchronfähigkeit. Als besonders kritisch erweisen sich die Anforderungen an die Synchronität verschiedener, an einer Aufgabe beteiligter Netzknoten, die Operationen auch zeitgleich, d. h. simultan, ausführen müssen Basis für echtzeitfähige Systeme Grundsätzlich sollte ein System bestimmte Voraussetzungen erfüllen, um bei Nutzung von Ethernet echtzeitfähige Bedingungen realisieren zu können. Dabei ist zu berücksichtigen,

2 3.4 Echtzeit-Ethernet-Kommunikation 175 dass ein System dann echtzeitfähig ist, wenn die eingesetzten Komponenten über die entsprechenden Voraussetzungen verfügen: Die Endgeräte müssen Informationen innerhalb einer vorgegebenen Zeit verarbeiten. Die Datenübertragung zwischen den Teilnehmern muss in einer deterministischen Zeit erfolgen. Der ursprüngliche CSMA/CD-Ansatz des Ethernet ist ungeeignet, da Kollisionen und damit Zeitverzögerungen nicht auszuschließen sind. Gegenwärtig gibt es unterschiedliche Strategien, um ein deterministisches Zeitverhalten bei der Kommunikation zwischen zwei Knoten mit Ethernet zu erreichen: Die Netzauslastung wird stark reduziert, um auf diese Weise die Kollisionswahrscheinlichkeit gering zu halten. Da Ethernet über eine für viele Anwendungen ohnehin viel zu üppige Bandbreite verfügt, kann die geringe Effizienz meist toleriert werden. Ethernet erlaubt Vollduplex-Kommunikation zwischen zwei Knoten über getrennte Sende- und Empfangskanäle. Hierbei wird die Kollisionsüberwachung in den Knoten deaktiviert, so dass zu jedem beliebigen Zeitpunkt störungsfrei bis zum nächsten Knoten übertragen werden kann. Die Verteilung der Ethernet-Telegramme durch Switches muss in einer festen Zeit abgewickelt werden. Dabei sind einige Besonderheiten zu berücksichtigen. Die Weiterleitungszeit kann von der Netzauslastung abhängen, da die Ethernet-Frames zwischen Einund Ausgangsspeicher sortiert werden müssen und die Gesetzmäßigkeit der Warteschlangentheorien zur Anwendung kommen kann. Dies gilt besonders dann, wenn Datenpakete aus unterschiedlichen Verbindungen gebündelt werden müssen. Das können beispielsweise Daten sein, die in Echtzeit zur Steuerung geroutet werden sollen, und Telegramme die Ein- und Ausgangsdaten für eine Visualisierung auf dem Standard- TCP/IP-Pfad bereitstellen sollen. Eine Möglichkeit, um den Engpass der Warteschlangen zu entschärfen, besteht in der Priorisierung der zu übertragenden Pakete. IEEE P ist eine Erweiterung der für die Verwendung von virtuellen LANs (VLAN) in IEEE Q spezifizierten Erweiterungen der Ethernet-Frames Q beschreibt einen 32 Bit langen VLAN-Tag, der dem MAC-Rahmen hinzugefügt wird und sowohl die zwölf Bit lange VLAN-ID als auch eine drei Bit lange Prioritätskennung enthält. Diese Kennung unterscheidet somit acht Prioritätsstufen, die in IEEE 802.1P festgelegt sind. Diese acht Bit können also zur Priorisierung genutzt werden, um die Echtzeitdaten als hochpriore Informationen schnell zur Steuerung zu leiten. Dieses Verfahren gibt es auch in herkömmlichen EDV-Netzen, beispielsweise um Video- oder Voice over IP- Anwendungen zu realisieren. Diese Daten müssen ebenfalls auf dem Weg durch die Infrastruktur innerhalb der Switches als hochprior erkannt werden, und niederpriore Telegramme müssen gegebenenfalls innerhalb eines Switch in einem geeigneten, internen Speicherbereich (seiner Queue) zwischengepuffert werden. Dieser Mechanismus greift in Netzwerken allerdings erst ab einer Netzlast größer als 50 % und wird daher nur in bestimmten Architekturen eine Rolle spielen. Auch Profinet-RT-Daten sind priorisiert, und zwar mit der höchstmöglichen Stufe von Sieben.

3 176 3 Konfiguration und Planung Bild 3.18 Priorisierung von Datenströmen In Netzen mit redundanten Pfaden müssen Broadcast-Stürme verhindert werden. Die automatische Konfiguration der Netze kann auf der Basis des Spanning Tree Protocol (STP) unter Umständen einige Minuten in Anspruch nehmen. Die Weiterentwicklung dieses Algorithmus ist in der IEEE 802.w verabschiedet und ist unter dem Namen Rapid Reconfiguration Spanning Tree oder Fast Spanning Tree realisiert. Mit Hilfe dieses Algorithmus ist eine Umschaltzeit innerhalb weniger Sekunden möglich. Spanning Tree Das Spanning Tree Protocol (STP) dient zur Vermeidung redundanter Netzwerkpfade (Schleifen) im LAN, speziell in geswitchten Umgebungen. Es ist in der IEEE-Norm 802.1D standardisiert. Netzwerke dürfen zu jedem möglichen Ziel immer nur einen aktiven Pfad haben, um zu vermeiden, dass Datenpakete dupliziert werden und mehrfach am Ziel eintreffen, was zu Fehlfunktionen in darüber liegenden Netzwerkschichten führen könnte und die Leistung des Netzwerks vermindern kann. Auf der anderen Seite ist es gerade gewünscht, dass redundante Netzwerkpfade als Backup für den Fehlerfall zur Verfügung stehen. Der Spanning-Tree-Algorithmus wird beiden Bedürfnissen gerecht. Zur Kommunikation zwischen den Bridges wird das Bridge Protokoll genutzt. Die Pakete dieses Protokolls werden Bridge Protocol Data Unit (BPDU) genannt.

4 3.4 Echtzeit-Ethernet-Kommunikation 177 Bild 3.19 Beispiel-Kommunikation zweier Teilnehmer Zunächst wird unter den Spanning-Tree-fähigen Switches im Netzwerk eine sogenannte Root Bridge gewählt, die als Wurzel im Netzwerk arbeitet. Das kann beispielsweise ein Switch sein, der vom Projektierer leicht erreichbar ist oder der an exponierter Stelle im Netzwerk zur Verfügung steht. Bild 3.20 Schleifenbildung ohne Spanning-Tree-Algorithmus

5 178 3 Konfiguration und Planung Bild 3.21 Festlegung der Rootbridge Dies geschieht, indem alle Bridges ihre Bridge-ID (die jede Bridge besitzt) an eine bestimmte Multicast-Gruppe mitteilen. Die Bridge mit der niedrigsten ID wird zur Root Bridge. Sollte die ID identisch sein, wird als nächstes Kriterium die MAC-Adresse der Komponenten benutzt. Von der Root Bridge aus werden die Pfade festgelegt, über die die anderen Bridges im Netzwerk erreichbar sind. Sollten redundante Pfade vorhanden sein, werden die Switches den entsprechenden Port deaktivieren. Die Pfade, über die kommuniziert werden darf, werden anhand von Pfadkosten bestimmt, die die dortige Bridge übermittelt. Die Kosten sind abhängig vom Abstand zur Root Bridge und dem zur Verfügung stehenden Uplink zum Ziel. Ein 10 MBit/s-Uplink hat beispielsweise höhere Pfadkosten als ein 100 MBit/s-Uplink zum gleichen Ziel und würde dabei nicht berücksichtigt. Auf diese Weise ist jedes Teilnetz im geswitchten LAN nur noch über eine einzige, die Designated Bridge erreichbar. Die Root-Bridge teilt den in der Hierarchie eine Stufe unterhalb liegenden Designated Bridges im Abstand von zwei Sekunden mit, dass sie noch da ist, woraufhin die empfangende Designated Bridge ebenfalls an nachfolgende Bridges die entsprechende Information senden darf. Wenn diese Hello-Pakete ausbleiben, hat sich folglich an der Topologie des Netzwerks etwas geändert und das Netzwerk muss sich reorganisieren. Diese Neuberechnung des Baums kann bis zu 30 Sekunden in Anspruch nehmen.

6 3.4 Echtzeit-Ethernet-Kommunikation 179 Bild 3.22 Festlegung der Root-Bridge Während dieser Zeit dürfen die Spanning-Tree-fähigen Bridges außer Spanning-Tree- Informationen keine Pakete im Netzwerk weiterleiten. Dies ist einer der größten Kritikpunkte am Spanning Tree-Algorithmus, da es möglich ist, mit gefälschten Spanning-Tree- Paketen eine Topologieänderung zu signalisieren und das gesamte Netzwerk für bis zu 30 Sekunden lahmzulegen. Um diesen potenziellen Sicherheitsmangel zu beheben, aber auch, um bei echten Topologieänderungen das Netzwerk schnell wieder in einen benutzbarem Zustand zu bringen, wurden schon früh von verschiedenen Herstellern Verbesserungen am Spanning-Tree-Algorithmus und dem dazugehörigen Protokoll erdacht. Eine davon, das Rapid Spanning Tree Protocol (RSTP) ist inzwischen zum offiziellen IEEE-Standard 802.1w geworden. Die Idee hinter RSTP ist, dass bei signalisierten Topologieänderungen nicht sofort die Netzwerkstruktur gelöscht wird, sondern erst einmal weiter gearbeitet wird und Alternativrouten berechnet werden. Erst danach wird ein neuer Baum zusammengestellt. Die Ausfallzeit des Netzwerks lässt sich so von 30 Sekunden auf unter eine Sekunde reduzieren. Bild 3.23 Abschaltung der redundanten Pfade