El año pasado, mientras configuraba un sistema de gestión de flotas para una empresa de logística, el cliente quería supervisar en tiempo real el consumo de combustible, las revoluciones del motor y la temperatura del refrigerante de cada camión. No solo querían que los datos se almacenaran localmente, sino que todo se transmitiera a la plataforma en la nube para que los despachadores pudieran supervisar el estado de los vehículos.

Parecía bastante sencillo. Pero una vez que nos pusimos manos a la obra, extraer datos del interior de los vehículos resultó ser mucho más complicado de lo esperado. Toda la información del vehículo se transmite a través del bus CAN, pero los formatos de los mensajes varían enormemente entre los distintos modelos de vehículos. Leer las revoluciones por minuto del motor de un camión FAW frente a las de un camión Dongfeng significa lidiar con identificadores de mensajes CAN, posiciones de campos de datos y factores de conversión completamente diferentes.

Al final, utilizamos una pasarela dual 5G para vehículos para resolver este problema. La pasarela se conecta al bus del vehículo a través de interfaces CAN, analiza todos los mensajes y, a continuación, lo sube todo a la nube a través de la red 5G. Todo ese proyecto me hizo apreciar profundamente la necesidad de que las pasarelas de los vehículos y el bus CAN funcionen conjuntamente.

Qué hace el bus CAN en los vehículos

Comencemos por explicar qué es realmente el bus CAN. CAN son las siglas de Controller Area Network (red de área de controlador). Bosch diseñó este bus de comunicación para su uso en automóviles en la década de 1980.

¿Por qué necesitamos el bus CAN? Los vehículos modernos incorporan docenas o incluso cientos de unidades de control electrónico. ECU del motor, ECU de la transmisión, ECU del ABS, ECU del cuadro de instrumentos, ECU de control de la carrocería... y la lista continúa. Estas ECU necesitan comunicarse entre sí. Si se tendieran cables individuales entre cada par de ECU, el mazo de cables sería una pesadilla.

El bus CAN conecta todas las ECU a un bus compartido. Piensa en ello como una línea de metro: todas las estaciones se encuentran en la misma ruta. Cualquier ECU puede enviar mensajes que reciben todas las demás ECU. Cada ECU procesa de forma selectiva los mensajes relevantes para su función.

Los vehículos comerciales suelen funcionar con 2 o 3 buses CAN independientes. El bus CAN del tren motriz conecta el motor, la transmisión, el ABS y otras ECU del tren motriz, y suele funcionar a 500 kbps o 250 kbps. El bus CAN de la carrocería se encarga de las luces, las cerraduras, el control de la climatización y los sistemas de confort, normalmente a 125 kbps. También puede haber un bus CAN dedicado al diagnóstico.

Las pasarelas de vehículos necesitan conectarse a estos buses CAN para leer los datos. Tomemos como ejemplo el SV910: viene con tres puertos CAN que pueden conectarse simultáneamente a varios buses CAN de vehículos.

El proceso de lectura de datos CAN

 

 

¿Cómo se leen exactamente estos datos? Veamos un ejemplo con las revoluciones por minuto del motor.

El primer paso es la conexión física.. Conecte la interfaz CAN de la pasarela al puerto de diagnóstico OBD del vehículo o directamente al bus CAN. Los vehículos comerciales suelen tener puertos OBD estándar, normalmente situados debajo del tablero o junto al asiento del conductor. El conector es trapezoidal con 16 pines.

El bus CAN utiliza señalización diferencial con dos cables: CAN_H y CAN_L. En el conector OBD, el pin 6 es CAN_H y el pin 14 es CAN_L. La interfaz CAN de la pasarela tiene los cables correspondientes, solo hay que emparejarlos. Nota importante: los extremos del bus CAN necesitan resistencias de terminación de 120 ohmios para evitar la reflexión de la señal. Algunas pasarelas integran resistencias de terminación internas, configurables mediante software.

El segundo paso es configurar la velocidad en baudios.. La velocidad de comunicación del bus CAN debe coincidir o no recibirá ningún dato. El tren motriz de los vehículos comerciales CAN suele funcionar a 250 kbps o 500 kbps; primero debe verificarlo. Consulte el manual de servicio del vehículo o realice una prueba con un analizador CAN profesional.

Configure la interfaz CAN de la puerta de enlace con la misma velocidad en baudios. Las puertas de enlace como la SV910 admiten múltiples velocidades en baudios, ajustables a través de archivos de configuración o interfaces de administración.

