Validieren von Automotive-Ethernet-Netzwerken mit Man-in-the-Middle-Tests

Automotive Ethernet führt Komplexität über veraltete Protokolle wie Controller Area Network (CAN) CAN oder Local Interconnect Network (LIN) hinaus ein. Während Softwarevalidierung auf höherer Ebene üblich ist, werden Low-Level-Kommunikationsfehler wie fehlerhafte Frames, Timing-Verstöße oder elektrisches Rauschen oft von kommerziellen NICs herausgefiltert und bleiben unentdeckt. Diese Fehler können sich in Form von ECU-Softwaresperrungen, unerklärlichen Fehlermeldungen, Latenzspitzen oder Ausfällen in Sleep/Wake-Protokollen wie TC10 äußern.

Um Zuverlässigkeit und Sicherheit zu gewährleisten, benötigen Ingenieure Werkzeuge, die Tests auf der MAC-Schicht ermöglichen, woher diese Probleme stammen. MitM-Tests schließen diese Lücke, indem sie die aktive Manipulation von Live-Datenverkehr, einschließlich Anomalien wie fehlerhafte Frame-Check-Sequenzen (FCS), ermöglichen, um die Systemrobustheit unter realen Bedingungen zu bewerten. Diese Funktion ist entscheidend für moderne Fahrzeuge, in denen Ethernet zeit- und sicherheitskritische Anwendungen unterstützt.

Validieren von Automotive-Ethernet-Netzwerken mit Man-in-the-Middle-Tests

Da Fahrzeuge immer vernetzter, autonomer und softwaredefinierter werden, entwickelt sich Automotive Ethernet als Rückgrat der Fahrzeugkommunikation. Von modernen Fahrerassistenzsystemen (ADAS) über Infotainment bis hin zu Fahrzeug-zu-allem (V2X) ermöglicht Automotive Ethernet den Datenaustausch mit hoher Geschwindigkeit und geringer Latenz zwischen immer komplexeren elektronischen Steuergeräten (ECUs).

Traditionelle Validierungsmethoden übersehen jedoch häufig Kommunikationsfehler, die zu Softwaresperrungen, Timing-Problemen und unvorhersehbarem Verhalten führen können. In diesem Whitepaper werden MitM-Tests (Man-in-the-Middle) als leistungsfähiges Verfahren vorgestellt, um verborgene Probleme aufzudecken und die Robustheit von Automotive-Ethernet-Netzwerken zu überprüfen.

Mit Hilfe der modularen NI-Hardwareplattform, insbesondere dem NI PXIe-6592 (das sowohl für das MitM als auch für das Personality/Sim-DUT verwendet wird), können Ingenieure reale Fehler simulieren, Datenverkehr einleiten und ECU-Antworten präzise überwachen.

MitM-Tests umfassen das Einfügen eines programmierbaren Testsystems zwischen zwei kommunizierende Geräte – in der Regel ECUs oder Gateways – zum Abfangen, Bearbeiten und Analysieren des Netzwerkverkehrs auf der MAC-Schicht. Im Gegensatz zur passiven Überwachung ermöglicht MitM es Ingenieuren, den Live-Datenverkehr aktiv zu manipulieren und kontrollierte Störungen einzuführen, um Fehlertoleranz und Fehlerbehandlungsmechanismen zu validieren.

Abbildung 1: MitM-Architekturdiagramm

Traditionelle NICs verwerfen ungültige Frames, wodurch eine Fehlerinjektion unmöglich ist. Das serielle Hochgeschwindigkeitsmodul PXIe-6592 umgeht die Betriebssystem- (OS) und Netzwerkkartenschichten (NIC) und bietet direkten Zugriff auf gültige oder fehlerhafte Ethernet-Frames mit Mikrosekundenlatenz und Zeitstempelgenauigkeit unter Mikrosekunden. Ingenieure können FCS unterbrechen, Datenverkehr aus Dateien oder Live-Quellen einschleusen, TC10-Sleep/Wake-Befehle auslösen, Datenverkehr in PCAP-Dateien (Packet Capture) anmelden und Tests mit Hilfe von GPC-APIs (Google Remote Procedure Call) automatisieren.

