Validation des réseaux Ethernet automobiles avec les tests Man-in-the-Middle

L'Ethernet automobile introduit de la complexité au-delà des anciens protocoles tels que CAN (Controller Area Network) ou LIN (Local Interconnect Network).Bien que la validation logicielle de haut niveau soit courante, les erreurs de communication de bas niveau, telles que les trames corrompues, les violations de cadencement ou le bruit électrique, sont souvent filtrées par les NIC commerciales et restent non détectées. Ces défaillances peuvent se manifester par des verrouillages logiciels de l'ECU, des messages d'erreur inexpliqués, des pics de latence ou des échecs dans les protocoles veille/veille tels que TC10.

Pour garantir la fiabilité et la sécurité, les ingénieurs ont besoin d’outils permettant de tester la couche MAC, d’où proviennent ces problèmes. Les tests MitM corrigent cette lacune en permettant une manipulation active du trafic en direct, y compris des anomalies telles que des séquences de vérification de trames (FCS) corrompues, pour évaluer la robustesse du système dans des conditions réelles. Cette capacité est essentielle pour les véhicules modernes, où Ethernet prend en charge les applications sensibles au temps et critiques pour la sécurité.

Validation des réseaux Ethernet automobiles avec les tests Man-in-the-Middle

Alors que les véhicules deviennent plus connectés, autonomes et définis par logiciel, l’Ethernet automobile apparaît comme l’épine dorsale de la communication à bord des véhicules. Des système avancé d'aide à la conduite (ADAS) à l’infodivertissement et au véhicule à tout (V2X), l’Ethernet automobile permet l’échange de données à haute vitesse et à faible latence sur des unités de commande électronique (ECU) de plus en plus complexes.

Cependant, les méthodes de validation traditionnelles négligent souvent les défauts de communication de bas niveau qui peuvent entraîner des blocages logiciels, des problèmes de cadencement et un comportement imprévisible. Ce white paper présente les tests man-in-the-middle (MitM) comme une technique puissante pour découvrir des problèmes cachés et valider la robustesse des réseaux Ethernet automobiles.

En tirant parti de la plate-forme matérielle modulaire de NI, en particulier le NI PXIe-6592 (utilisé à la fois pour le MitM et la personnalité/Sim-DUT), les ingénieurs peuvent simuler des défaillances réelles, injecter du trafic et surveiller les réponses de l’ECU avec précision.

Les tests MitM consistent à insérer un système de test programmable entre deux périphériques de communication (généralement des ECU ou des passerelles) pour intercepter, manipuler et analyser le trafic réseau au niveau de la couche MAC. Contrairement à la surveillance passive, MitM permet aux ingénieurs de manipuler activement le trafic en direct, en introduisant des perturbations contrôlées pour valider la tolérance aux pannes et les mécanismes de gestion des erreurs.

Figure 1 : Diagramme d'architecture MitM

Les NIC traditionnels suppriment les trames non valides, ce qui rend l'injection de défaut impossible. Le module série haute vitesse PXIe-6592 contourne les couches du système d’exploitation (OS) et de la carte d’interface réseau (NIC), offrant un accès direct aux trames Ethernet (valides ou corrompues) avec une latence de l’ordre de la microseconde et une précision d’horodatage inférieure à la microseconde. Les ingénieurs peuvent briser le FCS, injecter du trafic à partir de fichiers ou de sources en direct, déclencher des commandes veille/veille TC10, enregistrer le trafic dans des fichiers de capture de paquets (PCAP) et automatiser les tests à l’aide des interfaces de programmation d’applications (API) d’appel de procédure à distance (gRPC) de Google.

Figure 2 : Diagramme du flux de travail MitM

Pour permettre des tests "man-in-the-middle" à grande échelle, la plate-forme modulaire NI est conçue pour un contrôle déterministe hautes performances du trafic Ethernet automobile. Contrairement aux solutions NIC traditionnelles, cette plate-forme combine la flexibilité au niveau du FPGA avec la synchronisation et l’évolutivité du PXI, ce qui la rend idéale pour l’injection de défauts, l’analyse de cadencement et la validation de protocole. À la base, le système intègre du matériel spécialisé pour la manipulation de trames en temps réel et une pile logicielle qui prend en charge l’automatisation, le contrôle à distance et l’inspection approfondie des paquets.

