Entorno Labview de Análisis, Desarrollo y Simulación

Transcripción

1 PROYECTO FIN DE CARRERA Entorno Labview de Análisis, Desarrollo y Simulación de Comunicaciones en Bus CAN AUTOR: Marco A. Sánchez Rodríguez. DIRECTOR: Enric Vidal Idiarte. TITULACIÓN: E.T.I. Especialitat en Electrònica Industrial. DATA: Junio / 2005.

2 Índice Índice. Introducción....8 Objetivos Metodología Capítulo 1....CAN (Controller Area Network) El Bus CAN según el Modelo OSI Capa Física Características de los Cables (ISO 11898) Características de los Cables (ISO ) Capa de Enlace Estructura de un Nodo CAN BasicCAN FullCAN Características Principales del Protocolo CAN Flexibilidad de Configuración Jerarquía de Nodos Multimaster Técnica de Acceso al Bus Comunicación Conducida por Eventos Comunicación Broadcast Iniciativa de Transmisión de Datos Designación de la Información Respuesta a Petición Remota

3 Índice Confirmación del Mensaje Transmitido Formato de Codificación y Sincronización de Datos Sincronización entre Nodos Velocidad de Transmisión Relación Velocidad de Transmisión / Longitud del Bus Características del Controlador de Línea Mensajes y Tramas del CAN Formato de las Tramas Tipos de Controladores Tipos de Tramas Trama de Datos Trama de Interrogación Remota (Trama Remota) Trama de Error Trama de Sobrecarga Arbitraje Detección y Corrección de Errores Detección de Error (Error Detection) Aislamiento de Módulos Defectuosos Productos de CAN Existentes...36 Capítulo 2....CANoe (CAN Open Environment) CANcardX y CANcab Arquitectura del CANoe Editor de Base de Datos CANdb Características Principales del Editor CANdb Ventana Principal

4 Índice Tipos de Objetos Vínculos entre Objetos Creación de una Base de Datos Programación con el CAPL Browser Características Principales del Editor CAPL Browser El Lenguaje de Programación CAPL Declaración de Variables Procedimientos de Eventos Editor de Paneles Programa CANoe Configuración de la Simulación Bloque Generador Bloque Generador Interactivo Nodo de Red Bloque de Repetición Vincular una Base de Datos a la Simulación Configuración de la Medida Monitorización de Tramas Datos Gráficos Estadística Estadística del Bus Almacenamiento de Datos Filtros Capítulo 3....NI-CAN (National Instruments CAN) Hardware NI-CAN Tipos de Placas y Tarjetas de CAN

5 Índice Tipos de Cables de CAN Software NI-CAN Librería de Funciones Labview Tipos de Objetos Objetos de Tipo CAN Network Interface Objetos de Tipo CAN Aplicaciones con Solución Híbrida Funciones Disponibles en la Librería Estado de las Funciones Buffer de Lectura y Escritura Modelo de Programación para Aplicaciones de CAN Tipos de Comunicación en los Objetos CAN Recepción de Tramas de Datos No Solicitadas Recepción de Tramas de Datos Solicitadas Transmisión de Tramas de Datos No Solicitadas Transmisión de Tramas de Datos Solicitadas Transmisión de Tramas de Datos Consecutivas Capítulo 4....Diseño del Simulador de Redes de CAN Editor de Base de Datos Estructura de la Aplicación Guardar, Abrir y Importar Fichero Configuración de la Red de CAN Lista de Nodos de Red Lista de Mensajes Lista de Señales Informe en Formato Excel

6 Índice Informe en Formato Texto Visualizador de Bus CAN Estructura de la Aplicación Tipos de Visualizadores Simulador de Bus CAN Estructura de la Aplicación Configuración de la Simulación Función Rendezvous Trace Window CAN Interactivo Capítulo Guía de Diseño para el Usuario Edit Data Base Tipos de objetos Menús del Edit Data Base Network Nodes Messages Signals Informes en Formato Texto o Excel Simulator Inicio de la Simulación Interactive CAN Trace Window Simulación mediante Paneles Funcionamiento del Programa Labview Creación de un Panel

7 Índice 5.4. Bus Monitor Test Network Bus Monitor con Base de Datos Capítulo 6....Test del Programa de Simulación Sistema de Comunicación con 3 Nodos Informe de la Base de Datos del Sistema Simulado Descripción de los Paneles diseñados Panel del Airbag_Module Panel del Smart_Cluster Simulación de la Red de Bus CAN Simulación sin Paneles Simulación con Paneles Visualización de Mensajes de un Nodo Real Conclusiones Apéndice Características Técnicas de la Tarjeta NI-CAN Tipo de Conectores Utilizados en el Cable PCMCIA-CAN Apéndice Características Técnicas de la Tarjeta CANcardX Características Técnicas del Cable CANcab Características Eléctricas del CANcab 1054 (LOW SPEED)

8 Índice Características Eléctricas del CANcab 251 (HIGH SPEED) Bibliografía

9 Introducción Introducción. Los vehículos han ido evolucionando a sistemas eléctricos más complejos para adaptarse a los requerimientos de los usuarios, que cada vez exigen más calidad, seguridad y confort en sus vehículos. Este aumento progresivo de dispositivos eléctricos y electrónicos, se vio acentuado a finales de los años 90, lo que supuso un aumento considerable de la longitud y número de cables. Para contrarrestar el crecimiento desmesurado de los cableados, se comenzaron a introducir buses de comunicación, que permitían reducir el número de cables y paralelamente aumentar la fiabilidad. Además de la reducción de cableado, la introducción de los buses, ha hecho posible el aumento de prestaciones de seguridad y confort en el vehículo, ya que el flujo de información se comparte con todos los módulos conectados a la red. A principios de los años 80, comenzaron a desarrollarse los primeros protocolos de buses de comunicación: CAN, VAN, J1850, entre otros. Estos buses se pueden clasificar en cuatro tipos diferentes según su velocidad de transmisión: Clase A: bus de comunicación serie de ámbito local, que controla funciones de bajo nivel de criticidad, como el sensor de lluvia, los motores para el movimiento de los asientos,... La cantidad de información que circula en estos nodos es poca y el tiempo de respuesta no es crítico, por lo tanto, la capacidad de transmisión es aprox. de 10 kbit/s. El protocolo LIN podría ser un ejemplo. Clase B: conexión de componentes de carrocería y electrónica de confort, como el panel de instrumentos, módulos de puertas, módulo de ayuda al aparcamiento... Las velocidades típicas de transmisión de datos son entre 50 y 100 kbit/s. El más utilizado es el bus CAN de baja velocidad, aunque algunos fabricantes franceses utilizan todavía el bus VAN. 8

