Lasttests bei Industrial Ethernet

4. Dezember 2014, 11:11 Uhr | Von Bernd Westhoff, Marcus Tangermann und Frank Riemenschneider
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Eine Frage der Architektur

Die MCU eines Profinet-Gerätes wird also mit einer relativ hohen Anzahl unterschiedlicher Frames belastet. Diese Last nimmt mit der zunehmenden Größe eines projektierten Netzwerkes weiter zu. Insbesondere in der Startup-Phase eines Netzwerks können Frames wie LLDP oder ARP vermehrt als Burst auftreten.

Um auch in diesen Situationen eine zuverlässige Kommunikation zu gewährleisten, sollten sowohl Hardware als auch Software dafür ausgelegt sein. Für ein praktisches Beispiel soll daher erst einmal betrachtet werden, welche Abläufe für die Verarbeitung einer zyklischen Profinet-Kommunikation nötig sind.

Senden eines Profinet-Paketes.
Bild 1. Senden eines Profinet-Paketes.

Bild 1 zeigt einen Auszug aus dem Verlaufsabbild des Profinet-Stack der Firma Port auf einem Renesas RX63N. Die Daten wurden mit Hilfe des im Stack integrierten Tracing Framework gewonnen. Es zeigt den zeitlichen Verlauf der wichtigsten Verarbeitungsschritte zum Senden eines RT Frame.

Der Stack verwendet auf Embedded-Plattformen ohne Betriebssystem eine Timer-Routine, in der sämtliche verwendete Timer im ms-Takt auf Fälligkeit überprüft werden. Dies ist in Bild 1 durch OAL_timer mit einer grünen Linie gekennzeichnet. Zuerst wird der Timer für die zyklische Paketverarbeitung abgearbeitet. Dies ist in der Abbildung durch Cyclic mit gelber Linie dargestellt. In Cyclic wird der als nächstes zu versendende Frame zusammengestellt und an den Ethernet-Treiber übergeben. Ist Cyclic beendet, können weitere Timer abgearbeitet werden. In diesem Fall ist der nächste zu versendende LLDP Frame fällig. Bei LLDP (Link Layer Discovery Protocol) handelt es sich um ein Schicht-2-Protokoll zur Nachbarschaftserkennung, das nicht nur Anwendung bei Profinet findet. Innerhalb der als LLDP markierten Linie wird der Frame erzeugt und an den Ethernet-Treiber übergeben. Nach Beendigung des Timer sind noch zwei Aktivitäten beim Ethernet-Interrupt zu erkennen. Es handelt sich hierbei um die Bestätigung, dass die beiden Frames (zyklische Kommunikation und LLDP) versendet wurden. Am Marker oben rechts in der Abbildung (durch rotes Viereck gekennzeichnet) ist zu erkennen, dass die gesamte Aktion lediglich 119 µs in Anspruch genommen hat. Trägt man noch dem Kontextwechsel zwischen den Interrupts Rechnung, so dürfte die Zeit bei ca. 125 µs liegen. Die Taktung des Timer Interrupt liegt bei ca. 1 ms. Somit stellt der RX63N noch reichlich Rechenzeit außerhalb der Profinet-Kommunikation für die Verarbeitung der als nächstes zu sendenden Prozessdaten zur Verfügung. Weiterhin können in diesem Zeitraum andere Dienste, wie z.B. TCP für einen HTTP-Server, verarbeitet werden.

Verhalten bei Datenverkehr

Dies war ein einfaches Beispiel ohne zusätzlichen Datenverkehr. Wie verhält sich das System, wenn zusätzliche Daten eintreffen?

Zyklische Kommunikation und ARP-Flood.
Bild 2. Zyklische Kommunikation und ARP-Flood.

Hierzu werden zusätzlich mit Hilfe des Tool „tcpreplay“ vorher aufgenommene ARP-Pakete so schnell wie möglich wieder in das Netzwerk eingespeist. Dies ist in Bild 2 dargestellt. Die ARP-Pakete sind als häufig ausgelöster Ethernet Interrupt (rote Linie) zu erkennen.

Wie jedoch in der Abbildung zu erkennen ist, beeinflusst der zusätzliche Datenverkehr die zyklische Kommunikation kaum. Wie ist dies zu erklären? Zum einen braucht es für eine solche Realisierung eine MCU mit priorisierbaren und unterbrechbaren Interrupts. Diese Eigenschaft wurde beim Renesas RX63 korrekt umgesetzt. Die Verarbeitung bzw. Erzeugung der zyklischen Frames ist die wichtigste Aufgabe des Gerätes; somit wurde dem Timer Interrupt höchste Priorität zugewiesen. Er löst also auch dann aus, wenn das Gerät gerade im Ethernet Interrupt ein Paket verarbeitet, und unterbricht diesen.

Zum anderen kommt hier eine clevere Eigenschaft des RX63N zum Tragen, der gerade bei hoher Ethernet-Netzwerklast die CPU stark entlasten kann. Der RX63N besitzt einen eigenen DMA-Controller (EDMAC) für den Ethernet-Controller (ETHERC). Dadurch wird die CPU vom Kopieren der zu sendenden bzw. der empfangenen Ethernet Frames entlastet. Mit Hilfe von Deskriptoren gibt die CPU den Speicherbereich an, in welchem das zu sendende Paket liegt bzw. in welchen das empfangene Paket geschrieben werden soll. Die Pakete können dann von der CPU bearbeitet werden. Es ist dadurch möglich, ein Paket zu bearbeiten, während der EDMAC bereits weitere Pakete empfängt bzw. aussendet.


  1. Lasttests bei Industrial Ethernet
  2. Eine Frage der Architektur
  3. Ausblick

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Renesas Electronics Europe GmbH

Weitere Artikel zu Mikrocontroller