Validación de redes Ethernet automotrices con pruebas Man-in-the-Middle

Ethernet automotriz introduce complejidad más allá de los protocolos heredados como la red de área de controlador (CAN) CAN o la red de interconexión local (LIN). Aunque la validación de software de nivel superior es común, los errores de comunicación de bajo nivel, como tramas dañadas, violaciones de temporización o ruido eléctrico, a menudo son filtrados por las NIC comerciales y permanecen sin ser detectados. Estas fallas pueden manifestarse como bloqueos de software de ECU, mensajes de error inexplicables, picos de latencia o fallas en protocolos de suspensión/vigilia como TC10.

Para garantizar la fiabilidad y la seguridad, los ingenieros necesitan herramientas que permitan realizar pruebas en la capa MAC, donde se originan estos problemas. Las pruebas MitM abordan esta brecha al permitir la manipulación activa del tráfico en vivo, incluidas anomalías como secuencias de verificación de tramas (FCS) dañadas, para evaluar la robustez del sistema en condiciones reales. Esta capacidad es crítica para los vehículos modernos, donde Ethernet admite aplicaciones sensibles al tiempo y críticas para la seguridad.

Validación de redes Ethernet automotrices con pruebas Man-in-the-Middle

A medida que los vehículos se vuelven más conectados, autónomos y definidos por software, Ethernet automotriz está emergiendo como la columna vertebral de la comunicación dentro del vehículo. Desde los sistemas avanzados de asistencia al conductor (ADAS) hasta el infoentretenimiento y la comunicación del vehículo con todo (V2X), Ethernet automotriz permite el intercambio de datos de alta velocidad y baja latencia a través de unidades de control electrónico (ECU) cada vez más complejas.

Sin embargo, los métodos de validación tradicionales a menudo pasan por alto fallas de comunicación de bajo nivel que pueden conducir a bloqueos de software, problemas de sincronización y comportamiento impredecible. Este informe técnico presenta las pruebas de hombre en el medio (MitM) como una técnica poderosa para descubrir problemas ocultos y validar la robustez de las redes Ethernet automotrices.