10 Introducción Clase C: las funciones conectadas a este tipo de buses, son las del tren motopropulsor: unidades de control del motor, ABS, transmisión,... La transferencia de datos se realiza en tiempo real, entre valores de 200 kbit/s hasta 1 Mbit/s. El más utilizado es el protocolo CAN de alta velocidad. Clase D: los sistemas de radio, navegación y el resto de funciones multimedia disponibles en un vehículo, requieren mayores prestaciones en cuanto a la velocidad de transmisión. El medio más óptimo actualmente es la fibra óptica. La transferencia de datos puede alcanzar hasta los 10 Mbit/s. Los más utilizados son los protocolos MOST y D2B. El aumento de información entre módulos electrónicos, y en muchos casos de transferencia de información crítica para la seguridad de los ocupantes del vehículo, ha desencadenado un aumento drástico de la complejidad de las fases de diseño y validación de dichos módulos, por lo que se requieren herramientas de software y hardware que faciliten estas tareas. Una de las herramientas más utilizadas en el sector del automóvil, es la herramienta CANoe, que es utilizada para simular y desarrollar módulos de control electrónico y analizar el comportamiento de dicho módulo dentro de la red de comunicación CAN, donde será implementado. 9

11 Objetivos Objetivos. El aumento de sistemas de seguridad y confort en los vehículos, como se ha explicado en la introducción, derivó a la implementación de sistemas de control distribuidos dentro del automóvil. En estos sistemas, módulos de control electrónico conectados entre ellos mediante una red de bus CAN (protocolo más utilizado), se encargan de gestionar la información generada por sensores y actuadores. Debido a las duras especificaciones impuestas por los fabricantes de vehículos a los proveedores que desarrollan los módulos electrónicos, herramientas como el programa CANoe, ofrecen la oportunidad de disponer del sistema distribuido de control de la plataforma durante todo el proceso de desarrollo, teniendo así la oportunidad de chequear el funcionamiento del módulo creado dentro del entorno global del proyecto sin disponer del resto de módulos físicamente. El objetivo principal de este proyecto es desarrollar diferentes aplicaciones programadas en el entorno Labview, que puedan ser una alternativa al programa CANoe. 10

12 Metodología Metodología. Este proyecto surgió a partir de dos tarjetas de CAN, que estaban en desuso debido a la complejidad del software adjuntado. Cada vez que se quería simular algún módulo electrónico, se tenía que desarrollar una nueva aplicación en el entorno Labview. Como el problema radicaba en el software de comunicación entre el usuario y la tarjeta y, las tarjetas pertenecen a una empresa que se dedica a diseñar cajas inteligentes (Smart Junction Boxes), se pensó en diseñar un programa para el diagnóstico de éstas. Pero siendo más ambiciosos, por qué no ir más allá, y diseñar un programa para simular toda la red de Bus CAN. El problema principal era el tiempo de desarrollo de un programa de estas características, aunque una de las soluciones era diseñar sólo las funciones principales. El siguiente paso, fue buscar todo el material necesario y pensar en la metodología para realizar el proyecto. El material era muy diverso y bastante caro, por lo tanto intentamos conseguirlo de la misma empresa que había comprado las tarjetas. Material necesario: 1 o 2 Tarjetas PCMCIA-CAN/DS de National Instrument (ref ). Cables PCMCIA-CAN de National Instrument (ref y ). Software NI-CAN V1.0 (gratuito). 1 Licencia de Labview (Professional with Builder). 1 Licencia de Canoe V5.1 (ref ). 1 Ordenador con tarjeta PCMCIA. 1 Tarjeta CANcardX V1.0. de Vector Informatik (ref ). 1 Cable CANcab 1054 de Vecotr Informatik (ref ) A pesar de que el material descrito en los dos últimos puntos de la lista, fue imposible conseguirlo, y el ordenador obtenido era un Pentium III a 600 MHz con 256 MB de RAM, comenzamos a plantear nuestro proyecto. 11

13 Metodología El proyecto se planificó en siete fases, seis de las cuales coinciden con los capítulos que hemos desarrollado para realizar esta memoria. El capítulo CAN (Controller Area Network), sirve como introducción al protocolo de comunicación bus CAN, en el cual se describen las características principales de la Capa Física y de la Capa de Enlace del Modelo OSI. El capítulo Canoe (CAN Open Environment) incluye un análisis del funcionamiento del programa Canoe. El apartado correspondiente a la simulación, no pudo ser realizado con las tarjetas, al no disponer de ellas. En el capítulo NI-CAN (National Instruments-CAN) se describe el hardware y el software disponibles para programar las tarjetas y, sus características principales. Antes de describir el siguiente capítulo, debemos hacer referencia a una fase del proyecto que no ha sido incluida en la memoria, pero que también requirió algún tiempo, la familiarización con el programa Labview. LabView es un lenguaje de programación de alto nivel, de tipo gráfico y enfocado al uso en instrumentación. Pero como lenguaje de programación, debido a que cuenta con todas las estructuras de datos, puede ser usado para elaborar cualquier algoritmo que se desee, y utilizarlo en cualquier aplicación como en análisis, telemática, manejo de textos, etc., ideal para nuestro proyecto, ya que las tarjetas y el software disponible eran del mismo proveedor, National Instruments. El capítulo Diseño del Simulador de Redes de CAN, incluye una descripción de la arquitectura del programa que hemos diseñado. Como el lenguaje utilizado es de tipo gráfico, sólo hemos incluido en la memoria algunos ejemplos que nos ayudarán a comprender mejor el diseño del programa. El siguiente capítulo, Guía de Diseño para el Usuario, detalla los pasos que debe seguir el usuario para realizar una simulación. En el último capítulo, Test del Programa de Simulación, se examina el funcionamiento del programa diseñado, mediante dos ejercicios prácticos. 12

