14/05/2020
El mundo del automóvil moderno es una red compleja de sistemas electrónicos que necesitan hablar entre sí de forma rápida y fiable. Aquí es donde entra en juego el CAN bus, o Controller Area Network, un protocolo de comunicación diseñado específicamente para este propósito. No solo se limita a los coches, sino que su robustez y eficiencia lo han llevado a una multitud de otras aplicaciones.

- ¿Qué es el CAN Bus en un Coche y Cómo Funciona?
- El Protocolo CAN Bus: Estructura de Mensajes
- CAN FD: Evolución con Mayor Flexibilidad y Velocidad
- Ventajas Clave del Uso de CAN Bus
- Aplicaciones Populares del CAN Bus
- Una Breve Mirada a la Historia del CAN Bus
- Variaciones del Estándar CAN Bus
- Protocolos Adicionales sobre CAN
- Otros Buses de Comunicación en Vehículos
- ¿Puede Arduino Interactuar con CAN Bus?
- Interactuando con CAN Bus Usando Arduino y MCP2515
- Preguntas Frecuentes sobre CAN Bus y Arduino
¿Qué es el CAN Bus en un Coche y Cómo Funciona?
Imagina que cada componente electrónico importante en tu coche, como la unidad de control del motor (ECU), el sistema de frenos ABS, el airbag o el panel de instrumentos, es como un pequeño ordenador. Antes, cada uno de estos componentes necesitaba un cableado directo para comunicarse con otros, lo que resultaba en un laberinto de cables pesados y costosos. El CAN bus cambió esto al proporcionar una red común donde todos estos componentes pueden enviar y recibir mensajes.

El CAN bus es un protocolo basado en mensajes, lo que significa que los dispositivos envían paquetes de datos, o tramas, que están disponibles para todos los nodos de la red. Cada trama contiene un identificador que también define su prioridad. Si varios nodos intentan transmitir al mismo tiempo, el bus utiliza un método de arbitraje bit a bit sin pérdidas: el mensaje con el identificador numéricamente más bajo (y por lo tanto, la prioridad más alta) gana acceso al bus sin que se pierda el mensaje de menor prioridad, que esperará su turno.
A diferencia de otras redes, CAN no requiere un ordenador central. Cada nodo decide si el mensaje que ve en el bus es relevante para él basándose en el identificador. Esto hace que el sistema sea muy distribuido y tolerante a fallos.
El Protocolo CAN Bus: Estructura de Mensajes
El protocolo CAN está estandarizado bajo ISO 11898 y define cómo se estructuran los mensajes. Una trama CAN típica tiene varios campos:
- SOF (Start Of Frame): Un solo bit dominante que marca el inicio del mensaje.
- Identificador: Un campo que define la prioridad del mensaje. Puede ser de 11 bits (CAN estándar) o 29 bits (CAN extendido). Valores más bajos significan mayor prioridad.
- RTR (Remote Transmission Request): Un bit que indica si la trama es una solicitud de datos (trama remota) o si contiene datos (trama de datos).
- IDE (Identifier Extension bit): Indica si se usa un identificador estándar o extendido.
- R0/R1: Bits reservados para uso futuro.
- DLC (Data Length Code): Indica la cantidad de bytes de datos en la trama (de 0 a 8 bytes en CAN 2.0).
- Datos: Los datos reales que se transmiten (hasta 8 bytes en CAN 2.0).
- CRC (Cyclic Redundancy Check): Un campo de 15 bits para detectar errores en los datos.
- ACK (Acknowledgement): Los nodos que reciben el mensaje correctamente sobrescriben un bit recesivo en este campo con un bit dominante para confirmar la recepción.
- EOF (End Of Frame): Un campo de 7 bits que marca el final de la trama.
- IFS (Interframe Space): El tiempo de espera antes de que pueda comenzar la siguiente trama.
La robustez frente a interferencias electromagnéticas es una característica clave del CAN bus, lograda en parte por el uso de señalización diferencial en un par de cables trenzados.
CAN FD: Evolución con Mayor Flexibilidad y Velocidad
Con la creciente cantidad de datos generados por sistemas avanzados en los vehículos, surgió la necesidad de un CAN bus más rápido y con mayor capacidad de datos. Así nació CAN FD (Flexible Data Rate).
CAN FD aumenta la longitud estándar de los datos en una trama de 8 a 64 bytes, ¡un incremento del 800%! Además, la tasa de datos máxima se eleva de 1 Mbps a 8 Mbps. La flexibilidad radica en que los nodos pueden cambiar dinámicamente sus tasas de transmisión y tamaños de mensaje según las necesidades en tiempo real.
A pesar de estas mejoras, CAN FD es completamente compatible con versiones anteriores (CAN 2.0), lo que facilita su integración gradual en la industria automotriz. Aunque actualmente se encuentra principalmente en vehículos de alto rendimiento, se espera que se extienda a la mayoría de los vehículos en el futuro.

