Pasarela CAN Bus para tractores autónomos: arquitectura de integración y por qué fallan los sistemas de campo

Por qué falla la integración del bus CAN en los tractores autónomos cuando se utilizan en el campo

El posicionamiento RTK en los tractores autónomos ofrece ahora de forma habitual una precisión inferior a 5 cm. Los algoritmos de planificación de rutas se han validado en diversas implantaciones comerciales. Sin embargo, los ingenieros de campo que trabajan en la adaptación de tractores autónomos siguen encontrándose con el mismo tipo de fallo: el sistema funciona en condiciones controladas, pero falla a mitad de temporada durante las operaciones reales en el campo.

En la mayoría de los proyectos de adaptación, el fallo se remonta siempre al mismo punto: ni la antena GNSS, ni el algoritmo de cálculo de la trayectoria, sino la capa de integración del bus CAN en el propio vehículo. Falta una traducción fiable del protocolo. Falta un bucle de control local. Las órdenes de dirección se transmiten a través de una infraestructura que nunca se diseñó para el control del vehículo en tiempo real.

Este artículo aborda tres aspectos: cuáles son las causas de los fallos en la integración del bus CAN en las implementaciones de tractores autónomos, por qué las opciones arquitectónicas habituales agravan estos fallos y qué hace realmente, a nivel de sistema, una pasarela de bus CAN diseñada específicamente para tractores autónomos.

1. Protocolos de bus heterogéneos sin una capa de traducción unificada

Existe una pasarela de bus CAN para tractores autónomos destinada a resolver un problema que surge al principio de cualquier proyecto de adaptación: el vehículo utiliza varios buses incompatibles al mismo tiempo y no hay nada que los conecte entre sí. 

Una adaptación típica de un tractor autónomo utiliza al menos cuatro buses de comunicación incompatibles entre sí de forma simultánea:

• Controlador de la dirección y unidad de control electrónico del motor (ECU) en el bus CAN — protocolo J1939, normalmente a 250 Kbps o 500 Kbps
• Receptor RTK-GNSS que transmite mensajes NMEA a través de RS232
• IMU y sensores de suelo conectados a RS485 con Modbus RTU
• Implementar la retroalimentación de posición en las entradas digitales (DI)

Estas redes son incompatibles tanto a nivel físico como lógico. Las tramas J1939 no se corresponden con los registros Modbus. Las frases NMEA no se traducen en señales CAN. Sin un dispositivo que sirva de puente entre todas ellas a nivel local, los datos de los sensores no pueden llegar al algoritmo de control, y las órdenes de dirección no pueden llegar al actuador.

En los proyectos de modernización, la solución habitual consiste en utilizar convertidores de protocolo independientes conectados en cadena a través de un IPC. Esto resuelve el problema de la compatibilidad, pero aumenta la complejidad del cableado, introduce más puntos de fallo y no mejora la latencia de control.

2. Acumulación de latencia en los bucles de control con enrutamiento en la nube

Es aquí donde la arquitectura de pasarela CAN para tractores autónomos se diferencia más claramente de los diseños centrados en la nube, y donde los fallos sobre el terreno son más difíciles de diagnosticar. 

En las implantaciones sobre el terreno, la velocidad de la red rara vez es el factor limitante. Lo es, en cambio, la variabilidad.

Algunas arquitecturas de tractores autónomos canalizan el bucle de corrección de la dirección a través de un servidor remoto: se envían los datos de los sensores, se calcula la desviación de forma remota y se envía de vuelta la orden de corrección. Cuando la red funciona bien, la latencia de ida y vuelta es aceptable. Sin embargo, en los campos agrícolas con una cobertura 4G irregular, a menudo no es así. A una velocidad de trabajo en el campo de entre 6 y 8 km/h, un pico de 150-200 ms en la entrega de la orden produce un error de desviación lateral apreciable que se acumula a lo largo de una pasada.

Incorporar un bucle de control en el que el tiempo es un factor crítico en un enlace de latencia variable supone una incompatibilidad arquitectónica. El control de la dirección mediante el bus CAN requiere una respuesta local determinista, no una que dependa de la nube.

3. Fiabilidad ambiental a lo largo de toda la temporada de cultivo

Los requisitos de fiabilidad de una pasarela de bus CAN en tractores autónomos difieren de los de las implementaciones industriales estándar, y la mayor parte del hardware de uso general no supera la comparación. 