14 Capítulo 1 CAN (Controller Area Network) Capítulo 1. CAN (Controller Area Network). En febrero de 1986, Robert Bosch GmbH introdujo el protocolo de comunicación en serie CAN (Red de Área de Control) en el congreso de la Sociedad de Ingenieros de la Automoción (SAE). Actualmente, la mayoría de los coches fabricados en Europa, están equipados con al menos una red de comunicación CAN. También usada en otro tipo de transportes, como trenes o barcos, y en la automatización industrial. En definitiva, el protocolo CAN se ha convertido en uno de los sistemas de bus serie más utilizado en todo el mundo, principalmente en el sector del automóvil. El primer chip de control de CAN, el FullCAN-Chip 82526, no fue desarrollado hasta mediados de 1987 por la empresa Intel. Poco después, Philips Semiconductors también terminó el desarrollo de su primer chip, el 82C200. Ambos chips eran bastante diferentes respecto a la aceptación de filtros y manejo de errores. Por un lado, el concepto de FullCAN propiciado por Intel requería menos carga de CPU desde el microcontrolador conectado que la implementación de BasicCAN escogida por Philips. Por otro lado, el dispositivo FullCAN estaba limitado respecto el número de mensajes que podía recibir. La especificación del protocolo CAN de Bosch (versión 2.0) fue sometida a estandarización internacional a principios de los 90s. Después de varias disputas políticas debidas especialmente al bus de comunicación VAN (Vehicle Area Network) desarrollado por algunos de los mayores fabricantes de coches franceses, en 1993 se publicó la norma ISO para el bus CAN. Además del protocolo CAN, también fue definida la capa física para velocidades hasta 1 Mbit/s. En paralelo, el bus fault-tolerant para aplicaciones de baja velocidad (hasta 125 kbit/s) fue estandarizado en la ISO (sustituida posteriormente por la ISO ). En 1995, la norma ISO fue modificada, para añadir los identificadores de 29-bits, que hasta el momento eran de 11-bits solamente. 13

15 Capítulo 1 CAN (Controller Area Network) 1.1. El Bus CAN según el Modelo OSI. Las implementaciones hardware de CAN cubren de forma estandarizada las capas físicas y de enlace de la torre OSI (Open Systems Interconnection) de comunicaciones, mientras diversas soluciones software no estandarizadas, cubren la capa de aplicación. Las estandarizaciones ISO (International Standard Organization) a diferencia de las normas de Bosch, especifican también el medio de comunicación. Por lo tanto una implementación CAN a partir de las especificaciones de Bosch, no siempre será compatible con las normas ISO. Niveles del modelo OSI Capa de Aplicación Capa de Enlace Capa Física Aplicación Perfiles de dispositivos Establecimiento de conexión Contenido de los datos LLC (Logical Link Control) Filtrado de datos Notificación de sobrecarga Gestión de recuperación MAC (medium Access Control) Encapsulamiento de los datos Codificación de la trama Gestión del acceso al medio Detección de errores Señalización de errores Confirmación PLS (Physical Signalling) Codificación de bits Tiempo de bit Sincronización PMA (Physical Medium Access) Características del emisor/receptor MDI (Medium Dependent Interface) Conectores Soluciones no estándar Espec. Can Bosch ISO Figura 1.1. Niveles del Protocolo Bus CAN. 14

16 Capítulo 1 CAN (Controller Area Network) Capa Física. La capa física en CAN, es responsable de la transferencia de bits entre los distintos nodos que componen la red. Define aspectos como niveles de señal, codificación, sincronización y tiempos en que los bits se transfieren al bus. En la especificación original de CAN, la capa física no fue definida, permitiendo diferentes opciones para la elección del medio y niveles eléctricos de transmisión. Las características de las señales eléctricas en el bus, fueron establecidas más tarde por el estándar ISO para las aplicaciones de alta velocidad y, por el estándar para las aplicaciones de baja velocidad. Figura 1.2. Niveles de Tensión según el Estándar Figura 1.3. Niveles de Tensión según el Estándar

17 Capítulo 1 CAN (Controller Area Network) Características de los Cables (ISO 11898). Los cables según el estándar ISO deben reunir las características descritas en la figura siguiente. Características Impedancia Resistencia respecto a la longitud Retardo de línea Valor 108? mínimo, 120? nominal, 132? máximo 70 m? /m nominal 5 ns/m nominal Figura 1.4. Características de los Cables de Señal (ISO 11898). El par de cables trenzados (CAN_H y CAN_L) constituyen una transmisión de línea. Si dicha transmisión de línea no está configurada con los valores correctos, cada trama transferida causa una reflexión que puede originar fallos de comunicación. Como la comunicación en el CAN bus, fluye en ambos sentidos, ambos extremos de la red deben estar cerrados mediante una resistencia de 120?. Ambas resistencias deberían poder disipar 0.25 W de potencia. 120? 120? Figura 1.5. Red de Bus CAN de Alta Velocidad. 16

18 Capítulo 1 CAN (Controller Area Network) Características de los Cables (ISO ). Los cables según el estándar ISO deben reunir las características descritas en la figura 1.6. Características Inductancia respecto a la longitud: CAN_L y masa, CAN_H y masa, CAN_L y CAN_H Resistencia respecto a la longitud Valor 30 pf/m nominal 90 m? /m nominal Figura 1.6. Características de los Cables de Señal (ISO ). A diferencia del bus de alta velocidad, el bus de baja velocidad requiere dos resistencias en cada transceptor: RTH para la señal CAN_H y RTL para la señal CAN_L. Esta configuración permite al transceptor de bus de baja velocidad (fault-tolerant) detectar fallos en la red. La suma de todas las resistencias en paralelo, debe estar en el rango de 100? - 500?. Figura 1.7. Red de Bus CAN de Baja Velocidad (Fault-Toleramt). 17