Ventajas Clave del Uso de CAN Bus
El CAN bus se ha convertido en un estándar de la industria por sus múltiples beneficios:
- Simplicidad y Bajo Costo: Reduce drásticamente la cantidad de cableado complejo y costoso necesario para la comunicación entre ECUs, lo que disminuye el peso del vehículo y los puntos potenciales de fallo. Los chips controladores CAN son asequibles y están ampliamente disponibles.
- Centralización: Ofrece un punto centralizado para diagnóstico, registro de datos y configuración de todas las ECUs conectadas.
- Robustez: Es altamente resistente a perturbaciones eléctricas e interferencias electromagnéticas, lo que lo hace ideal para aplicaciones críticas de seguridad como los sistemas de frenos o airbags.
- Eficiencia: La priorización de mensajes garantiza que los datos más importantes lleguen sin demora ni interrupciones.
- Detección de Fallos: El protocolo incluye mecanismos robustos para la detección de errores, asegurando la integridad de los datos transmitidos.
- Implementación Sencilla: Es un estándar bien establecido con un amplio ecosistema de soporte.
La implementación de las capas física y de enlace de datos en microchips económicos facilita aún más su adopción.
Aplicaciones Populares del CAN Bus
Aunque nació para la industria automotriz, el CAN bus se ha expandido a muchos otros sectores debido a su fiabilidad y eficiencia:
- Automoción: Coches, camiones, motocicletas, autobuses.
- Transporte Pesado: Telemática de flotas, maquinaria agrícola y de construcción.
- Aeroespacial: Sistemas internos de aeronaves.
- Automatización Industrial: Control de procesos, robótica, maquinaria de fabricación.
- Sistemas de Edificios: Ascensores, escaleras mecánicas, sistemas de climatización.
- Equipamiento Médico: Dispositivos de diagnóstico y control.
- Electrodomésticos: Lavadoras, secadoras.
Una Breve Mirada a la Historia del CAN Bus
Antes del CAN bus, los vehículos se cableaban de manera similar a una casa antigua: cada luz, cada bocina, cada motor eléctrico, necesitaba un cable que lo conectara directamente a un interruptor o fuente de alimentación. Esto resultaba en miles de cables que añadían un peso considerable a los vehículos, afectando la eficiencia del combustible.
En la década de 1980, con el aumento de las unidades de control electrónico (ECUs) en los vehículos, la empresa alemana Robert Bosch GmbH, en colaboración con Mercedes-Benz e Intel, comenzó a desarrollar una red de comunicación que permitiera a estas ECUs interactuar de manera más eficiente. El objetivo era reducir el cableado y mejorar la fiabilidad.
En 1986, Bosch presentó el estándar CAN en el congreso SAE. Al año siguiente, Intel comenzó a enviar los primeros chips controladores CAN. Esto marcó un antes y un después en el diseño de vehículos, permitiendo la comunicación entre ECUs a través de un simple par de cables trenzados, reduciendo significativamente el peso y la complejidad.
Variaciones del Estándar CAN Bus
El estándar ISO 11898 define varias implementaciones, las más comunes en la industria automotriz son:
- Low Speed CAN: Utilizado para sistemas que no requieren altas tasas de actualización y donde la tolerancia a fallos es crucial, como controles de tablero, ventanas eléctricas, etc. La velocidad máxima es de 125 kbps.
- High Speed CAN: Empleado para comunicaciones entre sistemas críticos que necesitan alta velocidad y precisión, como ABS, control de estabilidad, ECUs de motor. Las tasas de datos varían entre 1 kbps y 1 Mbps.
- CAN FD: La versión más reciente, con tasas de datos de hasta 8 Mbps y capacidad para tramas de hasta 64 bytes, utilizada en aplicaciones de alto rendimiento y sistemas avanzados.
Protocolos Adicionales sobre CAN
CAN es un protocolo de mensajería, pero no define cómo interpretar los datos dentro de los mensajes. Por ello, se han desarrollado protocolos de capa superior que corren sobre CAN para añadir funcionalidad y estandarización. Algunos ejemplos son:
- SAE J1939: Desarrollado para vehículos pesados y camiones, define cómo se transmiten datos específicos como la velocidad del motor, temperatura, etc., sobre una capa física CAN.
- OBD II (On-Board Diagnostics II): El puerto de diagnóstico presente en la mayoría de los coches modernos. Permite acceder a datos del vehículo y códigos de error (DTC) a través de protocolos que a menudo se implementan sobre CAN.
- CANopen: Un protocolo de capa superior utilizado en sistemas de control embebidos y automatización industrial, especialmente en control de movimiento. Define modelos de comunicación y perfiles de dispositivo.
- XCP/CCP: Protocolos (Universal Measurement and Calibration Protocol y CAN Calibration Protocol) utilizados para la calibración de ECUs y la adquisición de datos. XCP es más moderno y puede correr sobre varios buses, incluyendo CAN.
Otros Buses de Comunicación en Vehículos
Los vehículos modernos utilizan a menudo una combinación de diferentes buses para optimizar el rendimiento y el costo según la aplicación:
Además del CAN bus y sus protocolos asociados, existen otras redes de comunicación en el ámbito automotriz:
- LIN Bus (Local Interconnect Network): Una alternativa de bajo costo a CAN, utilizada para aplicaciones sencillas con baja tasa de datos y un número limitado de nodos (maestro/esclavo), como elevalunas eléctricos o espejos. Es una red de un solo cable.
- FlexRAY: Diseñado para aplicaciones de control dinámico de alto rendimiento que requieren determinismo y tolerancia a fallos, como sistemas de dirección y frenado 'drive-by-wire'. Ofrece mayor velocidad (hasta 10 Mbps) y puede usar redundancia con dos pares de cables.
- MOST (Media-Oriented Systems Transport): Un bus optimizado para sistemas de infoentretenimiento y multimedia, ofreciendo altas tasas de datos agregadas para audio y video.
- Automotive Ethernet: Con la creciente necesidad de ancho de banda para cámaras, sensores LIDAR y sistemas de asistencia a la conducción, Ethernet está ganando terreno en el automóvil. Se están desarrollando estándares específicos (como BroadR-Reach y Ethernet TSN) para adaptar Ethernet a las duras condiciones y requisitos de tiempo real del entorno vehicular.
Aquí tienes una tabla comparativa de alto nivel:
| Bus | Velocidad Típica | Tamaño de Datos | Cableado | Topología | Uso Común | Detección de Error | Redundancia | Determinismo | Costo Relativo |
|---|---|---|---|---|---|---|---|---|---|
| LIN | 10-20 kbps | 8 Bytes | Un cable | Bus (Maestro/Esclavo) | Sensores, actuadores simples (luces, espejos) | CRC 8-bit | No | No | $ |
| CAN | Hasta 1 Mbps | 8 Bytes | Par trenzado sin blindaje | Bus | Bus principal, carrocería, chasis, tren motriz | CRC 15-bit | No | No inherente (por arbitraje) | $$ |
| CAN FD | Hasta 8 Mbps | 64 Bytes | Par trenzado sin blindaje | Bus | Tren motriz, control distribuido, sistemas avanzados | CRC 17 o 21-bit | No | No inherente (por arbitraje) | $$$ |
| FlexRAY | Hasta 10 Mbps | 254 Bytes | Par trenzado sin blindaje | Bus / Estrella / Mixta | Tren motriz de alto rendimiento, dirección/freno por cable | CRC 24-bit | Sí | Sí (TDMA) | $$$ |
| MOST | Hasta 150 Mbps (agregado) | Variable | Par trenzado sin blindaje o fibra óptica | Anillo / Estrella virtual | Sistemas de infoentretenimiento | CRC | Sí (Anillo) | Sí | $$ |
| Automotive Ethernet | Hasta 100 Mbps (por nodo) | 1500 Bytes | Par trenzado sin blindaje | Estrella / Árbol / Anillo | Diagnóstico, programación de ECU, sistemas avanzados | CRC 32-bit | No (en estándares básicos) | Sí (con TSN) | $$ |
¿Puede Arduino Interactuar con CAN Bus?
¡Absolutamente sí! Arduino, con su naturaleza flexible y la disponibilidad de módulos y librerías, es una excelente plataforma para experimentar y desarrollar proyectos que interactúen con redes CAN bus. Esto te permite, por ejemplo, leer datos de sensores de un coche, controlar dispositivos en una red industrial o simplemente aprender sobre el protocolo.
Para conectar un Arduino a una red CAN bus, necesitas hardware adicional. El chip más común utilizado como controlador CAN en módulos para Arduino es el MCP2515. Este chip implementa el protocolo CAN (hasta la versión 2.0B) y se comunica con el microcontrolador Arduino a través de la interfaz SPI (Serial Peripheral Interface).