Las temperaturas en la cabina durante las operaciones de campo en verano suelen alcanzar los 50–65 °C. A esto hay que añadir la vibración constante en terrenos accidentados, el polvo procedente de las labores de labranza y cosecha, y los lavados a presión periódicos. En los proyectos de modernización, los componentes que superan las pruebas de banco suelen fallar en el plazo de una temporada de cultivo. Las cajas refrigeradas por ventilador acumulan polvo. Los conectores se aflojan con la vibración. Los componentes diseñados para soportar hasta 70 °C no tienen margen térmico en una cabina que suele alcanzar temperaturas más elevadas.

Puerta de enlace CAN bus frente a IPC frente a PLC: comparación de arquitecturas de control de tractores autónomos 

Para los ingenieros que evalúan la arquitectura de control en un proyecto de tractor autónomo, la elección entre una pasarela CAN, un IPC o un PLC determina la complejidad de la integración, los costes de mantenimiento y la fiabilidad a largo plazo en condiciones de campo. 

Cada enfoque tiene un caso de uso legítimo; la cuestión es cuál se ajusta a los requisitos reales del sistema de bus CAN de un tractor autónomo.

PLC

Los PLC ofrecen un control local determinista con décadas de fiabilidad demostrada en la automatización industrial. La limitación en las aplicaciones de tractores autónomos es la amplitud del protocolo. Los PLC estándar no gestionan de forma nativa la decodificación de tramas J1939, el análisis sintáctico de frases NMEA y el cálculo de la desviación de la trayectoria de forma paralela. Añadir esas capacidades mediante módulos aumenta el coste del hardware y la complejidad de la integración. Los PLC resultan adecuados cuando las secuencias de control son fijas y los requisitos de protocolo son limitados; por ejemplo, para implementar la lógica de elevación vinculada a señales de los límites del campo.

IPC industrial

Un IPC con Linux gestiona toda la combinación de protocolos con las tarjetas de interfaz adecuadas y cuenta con la capacidad de cálculo necesaria para tareas exigentes: pilas de navegación completas, visión artificial para la detección de obstáculos y fusión compleja de sensores. El problema práctico en la instalación en cabinas agrícolas es de carácter ambiental. La refrigeración por ventilador supone un riesgo de acumulación de polvo en condiciones de labranza y cosecha. Su tamaño es mayor del que la mayoría de las cabinas pueden albergar cómodamente. El consumo de energía en los sistemas eléctricos de los vehículos de 12 V/24 V requiere una gestión adicional de la alimentación. Para aplicaciones de tractores autónomos que requieren gran capacidad de cálculo, un IPC suele seguir siendo la solución adecuada. Para el guiado RTK-GNSS con dirección mediante bus CAN y control de implementos ISOBUS, se requiere más hardware del que la tarea exige.

Pasarela CAN para vehículos agrícolas

Una pasarela industrial sin ventilador, con CAN nativo, RS232, RS485 y E/S digitales, resuelve directamente el problema de la conexión entre protocolos sin los inconvenientes medioambientales de un ordenador industrial refrigerado por ventilador. El bucle de control local se ejecuta en la pasarela, sin dependencia de la red en la ruta de control. Su diseño compacto se adapta a las instalaciones en cabina. La entrada de CC de amplio rango se conecta directamente a los sistemas eléctricos del vehículo sin necesidad de conversión de potencia adicional.

La contrapartida es el límite de capacidad de cálculo. Las tareas basadas en la visión artificial y los sistemas completos de navegación superan la capacidad de procesamiento de las actuales pasarelas periféricas agrícolas.

Para la implementación de tractores autónomos que utilicen posicionamiento RTK-GNSS con control de dirección mediante bus CAN y gestión de implementos a través de ISOBUS, una pasarela de bus CAN específica es la opción más adecuada desde el punto de vista arquitectónico, no porque sea más sencilla, sino porque se adapta a la carga de trabajo real y a las limitaciones del entorno.

Compatibilidad con J1939 e ISOBUS: qué requiere realmente la integración del bus CAN

Lograr una compatibilidad adecuada entre J1939 e ISOBUS es uno de los retos menos documentados en la implantación de pasarelas CAN para tractores autónomos, y una de las causas más habituales de retrasos en la integración en proyectos reales. 

La maquinaria agrícola de John Deere, Trimble, Topcon, AGCO y la mayoría de los principales fabricantes de equipos originales (OEM) se comunica a través de CAN utilizando J1939 como capa de protocolo base. ISOBUS (ISO 11783) amplía el protocolo J1939 con mensajes estandarizados para el acoplamiento de implementos y el control entre marcas, lo que explica que una pantalla de Trimble pueda controlar un implemento de otro fabricante a través del mismo bus CAN.