19 Capítulo 1 CAN (Controller Area Network) Capa de Enlace. Esta capa está dividida en dos subniveles: El subnivel LLC (Logical Link Control). Gestiona el filtrado de los mensajes, las notificaciones de sobrecarga y la administración de la recuperación. El subnivel MAC (Medium Access Control). Es el núcleo del protocolo CAN y gestiona el tramado y desentramado de los mensajes, el arbitraje a la hora de acceder al bus y el reconocimiento de los mensajes, así como el chequeo de posibles errores y su señalización, el aislamiento de fallos en unidades de control y la identificación del estado libre del bus para iniciar una transmisión o recepción de un nuevo mensaje Estructura de un Nodo CAN. Dentro de un nodo CAN, se pueden distinguir una serie de módulos interconectados entre ellos: un bus de direcciones, datos y un control (paralelo) enlazando el controlador central, la memoria de los datos y el programa (donde está almacenado el software de aplicación y el controlador de red de alto nivel), los dispositivos de entrada y salida y, la interfaz de comunicación. Desde el punto de vista del controlador, la interfaz de comunicación se puede ver como un conjunto de buzones, donde cada uno de éstos sirve como registro lógico de interfaz entre el controlador local y los nodos remotos. Si un nodo quiere comunicarse, tiene que dar de alta los correspondientes buzones de recepción y transmisión antes de hacer ninguna operación. 18

20 Capítulo 1 CAN (Controller Area Network) Sensores y Actuadores Memoria E/S Microprocesador Buzones Controlador de CAN Transceptor Red de Bus Can Figura 1.8. Estructura de un Nodo Can. Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes pasos: Para inicializar, el programador especifica los parámetros de los registros de control de interfaz de comunicación, como las características del controlador de red o la velocidad de transmisión. A continuación, se inicializan todos los buzones. En cada buzón se especifica si es receptor o transmisor y, su estado inicial, inicializando su parte de datos del buffer. Posteriormente, para transmitir un mensaje es necesario poner los datos en el buffer de datos correspondiente al buzón de transmisión y activar el flanco de transmisión. Por último, la interfaz de red intenta comunicar los datos a través de la red. El estado de la transferencia se puede comprobar en el estatus de estado de cada buzón. 19

21 Capítulo 1 CAN (Controller Area Network) Una vez hecha la configuración inicial a partir del software de la capa de aplicación de esta manera, los nodos CAN funcionan de forma autónoma. La capa de aplicación puede reconfigurar los parámetros que se requieren de manera on-line. La estructura de los buzones permite diferenciar dos tipos de implementaciones: BasicCAN y FullCAN. La diferencia está en como los mensajes recibidos son filtrados usando el identificador del mensaje antes de ser escritos en el buzón correspondiente BasicCAN. BasicCAN proporciona un filtro para los mensajes que consiste en un Selector- Identificador-Recibir_Mensaje (RX-ID_Selector) y la correspondiente Mascara- Identificador-Recibir_Mensaje (RX-ID_Mask), los cuales son definidos por el usuario en la inicialización de la interfaz BasicCAN. El identificador de un mensaje que llega se compara con el selector, ignorando los bits enmascarados por la máscara. Si el identificador concuerda, los datos se guardan en la parte del buffer correspondiente al buzón Registro-Dato / Identificador-Recibir (RX-ID / Data-Reg). El registro permite almacenar más de un mensaje, ya que este tipo de filtrado con máscara, permite que diferentes identificadores pasen el filtrado. Los mensajes serán leídos en orden FIFO (First in, First out). Cada vez que un mensaje llega, el control del buffer de recepción de mensajes (RX-Control) genera una interrupción, que hace que el controlador lea el mensaje. Este mensaje, antes de ser seleccionado, debe pasar por otro filtro de tipo software. RX-ID_Mask RX-ID_Selector = 0x7F6 = 0x490 x = bits no considerados en la comparación = 0x490 Identificadores Recibidos = 0x491 = 0x498 = 0x499 Figura 1.9. Ejemplo de Selección de los Mensajes Recibidos. 20

22 Capítulo 1 CAN (Controller Area Network) Para la transmisión de mensajes, el proceso es el mismo, con un único buffer de transmisión de mensajes. De este funcionamiento se puede extraer que en la implementación BasicCAN, habrá un vínculo muy importante entre el controlador CAN y el microcontrolador asociado, ya que el micro será interrumpido para trabajar con todos y cada uno de los mensajes. Cada nodo solo transmitirá cuando se produzca un evento en alguna de las señales que le conciernen. Por lo tanto, este funcionamiento es adecuado para nodos encargados de transmitir informaciones esporádicas, disminuyendo así la ocupación del bus FullCAN. La estructura básica del FullCAN es la misma que el BasicCAN, pero con dispositivos hardware adicionales que hacen que la máscara de recepción sea siempre transparente, no necesitando un registro para definir la máscara. Por consiguiente, solo un mensaje corresponderá a un Selector-Identificador, anulando también el segundo filtrado de software en el controlador. Aunque para conseguir más flexibilidad, se utilizan diversos beffers, que pueden ser programados para recibir o transmitir. En estas implementaciones, el número de buzones es de 16. Esta implementación no necesita interrumpir el microcontrolador asociado, reduciendo su carga de trabajo. Está orientado a nodos encargados de transmitir señales con un nivel elevado de frecuencia de actualización y/o seguridad. Como se puede observar en la figura siguiente, también hay soluciones híbridas, dónde se puede encontrar un buzón BasicCAN conjuntamente con varios buzones FullCAN. 21

