SlideShare uma empresa Scribd logo
1 de 89
Baixar para ler offline
Bus de CAN
Controller Area Network
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
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
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
●
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
●
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
●
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
●
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
●
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
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
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
Comunicación intra-vehicular
Desarrollo del protocolo CAN
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
Comunicación intra-vehicular
Desarrollo del protocolo CAN
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
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
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
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
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
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
Previo al CAN
Protocolo CAN
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.
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.
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
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
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
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
Configuración Básica
●
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
Descripción del Bus CAN
Bit stuffing con No Retorno a Cero (NRZ)
Descripción del Bus CAN
●
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
●
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
●
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
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.
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.
●
CSMA/CD NDA – «Carrier Sense Multiple Access/Collision
Detection by Non Destructive arbitration»
Descripción del Bus CAN
Arbitraje mediante identificador
Descripción del Bus CAN
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
2) Trama de datos remotos
●
Un Remote Frame (tipo 2.0A):
El estándar de CAN
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
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
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
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
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
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
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
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
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
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
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
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
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
«Physical Layer»
Capa física de CAN
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
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
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
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
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
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
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
Estándar - ISO
Capa física de CAN
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
Electromagnetic interference - EMI
Capa física de CAN
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
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
Aplicaciones en la Industria automotriz
Estandarización
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
Niveles de señal : ISO-IS 11898
Estandarización
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
Controlador integrado de CAN
●
Filtros para mensajes implementados en Hardware
ordenan y filtran los mensajes sin interrumpir al CPU.
Tipos de controladores CAN
CAN (SAE J1939) e.g: Caterpillar 797
CAN (SAE J1939) e.g: Caterpillar 797
CAN (SAE J1939) e.g: Caterpillar 797
CAN (SAE J1939) e.g: Caterpillar 797

Mais conteúdo relacionado

Mais procurados

207 el audi tt coupe
207 el audi  tt coupe207 el audi  tt coupe
207 el audi tt coupeToni Gim
 
192 el passat 97 - tecnica
192 el passat 97 - tecnica192 el passat 97 - tecnica
192 el passat 97 - tecnicaToni Gim
 
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cablesJOHAMES CRUZ
 
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdf
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdfCAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdf
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdfMiguel Angel Sejas Villarroel
 
Geometria del sistema_de_suspension[1]
Geometria del sistema_de_suspension[1]Geometria del sistema_de_suspension[1]
Geometria del sistema_de_suspension[1]JULIOCESARQUISPEHUAM
 
Electrónica del automovial explicada con claridad
Electrónica del automovial explicada con claridadElectrónica del automovial explicada con claridad
Electrónica del automovial explicada con claridadCarlos Castro
 
75 VAS 5051 Equipo diagnosis.pdf
75 VAS 5051 Equipo diagnosis.pdf75 VAS 5051 Equipo diagnosis.pdf
75 VAS 5051 Equipo diagnosis.pdfjcarrey
 
Motor de combustión interna
Motor de combustión internaMotor de combustión interna
Motor de combustión internadavidpazmi
 
Introducción a las Redes automotrices - CAN/LIN
Introducción a las Redes automotrices - CAN/LINIntroducción a las Redes automotrices - CAN/LIN
Introducción a las Redes automotrices - CAN/LINInterlatin
 

Mais procurados (20)

207 el audi tt coupe
207 el audi  tt coupe207 el audi  tt coupe
207 el audi tt coupe
 
192 el passat 97 - tecnica
192 el passat 97 - tecnica192 el passat 97 - tecnica
192 el passat 97 - tecnica
 
Celdas sub estasion
Celdas sub estasionCeldas sub estasion
Celdas sub estasion
 
Obd ii y pruebas de emisiones
Obd ii y pruebas de emisionesObd ii y pruebas de emisiones
Obd ii y pruebas de emisiones
 
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables
53161054 manual-de-canalizaciones-por-sistemas-de-bandejas-porta cables
 
Ecu
EcuEcu
Ecu
 
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdf
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdfCAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdf
CAN BUS INTRODUCCION A LOS SISTEMAS DE COMUNICACION DEL VEHICULO rdmf.pdf
 
Geometria del sistema_de_suspension[1]
Geometria del sistema_de_suspension[1]Geometria del sistema_de_suspension[1]
Geometria del sistema_de_suspension[1]
 
Electrónica del automovial explicada con claridad
Electrónica del automovial explicada con claridadElectrónica del automovial explicada con claridad
Electrónica del automovial explicada con claridad
 