Aprovechando la plataforma modular de hardware NI (específicamente, el NI PXIe-6592 (utilizado tanto para MitM como para Personality/Sim-DUT), los ingenieros pueden simular fallas del mundo real, inyectar tráfico y monitorear las respuestas de la ECU con precisión.

La prueba MitM implica insertar un sistema de prueba programable entre dos dispositivos de comunicación, normalmente ECU o gateway, para interceptar, manipular y analizar el tráfico de red en la capa MAC. A diferencia del monitoreo pasivo, MitM permite a los ingenieros manipular activamente el tráfico en vivo, introduciendo interrupciones controladas para validar la tolerancia a fallas y los mecanismos de manejo de errores.

Figura 1: Diagrama de arquitectura MitM

Los NIC tradicionales descartan tramas no válidas, lo que hace imposible la inyección de fallas. El módulo serie de alta velocidad PXIe-6592 evita las capas del sistema operativo (OS) y de la tarjeta de interfaz de red (NIC), proporcionando acceso directo a las tramas Ethernet, válidas o dañadas, con latencia de microsegundos y precisión de marca de tiempo de submicrosegundos. Los ingenieros pueden romper FCS, inyectar tráfico desde archivos o fuentes vivas, activar comandos de espera/activación TC10, registrar el tráfico en archivos de captura de paquetes (PCAP) y automatizar pruebas mediante interfaces de programación de aplicaciones (API) de llamada a procedimiento remoto (gRPC) de Google.

Figura 2: Diagrama de flujo de trabajo MitM

Para permitir las pruebas intermedias a escala, la plataforma modular NI está diseñada para un control determinista y de alto rendimiento del tráfico Ethernet automotriz. A diferencia de las soluciones tradicionales basadas en NIC, esta plataforma combina la flexibilidad a nivel de FPGA con la sincronización y escalabilidad de PXI, lo que la hace ideal para la inyección de fallas, el análisis de tiempos y la validación de protocolos. En su núcleo, el sistema integra hardware especializado para la manipulación de cuadros en tiempo real y una pila de software que admite automatización, control remoto e inspección profunda de paquetes.

Hardware: PXIe-6592 con cuatro puertos SFP compatibles con 100/1000BASE-T1 y otras variantes Ethernet.

Software: NI LabVIEW y API gRPC para automatización e integración de PCAP para análisis de paquetes.

En las pruebas MitM para Ethernet automotriz, dos capacidades principales definen cómo los ingenieros manipulan y analizan el tráfico de red en la capa MAC:

• Operaciones FCS: estas operaciones implican alterar la secuencia de comprobación de tramas en tramas Ethernet para simular corrupción y validar mecanismos de gestión de errores. MitM viene con varios modos de ruptura FCS.
• Métodos de inyección — Estos métodos son técnicas para introducir tráfico adicional —ya sea sintético o reproducido— en el flujo de comunicación para probar las ECU en condiciones realistas o extremas.

Juntas, estas capacidades permiten a los ingenieros reproducir problemas de campo, inyectar fallas controladas y validar la robustez en diversos escenarios, algo que las NIC tradicionales o la supervisión pasiva no pueden lograr.

Vamos a hacer una inmersión profunda en cada uno de ellos para analizar sus características.

La siguiente figura muestra dónde se aplica la función de interrupción de FCS (rectángulo rojo); el tráfico adquirido en el puerto 0 se pasa a la función de interrupción de FCS y, a continuación, el tráfico modificado se pasa al mezclador.

Figura 3: MitM FCS Breaking Característica Ubicación

MitM soporta múltiples modos de manipulación FCS. Esos modos se ilustran con archivos PCAP cargados en Wireshark®* y algunas capturas de pantalla están disponibles en el Apéndice A.

• Todo habilitado: Todos los marcos tienen FCS incorrecto.
• Todos Discapacitados: Todos los marcos tienen FCS correcto.
• 1 ciclo — 50%: La mitad de los cuadros han roto FCS.
• N ciclos: 50%: Cada dos cuadros han roto FCS.
• Random: Corrupción aleatoria de FCS.
• Porcentaje Porcentaje de tramas dañadas definido por el usuario.
• Custom: El usuario carga una matriz (hasta 8.192 elementos) para un control preciso.
  

La Figura 4 muestra cómo se aplican los ajustes de interrupción de FCS en el tráfico entrante por la FPGA.

Figura 4: Algoritmo FCS Breaking FPGA

MitM admite dos métodos de inyección:

Generador de tramas (DMA), que genera tramas para pruebas de esfuerzo, e inyección de puertos, que mezcla el tráfico en vivo desde el puerto 1 con las tramas generadas.

El tráfico inyectado se combina con tramas modificadas por FCS para simular condiciones de red realistas. Los rectángulos rojos de la figura 5 representan la trayectoria de inyección.

Figura 5: Inyección

En el apéndice B se detallan las condiciones de ensayo y los resultados del método de inyección del generador de cuadros (DMA).

Un segundo PXIe-6592 se utiliza para probar el MitM. Dirige una personalidad diferente de la FPGA llamada “Sim/DUT”,

Figura 6: MitM con configuración de prueba (Sim/DUT)

1. Pruebas de regresión para fallos conocidos

Cuando un problema de campo se rastrea a una trama dañada específica o anomalía de temporización, las pruebas MitM proporcionan una reproducción determinista del escenario de falla; por lo tanto, los ingenieros pueden:

• Reproduce patrones de tráfico exactos capturados desde el campo, incluidas tramas mal formadas e irregularidades de sincronización.
• Monitoree el comportamiento de la ECU en la capa MAC, asegurando visibilidad de las rutinas de manejo de errores y las respuestas de la pila de protocolos.
• Valide los parches de software correctivo en condiciones idénticas antes de la implementación, reduciendo el riesgo de regresión en entornos de producción.

2. Pruebas de esfuerzo bajo carga completa del autobús

Los sistemas MitM permiten la saturación controlada del bus Ethernet inyectando grandes volúmenes de tráfico mixto, tanto real como simulado, por lo que esto permite a los ingenieros:

• Empuje el ancho de banda a límites teóricos, validando el rendimiento y la latencia en las peores condiciones.
• Caracterizar el rendimiento de la ECU bajo congestión, incluida la priorización de tramas y la gestión de búfer.
• Identificar violaciones de tiempos y cuellos de botella que puedan comprometer la comunicación determinista en aplicaciones críticas para la seguridad.

3. Validación del protocolo de sueño/vigilia (TC10)

En los vehículos eléctricos, el protocolo TC10 regula las transiciones entre estados activos y de baja potencia. Las pruebas MitM garantizan el cumplimiento y la robustez al:

• Activar secuencias de sueño / vigilia con precisión de microsegundos, simulando restricciones de tiempo del mundo real.
• Introducir ruido controlado o retrasos para validar la resiliencia de la ECU frente a condiciones imperfectas de la red.
• Medir la latencia y el comportamiento de transición de potencia, proporcionando datos cuantitativos para el cumplimiento de los requisitos de gestión de potencia del OEM.

La adopción de sistemas MitM para la validación Ethernet supone un avance significativo en la prueba y garantía de redes automotrices. Al permitir un control preciso sobre la inyección de tráfico, la simulación de fallas y la validación de protocolos, estas soluciones permiten a los ingenieros recrear las condiciones de la red del mundo real, evaluar a fondo el comportamiento de la ECU y verificar el cumplimiento de los estrictos requisitos de la industria. Las pruebas de esfuerzo a plena carga del bus y la validación rigurosa del protocolo sleep/wake garantizan que los parámetros críticos, como el ancho de banda, la latencia y la administración de energía, no solo se midan, sino que también se optimicen para garantizar la seguridad y la confiabilidad. La capacidad de identificar cuellos de botella, violaciones de tiempos y resistencia contra condiciones imperfectas proporciona una base sólida para desarrollar vehículos eléctricos y conectados de próxima generación.

A medida que Ethernet automotriz continúa evolucionando, la integración de herramientas de validación avanzadas, como hardware basado en FPGA y software flexible y automatizado, seguirá siendo esencial para los OEM y los proveedores de nivel 1. Estas tecnologías no solo optimizan el proceso de desarrollo, sino que también elevan el estándar de seguridad, conectividad y eficiencia de los vehículos. De cara al futuro, las estrategias de validación integrales basadas en pruebas realistas serán fundamentales para satisfacer las demandas de arquitecturas de vehículos cada vez más complejas y garantizar el funcionamiento sin problemas de las soluciones de movilidad del mañana.

Esta sección ilustra los diferentes modos de ruptura de FCS disponibles con el MitM.

Nota: En los siguientes ejemplos de capturas de pantalla, se utiliza Wireshark®; se establece en:

• Compruebe si hay FCS y espere un FCS.
• Visualización en marcos de fuente rojos con FCS no válido.

Modo todo habilitado

En el modo todo habilitado, el FCS de todos los cuadros se rompe.

Figura 7: Modo de ruptura de FCS habilitado para todos: todas las tramas Ethernet capturadas muestran FCS no válido debido a la corrupción de MitM.

Modo para todos los discapacitados

En el modo desactivado, ningún fotograma tiene su FCS roto.

Figura 8: Modo de interrupción FCS para todos deshabilitados: captura Wireshark que muestra el tráfico Ethernet normal con todas las tramas

Modo 1 ciclo 50%

En este ejemplo, el tamaño del bloque es de 20 fotogramas. Implica que el 50 por ciento del bloque (10 cuadros) tiene su FCS roto y el resto (10 cuadros) tiene su FCS intacto.

Figura 9: Ciclo 50% FCS Breaking Mode – La mitad de los cuadros de cada bloque han roto FCS, la otra mitad siguen siendo válidos.

N ciclos 50% Modo

En este ejemplo, cada dos marcos tienen su FCS roto.

Figura 10: Modo de ruptura de FCS del 50% de ciclo: cada trama Ethernet tiene su FCS rota intencionalmente.

Porcentaje (%) Modo

En este modo, el tamaño del bloque es de 100 cuadros y el porcentaje pasado por el usuario es de 80. Implica que el 80 por ciento del bloque (80 cuadros) tiene su FCS roto y el resto (20 cuadros) tiene su FCS intacto, entonces repetimos eso.

Figura 11: Porcentaje (%) FCS Breaking Mode – Bloques repetidos de 100 fotogramas donde el 80% de los fotogramas han roto FCS intencionalmente y el 20% siguen siendo válidos.

Modo aleatorio

En este ejemplo, el usuario define un tamaño de bloque (hasta 8,192), se sintetizan valores aleatorios (Verdadero o Falso) y se utilizan para definir cuándo se rompe el marco FCS. Luego, se repite.

Figura 12: Modo de ruptura de FCS aleatorio: las tramas Ethernet tienen su FCS rota de acuerdo con un patrón aleatorio dentro de un tamaño de bloque definido por el usuario, repetido cíclicamente.

Esta sección ilustra el uso de la inyección (generador de marcos (DMA)).

Condiciones de prueba

Este es el resultado de una prueba a 1 Gb/s.

• El puerto 0 de MitM está conectado a una fuente de datos a través del enlace 1000BASE-T1.
• Los puertos 2 y 3 se conectan a otros puertos de prueba a través de cable SFP directo. Los puertos de prueba se utilizan para medir el número de tramas recibidas.
• Utilizamos la función de sniffing PCAP para adquirir el tráfico de salida del mezclador (datos MitM Tx). Esto permite una marca de tiempo muy precisa de las operaciones.
• La prueba se realiza en tres fases:
  • Fase 1. Comenzamos a aplicar tráfico en el Puerto 0 (MitM Rx). El tráfico se compone de 20 flujos, período de 100 μs. El tamaño del flujo varía de 78 a 173 bytes por incremento de 5 bytes. La fuente MAC es: 00:2F:80:17:29:68. El tráfico es generado por otra fuente basada en FPGA, utilizada con un adaptador SFP 1000BASE-T1.
  • Fase 2. Sin dejar de aplicar tráfico en el puerto 0, iniciamos el generador de tramas. El tráfico del generador es el mismo que el aplicado en el puerto 0 pero con una fuente MAC diferente: 00:2F80:11:25:34.
  • Fase 3. No más tráfico en el puerto 0, solo el generador de tramas de inyección.
• La cantidad de datos es de 1.200.000 cuadros en total. Desglose:
  • 600.000 fotogramas (30.000 fotogramas por flujo, 20 flujos) aplicados a MitM Rx, fuente MAC: 00:2F:80:17:29:68.
  • 600.000 fotogramas (30.000 fotogramas por flujo, 20 flujos) generados por el generador de fotogramas (DMA), fuente MAC: 00:2F80:11:25:34.

Resultados de la prueba

Fase 1

Solo tenemos MitM Rx. La Figura 13 muestra una representación de los flujos frente al tiempo. El ancho de cada barra es proporcional al tamaño del flujo.

Figura 13: Resultados de la prueba – Fase 1 (solo MitM Rx) – Actividad de la corriente a lo largo del tiempo con el ancho de la barra que indica el tamaño relativo de la corriente.

La Figura 14 muestra cada bloque de 20 flujos emitidos en un período de 100 μs. Es el mismo resultado, ampliado en un período.

Figura 14: Resultados de la prueba – Fase 1 (vista ampliada) – Ampliada en vista de un período de 100 μs que muestra un bloque de 20 flujos recibidos emitidos secuencialmente.

Esperamos 4 μs entre el tiempo de inicio de dos flujos consecutivos.

La Figura 15 muestra un subconjunto de los datos durante la Fase 1. Calculamos la media del período de cada flujo, la desviación estándar (s) y la varianza (s²) del período. Aquí, vemos solo los datos de la fuente MAC 00:2F:80:17:29:68: el generador de marcos aún no se está ejecutando.

Figura 15 Resultados de la prueba Fase 1: subconjunto: estadísticas por período de flujo (media, σ, σ2) para MAC 00:2F:80:17:29:68; generador de fotogramas apagado.

Otra medición interesante es el tiempo entre dos flujos consecutivos. La figura 16 muestra un gráfico de los períodos unidos entre sí. Esperamos 4 μs.

Figura 16: Resultados de la prueba Fase 1: tiempo entre flujos con períodos unidos, ~4 μs entre flujos consecutivos.

Fase 2

Durante esta fase, tenemos tráfico tanto en MitM Rx como en el generador de tramas. En la Figura 17, podemos ver los diferentes flujos de diferentes fuentes de tráfico.

Figura 17: Resultados de la prueba – Fase 2 – Transmite a lo largo del tiempo mostrando el tráfico MitM Rx y el tráfico del generador de tramas simultáneos desde múltiples fuentes.

Las parcelas de las barras planas son las del MitM Rx (la fuente MAC es: 00:2F:80:17:29:68). Los otros (no simples) son los de la inyección (generador de marcos), la fuente MAC es: 00:2F:80:11:25:34.El tráfico procedente de MitM Rx tiene prioridad sobre el tráfico de inyección. Por lo tanto, si tanto MitM Rx como la inyección tienen marcos, entonces los marcos de MitM Rx tienen una prioridad.

El tráfico de inyección podría afectar a la temporización del tráfico de MitM Rx en una situación de ejemplo como: en el mezclador, cuando no hay una trama de MitM Rx para enviar sino una trama de inyección para enviar, entonces se envía la trama de inyección. Si durante la inyección de MitM Rx está disponible, entonces su emisión se va a retrasar en el tiempo. Podemos ver eso si miramos el tiempo entre corrientes durante esa fase. Como recordatorio, en teoría, son 4 μs.

Figura 18: Resultados de la prueba – Fase 2 Inter-Stream Timing – Tiempo inter-stream que muestra tramas MitM Rx retrasadas cuando el tráfico de inyección ocupa el mezclador, a pesar de que MitM Rx tiene prioridad.

Si observamos las estadísticas de los flujos durante la prueba y la(s) media(s) todavía está en 100 μs, también podemos ver el efecto en el tiempo cuando observamos la(s) desviación(es) estándar (en comparación con la Fase 1).

Figura 19: Resultados de la prueba – Estadísticas de flujo de fase 2 – El período medio de flujo permanece en 100 μs, mientras que el aumento de la desviación estándar destaca la variabilidad de tiempo introducida por el tráfico de inyección simultáneo.

Fase 3

Durante esta fase, solo tenemos tráfico desde el generador de tramas. La fuente MAC es 00:2F:80:11:25:34.

Figura 20: Resultados de la prueba – Fase 3 – Actividad de transmisión a lo largo del tiempo que muestra solo el tráfico del generador de tramas desde MAC 00:2F:80:11:25:34.

Siguiendo la visión general del tráfico de fase 3, ahora ampliamos una ventana de tiempo más pequeña para resaltar la distribución temporal de flujos individuales de generador de tramas cuando no hay tráfico MitM Rx presente.

Figura 21: Resultados de la prueba – Fase 3 (Vista ampliada) – Vista ampliada de los flujos del generador de fotogramas a lo largo del tiempo, mostrando un espaciado de flujo constante sin interferencias MitM Rx.

Además de las visualizaciones en el dominio del tiempo, las estadísticas entre tramas proporcionan una mayor comprensión del comportamiento de temporización cuando solo está presente el tráfico del generador de tramas, lo que confirma intervalos de transmisión estables y baja fluctuación en ausencia de interferencia MitM Rx.

Figura 22: Resultados de la prueba – Estadísticas intertramas de fase 3 – Métricas de temporización intertramas por flujo para tráfico de solo inyección durante la fase 3.

En general

Para concluir, agregamos estadísticas en todas las fases para evaluar el rendimiento general y la estabilidad temporal en todas las corrientes.

Figura 23: Estadísticas generales de prueba: resultados agregados que muestran 1.200.000 fotogramas totales capturados, correspondientes a 30.000 fotogramas por flujo.

Por último, examinamos el tiempo global entre flujos en toda la prueba para comparar el comportamiento del sistema en fases con tráfico de recepción de MitM activo (Fase 1 y Fase 2) frente a fases con tráfico de solo inyección, destacando cómo las fuentes concurrentes influyen en las características generales de tiempo.

Figura 24: Gráfico de tiempo global entre flujos que muestra un intervalo plano de ~4 μs durante la Fase 1 y una mayor variación de temporización durante la Fase 2, sin datos entre flujos visibles para la Fase 3 solo de inyección.

• Aprende sobre pruebas Ethernet automotrices
• Descubra las plataformas de validación basadas en NI PXI
• Explore el NI Vehicle Communication Toolkit
• Ver Pruebas de ECU con NI PXIe-8520 y NI PXIe-8523
• Comprenda las pruebas HIL para sistemas automotrices