PriorityChannel: Was steckt hinter der Technologie? Robuste Industrial Ethernet-Geräte entwickeln mittels PriorityChannel

Industrial Ethernet-Anwendungen mit Protokollen wie Profinet RT, Ethernet/IP oder ModbusTCP können nicht nur in isolierten Teilnetzen exklusiv betrieben werden. Gerade ihr Vorteil, dass sie ohne weitere Vorkehrungen wie spezielle Gateways oder nur über den Umweg der Steuerung mit Standard TCP/IP kompatibel sind, macht ihre Beliebtheit im Anlagenbau aus. Dadurch wird es dem Anwender ermöglicht, in seiner Automatisierungszelle auch Geräte einzusetzen, die z.B. direkt mit einem Qualitätsmanagement- oder Produktionsplanungsystem kommunizieren, ohne den Umweg über die Steuerung. Profinet RT und Ethernet/IP ermöglichen in solchen heterogenen Anwendungen auch anspruchsvolle Echtzeitanwendungen bis herunter zu Zykluszeiten im Bereich von einstelligen Millisekunden. Um die nötige Vorfahrt im Netz zu erhalten, bedienen sich diese Protokolle etablierter Standards aus der IT-Welt, den Quality of Service (QoS) Diensten. Es gibt mehrere populäre Wege, QoS zu Implementieren. Zwei Methoden kommen bevorzugt zum Einsatz. Quality of Service für virtuelle Netzewerke Bei QoS nach IEEE802.1Q wird einem Nutzlasttelegramm (z.B. einem TCP/IP-Paket oder einem Profinet-Telegramm) im Ethernet-Telegramm ein kleines Datenpaket vorangestellt, das sogenannte VLAN-Tag (16Bit-Wort). Es dient u.a. dazu, virtuelle Netzwerke innerhalb eines physischen Ethernet-Netzes einzurichten. Diese Eigenschaft interessiert hier allerdings weniger. Aber: Das VLAN-Tag hat ein Feld, in dem eine Telegrammpriorität festgelegt werden kann. Professionelle industrietaugliche Switche unterstützen heute 802.1Q in der Regel. Wenn dies alle Switche im Netz beherrschen, kann diese Priorität genutzt werden, um den Echtzeitdaten bevorzugte Weiterleitung zu garantieren. QoS nach IEEE802.1Q ist ein Protokoll der Sicherungsschicht und seine Auswirkungen sind auf das physikalische Netz beschränkt. Das bedeutet, dass 802.1Q QoS nicht über Router in das Internet weitergegen werden kann. Da das Profinet-Echtzeittelegramm dazu auch nicht vorgesehen ist, ergänzen sich die Protokolle harmonisch. Wie funktioniert das bei Ethernet/IP? Einen anderen Weg geht Ethernet/IP. Hier wird das Service Differentiation Field (DSCP) des Internet Protocol (IP) Headers benutzt. Das ist möglich und sinnvoll, weil Ethernet/IP immer über IP mit TCP und UDP als Transportprotokoll betrieben wird. Das ist ein Unterschied zu Profinet, das ja ein eigenes Telegrammformat für die Echtzeitnachrichten auf Ethernet-Ebene definiert. DSCP ist ein QoS-Protokoll der Vermittlungsschicht und kann daher durchaus über Router hinweg, theoretisch sogar bis ins Internet genutzt werden. Allerdings ist dann keine Echtzeitperformance im Bereich von Millisekunden mehr zu erwarten. Gute Switche unterstützen auch DSCP. Ganz ohne IEEE802.1Q QoS muss man aber auch bei Ethernet/IP nicht leben. Sollte die Infrastruktur dieses fordern, kann man optional QoS nach IEEE802.1Q auch bei Ethernet/IP-Geräten aktivieren. Allerdings werden Ethernet/IP-Geräte immer mit ausgeschaltetem IEEE802.1Q ausgeliefert. Egal welches QoS-Protokoll genutzt wird, beide stellen sicher, dass Echtzeittelegramme im Netzwerk vorrangig behandelt werden. Und damit ist das Problem der Echtzeit erst mal auf Seiten des Netzes gelöst. Wo kommt nun PriorityChannel ins Spiel? Was im Gerät bei der Übertragung passiert Mikrocontroller, die heute in Feldgeräten eingesetzt werden, sind zwar noch weit von der Leistungsfähigkeit eines aktuellen PC oder auch nur eines guten Smartphones entfernt. Allerdings nur nach heutigen Maßstäben. Ein PC aus den 90er-Jahren hätte heute Mühe, mit manchem Feldgerät noch mitzukommen. Aber selbst mit so schnellen Mikrocontrollern kann es schwierig werden, mit einer 100MBit/s-Ethernet-Schnittstelle mitzuhalten. Dazu zwei kurze Rechnungen: Die minimale Telegrammlänge ist für Fast Ethernet (100MBit/s) auf 64Byte festgesetzt. Sollten noch weniger Nutzdaten übertragen werden, muss das Telegramm künstlich auf 64Byte verlängert werden. Zu den 64Byte kommen noch eine Preamble – ein Wechsel von Nullen und Einsen, um das Gegenüber auf die eigene Phasenlage einzuschwingen – von 8Byte und eine fest definierte Lücke von 12Bytes zwischen Telegrammen. Macht also 84Byte. Bei 100MBit/s dauert ein solches minimales Telegramm also nur (84*8) / 100Bit/µs = 6,72µs. Oder anders ausgedrückt: Pro Sekunde können bis zu 100.000.000 / (84*2) = 148.809 Telegramme versendet werden. Bei maximaler Telegrammlänge von 1.518Byte dauert ein Telegramm hingegen (1.538*8) / 100Bit/µs = 123µs. Das bedeutet auch: 8.127 solcher langen Telegramme können pro Sekunde übertragen werden. Ein Feldgerät würde, trotz aller Geschwindigkeitsgewinne der vergangenen Jahre, noch zahlreiche Probleme bekommen, sollte es über längere Zeiträume mit vielen Telegrammen bombardiert werden. Im Prinzip sollte nur der zyklische Echtzeitverkehr im Gerät behandelt werden müssen. Damit ist die Last des Gerätes ja begrenzt, und das Gerät sollte der Gefahr entzogen sein. Dem ist aber nicht so. Die Gefahr kommt aus zwei Richtungen. 1. Störungen aus dem Bereich der IT Teilnehmer im Ethernet können entweder direkt angesprochen werden (Unicast), als Gruppe (Multicast) oder einfach \’an alle\‘ (Broadcast). Während praktisch jeder Mikrocontroller mit Ethernet-Schnittstelle seine persönliche Unicast-Adresse ausfiltern kann, sind die Möglichkeiten zum Ausfiltern von Multicasts oft begrenzt. Bei Broadcast aber fehlen Filter in der Hardware meist völlig. Dazu kommt, dass die Protokolle der Infrastrukturverwaltung des Netzes (Bild 2) z.T. auf diese Broadcasts zurückgreifen, um z.B. die Zuordnung von Internet-Adressen (IP-Adressen, 4Byte) und Ethernet-Adressen (MAC-Adressen, 6Byte) zur Laufzeit auszuhandeln. Das zugehörige Address Resolution Protocol (ARP) verwirft periodisch diese Zuweisungen und dann kann es zu sogenannten ARP-Storms kommen (Bild 3). Und von vielleicht 100 ARP-Telegrammen, die das Gerät dann verarbeiten muss, ist höchstens eines wirklich für das Gerät bestimmt. Solche und ähnliche Fälle müssen in Software behandelt werden. Wenn das Gerät auch damit fertig wird, so kann doch der Echtzeitverkehr soweit gestört werden, dass die Zykluszeit erheblich abweicht und der Jitter ansteigt. Untersuchungen haben gezeigt, dass der Jitter so stark steigen kann, dass die eigentliche Zykluszeit nicht mehr eingehalten werden kann. In extremen Fällen wurden sogar Geräteausfälle beobachtet. 2. Auch das noch: Der Webserver im Gerät Geräteentwicklung bedeutet heute auch, dass neben dem Echtzeitprotokoll häufig erweiterte Diagnose- und Inbetriebnahme-Möglichkeiten gewünscht werden. Das Gerät sollte einen Webserver bieten, über den z.B. erweiterte Herstellerinformationen, Diagnosedaten und Informationen zum Lebenszyklus abgerufen werden können. Darüber hinaus lassen sich noch andere IP-Anwendungen nützlich einsetzen. Und diese Dienste sollen jederzeit, auch während der Echtzeitverkehr läuft, abrufbar sein. Zusätzliche IP-Verkehre auf dem gleichen Gerät bedeuten weiteren Jitter. Das Feldgerät wird belastet, und trotz moderner Mikrocontroller benötigen Taskwechsel immer noch ihre Zeit. Quality of Service vom Sensor und zum Aktor Die PriorityChannel-Technologie von Innovasic setzt genau bei diesen Problem an. PriorityChannel bedeutet die logische Fortführung von QoS innerhalb des Feldgerätes. Um das zu realisieren, sind drei Komponenten notwendig: 1. ein Mikrocontroller mit hoher Echtzeitleistung, 2. eine Möglichkeit, priorisierte Telegramme früh zu erkennen und in separaten Warteschlangen an die Anwendung zu übergeben, und 3. ein leistungsfähiger Adressfilter. Der von Innovasic entwickelte Kommunikationscontroller fido1100 bietet diese Optionen und eignet sich damit als Grundlage für die Entwicklung von Ethernet/IP- oder Profinet-Feldgeräten mit PriorityChannel. Notwendige Eigenschaften des Adressfilters Der Adressfilter des Kommunikationscontroller verfügt über bis zu 256 Einträgen. Damit lassen sich exakt die Unicast- und Multicast-Adressen ausfiltern, die für das Gerät relevant sind. Gerade bei Ethernet/IP, das intensiv das Konzept der Multicast-Telegramme nutzt, macht sich dieser Filter als Vorteil bemerkbar. Priorisierte Telegramme rechtzeitig filtern können Priorisierte Telegramme früh zu erkennen, wird ermöglicht durch den Universal I/O Controller (UIC) (Bild 4). Fido 1100 verfügt über vier solcher Einheiten. Jede UIC ist eine programmierbare RISC Engine, mit deren Fähigkeiten die Ethernet-Schnittstelle des fido1100 implementiert wird. Da die UIC frei programmierbar ist, kann hier für jedes Protokoll ein optimierter Filter implementiert werden. Die Profinet-Implementation erkennt so am Ethernet-Protokoll Type (EtherType) Echtzeittelegramme und kann diese in eine eigene Warteschlange einreihen und den zugehörigen Prozess starten. Bei Ethernet/IP ist der Vorgang komplexer. Hier muss die UIC erst erkennen, dass es sich um ein IP-Telegramm handelt, das ein UDP-Paket enthält, das an den Ethernet/IP Echtzeitport gerichtet ist. Aber auch das geht ohne Zeitverlust. Diese Auftrennung erfolgt also nicht primär anhand der QoS-Daten, sondern nach Art der Kommunikation. Die UIC trennt Echtzeitkanäle von Nicht-Echtzeitkanälen. Daher kommt auch der Name PriorityChannel für die gesamte Technologie. Aufgaben des Controllers – vor allem ohne Verzögerung Nachdem nun schon das meiste ausgefiltert wurde und die Spreu (nicht Echtzeit) vom Weizen (Echtzeit) getrennt wurde muss nun noch der eigentliche Controller schnell reagieren und ohne weitere Verzögerungen die Verarbeitung der Echtzeitpakete aufnehmen. Auch hier bietet fido1100 die nötige Unterstützung. Sein auf Hardware-Multitasking ausgelegter Kern verfügt über fünf Hardware-Threads. Man kann sich jeden dieser Threads wie einen eigenständigen, virtuellen Mikrocontroller vorstellen. Die Umschaltung zwischen diesen Threads erfolgt innerhalb von nur wenigen Buszyklen. Damit sind auf dem nur mit 66MHz getakteten Kommunikations-controller Umschaltzeiten zwischen diesen Threads möglich, die man bisher nur von wesentlich höher getakteten Prozessoren kannte. Erkennt die UIC also ein Echtzeittelegram, kann der Controller umgehend reagieren und mit der Behandlung beginnen. All diese Eigenschaften ermöglicht die PriorityChannel-Technologie (Bild 4). Der im Test gemessene Jitter unter Last beträgt bei Profinet nur 0,5% bei einer Zykluszeit von 2ms unabhängig vom Lastfall. Bei Ethernet/IP ist er z.Z. noch etwas höher, wird mit zukünftigen Optimierungen, aber in die gleiche Größenordnung zu bringen sein. PriorityChannel ermöglicht robuste Feldgeräte, die nicht beim ersten (ARP-) Sturm untergehen. Den Anwender nicht im Regen stehen lassen Robuste Feldgeräte sind nicht nur eine gute Methode, die eigenen Supportkosten klein zu halten. Sie sind auch ein Aushängeschild für die Leistungsfähigkeit von modernen Industrial Ethernet-Systemen wie Ethernet/IP und Profinet. Mit PriorityChannel lassen Gerätehersteller den Anwender nicht im Regen stehen. Kasten: Testprotokolle der Nutzerorganisationen