El documento presenta una introducción al protocolo de comunicación Controller Area Network (CAN). Originalmente desarrollado para la industria automotriz, CAN permite la comunicación multipunto confiable y económica entre dispositivos electrónicos dentro de un vehículo. El protocolo especifica las capas física, de protocolo y de filtrado de mensajes, y ofrece características como mensajes priorizados y capacidad para que nodos pequeños se mantengan en la red sin sobrecarga. CAN se ha convertido en un estándar ampliamente adoptado no solo en la industria
2. 2
Objetivo
Exponer los aspectos más relevantes del protocolo
de comunicación CAN así como una breve
semblanza de sus aplicaciones en la industria.
La presentación incluye la parte de implementación
física de las señales de comunicación así como las
diferentes capas que componen el protocolo definido
en el estandar ISO-IS-11898 e ISO-IS-11519.
Al finalizar esta presentación el alumno deberá tener
una comprensión amplia de las capacidades de este
bus así como reconocer las complejidades
relacionadas con su implementación
3. 3
Introducción
CAN es una red confiable y económica que permite a varios
dispositivos dentro de la red comunicarse entre sí
(Comunicación multi-punto).
El protocolo permite a las unidades de control electrónico
(ECUs) tener una sola interfaz de comunicación (ver Figura),
en lugar de tener diferentes entradas analógicas y digitales
para cada dispositivo en el sistema. Esto reduce tanto el
costo como el peso.
4. 4
Introducción
Este protocolo es usado principalmente la industria automotriz,
pero también es ampliamente utilizada en variedad de otras
industrias.
El protocolo CAN especifica:
– La capa física
– La capa de protocolo
– La capa de filtrado de mensajes (protocolos add-on)
Características Destacadas
– Estructura que incluye mensajes con priorización
– El protocolo permite que "pequeños" nodos puedan
mantenerse en la red sin ser sobrecargados por la
cantidad de mensajes recibidos
5. ●
Originalmente, CAN (Controller Area Network, por sus siglas en
inglés) fue desarrollado por Robert Bosch GmbH en 1983 en
respuesta al cableado de punto a punto empleado por los
fabricantes automotrices para conectar dispositivos electrónicos
dentro de los vehículos.
●
Conforme los fabricantes comenzaron a utilizar más y más
dispositivos electrónicos en los vehículos, los arneses de estos
aumentaban de costo y peso.
●
Al reemplazar en los vehículos el cableado punto-a-punto por
redes de comunicación, se lograron reducir los costos, el peso,
así como la complejidad de conexión.
●
CAN se convierte entonces en un sistema de bus serial de alta
confiabilidad para la comunicación entre dispositivos inteligentes.
Introducción
6. ●
El protocolo fue lanzado oficialmente en 1986 en la Sociedad de
Ingenieros Automotrices (SAE) congreso en Detroit, Michigan y los
primeros chips controladores CAN, producidos por Intel y Philips,
salieron al mercado en 1987.
●
La industria automotriz la adoptó rápidamente y en 1991 Robert
Bosch GmbH publicó la especificación CAN 2.0.
●
Para 1993, se convirtió en el estándar internacional conocido como
ISO 11898 y desde 1994, se han estandarizado varios protocolos
CAN de alto nivel, como CANopen y DeviceNet.
●
CAN es uno de los cinco protocolos utilizados en el estándar de
diagnóstico del vehículo de OBD-II, para autos y camiones ligeros
vendidos en los Estados Unidos desde 1996, y el estándar EOBD,
para todos los vehículos de gasolina en la Unión Europea desde
2001 y todos los vehículos diésel desde 2004.
Introducción
7. ●
Actualmente CAN es un estándar internacional y está plasmado
en la norma ISO 11898 (para aplicaciones de alta velocidad) y en
la ISO 11519 (para aplicaciones de baja velocidad).
●
Un automóvil moderno puede tener hasta 70 unidades de control
electrónico (ECU) para diversos subsistemas. Típicamente, el
mayor procesador es la unidad de control del motor, que también
se conoce como "ECU" en el contexto de automóviles; otros se
utilizan para la transmisión, airbags, antibloqueo de frenos, control
de velocidad, sistemas de audio, ventanas, puertas, ajuste del
espejo, etc.
●
Algunos de estos subsistemas son formalmente independientes,
pero las comunicaciones entre sí son esenciales.
Introducción
8. ●
Los fabricantes de equipo médico utilizan CAN como una red
embebida en los dispositivos médicos. Los hospitales controlan
componentes operativos del cuarto como luces, máquinas de
rayos X y camas de pacientes.
●
CANopen también es utilizado en aplicaciones no industriales
como equipos de laboratorio, telescopios, puertas, elevadores etc.
●
Un automóvil moderno puede tener hasta 70 unidades de control
electrónico (ECU) para diversos subsistemas. Típicamente, el
mayor procesador es la unidad de control del motor. Otros se
utiliza en el control de la transmisión, de bolsas de aire, sistemas
anti-bloqueo de frenos, sistemas de control de audio, ventanas,
puertas, ajustes del espejo, etc.
Introducción
9. ●
Algunos subsistemas puede no ser criticos para controlar
algunos tipos de actuadores, sin embargo su información puede
ser de utilidad para algunos ajustes o adecuaciones (e.g. recibir
información de retroalimentación de los sensores).
●
Hoy en día el bus CAN también se utiliza como un bus de campo
en entornos de automatización industriales, principalmente debido
al bajo costo de algunos controladores y procesadores CAN.
●
Bosch mantiene patentes sobre la tecnología pero los
fabricantes de microprocesadores y semiconductores pagan los
derechos de uso para incorporar ese protocolo a sus productos.
●
Los costos relacionados se transmiten normalmente al cliente
mediante el precio del chip, lo que significa que los derechos ya
han sido pagados y se puede hacer uso libre de esta tecnología.
Introducción
10. Comunicación intra-vehicular
●
Un vehículo típico tiene un gran número de sistemas de control
electrónico:
●
Algunos de estos sistemas de control son:
●
Control del motor
●
Control del cambios de velocidad y control del carburador
●
Sistemas anti-bloqueo de las llantas (ABS) «Anti-block
systems»
●
Control de tracción (ASC) «Acceleration skid control»
Desarrollo del protocolo CAN
11. Comunicación intra-vehicular
●
Para mejorar el comportamiento del vehículo, era necesario que
los diferentes sistemas de control (y sus sensores) pudieran
intercambiar información.
●
Esto se hace generalmente por interconexión directa entre los
diferentes sistemas (es decir, el punto de cableado punto).
●
El requerimiento para el intercambio de información ha crecido
desde entonces hasta tal punto que se requiere una red de
comunicación con una longitud de incluso varias millas y una gran
cantidad de conectores. Lo anterior produjo problemas relativos al
costo de materiales, los tiempos de producción y la confiabilidad
del sistema.
Desarrollo del protocolo CAN
13. Comunicación intra-vehicular
●
Con los sistemas convencionales, los datos se
intercambian por medio de líneas de señal dedicadas.
●
Pero esto se ha vuelto cada vez más difícil y costoso
conforme las funciones de control se vuelven cada vez más
complejos.
●
En el caso particular de sistemas de control complejos, el
número de conexiones ya no se puede aumentar mucho
más.
●
Solución: Utilizar las redes de bus de campo para la
interconexión de los distintos dispositivos de control
Desarrollo del protocolo CAN
15. Aplicaciones Industriales
●
Los controladores CAN y sus circuitos de interface son
pequeños y están disponibles como dispositivos de bajo costo
«off-the-shelf». Ellos funcionan a altas velocidades, en tiempo
real, en ambientes hostiles. Lo anterior ha llevado a que los
dispositivos CAN puedan ser utilizados en una amplia gama de
aplicaciones distintas al de la industria del automóvil, gracias a:
●
Reducción de tiempos de diseño e integración (disponibilidad
inmediata, múltiples fabricantes y múltiples herramientas).
●
Menores costos de conexión ( cables y conectores más
pequeños y ligeros).
●
Confiabilidad mejorada (menos conexiones).
Desarrollo del protocolo CAN
16. Aplicaciones Industriales
●
Los beneficios en reducción de costes y mejora de la fiabilidad
han permeado a una amplia gama de productos:
●
Sistemas Marítimos de control y navegación
●
Maquinaria agrícola y minera
●
Máquinas-herramientas
●
Grandes Telescopios
●
Sistemas médicos
●
Sistemas de control en líneas de producción
●
En la fabricación de papel y maquinaria de embalaje
●
Maquinaria para la producción de textiles, etc.
Desarrollo del protocolo CAN
17. Aplicaciones Industriales
●
Algunos de los sistemas de comunicación de bus de campo
disponibles actualmente en el mercado:
●
RS-232
●
RS-485
●
ARCNET
●
IEC 1158-2
●
ModBus
●
BITBUS (IEEE 1118) [+]
Desarrollo del protocolo CAN
●
HART
●
Conitel
●
DF1
●
Data Highway
18. Definición
●
Controller Area Network (CAN) es un rápido bus serial
diseñado para proporcionar:
●
Un eficiente, confiable y económico enlace entre
sensores y actuadores.
●
CAN utiliza un cable de par trenzado para comunicarse a
velocidades de hasta 1 Mbit / s con un máximo de 40
dispositivos.
●
Los buses de campo «fieldbus» basados en CAN se
utilizan actualmente en gran número de líneas de producción
y automatización, en fábricas de todo el mundo.
Protocolo CAN
19. Características
●
Cualquier nodo puede acceder al bus cuando el bus está
desocupado
●
Arbitraje NO destructivo a nivel de bits para permitir 100% el uso
del ancho de banda, sin pérdida de datos.
●
Prioridad de mensaje variable basado en identificadores de
paquete de 11 bits (o 29 bits)
●
Conexiones «Peer-to-peer» y «multi-cast»
●
Detección de errores, señalización y reenvío de mensajes
completamente automático.
●
Paquetes de datos de 8 bytes de longitud
Protocolo CAN
20. CAN vs. comunicación «punto a punto»
●
Mediante la introducción de un único bus como único medio de
comunicación, en comparación con la red de punto a punto, se
encuentra un compromiso entre la simplicidad de acceso al canal
y la simplicidad del circuito
●
Dado que dos dispositivos podrían querer transmitir
simultáneamente, tenemos que tener un protocolo de
direccionamiento (media access control : MAC) que permita
manejar la situación.
●
CAN gestiona el acceso MAC mediante el uso de un identificador
único para cada uno de los mensajes salientes
●
El Identificador de un mensaje representa su prioridad.
Protocolo CAN
22. Con CAN
Protocolo CAN
La solución a este problema fue la conexión de los sistemas de control
a través de un sistema de bus serial. Este bus tenía que cumplir
algunos requisitos especiales debido a su uso en un vehículo.
23. Con CAN
Protocolo CAN
La adición de hardware-CAN en cada unidad de control permite
incorporar las «reglas» o protocolo necesario para transmitir y recibir
información a través del bus.
24. Version 2.0 A(standard) / B(Extended)
• A: Objetos, Transferencias y capas físicas
- La capa de Objetos: maneja y controla los mensajes
y decide la transmisión o recepción de los mensajes.
- La capa de Transferencia: asegura que los mensajes
cumplan con lo establecido en el protocolo
- La capa Física: envía y recibe los mensajes
• B: La capa de enlace de datos y la capa física
Especificación del protocolo CAN
25. Capa de objetos «Higher layer protocols»
●
Los protocolos de capas superiores se encargan de:
●
Estandarizar los procedimientos de puesta en marcha,
incluyendo la velocidad de transmisión.
●
Gestionar los tipos de mensajes dentro de la comunicación.
●
Determinar el diseño de los mensajes.
●
Proporcionar rutinas para el manejo de errores a nivel de
sistema.
●
Algunos protocolos de capa superior son: Device Net,
CANKingdom o CANopen
El Bus de CAN
26. Capa de Transferencia
●
En la capa de transferencia se especifica que tan pequeños
pueden ser los paquetes de datos transportados desde el punto A
al punto B. Es bastante simple ya que NO contiene:
●
Lineas o tramas de control del tráfico entre nodos
●
Direcciones de nodos
●
Marcas complejas para iniciar/para la comunicación, etc.
●
Además el protocolo NO permite el envío de paquetes o
mensajes mayores a 8 bytes.
El Bus de CAN
27. CAN es un bus tipo «Broadcast».
●
Esto significa que todos los nodos pueden "escuchar" todas las
transmisiones. No hay manera de enviar un mensaje a un nodo
específico; todos los nodos, invariablemente, recoger todo el
tráfico de menajes. El hardware puede, sin embargo,
proporcionar un filtrado local para que cada nodo reaccione a
sólo los mensajes de su "interés".
El Bus de CAN
29. ●
La capa física utiliza una transmisión diferencial
mediante un cable de par trenzado.
●
El bus utiliza un protocolo No Retorno a Cero
(NRZ) con relleno de bits.
●
Los nodos están conectados al cable del bus en
modo de colector abierto (compuerta AND):
●
Si un sólo nodo está mandando al bus a un 0
lógico (nivel GND dominante), entonces todo el
bus estará en ese estado sin importar el número
de nodos que transmitan un 1 lógico.
Descripción del Bus CAN
31. Bit stuffing con No Retorno a Cero (NRZ)
Descripción del Bus CAN
32. ●
La maxima velocidad de transferencia del bus para
conexiones de pares de hilos trenzados (el medio
más común utilizado para la conexión de un bus de
CAN) es de 1000 kbits/segundo a una distancia
máxima de 40 metros o 130 pies .
●
La longitud del mensaje es de un máximo de 8
bytes de datos por cada mensaje.
●
Los mensajes están protegidos por un esquema de
validación de datos tipo CRC.
●
Existe baja latencia entre la petición de transmisión
de datos y el inicio de la propia transferencia.
Descripción del Bus CAN
33. ●
El acceso al bus se realiza a través del protocolo de
comunicaciones seriales «Carrier Sense Multiple
Access/Collision Detection with Non-Destructive Arbitration».
Esto significa que la colisión de mensajes se evita
mediante arbitraje bit a bit sin pérdida de tiempo.
●
No hay una dirección explícita en los mensajes, en
cambio, cada mensaje lleva un valor numérico que
controla su prioridad en el bus, y también puede
servir como una identificación de los contenidos del
mensaje.
Descripción del Bus CAN
34. ●
Un esquema elaborado plan de manejo de errores
que se traduce en mensajes retransmitidos cuando no
son recibidos correctamente.
●
El protocolo provee medios eficaces para aislar
fallas y eliminar nodos defectuosos presentes en el
bus.
Descripción del Bus CAN
35. Arbitraje mediante identificador
Descripción del Bus CAN
●
Sólo si todos los nodos transmiten
los bits recesivos (unos lógicos), el
bus estará en el estado recesivo.
●
Si algún nodo transmite un bit
dominante (cero), el bus pasará al
estado dominante.
36. Arbitraje mediante identificador
Descripción del Bus CAN
●
En los diagramas, T representa al transmisor y R al receptor. Por lo
tanto Note que los nodos pueden verificar el estado de la línea
durante la transmisión. Esto es muy importante sobre para el arbitraje.
37. ●
CSMA/CD NDA – «Carrier Sense Multiple Access/Collision
Detection by Non Destructive arbitration»
Descripción del Bus CAN
39. Estructura del mensaje de CAN
●
Los dispositivos CAN envían datos a través de una red CAN en
paquetes llamados «frames». Un paquete de CAN consiste en las
siguientes secciones:
●
Arreglo de identificación, bytes de datos, bit de
reconocimiento o acknowledge, etc.
●
Los «frames» también son referidos como mensajes de CAN.
Descripción del Bus CAN
40. Estructura del mensaje de CAN
●
Bit SOF (start-of-frame) – indica el inicio de un mensaje con un
bit dominante (lógica 0)
●
Arreglo de Identificación o Arbitration ID – identifica el mensaje
e indica la prioridad del mismo. Los mensajes se presentan en dos
formas:
●
Estándar, que utiliza un arreglo de identificación de 11 bits, y
●
Extendido, que utiliza un arreglo de identificación de 29 bits.
Descripción del Bus CAN
41. Estructura del mensaje de CAN
●
Bit SRR (Substitute-remote-request) – Sustituye al bit RTR en
mensajes extendidos, debe ser recesivo para permitir la
afirmación de un bit RTR dominante por otro nodo que se
encuentre enviando un mensaje estándar.
●
Bit IDE (identifier extension) – bit también recesivo que permite
la diferenciación entre paquetes o mensajes estándar y
extendidos.
Descripción del Bus CAN
42. Estructura del mensaje de CAN
●
Bit RTR (remote-transmission-request) – sirve para diferenciar
entre un paquete remoto de uno de datos. Un bit RTR dominante
(lógica 0) indica un paquete de datos. Un bit RTR recesivo (lógica
1) indica el envío de un paquete remoto.
●
Bits r0 (bits de uso reservado) – RB1, RB0 para posterior uso.
●
Bits DLC (data length code) – indica el número de bytes que
contiene el campo de datos.
Descripción del Bus CAN
43. Estructura del mensaje de CAN
●
Campo de Datos – contiene de 0 a 8 bytes de datos.
●
Bits CRC (cyclic redundancy check) – contiene un código de
revisión cíclica redundante de 15 bits y un bit recesivo para
delimitar. El campo CRC se utiliza para detectar errores.
●
Bit ACK (ACKnowledgement) – cualquier controlador CAN que
recibe mensajes correctamente envía un bit de ACK al final del
mensaje. El nodo transmisor revisa la presencia del bit ACK en el
bus e intenta nuevamente la transmisión en caso de no detectarlo.
Descripción del Bus CAN
44. Estructura del mensaje de CAN
●
Bits EOF (End-of-frame) – Bits usados para marcar el fin del
mensaje. 7 bits recesivos se usan para delimitar el paquete y
permitir el envío de un nuevo mensaje.
Descripción del Bus CAN
45. Definiciones del estándar
●
Ahí se definen 4 tipos de mensajes «Frames»:
●
Trama de datos «Data Frame». El tipo de
mensaje utilizado predominantemente en el bus.
●
Trama de datos remotos «Remote Frame»
●
Trama de error «Frame Error»
●
Trama de sobrecarga «Overload Frame»
El estándar de CAN
46. Definiciones del estándar
●
Los mensajes aprovechan el plan de arbitraje definido a
nivel de bits para controlar el acceso al bus, y genera que
cada mensaje sea etiquetado con una prioridad.
●
El estándar CAN define también incluye un elaborado plan
para el manejo de errores y el confinamiento de los mismos.
●
CAN puede implementarse utilizando diferentes capas
físicas, y también con un número variado de diferentes
conectores.
El estándar de CAN
47. 1) Trama de datos
●
La trama de datos comprende las siguientes partes
principales (omitiendo algunos detalles por brevedad):
I. El campo de arbitraje, que determina la prioridad del
mensaje de 2 o más nodos que compiten por el control del
bus. El campo de arbitraje contiene:
●
Versión CAN 2.0A: Un identificador de 11 bits mas un
bit dominante (RTR) siempre dominante para las tramas
de datos.
●
Versión CAN 2.0B: Identificador de 29 bits, que junto
con el bit RTR contiene 2 bits recesivos: el SRR y el IDE.
El estándar de CAN
48. 1) Trama de datos
II. El campo de datos: Contiene de 0 a 8 bytes de datos.
III. El campo CRC: Contiene una suma de comprobación de
15 bits calculado sobre la mayoría de las partes del mensaje.
Esta suma de comprobación se utiliza para la detección de
errores.
IV. Un bit de acuse de recibo «Acknowledgement»; con el
cual cualquier nodo de CAN, que haya recibido el mensaje
correctamente, envía un bit de acuse de recibo al final de
cada mensaje. El transmisor verifica la presencia del bit de
reconocimiento y retransmite el mensaje si no se detectá
algún acuse de recibo.
El estándar de CAN
49. 1) Trama de datos
El estándar de CAN
• CAN 2.0B (“extended CAN” 29-bit ID) Data Frame.
CAN 2.0A (“standard CAN” 11-bit ID) Data Frame.
50. 1) Trama de datos
El estándar de CAN
CAN 2.0A (“standard CAN” 11-bit ID) Data Frame.
●
Nota 1: Vale la pena señalar que la presencia de un Bit de Confirmación en el
bus «Acknowledgement» no significa que ninguno de los destinatarios previstos
por el transmisor hayan recibido el mensaje. Lo único que confirma es que uno
o más nodos en el bus han recibido correctamente la trama de bits.
●
Nota 2: El identificador en el campo de arbitraje no es, a pesar de su nombre,
un medio para necesariamente «identificar» el contenido del mensaje.
51. 2) Trama de datos remotos
●
El «Remote Frame» es igual que la trama de datos
estándar pero con dos diferencias importantes:
●
Está marcado explícitamente como Remote Frame (el
bit RTR en el campo de arbitraje es recesivo), y
●
No existe un campo de datos.
●
El objetivo del «Remote Frame» es la solicitud a algún
nodo de la transmisión de una trama de datos en particular.
●
Si, por ejemplo, un nodo transmite un «Remote Frame»
con ID de arbitraje = 234, cualquier nodo, podría responder
con los datos solicitados mediante ese ID.
El estándar de CAN
52. 2) Trama de datos remotos
●
Las Tramas de datos remotos pueden entonces ser
empleadas para implementar un esquema de tráfico de bus
tipo petición-respuesta.
●
En la práctica, sin embargo, se utiliza muy poco el
«Remote Frame».
●
Vale la pena mencionar que la norma CAN no prevee el
comportamiento descrito anteriormente. La mayoría de los
controladores de la CAN pueden programarse ya sea para
responder automáticamente a un «Remote Frame», o para
simplemente notificar al CPU local el evento (esquema
global de «Broadcasting»).
El estándar de CAN
53. 2) Trama de datos remotos
●
Hay un inconveniente con el «Remote Frame»: la longitud
del código de datos se debe ajustar a la longitud del mensaje
de respuesta esperada. De lo contrario, el arbitraje no
funcionará.
●
A veces se afirma que el nodo que emitirá la respuesta
iniciará su transmisión tan pronto como se reconoce el
identificador, de "llenado", del «Remote Frame» vacío. Este
no es el caso.
El estándar de CAN
54. 2) Trama de datos remotos
●
Un Remote Frame (tipo 2.0A):
El estándar de CAN
55. 3) Trama de error
●
La trama de error «error frame» es un mensaje especial que
viola las reglas de la trama de mensajes CAN. Se transmite
cuando un nodo detecta un fallo en los datos y modifica el
estado del bus haciendo que los demás nodos detecten a su
vez un fallo. Cada nodo actuará en consecuencia mandando
sus propias tramas de error.
●
El transmisor deberá percatarse del error e intentará de
manera automática retransmitir el mensaje original.
●
Existe un elaborado esquema de contadores que garantizan
que los nodos no puedan transmitir de manera repetida los
«error frames».
El estándar de CAN
56. 3) Trama de error
●
La trama de error consiste en:
●
Un indicador de error, que
consiste en 6 bits consecutivos
del mismo valor (violando la regla
de relleno de bits), y
●
Un delimitador de la trama de
error, que consiste en 8 bits
recesivos.
El estándar de CAN
The Error Frame
57. 3) Trama de error
●
El delimitador de error proporciona
el espacio necesario para que los
otros nodos en el bus puedan enviar
sus propias tramas de error cuando
por fin detectan el primer «error
frame» mandada por el primer nodo.
El estándar de CAN
The Error Frame
58. 4) Trama de sobrecarga
●
La trama de sobrecarga u «overload frame» se menciona
meramente para completar la descripción ya que actualmente
ya NO se utiliza. Los recientes controladores CAN son lo
suficientemente inteligentes como para evitar su uso. De
hecho, el único controlador que genera las tramas de
sobrecarga es el 82526 y ya está obsoleto.
●
La trama de sobrecarga es muy similar a la trama de error
con respecto al formato y se transmite por un nodo que se
encuentra demasiado ocupado como para responder a algún
requerimiento de otro nodo.
El estándar de CAN
59. Detección de Error
●
Error de Bit : Cuando lo que está en el bus es diferente
de lo que fue transmitido (propio nodo transmisor).
●
Excepto cuando un bit recesivo fue transmitido
●
Durante el arbitraje
●
Durante la ranura de «acknowlegde»
●
Comprobación de redundancia cíclica (CRC)
●
Verificación de trama (se verifica la estructura de la
trama)
El estándar de CAN
60. Detección de Error
●
Errores del «ACKNOWLEDGE» (ausencia de un bit
dominante durante la ranura ack).
●
Monitoreo (cada nodo que transmite también observa el
nivel de bus y así detecta diferencias entre el bit enviados y el
bit recibido).
●
Durante el «Relleno de bits» (verifica el cumplimiento de la
regla de relleno.)
●
Un marco es válido para un transmisor si no hay error hasta
el final de la trama (EOF) y para un receptor si no hubo
errores desde el siguiente hasta el último bit del EOF.
El estándar de CAN
61. Comportamiento en caso de Error
●
En caso de error durante el relleno de bits o durante
el reconocimiento del bit de ACK «acknowledge»
●
Se inicia o levanta una bandera de error durante
el siguiente bit
●
En caso de un error en el CRC (trama correcta pero
información alterada)
●
Se envía una trama de error después del
«acknowledge»
El estándar de CAN
62. Comportamiento en caso de Error
●
Confinamiento de fallos
●
Cada vez que se produce un error de recepción, el
registro REC se incrementa
●
Cada vez que una trama se recibe correctamente, el
registro REC se decrementa
●
Mismo mecanismo para los errores de emisión con el
registro TEC
●
Los valores de TEC y REC pueden desencadenar
cambios de modo (… a continuación)
El estándar de CAN
63. Modos de Conexión
●
Para hacer cumplir el confinamiento fallos, los nodos pueden
exhibir un comportamiento en uno de estas 3 modalidades:
I. Error activo : Normalmente toma parte en la
comunicación y puede enviar una trama de error (seis bits
consecutivos dominantes) cuando detecta un error.
II. Error pasivo : Participa en la comunicación, pero no
debe enviar una trama de error activo. En lugar de ello,
enviará una señal de error pasiva (seis bits consecutivos
recesivos que no modifican el nivel del bus)
●
Algunas restricciones (silencio entre dos tx).
El estándar de CAN
64. Modos de Conexión
III. Fuera del Bus: No se pueden enviar o recibir cualquier
marco.
●
Un nodo es movido a este estado cuando existe una
solicitud de alguna entidad (nodo) con capacidades de
supervisión de correcto funcionamiento del bus.
●
Puede salir de este estado sólo por una instrucción
directa del usuario
El estándar de CAN
65. Detalles de la trama de Error
Dos campos : Bandera de error y
delimitador de error
●
Bandera de error «Error Flag»
●
Activa : 6 bits dominantes
●
Pasiva : 6 bits recesivos
●
Como todos los nodos verifican el estado del bús y
la bandera viola las reglas de relleno de bits, cada
nodo generará a su vez su propia bandera de error.
La bandera tendrá entonces una duración total de
entre 6 a 12 bits.
El estándar de CAN
66. Detalles de la trama de Error
●
Delimitador de error «Error Delimiter»
●
8 bits recesivos
●
Después de enviar la bandera de error todos los
nodos envían bits recesivos.
●
Tan pronto como un nodo detecta un bit recesivo,
envía siete bits recesivos
El estándar de CAN
67. Recuperación de un Error
●
Retransmisión automática
●
De todas las tramas que han perdido el
arbitraje
●
De todos las tramas que han sido afectadas
por errores durante su transmisión
El estándar de CAN
69. Características
●
CAN define varias capas físicas que se pueden implementar.
Estas capas físicas clasifican ciertos aspectos de la red, como lo
son los niveles eléctricos, esquemas de señales, impedancia en
los cables, tasa máxima de transmisión, y más. Las capas físicas
más ampliamente utilizadas son:
●
CAN de Alta Velocidad
●
CAN de Baja Velocidad/Tolerante a Fallas
●
CAN de un Solo Cable
●
CAN Seleccionable por Software
Capa física de CAN
70. CAN de Alta Velocidad
●
CAN de alta velocidad es la capa física más común. Las redes
de CAN de alta velocidad están implementada con dos cables y
permiten la comunicación con tasas de transferencia de hasta 1
Mb/s.
●
Otros nombres para CAN de alta velocidad incluye CAN C e ISO
11898-2.
●
Los dispositivos típicos CAN de alta velocidad incluyen los
sistemas de frenos anti-bloqueo, módulos de control del motor y
sistemas de emisiones.
Capa física de CAN
71. CAN de Baja Velocidad/Tolerante a Fallas
●
Las redes de CAN de baja velocidad/tolerante a fallas también
están implementadas con dos cables, pueden comunicarse con
dispositivos a una tasa de hasta 125 kb/s, y cuenta con
transceptores con capacidades de tolerancia a fallas.
●
Otros nombres para esta versión de CAN son CAN B e ISO
11898-3.
●
Algunos ejemplos de dispositivos típicos en automóviles que
incluyen esta versión del protocolo son dispositivos de confort o la
luz de frenos.
Capa física de CAN
72. CAN de un Solo Cable
●
Las interfaces CAN de un solo cable pueden comunicarse con
dispositivos a una tasa de hasta 33.3 kb/s (88.3 kb/s en modo de
alta velocidad).
●
Otros nombres para CAN de un solo cable incluyen SAE-J2411,
CAN A, y GMLAN.
●
Los dispositivos de un solo cable típicos dentro de un automóvil
no requieren de un alto desempeño, como por ejemplo los
ajustadores de asientos y espejos.
Capa física de CAN
73. CAN Seleccionable por Software
●
Existen fabricantes de equipo de pruebas o desarrollo mediante
los cuales se pueden configurar las interfaces CAN mediante
software de manera que se puedan utilizar cualquiera de los
transceptores incluidos (de alta velocidad, de baja
velocidad/tolerante a fallas o de un solo cable).
●
Contar con múltiples transceptores permite desarrollar
aplicaciones que requieren combinar diferentes estándares, o
permite diseñar un sólo tipo de módulo que pueda aplicarse a
diferentes situaciones de comunicación.
●
Ventaja adicional de estos dispositivos de selección de hardware
por Software es el cambio de rol dependiendo de las condiciones
de operación.
Capa física de CAN
74. Velocidad de transmisión del Bus CAN
●
Límites de Arbitraje de la velocidad del bus.
● Velocidad máxima = 2 x tpd
● Donde tpd
= retardo de
propagación del
medio eléctrico
(par trensado del Bus).
Capa física de CAN
75. Estándar - ISO
●
Una de las implementaciones más comunes y más
baratas para la capa física es usar pares de hilos
trenzados. Las líneas del bus toman los nombres
"CAN_H" y "CAN_L".
●
Las dos líneas de bus CAN_H y CAN_L son
manipuladas por cada nodo produciendo una señal
diferencial.
●
El par de hilos trenzados tiene en cada extremo una
terminación en forma de una resistencia (típicamente de
120 ohms) para evitar reflexiones de señal en el bus.
Capa física de CAN
77. Electromagnetic interference - EMI
●
Debido a la naturaleza diferencial de su transmisión el bus
de CAN es insensible a las interferencias electromagnéticas,
ya que ambas líneas de bus se ven afectadas del mismo
modo por cualquier interferencia, no afectando a la
información.
●
Para reducir aún más la sensibilidad frente a las
interferencias electromagnéticas, las líneas del Bus, se
pueden proteger mediante blindaje.
●
Esto también reduce la emisión electromagnética del propio
bus, especialmente cuando se emplean altas velocidades de
transmisión.
Capa física de CAN
79. Aplicaciones en la Industria automotriz
Pueden ser clasificadas en 3 categorías diferentes en
función de sus capacidades en tiempo real.
●
Clase A : Bus de baja velocidad (hasta 10 kbps), e.g.:
body control, control de clima y posición de asientos.
●
Clase B : Bus de media velocidad (de 10 kbps a 125
kbps) e.g.: tablero de control y módulos de diagnóstico.
●
Clase C : Bus de alta velocidad (de 125 kbps a 1 Mbps)
para aplicaciones en tiempo real como de gestión del
motor, caja de cambios, frenado ABS, etc.
Estandarización
80. Aplicaciones en la Industria automotriz
Las definiciones del estandar de acuerdo a la velocidad
son:
●
CAN de alta velocidad : Norma ISO-IS 11898 para
velocidades de transferencia de entre 125 kbps a
1 Mbps
●
CAN de baja velocidad : Norma ISO-IS 11519-2
para velocidades de transferencia de hasta 125 kbps
Estandarización
82. Niveles de señal : ISO-IS 11898
●
Un bit recesivo se representa dentro del bus de CAN si
ambas líneas toman un nivel de aproximado de 2,5 V de
manera que la tensión diferencial entre CAN_H y CAN_L
es aproximadamente de 0 V.
●
Un bit dominante en cambio está representado por una
señal en CAN_H de a aproximadamente 3,5 V y en
CAN_L de aproximadamente 1,5 V. Esto se traduce en
una tensión diferencial para un bit dominante de
aproximadamente 2V.
Estandarización
84. Controlador barato de CAN
●
El CPU podría verse desbordado por la elevada
cantidad de mensajes recibidos, incluso si estos no eran
para él.
Tipos de controladores CAN
85. Controlador integrado de CAN
●
Filtros para mensajes implementados en Hardware
ordenan y filtran los mensajes sin interrumpir al CPU.
Tipos de controladores CAN