Abbildung 2: MitM-Workflow-Diagramm

Um Man-in-the-Middle-Tests in großem Maßstab zu ermöglichen, wurde die modulare Plattform von NI für eine leistungsstarke, deterministische Steuerung des Automotive-Ethernet-Datenverkehrs entwickelt. Im Gegensatz zu herkömmlichen NIC-basierten Lösungen kombiniert diese Plattform Flexibilität auf FPGA-Ebene mit der Synchronisation und Skalierbarkeit von PXI und ist somit ideal für Fehlerinjektion, Timing-Analyse und Protokollvalidierung. Im Kern integriert das System spezielle Hardware für die Echtzeit-Frame-Bearbeitung und einen Software-Stack, der Automatisierung, Fernsteuerung und tiefe Paketprüfung unterstützt.

Hardware: PXIe-6592 mit vier SFP-Ports, die 100/1000BASE-T1 und andere Ethernet-Varianten unterstützen.

Software: NI LabVIEW und gRPC APIs für die Automatisierung und PCAP-Integration für die Paketanalyse.

MitM-Tests für Automotive Ethernet definieren zwei Kernfunktionen, wie Ingenieure den Netzwerkverkehr auf der MAC-Schicht manipulieren und analysieren:

• FCS-Operationen—Hierbei wird die Frame-Prüfreihenfolge in Ethernet-Frames geändert, um Beschädigungen zu simulieren und Fehlerbehandlungsmechanismen zu validieren. MitM verfügt über mehrere FCS-Break-Modi.
• Injection-Methoden—Diese Methoden dienen dazu, zusätzlichen Traffic (synthetisch oder wiedergegeben) in den Kommunikations-Stream einzubringen, um ECUs unter realistischen oder extremen Bedingungen zu testen.

Zusammen ermöglichen diese Fähigkeiten es Ingenieuren, Feldprobleme zu reproduzieren, kontrollierte Fehler einzuschleusen und die Robustheit unter verschiedenen Bedingungen zu validieren – was traditionelle NICs oder passive Überwachung nicht leisten können.

Lassen Sie uns tief in jeden von ihnen eintauchen, um ihre Funktionen zu analysieren.

In der folgenden Abbildung sehen Sie, wo die FCS-Unterbrechungsfunktion (rotes Rechteck) angewendet wird. Erfasster Datenverkehr an Port 0 wird an die FCS-Unterbrechungsfunktion übergeben und modifizierter Datenverkehr wird dann an den Mischer weitergeleitet.

Abbildung 3: MitM FCS Breaking Feature Location

MitM unterstützt mehrere FCS-Bearbeitungsmodi. Diese Modi werden mit PCAP-Dateien veranschaulicht, die in Wireshark®* geladen werden, und einige Bildschirmaufnahmen sind im Anhang A verfügbar.

• Alle aktiviert: Alle Frames haben falsche FCS.
• Alle deaktiviert: Alle Frames haben die korrekte FCS.
• 1 Periode—50%: Bei der Hälfte der Frames ist FCS fehlerhaft.
• N Zyklen—50%: Bei jedem zweiten Rahmen ist FCS fehlerhaft.
• Zufall: Randomisierte FCS Korruption.
• Prozentualer Anteil: Benutzerdefinierter Prozentsatz der Frames fehlerhaft.
• Benutzerdefiniert: Der Benutzer lädt ein Array (bis zu 8.192 Elemente) für eine präzise Steuerung hoch.
  

Abbildung 4 zeigt, wie die FCS-Breaking-Einstellungen auf eingehenden Datenverkehr vom FPGA angewendet werden.

Abbildung 4: FCS - Fehlerhafter FPGA-Algorithmus

MitM unterstützt zwei Injektionsmethoden:

Frame-Generator (DMA), der Frames für Stresstests und Port-Injection erzeugt, die Live-Datenverkehr von Port 1 mit erzeugten Frames mischen.

Injizierter Datenverkehr wird mit FCS-modifizierten Frames kombiniert, um realistische Netzwerkbedingungen zu simulieren. Die roten Rechtecke in Abbildung 5 stellen den Injektionsweg dar.