Matériel : PXIe-6592 avec quatre ports SFP prenant en charge 100/1000BASE-T1 et d'autres variantes Ethernet.

Logiciels : API NI LabVIEW et gRPC pour l'automatisation et intégration PCAP pour l'analyse de paquets.

Dans les tests MitM pour Ethernet automobile, deux capacités fondamentales définissent comment les ingénieurs manipulent et analysent le trafic réseau au niveau de la couche MAC :

• Opérations FCS — Ces opérations consistent à modifier la séquence de vérification des trames dans les trames Ethernet pour simuler la corruption et valider les mécanismes de gestion des erreurs. MitM est livré avec plusieurs modes de rupture FCS.
• Méthodes d'injection — Ces méthodes sont des techniques permettant d'introduire du trafic supplémentaire (synthétique ou rejoué) dans le flux de communication pour tester les contraintes des ECU dans des conditions réalistes ou extrêmes.

Ensemble, ces capacités permettent aux ingénieurs de reproduire les problèmes de terrain, d’injecter des défaillances contrôlées et de valider la robustesse dans divers scénarios, ce que les NIC traditionnelles ou la surveillance passive ne peuvent pas réaliser.

Effectuons une plongée en profondeur dans chacun d’entre eux pour analyser leurs fonctionnalités.

La figure suivante montre où la fonctionnalité de coupure FCS (rectangle rouge) est appliquée ; le trafic acquis sur le port 0 est passé à la fonctionnalité de coupure FCS, puis le trafic modifié est passé au mélangeur.

Figure 3 : Emplacement de la fonctionnalité de rupture MitM FCS

MitM supporte plusieurs modes de manipulation FCS. Ces modes sont illustrés par des fichiers PCAP chargés dans Wireshark®* et certaines captures d'écran sont disponibles à l'annexe A.

• Tous activés : Toutes les trames ont un FCS incorrect.
• Tous désactivés : Toutes les trames ont un FCS correct.
• 1 période — 50 % : La moitié des trames ont un FCS brisé.
• N cycles — 50 % : Une trame sur deux a un FCS brisé.
• Aléatoire : Corruption de FCS randomisée.
• Pourcentage : Pourcentage de trames corrompues défini par l'utilisateur.
• Personnalisé : L'utilisateur télécharge un tableau (jusqu'à 8192 éléments) pour un contrôle précis.
  

La Figure 4 montre comment les paramètres de pause FCS sont appliqués sur le trafic entrant par le FPGA.

Figure 4 : Algorithme de rupture FPGA FCS

MitM supporte deux méthodes d'injection :

Générateur de trames (DMA), qui génère des trames pour les tests de contrainte, et injection de port, qui combine le trafic en direct du port 1 avec les trames générées.

Le trafic injecté est combiné avec des trames modifiées FCS pour simuler des conditions de réseau réalistes. Les rectangles rouges de la figure 5 représentent le chemin d'injection.

Figure 5 : Injection

L'annexe B détaille les conditions d'essai et les résultats de la méthode d'injection du générateur de trames (DMA).

Un deuxième PXIe-6592 est utilisé pour tester le MitM. Il dirige une personnalité FPGA différente appelée « Sim/DUT »,

Figure 6 : MitM avec configuration de test (Sim/DUT)

1. Test de régression pour les défaillances connues

Lorsqu’un problème de terrain est remonté à une trame corrompue spécifique ou à une anomalie de cadencement, les tests MitM fournissent une reproduction déterministe du scénario de défaillance ; par conséquent, les ingénieurs peuvent :

• Relire les modèles de trafic exacts capturés sur le terrain, y compris les trames mal formées et les irrégularités de cadencement.
• Surveillez le comportement de l’ECU au niveau de la couche MAC, garantissant une visibilité sur les sous-programmes de gestion d’erreur et les réponses de la pile de protocoles.
• Valider les correctifs logiciels correctifs dans des conditions identiques avant le déploiement, réduisant ainsi le risque de régression dans les environnements de production.

2. Test de contrainte sous pleine charge de bus

Les systèmes MitM permettent une saturation contrôlée du bus Ethernet en injectant de grands volumes de trafic mixte, réel et simulé, ce qui permet aux ingénieurs de :