El tercer paso consiste en supervisar y analizar los mensajes CAN.. Los datos del bus CAN se transmiten en forma de tramas. Cada trama contiene varias partes: ID del mensaje, longitud de los datos, contenido de los datos y suma de comprobación.

El ID del mensaje es la clave para identificar el contenido de cada mensaje. Para las RPM del motor, normas como GB/T 27930 y SAE J1939 definen los ID. J1939 es habitual en los vehículos comerciales: las RPM del motor utilizan el ID 0x0CF00400, con datos en los bytes 4 y 5.

La puerta de enlace supervisa continuamente el bus CAN, captura tramas con identificadores específicos y, a continuación, extrae los valores de RPM de los bytes de datos. El valor extraído es un dato sin procesar que debe convertirse a RPM reales mediante una fórmula. En la norma J1939, la resolución de RPM del motor es de 0,125 rpm/bit, por lo que hay que multiplicar el valor sin procesar por 0,125 para obtener las RPM reales.

El cuarto paso es empaquetar y cargar los datos.. Después de analizar el valor RPM, la puerta de enlace lo empaqueta en el formato adecuado para cargarlo a través de la red 5G a la nube. Los formatos comunes incluyen mensajes JSON, Protobuf y MQTT.

La frecuencia de carga depende de los requisitos. La supervisión en tiempo real puede necesitar actualizaciones cada segundo, mientras que la gestión general de la flota puede utilizar intervalos de 10 o 30 segundos. Una mayor frecuencia implica mayores costos de datos.

El reto de los diferentes modelos de vehículos

 

En teoría parece sencillo. La realidad es que adaptarse a diferentes modelos de vehículos es lo que más problemas causa.

La norma nacional GB/T 32960 define los formatos de datos para los vehículos de nueva energía, pero solo cubre los vehículos eléctricos. Los vehículos comerciales tradicionales propulsados por combustible siguen en su mayoría la norma SAE J1939, aunque las implementaciones específicas siguen variando.

Lo que complica aún más las cosas es que muchos fabricantes de automóviles utilizan mensajes CAN propios que van más allá de las definiciones estándar. Algunas marcas incluyen códigos de error y recordatorios de mantenimiento en mensajes privados con formatos no documentados. Para leer esos datos es necesario realizar ingeniería inversa u obtener documentación técnica del fabricante del automóvil.

Durante los proyectos, nos adaptamos a cada modelo de vehículo de forma individual. Primero recopilamos la documentación del protocolo CAN para ese modelo. Si no hay documentación disponible, utilizamos un analizador CAN para registrar los datos del bus y analizamos manualmente los formatos de los mensajes. A continuación, configuramos las reglas de análisis correspondientes en la puerta de enlace.

Las pasarelas como la SV910 admiten una configuración flexible. Puede definir reglas de análisis personalizadas, especificando qué bytes de qué ID de mensaje representan qué datos y qué fórmula de conversión aplicar. Los diferentes modelos de vehículos solo necesitan diferentes archivos de configuración, sin necesidad de cambiar el código.

Creamos una base de datos de modelos de vehículos que almacena configuraciones de protocolo CAN para diferentes marcas y modelos. Los nuevos proyectos comienzan verificando si ya existen configuraciones. Si no es así, las adaptamos y las añadimos a la base de datos. La biblioteca contiene ahora configuraciones para entre cuarenta y cincuenta modelos de vehículos.

Garantizar el rendimiento en tiempo real y la precisión de los datos

La lectura de datos CAN con pasarelas de vehículos exige un buen rendimiento en tiempo real. Especialmente en escenarios de conducción autónoma o ADAS, los retrasos en los datos pueden afectar a la seguridad.

El bus CAN en sí mismo tiene una latencia muy baja, medida en microsegundos. Sin embargo, el procesamiento, el empaquetado y la carga de la puerta de enlace añaden un retraso adicional. ¿Cómo se puede controlar esto?

En primer lugar, minimice los pasos de procesamiento.. Después de recibir tramas CAN, analícelas inmediatamente en controladores de interrupción o tareas de alta prioridad en lugar de ponerlas en cola. Una vez analizadas, colóquelas directamente en el búfer de transmisión y envíelas a través de la red 5G.

Segundo, usa la aceleración por hardware.. Algunas pasarelas avanzadas para vehículos integran controladores CAN con filtrado de hardware. Configure las reglas de filtrado a nivel de hardware para aceptar solo los ID de mensajes de interés y descartar los demás. Esto reduce la carga de la CPU y aumenta la velocidad de procesamiento.