Además del controlador MCP2515, necesitas un transceptor CAN. El transceptor (como el MCP2551 o TJA1050/TJA1051) es el encargado de adaptar las señales lógicas del controlador CAN (que operan a niveles de voltaje TTL/CMOS) a los niveles de voltaje diferenciales y robustos que se utilizan en los cables físicos del bus CAN (CAN High y CAN Low). Esencialmente, el transceptor es la interfaz física con el bus.
La forma más sencilla de empezar es utilizando un "CAN-BUS Shield" para Arduino. Estos shields integran tanto el controlador MCP2515 como el transceptor CAN en una placa que se conecta directamente sobre un Arduino Uno o compatible. También existen módulos CAN más pequeños que se conectan a Arduino mediante cables.
Interactuando con CAN Bus Usando Arduino y MCP2515
Una vez que tienes el hardware conectado, necesitas software para que el Arduino pueda enviar y recibir mensajes CAN. Afortunadamente, existen librerías para Arduino que simplifican enormemente esta tarea. Una librería popular para el MCP2515 es la librería `arduino-mcp2515`.
Esta librería te permite:
- Inicializar el controlador MCP2515, configurando la velocidad del bus CAN (baudrate) y el modo de operación (Normal, Loopback, Listen Only). Las velocidades comunes para CAN automotriz son 125 kbps, 250 kbps o 500 kbps.
- Definir mensajes CAN utilizando una estructura que típicamente incluye el ID del mensaje, el código de longitud de datos (DLC) y un array de bytes para los datos.
- Enviar mensajes al bus CAN.
- Recibir mensajes del bus CAN. Puedes hacerlo de forma síncrona (polling, revisando constantemente si hay mensajes) o asíncrona (usando interrupciones cuando llega un mensaje nuevo).
- Configurar máscaras y filtros de recepción para que el Arduino solo procese los mensajes con IDs específicos que le interesan, lo cual es crucial en redes CAN con mucho tráfico.
El proceso básico para enviar un mensaje implicaría configurar el shield/módulo, crear una estructura de mensaje con el ID y los datos deseados, y usar una función de la librería para enviar esa estructura. Para recibir, configurarías el shield/módulo, posiblemente establecerías filtros, y luego usarías una función para leer los mensajes disponibles, ya sea en un bucle principal o dentro de una rutina de interrupción.
La capacidad de configurar filtros y máscaras es muy importante. En una red CAN de vehículo, pueden circular cientos o miles de mensajes diferentes por segundo. Sin filtros, tu Arduino tendría que procesar cada mensaje, lo cual podría sobrecargar el microcontrolador. Las máscaras y filtros se configuran en el chip MCP2515 para que solo los mensajes que coincidan con los criterios definidos activen una interrupción o se almacenen en los búferes de recepción, haciendo la lectura mucho más eficiente.
Existen ejemplos y tutoriales que demuestran cómo usar estas librerías para tareas comunes como leer la velocidad del vehículo (si el mensaje correspondiente está disponible en el bus CAN y conoces su ID y formato) o enviar comandos simples a otros dispositivos CAN (si están diseñados para responder a ellos).