En la práctica, los estándares J1939 e ISOBUS definen la estructura de la trama. La integración de dispositivos específicos requiere la decodificación de grupos de parámetros (PGN) y números de parámetros sospechosos (SPN) propios de cada fabricante. En los proyectos de adaptación, es habitual encontrarse con controladores de dirección que utilizan la estructura de tramas estándar de J1939 con asignaciones de PGN propias, o implementaciones de ISOBUS que incluyen extensiones del proveedor junto con el conjunto de mensajes estándar.

Una pasarela de bus CAN con análisis de tramas configurable se encarga de esto sin necesidad de reescribir el código de la aplicación para cada dispositivo. El integrador configura los desplazamientos de campo, los tipos de datos y el escalado por PGN a nivel de la pasarela. Las tramas entrantes se decodifican automáticamente. Los comandos salientes se ensamblan a partir de los parámetros configurados. Cuando el siguiente dispositivo utiliza una estructura de trama diferente, cambia la configuración de la pasarela, pero no la de la aplicación de control.

Esto tiene importancia en la práctica cuando un proyecto de modernización combina controladores de dirección, unidades de control electrónico (ECU) del motor y componentes de distintos fabricantes. Sin un análisis configurable de tramas en la pasarela, cada nueva combinación de dispositivos requiere un trabajo de integración a medida en la capa de aplicación.

Cómo funciona el bucle de control local de la pasarela CAN en el vehículo

El valor fundamental de una pasarela de bus CAN para tractores autónomos radica en que el bucle de control de la dirección nunca sale del vehículo, y para comprender por qué esto es importante hay que analizar con exactitud cómo funciona dicho bucle. 

La pasarela se conecta directamente al bus CAN del vehículo, al receptor RTK-GNSS a través de RS232 y a los sensores a través de RS485. La conversión de protocolos se realiza de forma local —se decodifican las tramas J1939, se analizan las frases NMEA y se leen los registros Modbus— y los datos normalizados se envían a la aplicación de control local.

Cuando el vehículo se desvía de la trayectoria prevista, la lógica de control de la pasarela calcula la corrección y envía la orden de dirección a través de CAN directamente al controlador de la dirección. Todo ese ciclo —desde la entrada del sensor hasta la orden al actuador— se lleva a cabo en el propio vehículo. No hay ninguna red externa en el bucle.

La conectividad de red se encarga del registro de datos en la plataforma en la nube y de la supervisión remota de la flota. No interviene en el control de la dirección en tiempo real. En las implantaciones sobre el terreno en las que la conexión 4G se interrumpe durante la operación, el bucle de control de la dirección continúa sin interrupciones. Los datos se almacenan temporalmente de forma local y se sincronizan cuando se restablece la conectividad.

Especificaciones del EG8200 para la implementación de una pasarela de bus CAN en tractores autónomos

Los IOTRouter EG8200 Está diseñado como una pasarela de bus CAN para aplicaciones en tractores autónomos y vehículos agrícolas; es el único modelo de la serie EG que admite de forma nativa la interfaz CAN. 

 

Dos puertos CAN independientes Permite la conexión simultánea a redes de bus independientes —la red J1939 del tren de potencia a 500 Kbps y la red ISOBUS a 250 Kbps— en un único dispositivo, sin necesidad de un convertidor independiente.

Refrigeración pasiva sin ventilador Elimina la acumulación de polvo en entornos de trabajo agrícolas. Con un rango de funcionamiento de entre -40 °C y +85 °C, el dispositivo cubre las condiciones térmicas habituales de la cabina, con un margen por encima del límite máximo de 65 °C observado en las mediciones de campo.

BeiDou/GPS integrado proporciona a la pasarela una determinación de posición independiente, al margen del receptor RTK, lo que resulta útil para el seguimiento de flotas y para correlacionar los datos operativos con la ubicación sobre el terreno cuando no se dispone del flujo de datos RTK.

Instalación: lo que, según la experiencia en el despliegue sobre el terreno, es lo más importante

La instalación de una pasarela de bus CAN en un tractor autónomo implica una serie de decisiones de instalación que tienen un impacto desproporcionado en la fiabilidad a largo plazo, la mayoría de las cuales no aparecen en la documentación del producto. 

Terminación del bus CAN: compruébala antes de realizar la conexión

Las redes CAN de los vehículos están diseñadas con resistencias de terminación de 120 Ω en cada extremo físico del bus. Conectar la pasarela en una derivación intermedia del bus sin tener en cuenta la terminación existente provoca una impedancia incorrecta del bus y reflexiones de señal. En las instalaciones sobre el terreno, esto se manifiesta como errores intermitentes de comunicación CAN que guardan relación con la temperatura y la vibración, lo que puede llevar fácilmente a un diagnóstico erróneo de fallo de hardware. Antes de realizar la conexión, comprueba que el bus cuente con la terminación correcta en ambos extremos. No añadas un tercer punto de terminación.