• Poussez la bande passante à des limites théoriques, en validant le débit et la latence dans les pires conditions.
• Caractérisez les performances de l'ECU en cas de congestion, y compris la hiérarchisation des trames et la gestion des buffers.
• Identifier les violations de cadencement et les goulots d’étranglement susceptibles de compromettre la communication déterministe dans les applications critiques pour la sécurité.

3. Validation du protocole veille/sommeil (TC10)

Dans les véhicules électriques, le protocole TC10 régit les transitions entre les états actifs et de faible puissance. Les tests MitM garantissent la conformité et la robustesse en :

• Déclenchement de séquences veille/sommeil avec une précision de l’ordre de la microseconde, simulant des contraintes de cadencement réelles.
• Introduction de bruit contrôlé ou de retards pour valider la résilience de l'ECU face à des conditions réseau imparfaites.
• Mesure du comportement de la latence et de transition de puissance, fournissant des données quantitatives pour la conformité aux exigences de gestion de l’alimentation OEM.

L’adoption de systèmes MitM pour la validation Ethernet marque une avancée significative dans le test et l’assurance des réseaux automobiles. En permettant un contrôle précis de l’injection de trafic, de la simulation de défaillance et de la validation de protocole, ces solutions permettent aux ingénieurs de recréer des conditions de réseau réelles, d’évaluer minutieusement le comportement des ECU et de vérifier la conformité aux exigences strictes de l’industrie. Les tests de contrainte sous pleine charge du bus et la validation rigoureuse du protocole veille/sommeil garantissent que les paramètres critiques, tels que la bande passante, la latence et la gestion de l’alimentation, sont non seulement mesurés, mais aussi optimisés pour la sécurité et la fiabilité. La capacité d’identifier les goulots d’étranglement, les violations de cadencement et la résilience aux conditions imparfaites fournit une base solide pour développer des véhicules électriques et connectés de nouvelle génération.

Alors que l’Ethernet automobile continue d’évoluer, l’intégration d’outils de validation avancés, tels que du matériel basé sur FPGA et des logiciels flexibles et automatisés, restera essentielle pour les équipementiers et les fournisseurs de niveau 1. Ces technologies simplifient non seulement le processus de développement, mais rehaussent également la norme en matière de sécurité, de connectivité et d’efficacité des véhicules. À l’avenir, des stratégies de validation complètes fondées sur des tests réalistes seront essentielles pour répondre aux exigences d’architectures de véhicules de plus en plus complexes et garantir le fonctionnement transparent des solutions de mobilité de demain.

Cette section illustre les différents modes de rupture FCS disponibles avec le MitM.

Remarque : Dans les exemples de capture d'écran suivants, Wireshark® est utilisé ; il est défini à :

• Vérifiez s'il y a un FCS et attendez-vous à un FCS.
• Afficher dans les cadres de police rouges avec FCS non valide.

Mode tout activé

En mode tout activé, le FCS de toutes les trames est brisé.

Figure 7 : Mode de rupture FCS tout activé Mode de rupture FCS tout activé – Toutes les trames Ethernet capturées montrent un FCS non valide en raison d'une corruption MitM.

Mode tout désactivé

En mode tout désactivé, aucune trame n'a son FCS brisé.

Figure 8 : Mode de rupture FCS tout désactivé – Capture Wireshark montrant le trafic Ethernet normal avec toutes les trames

Mode 1 cycle 50%

Dans cet exemple, la taille de bloc est 20 étapes. Cela implique que 50 pour cent du bloc (10 étapes) a son FCS brisé et que le repos (10 étapes) a son FCS intact.

Figure 9 : Mode de rupture FCS 50 % – La moitié des trames de chaque bloc ont un FCS brisé, la moitié reste valide.

Mode N cycles 50%

Dans cet exemple, une trame sur deux a son FCS brisé.

Figure 10 : Mode de rupture FCS 50 % cycle – Une trame Ethernet sur deux a son FCS brisé intentionnellement.

Mode de pourcentage (%)

Dans ce mode, la taille de bloc est 100 trames et le pourcentage passé par l'utilisateur est 80. Cela implique que 80 pour cent du bloc (80 trames) a son FCS brisé et le reste (20 trames) a son FCS intact, puis nous répétons cela.