23 Capítulo 1 CAN (Controller Area Network) Figura Principales Diferencias entre BasicCAN y FullCAN Características Principales del Protocolo CAN. Las características más importantes del protocolo de comunicaciones CAN son descritas en los apartados siguientes Flexibilidad de Configuración. Una red de CAN es un sistema muy flexible, debido sobretodo a las características siguientes: 32 controladores de línea (un mayor número de nodos pueden ser conectados si las características eléctricas de los dispositivos no degradan la calidad de la señal según las especificaciones eléctricas establecidas por el estándar ISO y el estándar ISO ). La cantidad de datos a enviar en un mensaje puede variar de 0 a 8 bytes. La longitud máxima del mensaje es de 130 bits en CAN 2.0A y de 154 bits en 2.0B. 22

24 Capítulo 1 CAN (Controller Area Network) Jerarquía de Nodos Multimaster. CAN es un protocolo de comunicaciones multimaster, donde todos los nodos tienen el mismo derecho de acceso al bus y, cualquier nodo que transmita una trama, actúa como master durante la transmisión de la misma. Cuando el bus está libre, cualquier unidad electrónica puede empezar a transmitir el mensaje. El nodo con el mensaje de más alta prioridad, será el que gane la accesibilidad al bus. Al ser un bus de comunicaciones multimaster, aumenta la seguridad en el funcionamiento de la red, ya que si un nodo falla, el sistema no se colapsa y, puede seguir transmitiendo Técnica de Acceso al Bus. La técnica de acceso al medio que utiliza CAN es la CSMA/CD+CR (Carrier Sense, Multiple Access/Collision Detection and Collision Resolution). Con esta técnica, cada vez que un nodo tiene que transmitir, espera que el bus esté libre y, una vez que ocurre, empieza la transmisión sin dejar de leer los datos que se transmiten por el bus en ese momento. En el caso de que otro nodo acceda al bus simultáneamente, la colisión se resuelve con un arbritaje no destructivo a nivel de bit sobre el campo identificador, donde se asume el valor lógico 0 como dominante (alta prioridad) y el valor lógico 1 como recesivo (baja prioridad) y, se realiza la decisión con la función lógica AND Comunicación Conducida por Eventos. Debido a la característica multimaster del protocolo, la comunicación generalmente es conducida por eventos. Los eventos pueden ser de 3 tipos: esporádicos, periódicos o mixtos. Un mensaje esporádico es transmitido por un nodo, cuando un evento ocurre de manera ocasional. En cambio, un mensaje periódico es el resultado de un evento configurado previamente (por ejemplo, un reloj interno). El último tipo de mensaje es un mixto entre mensaje esporádico y periódico. 23

25 Capítulo 1 CAN (Controller Area Network) Comunicación Broadcast. En una red CAN, cada nodo coloca la información en el medio, donde todos los otros nodos, recibirán la información del nodo que está transmitiendo. La información será procesada por un nodo, cuando después de filtrar el campo identificador, se determine si esa información es relevante para este nodo o no. Este filtro tiene que ser definido por la aplicación, que especificará para cada nodo, qué mensajes son los que debe aceptar. Cables del bus de datos Figura Comunicación Broadcast Iniciativa de Transmisión de Datos. Dado que la comunicación se produce por eventos, ésta es iniciada automáticamente por el nodo donde la información es originaria. En el caso de que haya nodos que necesiten información con una cierta frecuencia, se asume que el nodo proveedor conoce este tiempo, con lo que podrá iniciar las transmisiones autónomamente, reduciendo así el tiempo de espera de la técnica petición-respuesta Designación de la Información. El nombre del mensaje (identificador) hace referencia a la información que contiene, no al nodo que la trasmite. El nombre del mensaje está contenido en el identificador, que a su vez, contiene la prioridad del mismo para realizar la elección. En el identificador no aparece el nombre del nodo que envía el mensaje, pero esta información 24

26 Capítulo 1 CAN (Controller Area Network) puede ser conocida indirectamente, ya que todos los nodos conocen en qué nodo se produce cada mensaje Respuesta a Petición Remota. A parte de la ya explicada transmisión por eventos, CAN también proporciona la técnica de trama de petición remota (Remote Request Frame). Esta trama permite a cualquier nodo que está inicializado como receptor de mensajes, pedir una transmisión de una trama a un nodo Confirmación del Mensaje Transmitido. Este protocolo dispone de un campo de confirmación (ACK: Aknowledge Field) en la trama de mensaje. Cada nodo que detecta un mensaje correcto en el bus, modifica el valor de este campo de recesivo a dominante, por lo tanto, si el transmisor lee el bit y no es dominante, es que se ha producido un error. Al funcionar por comunicación broadcast, todos los nodos responden con una señal de confirmación. De esta manera, un nodo puede determinar si está o no conectado a la red Formato de Codificación y Sincronización de Datos. CAN usa el formato NRZ (non-return-to-zero) para codificar los datos. Este tipo de codificación requiere poco ancho de banda para transmitir, pero en cambio, no puede garantizar la sincronización de la trama transmitida. Para resolver esta falta de sincronismo se emplea la técnica del bit stuffing : cada 5 bits consecutivos con el mismo estado lógico en una trama (excepto del delimitador de final de trama y el espacio entre tramas), se inserta un bit de diferente polaridad, de esta manera no se pierde la sincronización. Por otro lado este bit extra debe ser eliminado por el receptor de la trama, que solo lo utilizará para sincronizar la transmisión Sincronización entre Nodos. Después de una transmisión y recepción de un mensaje con éxito, se puede producir una interrupción de bit al mismo tiempo en todos los nodos de la red. Esta interrupción puede reajustar todos los relojes de todos los nodos del sistema. 25

27 Capítulo 1 CAN (Controller Area Network) Velocidad de Transmisión. La velocidad de transmisión es programable entre 10Kbps y 1 Mbps, utilizando normalmente fracciones binarias entre 1Mbps (1Mbps, 500Kbps, 250Kbps y así sucesivamente) Relación Velocidad de Transmisión / Longitud del Bus. Para realizar el arbitraje no destructivo, CAN requiere que la señalización que viaja de ida y vuelta (retardo de propagación) de un extremo a otro de la longitud máxima del cable se haga dentro del tiempo de bit. Este requerimiento es necesario para llevar a cabo el arbitraje no destructivo en el que se basa el protocolo. La relación entre la velocidad de transmisión y la longitud, ha de cumplir la siguiente desigualdad: 2t propagación < t bit Características del Controlador de Línea. El protocolo CAN proporciona dos modos de presentar la señal en el canal físico: Modo diferencial (+NRZ): requiere dos líneas para la señal y una para la tierra, leyéndose la señal como la diferencia entre las dos líneas de la señal. Proporciona una gran inmunidad al ruido. Modo balanceado (+NRZ): requiere una línea para la señal y una para la tierra, pero es muy susceptible al ruido 26