Abbildung 5: Einspritzung

In Anlage B sind die Prüfbedingungen und -ergebnisse für das DMA-Injektionsverfahren (Frame Generator) beschrieben.

Mit einem zweiten PXIe-6592 wird das MitM getestet. Es läuft eine andere FPGA-Persönlichkeit namens "Sim/DUT",

Abbildung 6: MitM mit Testaufbau (Sim/DUT)

1. Regressionstest auf bekannte Fehler

Wenn ein Feldproblem auf einen spezifischen fehlerhaften Rahmen oder eine Timing-Anomalie zurückgeführt wird, bieten MitM-Tests eine deterministische Wiedergabe des Fehlerszenarios. Daher können Ingenieure:

• Spielen Sie genaue Verkehrsmuster ab, die vom Feld aus erfasst wurden, einschließlich falsch geformter Rahmen und Timing-Unregelmäßigkeiten.
• Überwachen des ECU-Verhaltens auf der MAC-Ebene, um Transparenz über Fehlerbehandlungsroutinen und Protokollstapelreaktionen zu gewährleisten.
• Validieren Sie Korrektursoftware-Patches vor der Verteilung unter identischen Bedingungen, um das Risiko von Rückschritten in Produktionsumgebungen zu reduzieren.

2. Belastungstest unter voller Buslast

MitM-Systeme ermöglichen eine kontrollierte Sättigung des Ethernet-Busses durch Einspeisung eines hohen realen und simulierten Mischverkehrsaufkommens.

• Setzen Sie die Bandbreite auf theoretische Grenzen und validieren Sie Durchsatz und Latenz im ungünstigsten Fall.
• Charakterisierung der ECU-Leistung bei Überlastung, einschließlich Frame-Priorität und Pufferverwaltung.
• Erkennen von Zeitverstößen und Engpässen, die die deterministische Kommunikation in sicherheitskritischen Anwendungen beeinträchtigen können

3. Sleep/Wake Protocol Validierung (TC10)

Bei Elektrofahrzeugen regelt das TC10-Protokoll den Übergang zwischen dem aktiven und dem Low-Power-Zustand. MitM-Tests gewährleisten Compliance und Robustheit durch:

• Triggerung von Sleep/Wake-Sequenzen mit Mikrosekundengenauigkeit und Simulation realer Timing-Bedingungen.
• Einführung von kontrolliertem Rauschen oder Verzögerungen zur Validierung der Widerstandsfähigkeit der ECU gegenüber unvollkommenen Netzwerkbedingungen.
• Messen der Latenz und des Leistungsübergangsverhaltens und Bereitstellen quantitativer Daten für die Einhaltung der OEM-Anforderungen für das Energiemanagement.

Die Einführung von MitM-Systemen zur Ethernet-Validierung markiert einen bedeutenden Fortschritt bei der Prüfung und Sicherstellung von Automotive-Netzwerken. Durch die präzise Steuerung von Verkehrsinjektion, Fehlersimulation und Protokollvalidierung ermöglichen diese Lösungen Ingenieuren, reale Netzwerkbedingungen neu zu erstellen, das Verhalten von ECUs gründlich zu bewerten und die Einhaltung strenger Industrieanforderungen zu überprüfen. Stresstests unter voller Buslast und eine strenge Sleep/Wake-Protokollvalidierung stellen sicher, dass kritische Parameter wie Bandbreite, Latenz und Energiemanagement nicht nur gemessen, sondern auch auf Sicherheit und Zuverlässigkeit optimiert werden. Die Fähigkeit, Engpässe, Zeitverstöße und Widerstandsfähigkeit gegen unvollkommene Bedingungen zu erkennen, bietet eine robuste Grundlage für die Entwicklung von Elektrofahrzeugen der nächsten Generation und vernetzten Fahrzeugen.

