Mit der Version 2.3 der PROFINET-Spezifikation ist das Bestehen des Belastungstests (Payload-Test) verpflichtend geworden, um eine Zertifizierung zu erhalten. Können eingebettete MCUs diese Tests bestehen? Ja, wenn die Stack- und MCU-Hersteller ihre Hausaufgaben gemacht haben, wie dieser Artikel anhand der Renesas RX63N- und PROFINET-Stacks der port GmbH zeigt.
Keine Frage, mit dem Einzug von Industrial Ethernet in die Automatisierungswelt sind die Anforderungen an Rechenleistung und Implementierungskomplexität gestiegen. Während für einfache CANopen-Geräte ein 8-Bit-Prozessor mehr als ausreichend war, ist dies bei Protokollen wie PROFINET nicht der Fall.
Mitverantwortlich dafür sind einerseits die großen Datenmengen und andererseits die Vielseitigkeit der Dienste, die neben den Industrial-Ethernet-Protokollen auch Ethernet-Protokolle und die umfangreichen IP-basierten Protokolle bieten. .
Umso wichtiger ist es, diese Lasten parallel zur Standard-Steuerungskommunikation zu untersuchen.
Bevor wir diese Herausforderungen jedoch am Beispiel des RX63N bewerten, werfen wir einen Blick auf eine kurze Einführung in die allgemeinen Arten von Netzwerkverkehr und wie er von PROFINET verwendet wird.
Arten von Netzwerkverkehr
Um Lasttests besser zu verstehen, muss man sich zunächst überlegen, welche (falschen) Situationen welche Arten von Netzwerkverkehr verursachen könnten.
Indirekter Verkehr
Der auf den indirekten Verkehr bezogene Datenverkehr ist tatsächlich nicht für das zu testende Gerät bestimmt. Dabei kann es sich um Broadcast- (für alle Teilnehmer), Multicast- (für einige Teilnehmer) oder Unicast-Frames handeln. Broadcast- und Multicast-Frames im Netzwerk sind in die Ethernet-Schicht eingebettet und stehen daher jederzeit im Ethernet-Netzwerk zur Verfügung.
Was führt jedoch zu ungerichtetem Datenverkehr von Unicast-Frames? Dies geschieht in der Regel im Fehlerfall. Normalerweise adressiert ein Ethernet-Switch eine interne Adresstabelle. Empfängt der Switch einen Frame mit unbekannter MAC-Adresse, wird der Port, auf dem der Frame empfangen wurde, in der Adresstabelle aufgeführt. Dieses „Adresslernen“ ermöglicht es dem Switch, Unicast-Frames direkt an das Ziel zu senden und sie nicht wie im Fall von Broadcast-Nachrichten an alle Ports zu überfluten. Ist die Adresstabelle jedoch voll, versetzt zukünftiges Adresslernen den Switch in einen Failsafe-Modus: Frames werden wie beim Hub an alle Ports weitergeleitet. Dieses Verhalten wird durch das sogenannte „MAC Flooding“ (auch bekannt als Switch Jamming) gezielt ausgenutzt. Der Angreifer leitet tonnenweise Ethernet-Frames mit falschen Adressen weiter, bis die Switch-Tabelle voll ist. Hierfür reicht ein freier Ethernet-Port aus. Das Ziel des Angreifers ist es, absichtlich eine Überlastung zu erzeugen oder Informationen im gesamten Netzwerk zu lesen.
Direkten Verkehr
Beim direkten Verkehr handelt es sich um Verkehrsdaten, die vom Gerät gewollt sind und nicht wie beim indirekten Verkehr, wo sie vom Gerät fälschlicherweise weitergeleitet wurden. Diese Daten können per Unicast, Broadcast oder Multicast gesendet werden.
Bei diesem Datenverkehr können die Daten entweder von einer PROFINET-Verbindung oder von anderen Diensten wie einem auf dem Gerät laufenden HTTP-Server stammen. Darüber hinaus werden auch Daten aus gängigen Protokollen wie ARP verwendet. Diese Daten können sowohl in Echtzeit (RT) als auch in Nicht-Echtzeit (NRT) unterteilt werden. RT-Verkehr umfasst alles, was dazu dient, eine zyklische PROFINET-Verbindung aufrechtzuerhalten. Der NRT-Verkehr umfasst Daten aus dem PROFINET-Protokoll selbst sowie aus anderen Ethernet-Frames (z. B. IP-Verkehr).
Eine Frage der Architektur
Die MCU eines PROFINET-Geräts muss daher eine relativ hohe Anzahl von Frames bewältigen. Diese Last nimmt zu, wenn die Größe eines geplanten Netzwerks zunimmt. Insbesondere in der Anfangsphase eines Netzwerks kann es häufig vorkommen, dass Frames wie LLDP, ARP etc. sie platzen.
Sowohl Hardware als auch Software müssen richtig ausgelegt sein, um auch in diesen Situationen eine zuverlässige Kommunikation zu gewährleisten. Für ein praktisches Beispiel muss zunächst überlegt werden, welche Abfolge von Operationen notwendig ist, um eine zyklische PROFINET-Kommunikation abzuwickeln.
Abbildung 1 zeigt einen Ausschnitt aus einem Timing-Diagramm des PROFINET-Stacks der port GmbH auf einem Renesas RX63N. Die Daten wurden über das im Stack integrierte Tracking-Framework gewonnen. Zeigt chronologisch die Schritte des Hauptprozesses zum Übertragen eines RT-Frames.
Auf Embedded-Plattformen ohne Betriebssystem verwendet der Stack eine Timer-Routine, in der alle verwendeten Timer im Mikrosekunden-Takt auf ihren Ablauf überwacht werden. In Abbildung 1 veranschaulicht der OAL_timer dies mit einer grünen Linie. Zuerst wird der Timer für die zyklische Paketverarbeitung ausgeführt. Dies ist in Abbildung 1 von Cyclic mit der gelben Linie dargestellt. Bei Cyclic wird der nächste zu übertragende Frame zusammengestellt und an den Ethernet-Treiber übergeben. Wenn Cyclic beendet ist, können die restlichen Timer verarbeitet werden. In diesem Fall wird der nächste zu übertragende LLDP-Frame verarbeitet. LLDP (Link Layer Discovery Protocol) ist ein Layer-2-Protokoll, das die Nachbarschaftserkennung verwaltet und nicht nur in PROFINET verwendet wird. Der Frame wird auf der als LLDP gekennzeichneten Leitung generiert und durch den Ethernet-Treiber geleitet. Nachdem der Timer seine Aufgabe erfüllt hat, können noch zwei Ethernet-Interrupts identifiziert werden. Dies impliziert eine Bestätigung, dass die beiden Frames (zyklisch und LLDP) übertragen wurden. Das Ablesen des „Markers“ in der oberen rechten Ecke von Abbildung 1 (hervorgehoben durch ein rotes Rechteck) zeigt, dass die gesamte Aktion in nur 119 μs ausgeführt wird. Wenn auch die Unterbrechungsschaltung berücksichtigt worden wäre, würde die Zeit bei etwa 125 µs liegen. Der Timer-Interrupt wird etwa alle 1 ms ausgelöst. Damit kann der RX63N noch viel Rechenzeit aus dem PROFINET-Kommunikationsprozess herausnehmen, um die nächsten zu sendenden Daten zu verarbeiten. Auch können in diesem Zeitraum andere Dienste wie TCP für einen HTTP-Server verarbeitet werden.
Dies war ein einfaches Beispiel ohne zusätzliche Verkehrsdaten. Wie hätte sich das System verhalten, wenn zusätzliche Daten eingegangen wären?
Dazu werden mit dem Tool „tcpreplay“ zusätzlich vorab aufgezeichnete ARP-Pakete schnellstmöglich ins Netzwerk zurückgespielt. Dies ist in Abbildung 2 dargestellt. ARP-Pakete sind als häufig ausgelöster Ethernet-Interrupt (rote Linie) zu erkennen. Wie in der Abbildung zu sehen ist, wirkt sich der zusätzliche Datenverkehr jedoch stark auf die zyklische Kommunikation aus. Wie lässt sich das erklären? Zunächst benötigen Sie für diese Realisierung eine MCU, die Interrupt-Priorisierung und Interrupt ermöglicht. Diese Funktion ist im Renesas RX63 korrekt implementiert. Die Verarbeitung bzw. Generierung von zyklischen Frames ist der wichtigste Teil des Geräts, daher wurde dem Timer-Interrupt die höchste Priorität zugewiesen. Daher wird es auch ausgelöst, während das Gerät in der Ethernet-Interrupt-Routine damit beschäftigt ist, ein Paket zu verarbeiten, und es abbricht.
Zum anderen spielt hier eine intelligente Funktionalität der RX63N eine wichtige Rolle, die gerade bei dichter Datenlast im Ethernet-Netzwerk die CPU stark entlasten kann. Der RX63N ist mit einem eigenen DMA-Controller (EDMAC) für den Ethernet-Controller (ETHERC) ausgestattet. Dies entlastet die CPU von der Aufgabe, die zu sendenden oder zu empfangenden Ethernet-Frames zu kopieren. Mittels der Deskriptoren zeigt die CPU auf den Speicherbereich, in dem sich das zu übertragende Paket befindet oder in dem das empfangene Paket gespeichert werden soll. Die CPU kann dann die Pakete verarbeiten. Daher ist es möglich, ein Paket zu verarbeiten, während der EDMAC bereits andere Pakete empfängt oder sendet.
Perspektiven
Es besteht kein Zweifel, dass es in zukünftigen Belastungstests Bestandteil jedes Freigabetests, wenn nicht sogar jeder Zertifizierung sein wird. Dabei ist es wichtig, nicht nur die Kommunikation zu überprüfen, sondern auch Netzwerkfehlerzustände zu simulieren.
Bei PROFINET werden Belastungstests in naher Zukunft Teil der Zertifizierung werden. Bei Netzwerkbelastungstests werden neben den RT-Daten zusätzlich noch unterschiedliche Protokolle per Unicast, Broadcast, aber auch per Multicast in den Netzwerkverkehr eingespeist. Auf diese Weise werden unterschiedliche Belastungsstufen von normalem Netzwerkverkehr bis hin zu Netzwerküberlastung simuliert. Dies erfolgt in Abhängigkeit von der gewünschten Leistungsklasse (Netzlastklasse).
Andererseits müssen sowohl MCU- als auch Stack-Hersteller ihre Hausaufgaben machen. Sowohl die Software als auch die Hardware müssen auf mögliche Fehler vorbereitet sein, wie es bei der RX63N der Fall ist.
Was müssen Sie tun, um loszulegen?
Für einen unerfahrenen Benutzer mögen die vorherigen Abschnitte relativ kompliziert klingen. Für die ersten Schritte empfiehlt sich der Einsatz eines RSK (Renesas Starter Kit) RX63N, da zusammen mit dem PROFINET-Stack der port GmbH eine „Ready-To-Go“-Lösung angeboten wird, die hilft, die Entwicklung von Applikationen schnell durchzuführen und agil Prototypen. Als Entwicklungswerkzeuge stehen der Renesas E1 JTAG-Debugger und die Entwicklungsumgebung e2Studio zur Verfügung. Die e2Studio-Entwicklungsumgebung integriert alle notwendigen Tools zum Schreiben und Debuggen der Software. Die Demoanwendung enthält alle für das Projekt notwendigen Dateien, um somit zu einem reibungslosen Start des Starterkits beizutragen.
Der RSK enthält eine RX63N-MCU mit 2 MB On-Chip-Flash und 128 KByte On-Chip-RAM. Diese Produktgruppe mit 165 DMIPS und 100 MHz CPU- und Flash-Betrieb erreicht eine hohe Rechenleistung. Um es in unterschiedlichsten Produkten mit unterschiedlichen Profilen und Anforderungen einsetzen zu können, ist diese Produktgruppe hoch skalierbar. Die RX63N sind in Flash-Speicherversionen von 512 KByte bis 2 MB und RAM-Größen von 128 KByte bis 256 KByte erhältlich. Bei den Packages gibt es Versionen in verschiedenen Varianten: LQFP, LGA und BGA. Neben der IEEE 802.3 Ethernet MAC-konformen Schnittstelle mit Media Independent Interface (MII) und Reduced Media Independent Interface (RMII) zum einfachen Anschluss an einen PHY bieten diese Komponenten Controller Area Network (CAN) 2.0B-Schnittstellen mit bis zu drei Kanälen ( hier ist auch eine CANopen-Lösung der port GmbH verfügbar), zwei Universal Serial Bus (USB) Full Speed Hosts, USB OTG und Gerätefunktionen. Die RX sind darauf ausgelegt, eine hohe Integrationsdichte und attraktive Fabric-Kosten zu bieten, kombiniert mit extrem schneller eingebetteter Flash-Technologie. Daher sind sie die richtige Wahl für Anwendungen, die leistungsfähige Kommunikationsstacks benötigen, wie z. B. im PROFINET-Bereich mit Single-Chip-Lösungen, um den Einsatz externer Speicher zu vermeiden. Ausführliche Informationen zu diesem Thema können im Internet heruntergeladen werden und sind selbstverständlich im Starterkit enthalten.
Eine gute Kombination
Im RXMAX-Programm von Renesas bietet die Kombination aus der Renesas RX32N 63-Bit MCU und dem PROFINET-Port-Stack einen besonders attraktiven Einstieg in den Bereich der PROFINET-Anwendungen. Die Renesas RX63N MCU kann ohne Einschränkungen mit dem PROFINET-Port arbeiten, was die Entwicklung von leistungsstarken und kostengünstigen PROFINET I/O-Geräten (CC-A, RT-1) ermöglicht.
Der Kostenvorteil kann sich durch die vereinfachte Netzwerkstruktur auf Integratoren und deren Kunden erstrecken.
Grundsätzlich sind Lösungen wie CANopen, EtherNet/IP, POWERLINK und EtherCAT unter derselben Plattform möglich.