28 Capítulo 1 CAN (Controller Area Network) 1.4. Mensajes y Tramas del CAN Formato de las Tramas. El protocolo CAN tiene dos formatos diferentes para transmitir datos: el formato de trama estándar (Standard Frame), según la especificación CAN 2.0A y, el formato de trama extendida (Extended Frame) según la especificación CAN 2.0B. La principal diferencia entre ambos, es la longitud del identificador del mensaje (ID), que en el caso de la trama estándar es de 11 bits (2032 identificadores, ya que los 16 identificadores de menor prioridad están reservados) y en el caso de la extendida es de 29 bits (más de 536 millones de identificadores) Tipos de Controladores. CAN: Debido a los diferentes tipos de formato, existen tres tipos de controladores de Controladores 2.0A: únicamente transmiten y reciben mensajes en formato estándar. Si el formato es extendido se producirá un error. Controladores 2.0B pasivos: únicamente transmiten y reciben mensajes en formato estándar, pero admiten la recepción de mensajes en formato extendido, aunque los ignora posteriormente. Controladores 2.0B activos: transmiten y reciben mensajes en ambos formatos Tipos de Tramas. La transferencia de mensajes está controlada por cuatro tipos diferentes de tramas: Trama de datos: es la utilizada por un nodo normalmente para poner información en el bus. Puede incluir entre 0 y 8 bytes de información útil. 27

29 Capítulo 1 CAN (Controller Area Network) Trama de interrogación remota (remote frame): puede ser utilizada por un nodo para solicitar la transmisión de una trama de datos con la información asociada a un identificador dado. Tramas de error: utilizadas para indicar al resto de nodos la detección de un error, invalidando el mensaje erróneo (excepto cuando se produce un error de tipo pasivo). Trama de sobrecarga: permite que un nodo fuerce a los demás a alargar el tiempo entre transmisión de tramas sucesivas Las tramas de datos y las tramas remotas pueden ser configuradas en ambos formatos: trama estándar y trama extendida. Entre dos tramas enviadas consecutivamente existe una trama denominada espacio intertrama (interframe space), compuesta por 3 bits recesivos, durante la cual, no es posible iniciar ninguna transmisión de trama. Después de este periodo el controlador CAN observa si el bus está libre antes de iniciar una transmisión. Mientras el bus está libre o en reposo, se mantiene constantemente el nivel recesivo del bus Trama de Datos. Como hemos comentado anteriormente, las tramas de datos pueden ser configuradas de dos formas distintas, con formato estándar o extendido. La trama en formato estándar esta formada de los siguientes campos: Bit de start of frame (SOF). Consiste en un bit dominante que sincroniza todos los nodos con el flanco descendente de SOF, generado por el emisor cuando quiere iniciar una transmisión estando el bus libre (bus idle). Campo de arbitraje (Arbitration Field). Compuesto por 12 bits, 11 bits corresponden al identificador (ID) que define la prioridad del mensaje y 1 bit al RTR (Remote Transmission Request), que indica si el mensaje a transmitir es una trama de datos (RTR=0, dominante) o, una trama remota o de petición de datos (RTR=1, recesivo). 28

30 Capítulo 1 CAN (Controller Area Network) Campo de control (Control Field). Compuesto por 6 bits. Un bit de IDE (Identifier Extension Bit) que indica si la trama es estándar (IDE=0) o extendida (IDE=1), un bit dominante R0 usado para futuras expansiones del sistema y, 4 bits de DLC (Data Lenght Code) que indican el número de bytes a transmitir en el campo de datos. Campo de datos (Data field). Contiene la información del mensaje y su tamaño puede variar entre 0 y 8 bytes de datos. Campo de chequeo, CRC (Cyclic Redundant Code). Compuesto por 16 bits, 15 bits son usados para chequear los errores que se producen en la transmisión de la trama y el último bit (recesivo) delimita el campo CRC. Campo de confirmación, ACK (Aknowledge Field). Compuesto por 2 bits, ACKslot y ACK-delimiter, que son transmitidos como recesivos. Cada nodo que detecta un mensaje correcto en el bus, modifica el valor del bit de recesivo a dominante, por lo tanto, si el transmisor lee el bit y no es dominante, quiere decir que se ha producido un error. Esta confirmación no es completa, ya que si el transmisor lee un valor dominante, quiere decir que el mensaje se ha recibido correctamente en el bus, pero no que lo haya recibido la aplicación correspondiente. Bits de end of frame (EOF). Compuesto por 7 bits recesivos para indicar el final de trama. La trama extendida se diferencia de la estándar en algunos aspectos. El campo de arbitraje tiene 32 bits divididos en un grupo de 11 bits, igual que en el formato estándar y otro de 18 bits que el formato estándar no contiene. Ambos grupos, están separados por el bit SRR(Substitute Remote Request) recesivo y el bit IDE también recesivo que indica que la trama es extendida. El bit SRR al ser recesivo, garantiza el acceso prioritario al bus de la trama estándar. Seguidamente está el bit RTR (Remote Transmission Request), que podemos encontrar en ambos formatos. Además, el campo de control cambia su bit IDE (formato estándar), por un bit R1 dominante (formato extendido). 29