Preguntas Frecuentes sobre CAN Bus y Arduino
Aquí respondemos algunas dudas comunes:
¿Qué necesito exactamente para conectar Arduino a CAN bus?
Necesitas un Arduino (Uno, Mega, etc.), un módulo o shield controlador CAN (típicamente basado en MCP2515) que incluya también un transceptor CAN, y cables para conectar al bus CAN (CAN High y CAN Low).
¿Puedo leer datos de mi coche con Arduino CAN?
Sí, es posible. Sin embargo, necesitas saber los identificadores de los mensajes CAN que contienen los datos que te interesan (velocidad, RPM, temperatura, etc.) y cómo están codificados esos datos dentro del mensaje. Esta información a menudo no está documentada públicamente y puede variar entre fabricantes y modelos de vehículos.
¿Es seguro conectar mi Arduino al CAN bus de mi coche?
Deberías tener precaución extrema. Conectar hardware inadecuado o enviar mensajes incorrectos al bus CAN de un vehículo moderno puede afectar sistemas críticos de seguridad (frenos, dirección, airbags) o causar daños a las ECUs. Es recomendable practicar en bancos de prueba o vehículos no críticos primero y entender muy bien el protocolo.
¿Qué diferencia hay entre CAN 2.0 y CAN FD para proyectos con Arduino?
La mayoría de los módulos MCP2515 para Arduino implementan CAN 2.0B (estándar y extendido, hasta 1 Mbps). Si necesitas interactuar con una red CAN FD (que permite más datos por mensaje y velocidades de hasta 8 Mbps), necesitarás un controlador y transceptor CAN FD específicos, que son menos comunes y más caros en el ámbito de hobby que los componentes CAN 2.0.
¿Puedo enviar mis propios mensajes al CAN bus con Arduino?
Sí, puedes construir y enviar tramas CAN con tu Arduino. Sin embargo, para que otros dispositivos en el bus respondan a tus mensajes, deben estar programados para hacerlo. En un coche, enviar mensajes arbitrarios puede tener consecuencias inesperadas o ninguna reacción.
En resumen, el CAN bus es un pilar fundamental en la arquitectura electrónica de los vehículos y muchos otros sistemas. Su diseño robusto, eficiente y distribuido lo hace ideal para entornos exigentes. Gracias a la disponibilidad de módulos económicos y librerías, plataformas como Arduino permiten a entusiastas y desarrolladores explorar y trabajar con esta tecnología, abriendo un mundo de posibilidades para proyectos de monitorización, control y aprendizaje.
Si quieres conocer otros artículos parecidos a CAN Bus y Arduino: Comunicación en tu Proyecto puedes visitar la categoría Automóviles.