Tercero, maneja las marcas de tiempo con cuidado.. Cada trama CAN debe recibir una marca de tiempo inmediatamente después de su recepción en la puerta de enlace. Esta marca de tiempo debe tener una precisión de microsegundos. Los datos cargados en la nube deben llevar esta marca de tiempo para que la nube sepa cuándo se recopilaron.

El SV910 es compatible con los protocolos de sincronización horaria PTP/GPTP, lo que garantiza una sincronización de reloj de alta precisión entre la puerta de enlace y otros dispositivos. Esto es fundamental para situaciones que requieren la coordinación de varios dispositivos.

También se debe garantizar la precisión de los datos. Aunque el bus CAN tiene una función integrada de verificación de errores, ocasionalmente aparecen datos corruptos. Las pasarelas necesitan una validación secundaria. En el caso de las revoluciones por minuto del motor, el funcionamiento normal no puede pasar repentinamente de 1000 a 5000 rpm y viceversa. Marque esos datos anómalos como sospechosos en lugar de utilizarlos directamente.

Gestione también las situaciones de silencio del bus. Si no se ha recibido un determinado mensaje durante un periodo prolongado, es posible que la ECU correspondiente haya fallado o que el bus se haya desconectado. Las pasarelas deben detectar esta condición e informar de la anomalía.

Ventajas de la arquitectura 5G dual

El SV910 cuenta con una arquitectura 5G dual con dos módulos 5G. ¿Por qué 5G dual?

La primera razón es la redundancia de respaldo.. Los vehículos comerciales que realizan rutas de largo recorrido pueden atravesar zonas con mala señal. Con 5G único, la pérdida de señal implica la imposibilidad de transmitir datos. El 5G dual utiliza tarjetas SIM de diferentes operadores: China Telecom y China Unicom, o China Mobile y China Unicom. Cuando una señal se degrada, se cambia a la otra.

El cambio puede ser automático. La puerta de enlace supervisa la intensidad de la señal y la latencia en ambos enlaces 5G en tiempo real, utilizando el que tenga mejor calidad. O bien, utiliza ambos enlaces simultáneamente para la agregación de enlaces, duplicando el ancho de banda.

La segunda razón es la distribución del tráfico.. Las aplicaciones para vehículos suelen implicar múltiples flujos de datos: datos del bus CAN, vídeo de la cámara, datos de posicionamiento, comunicación V2X. Estos tipos de datos tienen características diferentes y distintos requisitos de ancho de banda/latencia.

Envíe los datos críticos de control a través de un enlace 5G y los vídeos con mucho tráfico a través del otro. Esto evita interferencias y garantiza la entrega en tiempo real de los datos críticos.

La tercera razón es el aislamiento de seguridad.. Algunas plataformas de gestión de flotas requieren una separación física entre los canales de control de los vehículos y los canales de recopilación de datos por motivos de seguridad. El 5G dual cumple perfectamente este requisito. Las órdenes de control utilizan enlaces dedicados, mientras que los datos recopilados utilizan otros. Incluso si los piratas informáticos comprometen el canal de datos, no pueden manipular las órdenes de control.

Integración con plataformas de gestión de flotas

Después de recopilar los datos, las pasarelas de los vehículos los suben a las plataformas de gestión de flotas. Las plataformas suelen ser servicios en la nube que ofrecen funciones de monitoreo de vehículos, reproducción de rutas, informes estadísticos, alertas de fallos y otras funciones.

Existen varias opciones de protocolo para la carga de datos. MQTT es el más común.. Es un protocolo de cola de mensajes ligero diseñado específicamente para el IoT. Las puertas de enlace actúan como clientes MQTT, conectándose a servidores MQTT en la nube y publicando mensajes periódicamente.

MQTT admite diferentes niveles de calidad de servicio (QoS). QoS 0 es como máximo una vez: enviar y olvidar, con posible pérdida. QoS 1 es como mínimo una vez: entrega garantizada, pero con posibles duplicados. QoS 2 es exactamente una vez: entrega garantizada sin duplicados. Elija el QoS adecuado en función de la importancia de los datos.

