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
editarEl 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
editarCAN 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
editarLa 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
editarISO 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.
Extensiones del CAN de alta velocidad
editarLa 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
editarISO 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.
CAN FD (flexible data-rate)
editarEn 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
editarDefine 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
editar
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.
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
editar
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.
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 (m) |
Tasa de transferencia (kbit/s) |
|---|---|
| 40 | 1000 |
| 100 | 500 |
| 200 | 250 |
| 500 | 100 |
| 1000 | 50 |
Sincronización de bits
editarTodos 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.
- 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
editarEl 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)
editarLa 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
editarExisten 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
editarUna 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
editar
El formato de la trama es el siguiente:
| Nombre del campo | Longitud (bits) | Finalidad |
|---|---|---|
| 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 remota - RTR (cian) | 1 | Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones remotas. |
| Bit de extensión de identificador - IDE | 1 | Dominante (0) para el formato base (identificador de 11 bits). |
| Bit reservado (r0) | 1 | Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como recesivo. |
| Código de longitud de datos - DLC (amarillo) | 4 | Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor que 8 el mensaje será de 8 bytes como máximo de cualquier modo. |
| Campo de datos (rojo) | 0–64 (0-8 bytes) | Datos de la trama (la longitud del campo viene dada por el código de longitud de datos o DLC). |
| CRC | 15 | Verificación por redundancia cíclica. Código que verifica que los datos fueron transmitidos correctamente. |
| Delimitador CRC | 1 | Debe ser recesivo (1). |
| Hueco de acuse de recibo - ACK | 1 | El transmisor emite recesivo (1) y cualquier receptor emite dominante (0). |
| Delimitador ACK | 1 | Debe ser recesivo (1). |
| Fin de trama EOF | 7 | Debe ser recesivo (1). |
Formato extendido
editarEn 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:
| Nombre del campo | Longitud (bits) | Finalidad |
|---|---|---|
| Inicio de trama | 1 | Demarca el comienzo de una transmisión. |
| Identificador A - ID_A | 11 | Primera parte del identificador (único) que también representa la prioridad de la trama. |
| Sustituto de transmisión remota - SRR | 1 | Debe ser recesivo (1). |
| Bit de extensión de identificador - IDE | 1 | Recesivo (1) para el formato extendido (identificador de 29 bits). |
| Identificador B - ID_B | 18 | Segunda parte del identificador (único) que también representa la prioridad de la trama. |
| Petición de transmisión remota - RTR | 1 | Dominante (0) para tramas de datos y recesivo (1) para tramas de peticiones remotas. |
| Bits reservados (r1, r0) | 2 | Bit reservado. Debe ser dominante (0), pero aceptado tanto dominante como recesivo. |
| Código de longitud de datos - DLC | 4 | Número de bytes de datos en el mensaje, entre 0 y 8. Si este campo es mayor que 8 el mensaje será de 8 bytes como máximo de cualquier modo. |
| Campo de datos | 0–64 (0-8 bytes) | Datos de la trama (la longitud del campo viene dada por el código de longitud de datos o DLC). |
| CRC | 15 | Verificación por redundancia cíclica. Código que verifica que los datos fueron transmitidos correctamente. |
| Delimitador CRC | 1 | Debe ser recesivo (1). |
| Hueco de acuse de recibo - ACK | 1 | El transmisor emite recesivo (1) y cualquier receptor emite dominante (0). |
| Delimitador ACK | 1 | Debe ser recesivo (1). |
| Fin de trama - EOF | 7 | Debe ser recesivo (1). |
Trama remota
editarGeneralmente 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
editarLa 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
editarEs 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
editarLas 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)
editarPara 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.
Protocolos basados en CAN
editarLos 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
editar- Protocolos de comunicación para el automóvil
- Protocolos de comunicación genéricos
Referencias
editar- ↑ «CAN History». CAN in Automation.
- ↑ Bosch Semiconductor CAN Literature Archivado el 19 de agosto de 2014 en Wayback Machine.
- ↑ «CAN knowledge» (en inglés). CAN in Automation. Consultado el 19 de agosto de 2015.
- ↑ a b «CAN FD - The basic idea» (en inglés). CAN in Automation. Consultado el 19 de agosto de 2015.
- ↑ «ISO 11898-5:2007». International Organization for Standardization. Consultado el 22 de agosto de 2015.
- ↑ «ISO 11898-6:2013». International Organization for Standardization. Consultado el 22 de agosto de 2015.
- ↑ «AN228: A CAN Physical Layer Discussion». Microchip Technology Inc. 2002. Consultado el 22 de agosto de 2015.
- ↑ «SLLA337: Overview of 3.3V CAN Transcievers». Texas Instruments Inc. 2013. Consultado el 22 de agosto de 2015.
- ↑ «SLLA 270: Controller Area Network physical layer requirements». Texas Instruments Inc. 2008. Consultado el 22 de agosto de 2015.
- ↑ «AN1798: CAN bit timing requirements». Freescale Semiconductor. Consultado el 22 de agosto de 2015.
Enlaces externos
editar
Wikimedia Commons alberga una categoría multimedia sobre Bus CAN.- http://www.canbus.galeon.com/electronica/canbus.htm Archivado el 4 de junio de 2004 en Wayback Machine.
- http://www.can-cia.org/
- Plataforma independiente de la discusión CANLIST (en inglés)
- CAN Protocolo Tutorial (en inglés)