Figure 11 : Pourcentage (%) Mode de rupture FCS – Répétition de blocs de 100 trames où 80 % des trames ont brisé intentionnellement FCS et 20 % restent valides.

Mode aléatoire

Dans cet exemple, l'utilisateur définit une Taille de bloc (jusqu'à 8192), les valeurs aléatoires (Vrai ou Faux) sont synthétisées et utilisées pour définir quand la trame FCS est brisée. Puis il se répète.

Figure 12 : Mode de coupure FCS aléatoire : les trames Ethernet ont leur FCS brisée selon un modèle aléatoire dans une taille de bloc définie par l’utilisateur, répétée cycliquement.

Cette section illustre l'utilisation de l'injection (générateur de trames (DMA)).

Conditions de test

Ceci est le résultat d'un test à 1 Go/s.

• Le port 0 de MitM est connecté à une source de données via la liaison 1000BASE-T1.
• Les ports 2 et 3 sont connectés à d’autres ports de test via un câble SFP direct. Les ports de test sont utilisés pour mesurer le nombre de trames reçues.
• Nous utilisons la fonctionnalité de reniflage PCAP pour acquérir le trafic de sortie du mélangeur (données MitM Tx). Ceci permet un horodatage très précis des opérations.
• Le test se déroule en trois phases :
  • Phase 1. Nous commençons à appliquer du trafic sur le port 0 (MitM Rx). Le trafic est composé de 20 flux, période de 100 μs. La taille du flux varie de 78 à 173 octets par incrément de 5 octets. La source MAC est : 00:2F:80:17:29:68. Le trafic est généré par une autre source basée sur FPGA, utilisée avec un adaptateur SFP 1000BASE-T1.
  • Phase 2. Tout en continuant à appliquer du trafic sur le port 0, nous démarrons le générateur de trames . Le trafic du générateur est le même que celui appliqué sur le port 0 mais avec une source MAC différente : 00:2F80:11:25:34.
  • Phase 3. Plus de trafic sur le port 0, seulement le générateur de trames d'injection .
• La quantité de données est de 1 200 000 trames au total. Une panne :
  • 600 000 trames (30 000 trames par flux, 20 flux) appliquées à MitM Rx, source MAC : 00:2F:80:17:29:68.
  • 600 000 trames (30 000 trames par flux, 20 flux) générées par le générateur de trames (DMA), source MAC : 00:2F80:11:25:34.

Résultats du test

Phase 1

Nous avons MitM Rx uniquement. La figure 13 montre une représentation des flux en fonction du temps. La largeur de chaque barre est proportionnelle à la taille du flux.

Figure 13 : Résultats du test – Phase 1 (MitM Rx uniquement) – Activité du flux au fil du temps avec une largeur de barre indiquant la taille relative du flux.

La figure 14 montre chaque bloc de 20 flux émis à une période de 100 μs. C’est le même résultat, zoom sur une période.

Figure 14 : Résultats du test – Phase 1 (Affichage zoomé) – Zoom avant sur une période de 100 μs montrant un bloc de 20 flux reçus émis séquentiellement.

Nous nous attendons à 4 μs entre le temps de départ de deux flux consécutifs.

La figure 15 montre un sous-ensemble des données pendant la phase 1. Nous calculons la moyenne de la période de chaque flux, l'écart-type (s) et la variance (s²) de la période. Ici, nous ne voyons que les données de la source MAC 00:2F:80:17:29:68 — le générateur de trames n'est pas encore en cours d'exécution.

Figure 15 : Résultats du test Phase 1 sous-ensemble : statistiques de période par flux (moyenne, σ, σ2) pour MAC 00:2F:80:17:29:68; générateur de trames éteint.

Une autre mesure intéressante est le temps entre deux flux consécutifs. La figure 16 montre un graphe de périodes jointes. Nous attendons 4 μs.

Figure 16 : Phase 1 : temps entre flux avec périodes jointes, ~4 μs entre flux consécutifs.

Phase 2

Pendant cette phase, nous avons du trafic à la fois sur MitM Rx et le générateur de trames. Dans la figure 17, nous pouvons voir les différents flux provenant de différentes sources de trafic.