Rodamientos 1
Rodamientos 1Rodamientos 1
Rodamientos 1
 
75 VAS 5051 Equipo diagnosis.pdf
75 VAS 5051 Equipo diagnosis.pdf75 VAS 5051 Equipo diagnosis.pdf
75 VAS 5051 Equipo diagnosis.pdf
 
Cables de acero en maquinas de elevacion
Cables de acero en maquinas de elevacionCables de acero en maquinas de elevacion
Cables de acero en maquinas de elevacion
 
Perfiles rieles
Perfiles rielesPerfiles rieles
Perfiles rieles
 
Suspension neumatica
Suspension neumaticaSuspension neumatica
Suspension neumatica
 
Manual del instalador de sistemas gas gnc y glp
Manual del instalador de sistemas gas gnc y glpManual del instalador de sistemas gas gnc y glp
Manual del instalador de sistemas gas gnc y glp
 
Motor de combustión interna
Motor de combustión internaMotor de combustión interna
Motor de combustión interna
 
Introducción a las Redes automotrices - CAN/LIN
Introducción a las Redes automotrices - CAN/LINIntroducción a las Redes automotrices - CAN/LIN
Introducción a las Redes automotrices - CAN/LIN
 
Sensores automotrices
Sensores automotricesSensores automotrices
Sensores automotrices
 
Mecanica6
Mecanica6Mecanica6
Mecanica6
 
Tiida arranque-carga
Tiida arranque-cargaTiida arranque-carga
Tiida arranque-carga
 

Semelhante a CAN Bus: Protocolo de comunicación CAN

C1 CAN HS Y FD.pptx
C1 CAN HS Y FD.pptxC1 CAN HS Y FD.pptx
C1 CAN HS Y FD.pptxDavid Parari
 
Devicenet
DevicenetDevicenet
Devicenetdave
 
C1 CAN HS Y FD.pdf
C1 CAN HS Y FD.pdfC1 CAN HS Y FD.pdf
C1 CAN HS Y FD.pdfDavid Parari
 
Info plc net_redes_industriales
Info plc net_redes_industrialesInfo plc net_redes_industriales
Info plc net_redes_industrialesJonathan Cardenas
 
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdf
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdfDiapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdf
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdfjorgejvc777
 
Protocolos de comunicación para PLCs
Protocolos de comunicación para PLCsProtocolos de comunicación para PLCs
Protocolos de comunicación para PLCsUDO Monagas
 
Rtu unidad 3 - tema 4
Rtu   unidad 3 - tema 4Rtu   unidad 3 - tema 4
Rtu unidad 3 - tema 4UDO Monagas
 
Implementacion de redes industriales
Implementacion de redes industrialesImplementacion de redes industriales
Implementacion de redes industrialescarensil
 
Implementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialesImplementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialescarensil
 
Implementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialesImplementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialescarensil
 
Tarea bus de_campo[1]
Tarea bus de_campo[1]Tarea bus de_campo[1]
Tarea bus de_campo[1]jotikaus
 
Aportee individual y colaborativo
Aportee individual y colaborativoAportee individual y colaborativo
Aportee individual y colaborativojairdaza5
 
Profinet curso presentacion tecnm tlahuac.pptx
Profinet curso presentacion tecnm tlahuac.pptxProfinet curso presentacion tecnm tlahuac.pptx
Profinet curso presentacion tecnm tlahuac.pptxIVANFABIANLUNA
 
Cableado
CableadoCableado
Cableado1 2d
 
Paper practica2
Paper practica2Paper practica2
Paper practica2carensil
 
Cableadodedatosv2 2004
Cableadodedatosv2 2004Cableadodedatosv2 2004
Cableadodedatosv2 2004cesarbarriga
 
Redes De Cableado Estructurado
Redes De Cableado EstructuradoRedes De Cableado Estructurado
Redes De Cableado Estructuradoronald
 

Semelhante a CAN Bus: Protocolo de comunicación CAN (20)

C1 CAN HS Y FD.pptx
C1 CAN HS Y FD.pptxC1 CAN HS Y FD.pptx
C1 CAN HS Y FD.pptx
 
Devicenet
DevicenetDevicenet
Devicenet
 
C1 CAN HS Y FD.pdf
C1 CAN HS Y FD.pdfC1 CAN HS Y FD.pdf
C1 CAN HS Y FD.pdf
 
Info plc net_redes_industriales
Info plc net_redes_industrialesInfo plc net_redes_industriales
Info plc net_redes_industriales
 
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdf
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdfDiapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdf
Diapositiva de Estudio: PPT Protocolos de Comunicación Para PLCs.pdf
 