31 Capítulo 1 CAN (Controller Area Network) Formato Estándar IDE Formato Extendido Figura Composición de las Tramas Trama de Interrogación Remota (Trama Remota). El formato, por un lado es análogo a la trama de datos pero con el bit RTR recesivo, pero por el otro, una trama remota no incluye nunca datos. El identificador es el del mensaje que se solicita, el campo longitud corresponde a la cantidad de bytes requeridos Trama de Error. Las tramas de error son generadas por cualquier nodo que detecta un error. Consisten en dos campos: Indicador de error (Error Flag) y Delimitador de error (Error Delimter). El delimitador de error consta de 8 bits recesivos consecutivos y permite a los nodos reiniciar la comunicación limpiamente tras el error. El Indicador de error es distinto según el estado de error. Si un nodo en estado de error "Activo" detecta un error en el bus, interrumpe la comunicación del mensaje en proceso, generando un "Indicador de error activo" que 30

32 Capítulo 1 CAN (Controller Area Network) consiste en una secuencia de 6 bits dominantes sucesivos. Esta secuencia rompe la regla de relleno de bits y provocará la generación de tramas de error en otros nodos. Por lo tanto, el Indicador de error puede extenderse entre 6 y 12 bits dominantes sucesivos. Finalmente, se recibe el campo de delimitación de error formado por los 8 bits recesivos. Entonces la comunicación se reinicia y el nodo que había sido interrumpido reintenta la transmisión del mensaje. Si un nodo en estado de error "Pasivo" detecta un error, el nodo transmite un "Indicador de error pasivo", seguido de nuevo, por el campo delimitador de error. El indicador de error de tipo pasivo consiste en 6 bits recesivos seguidos, con lo cual, la trama de error para un nodo pasivo es una secuencia de 14 bits recesivos. De aquí se deduce que la transmisión de una trama de error de tipo pasivo no afectará a ningún nodo en la red, excepto cuando el error sea detectado por el propio nodo que está transmitiendo. En ese caso los demás nodos detectarán una alteración de las reglas de relleno y transmitirán a su vez tramas de error. Después de producirse la trasmisión de un indicador de error, cada nodo envía bits recesivos y monitoriza el bus hasta detectar un bit recesivo. Acto seguido, comienza la transmisión de siete bits recesivos más. Figura Trama de Error. 31

33 Capítulo 1 CAN (Controller Area Network) Trama de Sobrecarga. Una trama de sobrecarga tiene el mismo formato que una trama de error activo, sin embargo, sólo puede generarse durante el espacio entre tramas. Diferenciándose de esta forma de una trama de error, que sólo puede ser transmitida durante la transmisión de un mensaje. La trama de sobrecarga consta de dos campos, el Indicador de Sobrecarga, y el Delimitador. El indicador de sobrecarga consta de 6 bits dominantes que pueden ir seguidos por los generados por otros nodos, dando lugar a un máximo de 12 bits dominantes. En cambio, el delimitador es de 8 bits recesivos. Una trama de sobrecarga puede ser generada por cualquier nodo que debido a sus condiciones internas no está preparado para iniciar la recepción de un nuevo mensaje, retrasando de esta forma, el inicio de transmisión de un nuevo mensaje. Un nodo puede generar como máximo 2 tramas de sobrecarga consecutivas para retrasar un mensaje. Otra razón para iniciar la transmisión de una trama de sobrecarga es la detección por cualquier nodo de un bit dominante en los 3 bits de espacio entre tramas. Por todo ello, una trama de sobrecarga generada por un nodo conducirá a la generación de tramas de sobrecarga por los demás nodos, dando lugar como se ha indicado, a un máximo de 12 bits dominantes de indicador de sobrecarga Arbitraje. Un nodo al comenzar la transmisión de un mensaje, monitoriza constantemente el estado del bus. Si durante la transmisión del campo de arbitraje, detecta en el bus un bit dominante cuando el bit transmitido por ese nodo ha sido recesivo, detiene su transmisión y continua recibiendo la trama monitorizada en el bus. De esta forma no hay pérdida de información y no se destruye por colisión, ninguna trama de datos o remota. 32

34 Capítulo 1 CAN (Controller Area Network) Figura Ejemplo de Arbitraje del Bus CAN. En un bus único, un identificador de mensaje ha de ser asignado a un solo nodo concreto, es decir, se ha de evitar que dos nodos puedan iniciar la transmisión simultánea de mensajes con el mismo identificador y datos diferentes. La filosofía del protocolo CAN dice que cada mensaje es único en el sistema. Por ejemplo, si en un automóvil existe la variable "presión de aceite", esta variable ha de ser transmitida por un nodo concreto, con un identificador concreto, con longitud fija y coherente con la codificación de la información en el campo de datos Detección y Corrección de Errores. Una de las características más importantes y útiles del CAN es su alta fiabilidad, incluso en entornos de ruido extremos, el protocolo CAN proporciona una gran variedad de mecanismos para detectar errores en las tramas. Esta detección de error es utilizada para retransmitir la trama hasta que sea recibida con éxito. Otro tipo de error es el de aislamiento, y se produce cuando un dispositivo no funciona correctamente y un alto por ciento de sus tramas son erróneas. Este error de aislamiento impide que el mal funcionamiento de un dispositivo, condicione el funcionamiento del resto de nodos implicados en la red. 33

35 Capítulo 1 CAN (Controller Area Network) Detección de Error (Error Detection). En el momento en que un dispositivo detecta un error en una trama, este dispositivo transmite una secuencia especial de bits, el error flag (ver el apartado correspondiente a Trama de errores). Cuando el dispositivo que ha transmitido la trama errónea detecta el error flag, transmite la misma trama de nuevo. Los dispositivos de CAN detectan los errores descritos a continuación: Error de Bit (Bit Error). Durante la trasmisión de una trama, el nodo que transmite, simultáneamente monitoriza el bus. Cualquier bit que reciba con polaridad inversa a la que ha transmitido se considera un error de bit, excepto cuando se recibe durante el campo de arbitraje o en el bit de reconocimiento. Además, no se considera error de bit, la detección de bit dominante por un nodo en estado de error pasivo que transmite una trama de error pasivo. Error de relleno (Stuff Error). Se considera error de relleno la detección de 6 bits consecutivos del mismo signo, en cualquier campo que siga la técnica de relleno de bits, donde por cada 5 bits iguales se añade uno diferente. Error de CRC. Cuando el cálculo de CRC realizado por un receptor no coincide con el recibido en la trama. El campo CRC (Cyclic Redundant Code) contiene 15 bits y una distancia de Hamming de 6, lo que asegura la detección de 5 bits erróneos por mensaje. Estas medidas sirven para detectar errores de transmisión debido a posibles incidencias en el medio físico como por ejemplo el ruido. Error de forma (Form Error). Cuando un campo de formato fijo se recibe alterado en algún bit. Error de reconocimiento (Acknowledgment Error). Cuando ningún nodo cambia a dominante el bit de reconocimiento trama de error. Si un nodo advierte alguno de los fallos anteriores, inicia la transmisión de una 34

