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
protección frente a interferencias electromagnéticas.
Niveles de tensión del bus CAN
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 cable.
Conector D-sub de 9 pines (DE-9)
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 (r0)
Código de longitud de datos
- DLC (amarillo)
Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como
1
recesivo.
Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor
4
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 (rojo)
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 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» (http://www.can-cia.org/can-knowledge/can/can-history/). CAN in Automation.
2. Bosch Semiconductor CAN Literature (http://www.bosch-semiconductors.de/en/ubk_semiconductors/ip_
modules_3/produkttabelle_ip_modules/can_literature_1/can_literature.html) Archivado (https://web.archi
ve.org/web/20140819090626/http://www.bosch-semiconductors.de/en/ubk_semiconductors/ip_modules
_3/produkttabelle_ip_modules/can_literature_1/can_literature.html) el 19 de agosto de 2014 en
Wayback Machine.
3. «CAN knowledge» (http://www.can-cia.de/can-knowledge/) (en inglés). CAN in Automation. Consultado
el 19 de agosto de 2015.
4. «CAN FD - The basic idea» (http://www.can-cia.de/can-knowledge/can/can-fd/) (en inglés). CAN in
Automation. Consultado el 19 de agosto de 2015.
5. «ISO 11898-5:2007» (http://www.iso.org/iso/catalogue_detail.htm?csnumber=41284). International
Organization for Standardization. Consultado el 22 de agosto de 2015.
6. «ISO 11898-6:2013» (http://www.iso.org/iso/catalogue_detail.htm?csnumber=59165). International
Organization for Standardization. Consultado el 22 de agosto de 2015.
7. «AN228: A CAN Physical Layer Discussion» (http://ww1.microchip.com/downloads/en/AppNotes/00228
a.pdf). Microchip Technology Inc. 2002. Consultado el 22 de agosto de 2015.
8. «SLLA337: Overview of 3.3V CAN Transcievers» (http://www.ti.com/lit/an/slla337/slla337.pdf). Texas
Instruments Inc. 2013. Consultado el 22 de agosto de 2015.
9. «SLLA 270: Controller Area Network physical layer requirements» (http://www.ti.com/lit/an/slla270/slla27
0.pdf). Texas Instruments Inc. 2008. Consultado el 22 de agosto de 2015.
10. «AN1798: CAN bit timing requirements» (http://www.freescale.com/files/microcontrollers/doc/app_note/
AN1798.pdf). Freescale Semiconductor. Consultado el 22 de agosto de 2015.

Enlaces externos
Wikimedia Commons alberga una categoría multimedia sobre Bus CAN.
http://www.canbus.galeon.com/electronica/canbus.htm Archivado (https://web.archive.org/web/2004060
4161544/http://www.canbus.galeon.com/electronica/canbus.htm) el 4 de junio de 2004 en Wayback
Machine.
http://www.can-cia.org/
Plataforma independiente de la discusión CANLIST (https://canlist.org/) (en inglés)
CAN Protocolo Tutorial (http://www.kvaser.com/about-can/the-can-protocol/) (en inglés)

Obtenido de «https://es.wikipedia.org/w/index.php?title=Bus_CAN&oldid=152058630»