Im Zuge der Weiterentwicklung von Automotive Ethernet wird die Integration von fortgeschrittenen Validierungswerkzeugen wie FPGA-basierter Hardware und flexibler, automatisierter Software für OEMs und Tier-1-Zulieferer unerlässlich bleiben. Diese Technologien vereinfachen nicht nur den Entwicklungsprozess, sondern erhöhen auch den Standard für Fahrzeugsicherheit, Konnektivität und Effizienz. Um den Anforderungen zunehmend komplexer Fahrzeugarchitekturen gerecht zu werden und den nahtlosen Betrieb der Mobilitätslösungen von morgen zu gewährleisten, sind umfassende Validierungsstrategien entscheidend, die auf realistischen Tests basieren.

In diesem Abschnitt werden die verschiedenen FCS-Unterbrechungsmodi des MitM veranschaulicht.

Hinweis: In den folgenden Screenshot-Beispielen wird Wireshark® verwendet:

• Prüfen Sie auf FCS und erwarten Sie eine FCS.
• In roten Schriftrahmen mit ungültigem FCS anzeigen.

All-Aktivierter Modus

Im aktivierten Modus ist die FCS aller Frames fehlerhaft.

Abbildung 7: All-Enabled FCS Breaking Mode All-Enabled FCS Breaking Mode – Alle aufgezeichneten Ethernet-Frames zeigen aufgrund von MitM-Fehlern ungültige FCS an.

All-Deaktivierter Modus

Im All-Deabled-Modus ist kein FCS für Frames fehlerhaft.

Abbildung 8: FCS-Unterbrechungsmodus deaktiviert – Wireshark-Aufnahme mit normalem Ethernet-Datenverkehr mit allen Frames

1 Zyklus 50% Modus

In diesem Beispiel beträgt die Blockgröße 20 Frames. Es bedeutet, dass bei 50 Prozent des Blocks (10 Frames) die FCS fehlerhaft ist und beim Rest (10 Frames) die FCS unberührt ist.

Abbildung 9: Zyklischee 50% FCS-Unterbrechungsmodus – Die Hälfte der Frames in jedem Block hat FCS-Fehler, die Hälfte behält ihre Gültigkeit.

N Perioden 50% Modus

In diesem Beispiel ist die FCS jedes zweiten Rahmens fehlerhaft.

Abbildung 10: N‐Cycle 50% FCS Breaking Mode – Bei jedem zweiten Ethernet-Frame ist das FCS absichtlich fehlerhaft.

Prozent (%) Modus

In diesem Modus beträgt die Blockgröße 100 Frames und der Prozentsatz, der vom Benutzer weitergegeben wird, 80. Es bedeutet, dass bei 80 Prozent des Blocks (80 Frames) die FCS fehlerhaft ist und beim Rest (20 Frames) die FCS unberührt ist, dann wiederholen wir das.

Abbildung 11: Prozent (%) FCS-Unterbrechungsmodus – Wiederholen von Blöcken mit 100 Frames, wobei 80% der Frames absichtlich FCS gebrochen haben und 20% gültig bleiben.

Zufallsmodus

In diesem Beispiel definiert der Benutzer eine Blockgröße (bis zu 8.192), Zufallswerte (True oder False) werden synthetisiert und verwendet, um zu definieren, wann der Rahmen FCS fehlerhaft ist. Dann wiederholt es sich.

Abbildung 12: Zufälliger FCS-Unterbrechungsmodus – Ethernet-Frames werden nach einem zufälligen Muster innerhalb einer benutzerdefinierten Blockgröße gebrochen und zyklisch wiederholt.

In diesem Abschnitt wird die Verwendung der Einspritzung (Framegenerator (DMA)) veranschaulicht.

Testbedingungen

Dies ist das Ergebnis eines Tests mit 1 Gb/s.