Figure 17 : Résultats du test – Phase 2 – Flux au fil du temps montrant le trafic Rx MitM simultané et le trafic du générateur de trames provenant de plusieurs sources.

Les tracés des barres unies sont ceux du MitM Rx (source MAC : 00:2F:80:17:29:68). Les autres (pas simples) sont ceux de l’injection (générateur de trames), la source MAC est : 00:2F:80:11:25:34.Le trafic en provenance de MitM Rx a priorité sur le trafic d'injection. Ainsi, si MitM Rx et injection ont des trames, les trames de MitM Rx ont une priorité.

Le trafic d'injection peut affecter le cadencement du trafic MitM Rx dans une situation d'exemple telle que : dans le mélangeur, lorsqu'il n'y a pas de trame de MitM Rx à envoyer mais une trame d'injection à envoyer, alors la trame d'injection est envoyée. Si pendant l’injection de MitM Rx est disponible, son émission sera retardée dans le temps. Nous pouvons le voir si nous regardons le temps entre les flux pendant cette phase. Pour rappel, en théorie, c’est 4 μs.

Figure 18 : Résultats des tests – Phase 2 Cadencement inter-flux – Temps inter-flux montrant les trames MitM Rx retardées lorsque le trafic d’injection occupe le mélangeur, bien que MitM Rx ait la priorité.

Si nous examinons les statistiques des flux pendant le test et que la ou les moyennes sont toujours à 100 μs, nous pouvons également voir l’effet sur le cadencement lorsque nous examinons les écarts-types (par rapport à la phase 1).

Figure 19 : Résultats des tests – Statistiques des flux de phase 2 – La période moyenne des flux reste à 100 μs, tandis que l’augmentation de l’écart-type met en évidence la variabilité de cadencement introduite par le trafic d’injection simultané.

Phase 3

Pendant cette phase, nous avons seulement le trafic du générateur de trames. La source MAC est 00:2F:80:11:25:34.

Figure 20 : Résultats du test – Phase 3 – Activité du flux au fil du temps affichant uniquement le trafic du générateur de trames de MAC 00:2F:80:11:25:34.

Suite à l’aperçu du trafic de la phase 3, nous zoomons maintenant sur une fenêtre temporelle plus petite pour mettre en évidence la distribution temporelle des flux de génération de trames individuels lorsqu’aucun trafic MitM Rx n’est présent.

Figure 21 : Résultats du test – Phase 3 (Affichage zoomé) – Vue zoomée des flux générateurs de trames au fil du temps, montrant un espacement constant des flux sans interférence MitM Rx.

En plus des visualisations temporelles, les statistiques entre trames fournissent un meilleur aperçu du comportement de cadencement lorsque seul le trafic du générateur de trames est présent, confirmant des intervalles de transmission stables et un faible jitter en l’absence d’interférence MitM Rx.

Figure 22 : Résultats des tests – Statistiques inter-trames de la phase 3 – Statistiques de cadencement inter-trames par flux pour le trafic injection seule pendant la phase 3.

Ensemble

Pour conclure, nous agrégeons des statistiques sur toutes les phases pour évaluer le débit global et la stabilité de cadencement pour tous les flux.

Figure 23 : Statistiques globales des tests – Résultats globaux montrant un total de 1 200 000 trames capturées, correspondant à 30 000 trames par flux.

Enfin, nous examinons le cadencement global inter-flux tout au long du test pour comparer le comportement du système dans les phases avec du trafic de réception MitM actif (phase 1 et phase 2) par rapport aux phases avec du trafic d’injection uniquement, en soulignant comment les sources concurrentes influencent les caractéristiques de cadencement globales.

Figure 24 : Diagramme temporel global inter-flux montrant un intervalle plat d'environ 4 μs pendant la phase 1 et une variation de cadencement accrue pendant la phase 2, sans données inter-flux visibles pour la phase 3 uniquement par injection.

• En savoir plus sur les tests Ethernet automobile
• Découvrez les plates-formes de validation NI PXI
• Explorer le NI Vehicle Communication Toolkit
• Voir Test ECU avec NI PXIe-8520 et NI PXIe-8523
• Comprendre les tests HIL pour les systèmes automobiles