Bus CAN
CAN (siglas del inglés Controller Area Network) es un protocolo de comunicaciones desarrollado por
la firma alemana Robert Bosch GmbH, basado en una topología bus para la transmisión de mensajes en
entornos distribuidos. Además ofrece una solución a la gestión de la comunicación entre múltiples CPUs
(unidades centrales de proceso).
El protocolo de comunicaciones CAN proporciona los siguientes beneficios:
Ofrece alta inmunidad a las interferencias, habilidad para el autodiagnóstico y la reparación de errores
de datos.
Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de
comunicar subsistemas de diferentes fabricantes sobre una red común o bus.
El procesador anfitrión (host) delega la carga de comunicaciones a un periférico inteligente, por lo
tanto el procesador anfitrión dispone de mayor tiempo para ejecutar sus propias tareas.
Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a
punto, excepto en los enganches.
Historia y evolución del protocolo CAN
El desarrollo del protocolo CAN comenzó en 1983 en la empresa Robert Bosch GmbH (comúnmente
conocida como Bosch). El protocolo fue oficialmente lanzado en 1986 en el congreso de la Sociedad de
Ingenieros Automotrices (SAE) en Detroit. Los primeros controladores CAN llegaron al mercado en 1987
de la mano de Intel y Philips.1
Bosch publicó posteriormente varias versiones de la especificación CAN, siendo la última de ellas la
especificación CAN 2.0, publicada en 1991. Esta especificación consta de dos partes; la parte A para el
formato estándar y la parte B para el formato extendido. Un dispositivo CAN que usa el formato estándar
utiliza identificadores de 11 bits y es comúnmente referido como dispositivo CAN 2.0A. Un dispositivo CAN
que usa el formato extendido utiliza identificadores de 29 bits y es comúnmente referido como dispositivo
CAN 2.0B. Los estándares CAN 2.0A/B y otros documentos de referencia relacionados con CAN son de
acceso libre a través de Bosch.2
En 1993 se publicó el estándar ISO 11898 del bus CAN y ha sido a partir de ese momento un estándar de la
Organización Internacional para la Normalización. Actualmente el bus CAN está estandarizado por las
siguientes normas:
ISO 11898-1:2015, Part 1: Data link layer and physical signalling
ISO 11898-2:2016, Part 2: High-speed medium access unit
ISO 11898-3:2006. Part 3: Low-speed, fault-tolerant, medium-dependent interface. Este estándar ha
sido revisado y confirmado en 2015
ISO 11898-4:2004, Part 4: Time-triggered communication. Este estándar ha sido revisado y confirmado
en 2013
ISO 11898-5:2007, Part 5: High-speed medium access unit with low power mode
ISO 11898-6:2013, Part 6: High-speed medium access unit with selective wake-up functionality
ISO 16845:2016, Conformance test plan
En 2011 Bosch, en cooperación con los fabricantes de automóviles y otros expertos del bus CAN, comenzó a
desarrollar la siguiente generación del CAN: el protocolo CAN FD (flexible data-rate). El CAN FD es
compatible hacia atrás, es decir, un controlador CAN FD es capaz de comprender un mensaje CAN clásico
(o CAN 2.0). Por el contrario, un controlador CAN clásico destruye un mensaje CAN FD emitiendo un
mensaje de error. El nuevo CAN FD es capaz de transmitir datos más rápido que 1 Mbps (la velocidad
máxima del CAN clásico). Ambos protocolos, el CAN clásico y el CAN FD, están estandarizados en la norma
ISO/DIS 11898-1.3 4
Principales características de CAN
CAN se basa en el modelo productor/consumidor, el cual es un concepto, o paradigma de comunicaciones
de datos, que describe una relación entre un productor y uno o más consumidores. CAN es un protocolo
orientado a mensajes, es decir la información que se va a intercambiar se descompone en mensajes, a los
cuales se les asigna un identificador y se encapsulan en tramas para su transmisión. Cada mensaje tiene un
identificador único dentro de la red, con el cual los nodos deciden aceptar o no dicho mensaje. Dentro de
sus principales características se encuentran:
Prioridad de mensajes.
Garantía de tiempos de latencia.
Flexibilidad en la configuración.
Recepción por multidifusión (multicast) con sincronización de tiempos.
Sistema robusto en cuanto a consistencia de datos.
Sistema multimaestro.
Detección y señalización de errores.
Retransmisión automática de tramas erróneas
Distinción entre errores temporales y fallos permanentes de los nodos de la red, y desconexión
autónoma de nodos defectuosos.
CAN fue desarrollado inicialmente para aplicaciones en los automóviles y por lo tanto la plataforma del
protocolo es resultado de las necesidades existentes en el área de la automoción. La Organización
Internacional para la Estandarización (ISO, International Organization for Standardization) define dos
tipos de redes CAN: una red de alta velocidad (hasta 1 Mbit/s), bajo el estándar ISO 11898-2, destinada
para controlar el motor e interconectar las unidades de control electrónico (ECU); y una red de baja
velocidad tolerante de fallos (menor o igual a 125 kbit/s), bajo el estándar ISO 11519-2/ISO 11898-3,
dedicada a la comunicación de los dispositivos electrónicos internos de un automóvil como son control de
puertas, techo corredizo, luces y asientos.
Tipos de bus CAN
La especificación de los buses CAN está recogida en el conjunto de estándares ISO 11898. Dicha
especificación define las dos primeras capas, la capa física y la capa de enlace de datos, del modelo OSI de
interconexión de sistemas. Sobre la base de dichos estándares, los buses CAN se pueden clasificar en dos
tipos:
CAN de alta velocidad (hasta 1 Mbit/s).
CAN de baja velocidad tolerante de fallos (hasta 125 kbit/s).
CAN de alta velocidad
ISO 11898-2, también llamado CAN de alta velocidad, usa un único bus lineal terminado en cada extremo
con sendas resistencias de 120 Ω. Es importante que el valor de las resistencias de terminación coincida
con la impedancia característica del bus, definida en 120 Ω, para evitar reflexiones en la línea que podrían
perturbar la comunicación. Con esta configuración la velocidad del bus es de un máximo de 1 Mbit/s.
Bus CAN de alta velocidad. ISO 11898-2
Extensiones del CAN de alta velocidad
La Organización Internacional para la Normalización (ISO) ha definido unas extensiones opcionales de la
capa física del bus CAN de alta velocidad (ISO 11898-2). Dichas extensiones están descritas en sus
respectivos estándares y son útiles para sistemas con requisitos específicos. También definen la
compatibilidad con ISO 11898-2.
ISO 11898-5 especifica la capa física con tasas de transmisión de hasta 1 Mbit/s para sistemas que
requieren bajo consumo de energía cuando no hay comunicaciones activas en el bus de datos.
ISO 11898-5 representa una extensión de ISO 11898-2 y aquellas implementaciones que cumplan
cualquiera de estas dos normas, es decir, los nodos CAN de alta velocidad con y sin bajo consumo de
energía, son interoperables entre sí y pueden coexistir en la misma red.5
ISO 11898-6 es una extensión de ISO 11898-2 y de ISO 11898-5. Esta extensión especifica la capa
física de un bus CAN de hasta 1 Mbit/s, proporcionando un método selectivo de activación de nodos
(wake-up) usando tramas CAN configurables. Las implementaciones de ISO 11898-6, ISO 11898-2 e
ISO 11898-5 son interoperables y se pueden usar en una misma red simultáneamente.6
CAN de baja velocidad tolerante de fallos
ISO 11898-3, también llamado CAN de baja velocidad tolerante de fallos, puede utilizar un bus lineal, un
bus en estrella o múltiples buses en estrella conectados por un bus lineal. El bus está terminado en cada
nodo por una fracción de la resistencia de terminación total. La resistencia de terminación total debería ser
un valor próximo a 100 Ω, pero no inferior a 100 Ω. Este estándar permite velocidades de hasta 125 kbit/s.
Bus CAN de baja velocidad tolerante de fallos. ISO 11898-3
CAN FD (flexible data-rate)
En 2011 Bosch comenzó a trabajar en una evolución del CAN. En 2012 lanzó CAN FD 1.0, que ofrece un
aumento de la tasa de transferencia después del arbitraje. De momento (2015), solo se ha definido la capa
de enlace de datos del CAN FD. La frecuencia se puede multiplicar hasta por 8 y el número máximo de
bytes por trama aumenta, siendo posible transmitir una mayor cantidad de datos en el mismo tiempo.4 La
especificación está recogida en el borrador de norma ISO/DIS 11898-1:2015.
Capa física
Define los aspectos del medio físico para la transmisión de datos entre nodos de una red CAN, las
características materiales y eléctricas y la transmisión del flujo de bits a través del bus.
Niveles de tensión del bus
La transmisión de señales en un bus CAN se lleva a cabo a través de dos
cables trenzados. Las señales de estos cables se denominan CAN_H
(CAN high) y CAN_L (CAN low) respectivamente. El bus tiene dos
estados definidos: estado dominante y estado recesivo. En estado
recesivo, los dos cables del bus se encuentran al mismo nivel de tensión
(common-mode voltage), mientras que en estado dominante hay una
diferencia de tensión entre CAN_H y CAN_L de al menos 1,5 V. La
transmisión de señales en forma de tensión diferencial, en comparación
con la transmisión en forma de tensiones absolutas, proporciona
Niveles de tensión del bus CAN
protección frente a interferencias electromagnéticas.
La tensión en modo común puede estar, según la especificación, en cualquier punto entre -2 y 7 V. La
tensión diferencial del bus (la diferencia entre CAN_H y CAN_L) en modo dominante debe estar entre 1,5
y 3 V. No se especifica, en cambio, que la tensión de modo común, cuando el bus está en modo recesivo,
deba estar comprendida entre la tensión de CAN_L y la tensión de CAN_H cuando el bus está en modo
dominante. Esto permite la conexión directa entre nodos que operen a distintas tensiones, e incluso nodos
que sufran diferencia de tensión entre sus respectivas tierras.7 8
Cable y conectores
Los distintos nodos de un bus CAN deben estar interconectados
mediante un par de cables trenzados con una impedancia característica
de 120 Ω, y puede ser cable apantallado o sin apantallar. El cable
trenzado proporciona protección frente a interferencias
electromagnéticas externas. Y si, además, está apantallado, la
protección será mayor pero a cambio de un incremento en el coste del Conector D-sub de 9 pines (DE-9)
cable.
El estándar CAN, a diferencia de otros estándares como el USB, no especifica ningún tipo de conector para
el bus y por lo tanto cada aplicación puede tener un conector distinto. Sin embargo, hay varios formatos
comúnmente aceptados como el conector D-sub de 9 pines, con la señal CAN_L en el pin 2 y la señal
CAN_H en el pin 7.
Las propiedades de la línea de transmisión limitan el ancho de banda de los datos. Orientativamente, se
aceptan los siguientes valores como límite de longitud del bus en función de la tasa de transferencia:9
Longitud del bus Tasa de transferencia
(m) (kbit/s)
40 1000
100 500
200 250
500 100
1000 50
Sincronización de bits
Todos los nodos de un bus CAN deben trabajar con la misma tasa de transferencia nominal. Dado que el
bus CAN no usa una señal de reloj separada, factores como la deriva de reloj y la tolerancia de los
osciladores causan que haya una diferencia entre la tasa de transferencia real de los distintos nodos. Por
ello es necesario un método de sincronización entre los nodos. La sincronización es especialmente
importante en la fase de arbitraje ya que durante el arbitraje cada nodo debe ser capaz de observar tanto
los datos transmitidos por él como los datos transmitidos por los demás nodos.
El requisito mínimo para un bus CAN es que dos nodos, estando en sendos extremos de la red con el
máximo retardo de propagación entre ellos, y cuyos controladores CAN tienen unas frecuencias de reloj en
los límites opuestos de la tolerancia de frecuencia especificada, sean capaces de recibir y leer correctamente
todos los mensajes transmitidos por la línea. Esto incluye que todos los nodos muestreen el valor correcto
de cada bit.10
El controlador CAN espera que una transición del bus de recesivo a dominante ocurra en un determinado
intervalo de tiempo. Si la transición no ocurre en el intervalo esperado, el controlador reajusta la duración
del siguiente bit en consecuencia. Dicho ajuste se lleva a cabo dividiendo cada bit en intervalos o cuantos
de tiempo (del latín quantum) y asignando los intervalos a los cuatro segmentos de cada bit:
sincronización, propagación, segmento de fase 1 y segmento de fase 2.
Ejemplo de cuantificación de un bit CAN con 10 cuantos de tiempo por bit
Segmento de sincronización: es el intervalo de tiempo en el que se supone que ocurren las
transiciones de recesivo a dominante.
Segmento de propagación: es el intervalo de tiempo que compensa los retardos de propagación a lo
largo de la línea.
Segmentos de fase 1 y 2: Se usan para llevar a cabo la resincronización de los nodos. El segmento de
fase 1 puede ser alargado o el 2 acortado para la resincronización. El punto de muestreo del bit se
encuentra inmediatamente después del segmento de fase 1. El punto de muestreo se encuentra
habitualmente cerca del 75 % de la duración total del bit.
La configuración de los segmentos del bit se hacen sobre la base de la frecuencia de reloj de cada
controlador CAN. Los segmentos se configuran individualmente para cada controlador en un mismo bus. A
efectos prácticos, la configuración de los segmentos del bit supone un compromiso entre la tasa de
transferencia y tolerancia de los osciladores.
Capa de enlace de datos
El protocolo CAN proporciona un acceso multimaestro al bus con una resolución determinista de las
colisiones. La capa de enlace de datos define el método de acceso al medio así como los tipos de tramas
para el envío de mensajes.
Acceso al medio (arbitraje)
La especificación del CAN usa los términos “dominante” y “recesivo” para referirse a los bits, donde un bit
dominante equivale al valor lógico 0 y un bit recesivo equivale al valor lógico 1. El estado inactivo del bus es
el estado recesivo (valor lógico 1). Cuando dos nodos intentan transmitir bits diferentes se denomina
colisión y el valor del bit dominante prevalece sobre el valor del bit recesivo. En ese caso el nodo que
intentaba transmitir el valor recesivo detecta la colisión y pasa a modo pasivo, es decir, deja de transmitir
para escuchar lo que transmite el otro nodo. Por esta razón es importante que todos los nodos estén
sincronizados y muestreen todos los bits del bus simultáneamente.
El arbitraje se produce durante los primeros bits de una trama o mensaje, durante la transmisión de lo que
se conoce como identificador del mensaje. Al final del proceso de arbitraje solo debe quedar un nodo con el
control del bus. Por ello cada nodo debe manejar identificadores únicos. Cuando un nodo pierde el
arbitraje aplaza la transmisión de su trama para intentarlo de nuevo cuando finalice la trama actual.
Conociendo los identificadores de todos las tramas que intentan ser transmitidas, se puede establecer de
manera determinista el orden en el que son transmitidas. Así, una trama CAN con identificador más bajo
(mayor número de bits dominantes en las primeras posiciones) tiene más prioridad que una trama con
identificador más alto.
Tipos de trama
Existen cuatro tipos de trama CAN:
Trama de datos (data frame)
Trama remota (remote frame)
Trama de error (error frame)
Trama de sobrecarga (overload frame)
Trama de datos
Una trama de datos CAN puede ser de uno de los dos siguientes formatos:
Formato base: con identificador de 11 bits.
Formato extendido: con identificador de 29 bits.
El estándar dice que un controlador CAN debe aceptar tramas en formato base, y puede o no aceptar
tramas en formato extendido. Pero en cualquier caso debe tolerar tramas en formato extendido. Es decir,
que si un controlador está configurado para que solo acepte tramas en formato base no debe lanzar un
error cuando reciba una trama en formato extendido, sino que simplemente no transmitirá el mensaje al
procesador central.
Formato base
Trama CAN en formato base con las tensiones eléctricas del bus y sin bits de relleno
El formato de la trama es el siguiente:
Longitud
Nombre del campo Finalidad
(bits)
Inicio de trama 1 Demarca el comienzo de una transmisión.
Identificador - ID (verde) 11 Un identificador (único) que también representa la prioridad de la trama.
Petición de transmisión Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones
1
remota - RTR (cian) remotas.
Bit de extensión de
1 Dominante (0) para el formato base (identificador de 11 bits).
identificador - IDE
Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como
Bit reservado (r0) 1
recesivo.
Código de longitud de Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor
4
datos - DLC (amarillo) que 8 el mensaje será de 8 bytes como máximo de cualquier modo.
0–64 (0-8 Datos de la trama (la longitud del campo viene dada por el código de longitud
Campo de datos (rojo)
bytes) de datos o DLC).
Verificación por redundancia cíclica. Código que verifica que los datos fueron
CRC 15
transmitidos correctamente.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de recibo -
1 El transmisor emite recesivo (1) y cualquier receptor emite dominante (0).
ACK
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama EOF 7 Debe ser recesivo (1).
Formato extendido
En el formato extendido los dos campos de identificador se combinan para formar el identificador de 29
bits. El formato de la trama es el siguiente:
Longitud
Nombre del campo Finalidad
(bits)
Inicio de trama 1 Demarca el comienzo de una transmisión.
Primera parte del identificador (único) que también representa la prioridad de la
Identificador A - ID_A 11
trama.
Sustituto de transmisión
1 Debe ser recesivo (1).
remota - SRR
Bit de extensión de
1 Recesivo (1) para el formato extendido (identificador de 29 bits).
identificador - IDE
Segunda parte del identificador (único) que también representa la prioridad de la
Identificador B - ID_B 18
trama.
Petición de transmisión Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones
1
remota - RTR remotas.
Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como
Bits reservados (r1, r0) 2
recesivo.
Código de longitud de Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor
4
datos - DLC que 8 el mensaje será de 8 bytes como máximo de cualquier modo.
0–64 (0-8 Datos de la trama (la longitud del campo viene dada por el código de longitud de
Campo de datos
bytes) datos o DLC).
Verificación por redundancia cíclica. Código que verifica que los datos fueron
CRC 15
transmitidos correctamente.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de
1 El transmisor emite recesivo (1) y cualquier receptor emite dominante (0).
recibo - ACK
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama - EOF 7 Debe ser recesivo (1).
Trama remota
Generalmente los datos se transmiten como trama de datos. Sin embargo, es posible que un nodo requiera
unos datos desde otro nodo. En ese caso, el primero puede enviar una trama remota para pedir el envío de
algún dato. El nodo que requiere la información envía entonces una trama con una petición de transmisión
remota (RTR = 1; recesivo). Las tramas remotas o de petición de transmisión remota solo se diferencian de
las tramas de datos en que las tramas remotas no tienen campo de datos.
Trama de error
La trama de error es una trama especial que viola las reglas de formato de las tramas CAN. Se transmite
cuando un nodo detecta un mensaje erróneo, y provoca que los demás nodos también transmitan una
trama de error. Un complejo mecanismo de contadores de error integrado en el controlador asegura que un
nodo no bloquee el bus con continuas tramas de error.
Trama de sobrecarga
Es similar a la trama de error en cuanto a que viola el formato de las tramas CAN. Es transmitida por un
nodo que se encuentra muy ocupado y el bus proporciona entonces un retardo extra entre tramas.
Separación entre tramas
Las tramas de datos y remotas están separadas por al menos tres bits recesivos (1). Después de eso, si se
detecta un bit dominante (0), es considerado como el inicio de una nueva trama. Las tramas de error y de
sobrecarga no respetan el espaciado entre tramas.
Bits de relleno (bit stuffing)
Para asegurar que hay suficientes transiciones recesivo-dominante y garantizar así la sincronización, un bit
de polaridad opuesta es insertado después de cinco bits consecutivos de la misma polaridad. Esta práctica
es necesaria debido a la codificación sin vuelta a cero del protocolo CAN. Los bits insertados son
eliminados por el receptor.
Todos los campos de la trama son rellenados a excepción del delimitador CRC, el acuse de recibo ACK, y el
fin de trama. Cuando un nodo detecta seis bits consecutivos iguales en un campo susceptible de ser
rellenado lo considera un error y emite un error activo. Un error activo consiste en seis bits consecutivos
dominantes y viola la regla de relleno de bits.
La regla de los bits de relleno implica que una trama puede ser más larga de lo esperado si se suman los
bits teóricos de cada campo de la trama.
Trama CAN antes y después de la adición de bits de relleno (en morado)
Protocolos basados en CAN
Los estándares del bus CAN solo especifican las dos primeras capas, la capa física y la capa de enlace de
datos, según el modelo OSI. Puesto que CAN no incluye tareas de capas superiores tales como
direccionamiento, control de acceso, transporte de bloques de datos mayores que una trama, etc., han ido
surgiendo protocolos en capas superiores basados en CAN, sobre todo en la capa de aplicación.
Cabe mencionar los siguientes:
ARINC 825 (para la aviación)
CANaerospace (para la aviación)
CAN Kingdom
CANopen (para automatización industrial)
CCP / XCP
DeviceNet (para automatización industrial)
EnergyBus (para vehículos eléctricos)
GMLAN (de General Motors)
ISO 15765-4
ISO 11783 o ISOBUS (para la agricultura)
ISO 14229
SAE J1939 (para vehículos pesados)
ISO 11992 (para tráileres pesados)
MilCAN
NMEA 2000 (para la industria marina)
OSEK
RV-C (para vehículos recreacionales)
SafetyBUS p (para la automatización industrial)
SmartCraft
Smart Distributed System (SDS)
VSCP (para la automatización de edificios)
Véase también
IEC 62196
Protocolos de comunicación para el automóvil
FlexRay
LIN
MOST
Protocolos de comunicación genéricos
RS-232
RS-485
Referencias
1. «CAN History» ([Link] CAN in Automation.
2. Bosch Semiconductor CAN Literature ([Link]
_modules_3/produkttabelle_ip_modules/can_literature_1/can_literature.html) Archivado ([Link]
[Link]/web/20140819090626/[Link]
es_3/produkttabelle_ip_modules/can_literature_1/can_literature.html) el 19 de agosto de 2014 en
Wayback Machine.
3. «CAN knowledge» ([Link] (en inglés). CAN in Automation. Consultado
el 19 de agosto de 2015.
4. «CAN FD - The basic idea» ([Link] (en inglés). CAN in
Automation. Consultado el 19 de agosto de 2015.
5. «ISO 11898-5:2007» ([Link] International
Organization for Standardization. Consultado el 22 de agosto de 2015.
6. «ISO 11898-6:2013» ([Link] International
Organization for Standardization. Consultado el 22 de agosto de 2015.
7. «AN228: A CAN Physical Layer Discussion» ([Link]
[Link]). Microchip Technology Inc. 2002. Consultado el 22 de agosto de 2015.
8. «SLLA337: Overview of 3.3V CAN Transcievers» ([Link] Texas
Instruments Inc. 2013. Consultado el 22 de agosto de 2015.
9. «SLLA 270: Controller Area Network physical layer requirements» ([Link]
[Link]). Texas Instruments Inc. 2008. Consultado el 22 de agosto de 2015.
10. «AN1798: CAN bit timing requirements» ([Link]
[Link]). Freescale Semiconductor. Consultado el 22 de agosto de 2015.
Enlaces externos
Wikimedia Commons alberga una categoría multimedia sobre Bus CAN.
[Link] Archivado ([Link]
04161544/[Link] el 4 de junio de 2004 en Wayback
Machine.
[Link]
Plataforma independiente de la discusión CANLIST ([Link] (en inglés)
CAN Protocolo Tutorial ([Link] (en inglés)
Obtenido de «[Link]