• Port 0 von MitM ist über 1000BASE-T1 mit einer Datenquelle verbunden.
• Port 2 und 3 sind über ein direktes SFP-Kabel mit einigen anderen Testports verbunden. Mit den Testports wird die Anzahl der empfangenen Frames gemessen.
• Wir verwenden die PCAP-Sniffing-Funktion, um den Ausgangsverkehr des Mischers zu erfassen (MitM-Tx-Daten). Dies ermöglicht einen sehr genauen Zeitstempel der Operationen.
• Der Test läuft in drei Phasen ab:
  • Phase 1. Wir beginnen Datenverkehr auf Port 0 (MitM Rx) anzuwenden. Der Datenverkehr besteht aus 20 Streams, 100 μs Periodendauer. Die Stream-Größe variiert von 78 bis 173 Bytes, wobei 5 Bytes inkrementiert werden. Die MAC-Quelle lautet: 00:2F:80:17:29:68. Der Datenverkehr wird von einer anderen FPGA-basierten Quelle erzeugt, die mit einem SFP-1000BASE-T1-Adapter verwendet wird.
  • Phase 2. Während wir noch Traffic auf Port 0 anwenden, starten wir den Frame-Generator . Der Datenverkehr des Generators ist der gleiche wie an Port 0, jedoch mit einer anderen MAC-Quelle: 00:2F80:11:25:34.
  • Phase 3. Kein Datenverkehr mehr an Port 0, nur der Einspritzrahmengenerator.
• Die Datenmenge beträgt insgesamt 1.200.000 Frames. Untergliederung:
  • 600.000 Frames (30.000 Frames pro Stream, 20 Streams) auf MitM Rx angewendet, MAC-Quelle: 00:2F:80:17:29:68.
  • 600.000 Frames (30.000 Frames pro Stream, 20 Streams), erzeugt vom Frame-Generator (DMA), MAC-Quelle: 00:2F80:11:25:34.

Testergebnisse

Phase 1

Wir haben nur MitM Rx. Abbildung 13 zeigt eine Darstellung der Streams über der Zeit. Die Breite jedes Balkens ist proportional zur Stream-Größe.

Abbildung 13: Testergebnisse – Phase 1 (nur MitM Rx) – Stream-Aktivität im Laufe der Zeit, wobei Balkenbreite die relative Stream-Größe angibt.

Abbildung 14 zeigt jeden Block mit 20 Streams, die mit einer Periode von 100 μs ausgegeben werden. Es ist das gleiche Ergebnis, in eine Periode gezoomt.

Abbildung 14: Testergebnisse – Phase 1 (Zoomed-Ansicht) – Vergrößerte Ansicht einer 100-μs-Periode mit einem Block von 20 empfangenen Streams, die nacheinander ausgegeben wurden.

Wir erwarten 4 μs zwischen zwei aufeinanderfolgenden Streams.

Abbildung 15 zeigt einen Teil der Daten während Phase 1. Wir berechnen den Mittelwert der Periode jedes Streams, die Standardabweichung (s) und die Varianz (s²) der Periode. Hier sehen wir nur Daten von der MAC-Quelle 00:2F:80:17:29:68 – der Frame-Generator läuft noch nicht.

Abbildung 15: Unterabschnitt der Testergebnisse Phase 1: Periodendauer (Mittelwert, σ, σ2) für MAC 00:2F:80:17:29:68; Rahmengenerator ausgeschaltet.

Eine weitere interessante Messung ist die Zeit zwischen zwei aufeinanderfolgenden Streams. Abbildung 16 zeigt einen Graphen der miteinander verbundenen Perioden. Wir erwarten 4 μs.

Abbildung 16: Testergebnisse Phase 1: Zwischen-Stream-Zeit mit verbundenen Perioden, ~4 μs zwischen aufeinanderfolgenden Streams.

Phase 2

Während dieser Phase haben wir Traffic auf MitM Rx und dem Frame-Generator. In Abbildung 17 sehen wir die verschiedenen Streams von verschiedenen Traffic-Quellen.

Abbildung 17: Testergebnisse – Phase 2 – Streams mit parallelem MitM-Rx-Datenverkehr und Frame-Generator-Datenverkehr von mehreren Quellen.

Die Plots der einfachen Balken stammen vom MitM Rx (MAC-Quelle ist: 00:2F:80:17:29:68). Die anderen (nicht einfach) sind die von der Injektion (Frame-Generator), MAC-Quelle ist: 00:2F:80:11:25:34.Der Verkehr von MitM Rx hat Vorrang vor dem Einspritzverkehr. Wenn also sowohl MitM Rx als auch injection Frames haben, haben die Frames von MitM Rx Priorität.