Lugar de instalación: la temperatura de la superficie no es la misma que la temperatura ambiente

El EG8200 está homologado para una temperatura de hasta +85 °C. Las temperaturas en el interior de la cabina durante las operaciones de campo en verano suelen oscilar entre los 50 y los 65 °C. Un dispositivo instalado en un lugar donde la luz solar incida directamente sobre la carcasa puede alcanzar temperaturas entre 15 y 20 °C superiores a la temperatura ambiente, lo que basta para agotar el margen de seguridad. Instálelo en un lugar a la sombra dentro de la cabina o en una carcasa sellada, lejos de la exposición solar.

Node-RED para la puesta en marcha sobre el terreno

La pasarela ejecuta Node-RED para la lógica de las aplicaciones de control local. El filtrado de ID de CAN, la configuración de la velocidad de transmisión, los parámetros RS232, la lógica de procesamiento de los sensores y las condiciones de salida de los dispositivos de salida (DO) se configuran a través de la interfaz gráfica, sin necesidad de código a nivel del dispositivo. En proyectos de modernización en los que es necesario ajustar los parámetros durante la puesta en marcha, los cambios se realizan a través de la interfaz sin necesidad de acceder físicamente al dispositivo cada vez.

Puesta en marcha de una flota de varios vehículos

Un EG8200 por vehículo como nodo periférico independiente. Las actualizaciones remotas de firmware a través de 4G permiten realizar el mantenimiento rutinario sin necesidad de desplazamientos sobre el terreno. El modo AP admite hasta 20 conexiones simultáneas de clientes WiFi para situaciones de red local sobre el terreno.

Preguntas frecuentes sobre la integración de pasarelas CAN para proyectos de tractores autónomos

Estas cuestiones surgen constantemente en las implementaciones de pasarelas CAN para tractores autónomos, especialmente en proyectos de adaptación multimarca en los que deben coexistir en la misma red del vehículo dispositivos J1939 e ISOBUS de distintos fabricantes. 

¿Pueden ambos puertos CAN funcionar simultáneamente a diferentes velocidades de transmisión?

Sí. Cada puerto se configura de forma independiente en un rango de 125 Kbps a 1 Mbps. En las instalaciones en las que el sistema J1939 del tren de potencia funciona a 500 Kbps y las aplicaciones ISOBUS a 250 Kbps, ambos se conectan a un único EG8200 sin necesidad de un convertidor independiente.

¿Cómo gestiona la pasarela las tramas CAN propias de determinados fabricantes?

El nodo CAN avanzado funciona a nivel de trama y es independiente del protocolo. Las compensaciones de campo, los tipos de datos y los factores de escala se configuran por cada ID de CAN. Tanto los PGN estándar de J1939 como las extensiones propias utilizan el mismo mecanismo. Cuando un nuevo dispositivo tiene una estructura de trama diferente, cambia la configuración de la pasarela, pero no la de la aplicación de control.

¿Afecta la pérdida de señal 4G al bucle de control de la dirección?

No. El bucle de control de la dirección se ejecuta localmente en la pasarela. La red 4G transmite los datos operativos a la plataforma en la nube; no forma parte de la ruta de control en tiempo real. En las instalaciones sobre el terreno en las que la señal se interrumpe durante el funcionamiento, el control local continúa con normalidad y los datos almacenados en el búfer se sincronizan cuando se restablece la conectividad.

¿En qué casos resulta más adecuado un IPC que una pasarela de bus CAN para tractores autónomos?

Cuando la aplicación requiere visión artificial, una pila completa de navegación ROS o cargas de trabajo de fusión de sensores que superan la capacidad de un procesador de doble núcleo a 1,2 GHz, un IPC es el hardware adecuado. Para el guiado autónomo basado en RTK-GNSS con dirección mediante bus CAN y control de implementos ISOBUS, la capacidad de procesamiento del EG8200 se encarga de la carga de trabajo, y su diseño sin ventilador, su entrada de voltaje amplio y sus puertos CAN nativos reducen el trabajo de integración en comparación con un IPC con adaptadores adicionales.

¿Para qué aplicaciones de tractores autónomos no es adecuada esta pasarela?

La detección de obstáculos basada en la visión, el procesamiento de nubes de puntos LiDAR y las aplicaciones que ejecutan pilas de navegación totalmente autónomas superan el límite de capacidad de cálculo del EG8200. Para esas cargas de trabajo, el hardware adecuado es un IPC o una plataforma de cálculo diseñada específicamente para vehículos autónomos. El EG8200 se encarga de la pasarela del bus CAN y de la capa de control local, pero no de la capa de percepción.