Protocolos de comunicación para PLCs
Protocolos de comunicación para PLCsProtocolos de comunicación para PLCs
Protocolos de comunicación para PLCs
 
Rtu unidad 3 - tema 4
Rtu   unidad 3 - tema 4Rtu   unidad 3 - tema 4
Rtu unidad 3 - tema 4
 
Bus can
Bus canBus can
Bus can
 
Implementacion de redes industriales
Implementacion de redes industrialesImplementacion de redes industriales
Implementacion de redes industriales
 
Implementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialesImplementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industriales
 
Implementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industrialesImplementacion y evaluacion de redes industriales
Implementacion y evaluacion de redes industriales
 
Tarea bus de_campo[1]
Tarea bus de_campo[1]Tarea bus de_campo[1]
Tarea bus de_campo[1]
 
Aportee individual y colaborativo
Aportee individual y colaborativoAportee individual y colaborativo
Aportee individual y colaborativo
 
Profinet curso presentacion tecnm tlahuac.pptx
Profinet curso presentacion tecnm tlahuac.pptxProfinet curso presentacion tecnm tlahuac.pptx
Profinet curso presentacion tecnm tlahuac.pptx
 
CAN_VAN.pdf
CAN_VAN.pdfCAN_VAN.pdf
CAN_VAN.pdf
 
Cableado
CableadoCableado
Cableado
 
Paper practica2
Paper practica2Paper practica2
Paper practica2
 
Cableadodedatosv2 2004
Cableadodedatosv2 2004Cableadodedatosv2 2004
Cableadodedatosv2 2004
 
Tecnologías de acceso
Tecnologías de accesoTecnologías de acceso
Tecnologías de acceso
 
Redes De Cableado Estructurado
Redes De Cableado EstructuradoRedes De Cableado Estructurado
Redes De Cableado Estructurado
 

Último

12 Clasificacion de las Computadoras.pdf
12 Clasificacion de las Computadoras.pdf12 Clasificacion de las Computadoras.pdf
12 Clasificacion de las Computadoras.pdfedwinmelgarschlink2
 
Guia para el registro en el sitio slideshare.pdf
Guia para el registro en el sitio slideshare.pdfGuia para el registro en el sitio slideshare.pdf
Guia para el registro en el sitio slideshare.pdflauradbernals
 
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señorkkte210207
 
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdf
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdfNUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdf
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdfisrael garcia
 
memoria de la empresa Pil Andina para d
memoria de la empresa Pil Andina para  dmemoria de la empresa Pil Andina para  d
memoria de la empresa Pil Andina para dRodrigoAveranga2
 
Las redes sociales en el mercado digital
Las redes sociales en el mercado digitalLas redes sociales en el mercado digital
Las redes sociales en el mercado digitalNayaniJulietaRamosRa
 

Último (6)

12 Clasificacion de las Computadoras.pdf
12 Clasificacion de las Computadoras.pdf12 Clasificacion de las Computadoras.pdf
12 Clasificacion de las Computadoras.pdf
 
Guia para el registro en el sitio slideshare.pdf
Guia para el registro en el sitio slideshare.pdfGuia para el registro en el sitio slideshare.pdf
Guia para el registro en el sitio slideshare.pdf
 
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor
02. Mr. Spencer (T.L. Sawn).pdf.libro de un señor
 
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdf
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdfNUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdf
NUVO PROGRAMAS DE ESCUELAS NUEVO-ACUERDO-CTE.pdf
 
memoria de la empresa Pil Andina para d
memoria de la empresa Pil Andina para  dmemoria de la empresa Pil Andina para  d
memoria de la empresa Pil Andina para d
 
Las redes sociales en el mercado digital
Las redes sociales en el mercado digitalLas redes sociales en el mercado digital
Las redes sociales en el mercado digital
 

CAN Bus: Protocolo de comunicación CAN

  • 1. Bus de CAN Controller Area Network
  • 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
  • 76. Estándar - ISO 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
  • 78. Electromagnetic interference - EMI 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
  • 81. Aplicaciones en la Industria automotriz 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
  • 83. Niveles de señal : ISO-IS 11898 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
  • 86. CAN (SAE J1939) e.g: Caterpillar 797
  • 87. CAN (SAE J1939) e.g: Caterpillar 797
  • 88. CAN (SAE J1939) e.g: Caterpillar 797
  • 89. CAN (SAE J1939) e.g: Caterpillar 797