Bus de CAN. Controller Area Network

Transcripción

1 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 e ISO-IS 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 2

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. 3

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 4

5 Introducción 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.

6 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 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 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.

7 Introducción Actualmente CAN es un estándar internacional y está plasmado en la norma ISO (para aplicaciones de alta velocidad) y en la ISO (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.

8 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.

9 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.

10 Desarrollo del protocolo CAN 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»

11 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.

12 Desarrollo del protocolo CAN Comunicación intra-vehicular

13 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

14 Desarrollo del protocolo CAN Comunicación intra-vehicular

15 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).

16 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.

17 Desarrollo del protocolo CAN Aplicaciones Industriales Algunos de los sistemas de comunicación de bus de campo disponibles actualmente en el mercado: RS-232 HART RS-485 Conitel ARCNET DF1 IEC Data Highway ModBus BITBUS (IEEE 1118) [+]

18 Protocolo CAN 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.

19 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

20 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.

21 Protocolo CAN Previo al CAN

22 Protocolo CAN Con 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 Protocolo CAN Con 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 Especificación del protocolo CAN 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

25 El Bus de 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

26 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.

27 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".

28 Configuración Básica

29 Descripción del Bus CAN 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.

30 Descripción del Bus CAN

31 Descripción del Bus CAN Bit stuffing con No Retorno a Cero (NRZ)

32 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.

33 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.

34 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.

35 Descripción del Bus CAN Arbitraje mediante identificador 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 Descripción del Bus CAN Arbitraje mediante identificador 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 Descripción del Bus CAN CSMA/CD NDA «Carrier Sense Multiple Access/Collision Detection by Non Destructive arbitration»

38 Descripción del Bus CAN Arbitraje mediante identificador

39 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.

40 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.

41 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.

42 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.

43 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.

44 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.

45 El estándar de 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»

46 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.

47 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.

48 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.

49 El estándar de CAN 1) Trama de datos CAN 2.0A ( standard CAN 11-bit ID) Data Frame. CAN 2.0B ( extended CAN 29-bit ID) Data Frame.

50 El estándar de CAN 1) Trama de datos 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 El estándar de CAN 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.

52 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»).

53 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.

54 El estándar de CAN 2) Trama de datos remotos Un Remote Frame (tipo 2.0A):

55 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».

56 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. The Error Frame

57 El estándar de CAN 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. The Error Frame

58 El estándar de CAN 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 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.

59 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)

60 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.

61 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»

62 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)

63 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).

64 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

65 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.

66 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

67 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

68 Capa física de CAN «Physical Layer»

69 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

70 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 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.

71 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 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.

72 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.

73 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.

74 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).

75 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.

76 Capa física de CAN Estándar - ISO

77 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.

78 Capa física de CAN Electromagnetic interference - EMI

79 Estandarización 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.

80 Estandarización Aplicaciones en la Industria automotriz Las definiciones del estandar de acuerdo a la velocidad son: CAN de alta velocidad : Norma ISO-IS para velocidades de transferencia de entre 125 kbps a 1 Mbps CAN de baja velocidad : Norma ISO-IS para velocidades de transferencia de hasta 125 kbps

81 Estandarización Aplicaciones en la Industria automotriz

82 Estandarización Niveles de señal : ISO-IS 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.

83 Estandarización Niveles de señal : ISO-IS 11898

84 Tipos de controladores CAN Controlador barato de CAN El CPU podría verse desbordado por la elevada cantidad de mensajes recibidos, incluso si estos no eran para él.

85 Tipos de controladores CAN Controlador integrado de CAN Filtros para mensajes implementados en Hardware ordenan y filtran los mensajes sin interrumpir al CPU.

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