36 Capítulo 1 CAN (Controller Area Network) El protocolo CAN especifica diversos fallos en la línea física de comunicación, como por ejemplo línea desconectada, problemas con la terminación de los cables o líneas cortocircuitadas, aunque, no especifica como reaccionar en caso de que se produzca algún error de estos Aislamiento de Módulos Defectuosos. Para evitar que un nodo en problemas condicione el funcionamiento del resto de la red, se han incorporado a la especificación de CAN, medidas de aislamiento de nodos defectuosos que son gestionadas por los controladores. Un nodo puede encontrarse en uno de los tres estados siguientes en relación con la gestión de errores: Error activo (error Active). Es el estado normal de un nodo. Participa en la comunicación y en caso de detección de error envía una trama de error activa. Error pasivo (Error Passive). Un nodo en estado de error pasivo participa en la comunicación, sin embargo ha de esperar una secuencia adicional de bits recesivos antes de intentar transmitir y sólo puede señalar errores con una trama de error pasivo. Anulado (Bus off). En este estado deshabilitará su transceptor y no participará en la comunicación. La evolución entre estos estados se basa en dos contadores incluidos en el controlador de comunicaciones: Contador de errores de transmisión (TEC) y Contador de errores de recepción (REC). Inicio Error Activo REC <=127 o TEC <=127 REC >127 o TEC >127 y TEC <= Secuencias de 11 bits recesivos + TEC = 0 y REC = 0 Error Pasivo TEC >255 Anulado Figura Evolución entre Estados de Error. 35

37 Capítulo 1 CAN (Controller Area Network) 1.6. Productos de CAN Existentes. El estado del estándar alcanzado por CAN, lo convierte en una tecnología habitual en la industria, y numerosas firmas fabrican y distribuyen productos compatibles con este protocolo de comunicaciones. Entre los productos existentes se encuentran: Controladores de CAN que gestionan las comunicaciones a través de este protocolo. Se subdividen a su vez en: - Módulos CAN integrados en el mismo chip del microcontrolador. Existen versiones CAN con los microcontroladores más populares del mercado. - Controladores CAN independientes que permiten a microcontroladores no incluidos en la anterior categoría, comunicarse a través del CAN. - Tarjetas de conexión con PCs. Transceivers (transceptores) de CAN, que funcionan como interfaz entre el controlador y los cables de bus físico en una red de CAN. Software y herramientas diversas de monitorización de sistemas CAN, útiles tanto en la fase de diseño y simulación, como en la fase de testeo. 36

38 Capítulo 2 CANoe (CAN Open Environment) Capítulo 2. CANoe (CAN Open Environment). CANoe es una herramienta universal para desarrollar, simular y analizar entornos de comunicación para el bus CAN, que permite simular módulos de control electrónico y simular el entorno de comunicación o comunicarse con otros módulos mediante el bus CAN. En el caso de la industria automovilística, donde el número de unidades electrónicas incrementa día a día, y cada una de ellas suele estar desarrollada por empresas diferentes, mediante CANoe se tiene la oportunidad que todos los proveedores tengan o puedan disponer del sistema distribuido de control de la plataforma durante todo el proceso de desarrollo, teniendo la oportunidad de hacer el chequeo del funcionamiento de su módulo dentro del entorno global del sistema, sin tener los otros módulos físicamente CANcardX y CANcab. La tarjeta CANcardX es una tarjeta de adquisición de datos que cumple los estándares de tarjetas de PCMCIA. Utiliza el microcontrolador SAB-C1610 de Siemens y dos controladores de CAN SJA1000 de Philips, preparados para trabajar tanto en el modo estándar como en el extendido, así como para la recepción y el análisis de tramas remotas y, detectar o generar tramas de error en el bus. CANcardX proporciona dos canales de CAN completamente independientes el uno del otro con dos conexiones separadas. Los transceptores de CAN se encuentran integrados en los cables de conexión, los llamados CANcabs, que conectan la tarjeta con la red de CAN. Hay diversos modelos de CANcab, con diferentes tensiones, diferentes baud rates, un solo cable o modo diferencial. Para más información técnica sobre la tarjeta CANcardX o los cables CANcabs, ver el Apéndice 2. 37

39 Capítulo 2 CANoe (CAN Open Environment) 2.2. Arquitectura del CANoe. El programa CANoe está compuesto de los siguientes ejecutables: Con el editor CANdb++ se crean las bases de datos (*.dbc), las cuáles contienen la información simbólica. Esto incluye los nodos de red y los nombres simbólicos utilizados para mensajes, señales y variables de entorno. El CAPL Browser se utiliza para crear y compilar programas CAPL, que permiten configurar la simulación y la medición. Los programas creados pueden contener el identificador del mensaje y los datos, o los nombres de los mensajes y las señales definidas en la base de datos. El editor Panel es un programa para crear paneles gráficos de control que son cargados posteriormente en el CANoe, y representan la interfaz entre el usuario y la red de nodos simulada. En estos paneles pueden utilizarse tanto controles como visualizadores, además de elementos creados con cualquier editor de bitmap. Cada elemento es configurado con una variable de entorno que ha sido creada previamente en la base de datos. La aplicación CANoe.exe se utiliza para medir y simular sistemas de CAN. Para crear estos sistemas, el programa utiliza los datos creados en los programas anteriores y los asocia entre sí. Figura 2.1. Arquitectura del Programa CANoe. 38