Der Injektionsverkehr könnte sich in einer Beispielsituation auf das MitM-Rx-Timing auswirken, z. B. wenn im Mischer kein Frame von MitM Rx gesendet wird, sondern ein Frame von Injektion gesendet wird. Wenn während der Injektion von MitM Rx verfügbar ist, wird seine Emission zeitlich verzögert. Das können wir sehen, wenn wir uns die Zwischen-Stream-Zeit in dieser Phase ansehen. Zur Erinnerung: Theoretisch sind es 4 μs.

Abbildung 18: Testergebnisse – Inter-Stream-Timing der Phase 2 – Zwischen-Stream-Zeit zeigt verzögerte MitM-Rx-Frames an, wenn der Einspritzverkehr den Mischer belegt, obwohl MitM Rx Priorität hat.

Wenn wir uns die Statistiken der Streams während des Tests ansehen und der Mittelwert (die Mittelwerte) immer noch bei 100 μs liegt, können wir auch die Auswirkung auf das Timing sehen, wenn wir Standardabweichungen (im Vergleich zu Phase 1) betrachten.

Abbildung 19: Testergebnisse – Phase-2-Stream-Statistik – Die mittlere Stream-Periode bleibt bei 100 μs, während die erhöhte Standardabweichung die durch den gleichzeitigen Einspritzverkehr verursachte Timing-Variabilität hervorhebt.

Phase 3

Während dieser Phase haben wir nur Traffic vom Frame-Generator. MAC-Quelle ist 00:2F:80:11:25:34.

Abbildung 20: Testergebnisse – Phase 3 – Stream-Aktivität im Laufe der Zeit, die nur den Datenverkehr zwischen Frame-Generatoren vom MAC 00:2F:80:11:25:34 zeigt.

Nach dem Überblick über den Phase-3-Datenverkehr zoomen wir nun in ein kleineres Zeitfenster, um die zeitliche Verteilung einzelner Frame-Generator-Streams hervorzuheben, wenn kein MitM-Rx-Datenverkehr vorliegt.

Abbildung 21: Testergebnisse – Phase 3 (Zoom-Ansicht) – Vergrößerte Ansicht von Frame-Generator-Streams mit gleichbleibendem Stream-Abstand ohne MitM-Rx-Störungen.

Zusätzlich zu Zeitbereichs-Visualisierungen liefern Interframe-Statistiken weitere Einblicke in das Timing-Verhalten, wenn nur Frame-Generator-Datenverkehr vorhanden ist, was stabile Übertragungsintervalle und geringen Jitter ohne MitM-Rx-Störungen bestätigt.

Abbildung 22: Testergebnisse – Interframe-Statistik der Phase 3 – Timing-Metriken zwischen Frames für den reinen Injektionsverkehr während Phase 3.

Gesamt

Abschließend aggregieren wir Statistiken über alle Phasen, um den Gesamtdurchsatz und die Timing-Stabilität über alle Streams hinweg zu bewerten.

Abbildung 23: Gesamte Teststatistik – Gesamtergebnisse mit 1.200.000 erfassten Frames, was 30.000 Frames pro Stream entspricht.

Abschließend untersuchen wir das globale Inter-Stream-Timing während des gesamten Tests, um das Systemverhalten in Phasen mit aktivem MitM-Empfangsverkehr (Phase 1 und Phase 2) mit Phasen mit reinem Injektionsverkehr zu vergleichen.

Abbildung 24: Globaler Inter-Stream-Zeitplot, der ein flaches Intervall von ~4 μs während Phase 1 und eine erhöhte Timing-Variation während Phase 2 zeigt, wobei für Phase 3 keine Inter-Stream-Daten sichtbar sind.

• Weitere Informationen zu Automotive-Ethernet-Tests
• Entdecken Sie die PXI-basierten Validierungsplattformen von NI
• NI Vehicle Communication Toolkit erkunden
• Siehe ECU-Tests mit NI PXIe-8520 und NI PXIe-8523
• HIL-Tests für Automotive-Systeme