HTTP/HTTPS también se usa ampliamente.. Las puertas de enlace empaquetan periódicamente los datos recopilados y los cargan mediante solicitudes HTTP POST a las API en la nube. Este enfoque es sencillo y directo, y ofrece una buena compatibilidad. La desventaja es que la sobrecarga de HTTP supera a la de MQTT, por lo que es menos adecuado para la transmisión de datos pequeños de alta frecuencia.

También existen algunos protocolos especializados.. Por ejemplo, JT/T 808 es el protocolo de comunicación estándar del Ministerio de Transporte para terminales de sistemas de posicionamiento por satélite para vehículos de transporte por carretera. Muchas plataformas de gestión de flotas de vehículos comerciales utilizan este estándar. Para ser compatible con JT/T 808 es necesario implementar la pila de protocolos completa.

El formato de los datos debe acordarse con la plataforma. JSON es habitual, legible para los humanos y fácil de depurar. Pero JSON ocupa espacio, por lo que si los costos de los datos son sensibles, utilice formatos binarios como Protobuf o formatos compactos personalizados.

Implementación de funciones de diagnóstico

Además de leer datos en tiempo real, las pasarelas de los vehículos pueden realizar diagnósticos.

Las ECU de los vehículos generan códigos de diagnóstico de fallos (DTC). Cuando el motor funciona mal, genera códigos como P0001 o P0002. Estos códigos se almacenan en las ECU y se pueden leer a través del bus CAN.

Los protocolos de diagnóstico estándar son ISO 14229 (UDS: Servicios de Diagnóstico Unificados) y SAE J1939-73. La pasarela actúa como cliente de diagnóstico, enviando solicitudes de diagnóstico a las ECU, que devuelven códigos de error e información relacionada.

Después de leer los códigos de falla, tradúzcalos a descripciones legibles. ¿Qué significa P0001? Circuito de control del regulador de volumen de combustible/abierto. Esta traducción requiere una base de datos de códigos de falla. Las puertas de enlace pueden almacenar descripciones de códigos comunes internamente o cargarlas en la nube para su traducción.

Gracias a los códigos de falla, las plataformas de gestión de flotas pueden proporcionar alertas tempranas. Por ejemplo, la detección de un código de temperatura alta del refrigerante notifica inmediatamente a los conductores y a los departamentos de mantenimiento, evitando daños por sobrecalentamiento del motor.

Las aplicaciones avanzadas realizan un mantenimiento predictivo. Analizan las tendencias de diversos parámetros del vehículo para predecir posibles fallos. Por ejemplo, una disminución gradual de la presión del aceite del motor aún no ha activado los códigos de avería, pero muestra señales de advertencia, lo que incita a los conductores a revisar el aceite.

Lecciones aprendidas de proyectos reales

Después de numerosos proyectos, hemos encontrado muchos obstáculos.

Primera lección: proteja adecuadamente el bus CAN.. El bus CAN del vehículo es fundamental. Si los fallos de la pasarela provocan una caída del bus o transmiten mensajes erróneos, el funcionamiento normal del vehículo podría verse afectado.

Las interfaces CAN de puerta de enlace necesitan aislamiento eléctrico para evitar la propagación de fallos. Los circuitos de protección del bus deben desconectarse automáticamente en caso de sobretensión o sobrecorriente. El software también necesita mecanismos de protección: detener la transmisión si se detectan anomalías para evitar interferencias en el bus.

Segunda lección: las modificaciones de los vehículos deben cumplir con la normativa.. La instalación de pasarelas de vehículos en vehículos comerciales constituye una modificación del vehículo. Debe cumplir con los requisitos normativos nacionales y locales sin comprometer el rendimiento de seguridad del vehículo. Algunas regiones exigen el registro en la administración de vehículos después de las modificaciones.

Tercera lección: la seguridad de los datos y la protección de la privacidad son muy importantes.. Las rutas y el comportamiento de conducción de los vehículos implican privacidad. Cifrar la transmisión de datos, anonimizar el almacenamiento. El acceso a la plataforma en la nube requiere controles de permiso; no se puede filtrar información a terceros de manera casual.

En general, la lectura de los datos del vehículo a través del bus CAN con pasarelas de vehículo constituye la base de las aplicaciones de vehículos conectados. La tecnología en sí misma no es compleja, pero para hacerlo bien hay que prestar atención a muchos detalles. Adaptar diferentes modelos de vehículos, garantizar el rendimiento en tiempo real, la precisión de los datos y la fiabilidad de las comunicaciones: todos los aspectos deben perfeccionarse cuidadosamente para proporcionar un servicio estable y confiable.