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. Índice Índice. Introducción. .......................................................................................... 8 Objetivos. ..............................................................................................10 Metodología. .........................................................................................11 Capítulo 1. ................................................... CAN (Controller Area Network). ................................................................................................................13 1.1. El Bus CAN según el Modelo OSI..................................................14 1.1.1. 1.1.1.1. Características de los Cables (ISO 11898). ......................................... 16 1.1.1.2. Características de los Cables (ISO 11519-2)....................................... 17 1.1.2. 1.2. Capa Física..........................................................................................15 Capa de Enlace....................................................................................18 Estructura de un Nodo CAN. .........................................................18 1.2.1. BasicCAN. ..........................................................................................20 1.2.2. FullCAN..............................................................................................21 1.3. Características Principales del Protocolo CAN............................22 1.3.1. Flexibilidad de Configuración. ...........................................................22 1.3.2. Jerarquía de Nodos Multimaster. ........................................................23 1.3.3. Técnica de Acceso al Bus. ..................................................................23 1.3.4. Comunicación Conducida por Eventos...............................................23 1.3.5. Comunicación Broadcast. ...................................................................24 1.3.6. Iniciativa de Transmisión de Datos. ...................................................24 1.3.7. Designación de la Información. ..........................................................24 1.3.8. Respuesta a Petición Remota. .............................................................25 1 Índice 1.3.9. Confirmación del Mensaje Transmitido. ...........................................25 1.3.10. Formato de Codificación y Sincronización de Datos. ........................25 1.3.11. Sincronización entre Nodos. ...............................................................25 1.3.12. Velocidad de Transmisión. .................................................................26 1.3.13. Relación Velocidad de Transmisión / Longitud del Bus. ...................26 1.3.14. Características del Controlador de Línea............................................26 1.4. Mensajes y Tramas del CAN. .........................................................27 1.4.1. Formato de las Tramas........................................................................27 1.4.1.1. 1.4.2. Tipos de Controladores........................................................................ 27 1.4.2.1. Trama de Datos.................................................................................... 28 1.4.2.2. Trama de Interrogación Remota (Trama Remota). ............................. 30 1.4.2.3. Trama de Error..................................................................................... 30 1.4.2.4. Trama de Sobrecarga. .......................................................................... 32 1.4.3. 1.5. Tipos de Tramas..................................................................................27 Arbitraje. .............................................................................................32 Detección y Corrección de Errores. ...............................................33 1.5.1. Detección de Error (Error Detection). ................................................34 1.5.2. Aislamiento de Módulos Defectuosos. ...............................................35 1.6. Productos de CAN Existentes.........................................................36 Capítulo 2. ............................................... CANoe (CAN Open Environment). ................................................................................................................37 2.1. CANcardX y CANcab. ....................................................................37 2.2. Arquitectura del CANoe. ................................................................38 2.3. Editor de Base de Datos CANdb++................................................39 2.3.1. Características Principales del Editor CANdb++. ..............................39 2.3.2. Ventana Principal................................................................................40 2 Índice 2.3.3. Tipos de Objetos. ................................................................................41 2.3.4. Vínculos entre Objetos........................................................................43 2.3.5. Creación de una Base de Datos...........................................................43 2.4. Programación con el CAPL Browser. ...........................................46 2.4.1. Características Principales del Editor CAPL Browser. ......................46 2.4.2. El Lenguaje de Programación CAPL..................................................47 2.4.2.1. Declaración de Variables..................................................................... 47 2.4.2.2. Procedimientos de Eventos.................................................................. 49 2.5. Editor de Paneles. ............................................................................50 2.6. Programa CANoe. ...........................................................................52 2.6.1. Configuración de la Simulación. ........................................................53 2.6.1.1. Bloque Generador................................................................................ 55 2.6.1.2. Bloque Generador Interactivo. ............................................................ 57 2.6.1.3. Nodo de Red. ....................................................................................... 58 2.6.1.4. Bloque de Repetición. ......................................................................... 60 2.6.1.5. Vincular una Base de Datos a la Simulación....................................... 61 2.6.2. Configuración de la Medida. ..............................................................62 2.6.2.1. Monitorización de Tramas................................................................... 62 2.6.2.2. Datos.................................................................................................... 63 2.6.2.3. Gráficos. .............................................................................................. 64 2.6.2.4. Estadística............................................................................................ 64 2.6.2.5. Estadística del Bus............................................................................... 66 2.6.2.6. Almacenamiento de Datos................................................................... 67 2.6.2.7. Filtros................................................................................................... 68 Capítulo 3. .......................................NI-CAN (National Instruments–CAN). ................................................................................................................69 3.1. Hardware NI-CAN. .........................................................................69 3.1.1. Tipos de Placas y Tarjetas de CAN. ...................................................69 3 Índice 3.1.2. Tipos de Cables de CAN. ...................................................................70 3.2. Software NI-CAN. ...........................................................................71 3.3. Librería de Funciones Labview......................................................72 3.3.1. Tipos de Objetos. ................................................................................72 3.3.1.1. Objetos de Tipo CAN Network Interface............................................ 72 3.3.1.2. Objetos de Tipo CAN. ......................................................................... 73 3.3.1.3. Aplicaciones con Solución Híbrida. .................................................... 74 3.3.2. Funciones Disponibles en la Librería. ................................................76 3.3.2.1. Estado de las Funciones....................................................................... 79 3.3.2.2. Buffer de Lectura y Escritura. ............................................................. 79 3.4. Modelo de Programación para Aplicaciones de CAN. ................80 3.5. Tipos de Comunicación en los Objetos CAN. ...............................83 3.5.1. Recepción de Tramas de Datos No Solicitadas. .................................83 3.5.2. Recepción de Tramas de Datos Solicitadas. .......................................83 3.5.3. Transmisión de Tramas de Datos No Solicitadas. ..............................84 3.5.4. Transmisión de Tramas de Datos Solicitadas. ....................................85 3.5.5. Transmisión de Tramas de Datos Consecutivas. ................................85 Capítulo 4. .................................... Diseño del Simulador de Redes de CAN. ................................................................................................................86 4.1. Editor de Base de Datos. .................................................................87 4.1.1. Estructura de la Aplicación.................................................................87 4.1.2. Guardar, Abrir y Importar Fichero. ....................................................89 4.1.3. Configuración de la Red de CAN. ......................................................91 4.1.3.1. Lista de Nodos de Red......................................................................... 93 4.1.3.2. Lista de Mensajes. ............................................................................... 95 4.1.3.3. Lista de Señales. .................................................................................. 97 4.1.3.4. Informe en Formato Excel................................................................... 98 4 Índice 4.1.3.5. 4.2. Informe en Formato Texto................................................................... 99 Visualizador de Bus CAN. ............................................................100 4.2.1. Estructura de la Aplicación...............................................................100 4.2.2. Tipos de Visualizadores....................................................................101 4.3. Simulador de Bus CAN. ................................................................102 4.3.1. Estructura de la Aplicación...............................................................102 4.3.2. Configuración de la Simulación. ......................................................104 4.3.2.1. Función Rendezvous. ........................................................................ 105 4.3.2.2. Trace Window. .................................................................................. 105 4.3.2.3. CAN Interactivo. ............................................................................... 106 Capítulo 5. ..................................................... Guía de Diseño para el Usuario. ..............................................................................................................108 5.1. Edit Data Base................................................................................109 5.1.1. Tipos de objetos. ...............................................................................109 5.1.2. Menús del Edit Data Base.................................................................110 5.2. 5.1.2.1. Network Nodes. ................................................................................. 110 5.1.2.2. Messages............................................................................................ 113 5.1.2.3. Signals. .............................................................................................. 116 5.1.2.4. Informes en Formato Texto o Excel.................................................. 119 Simulator. .......................................................................................120 5.2.1. 5.3. Inicio de la Simulación. ....................................................................122 5.2.1.1. Interactive CAN................................................................................. 122 5.2.1.2. Trace Window. .................................................................................. 123 Simulación mediante Paneles. ......................................................124 5.3.1. Funcionamiento del Programa Labview. ..........................................124 5.3.2. Creación de un Panel. .......................................................................125 5 Índice 5.4. Bus Monitor....................................................................................134 5.4.1. Test Network.....................................................................................135 5.4.2. Bus Monitor con Base de Datos. ......................................................136 Capítulo 6. ................................................. Test del Programa de Simulación. ..............................................................................................................139 6.1. Sistema de Comunicación con 3 Nodos. ......................................139 6.1.1. Informe de la Base de Datos del Sistema Simulado. ........................139 6.1.2. Descripción de los Paneles diseñados...............................................140 6.1.2.1. Panel del Airbag_Module.................................................................. 140 6.1.2.2. Panel del Smart_Cluster. ................................................................... 141 6.1.3. 6.2. Simulación de la Red de Bus CAN...................................................142 6.1.3.1. Simulación sin Paneles. ..................................................................... 142 6.1.3.2. Simulación con Paneles. .................................................................... 143 Visualización de Mensajes de un Nodo Real...............................144 Conclusiones. ......................................................................................145 Apéndice 1...........................................................................................146 Características Técnicas de la Tarjeta NI-CAN. ..................................146 Tipo de Conectores Utilizados en el Cable PCMCIA-CAN.................147 Apéndice 2...........................................................................................148 Características Técnicas de la Tarjeta CANcardX. .............................148 Características Técnicas del Cable CANcab.........................................149 Características Eléctricas del CANcab 1054 (LOW SPEED) .................150 6 Índice Características Eléctricas del CANcab 251 (HIGH SPEED)....................151 Bibliografía. ........................................................................................152 7 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 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 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 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. 778266-01). § Cables PCMCIA-CAN de National Instrument (ref. 187457-01 y 184402-01). § Software NI-CAN V1.0 (gratuito). § 1 Licencia de Labview (Professional with Builder). § 1 Licencia de Canoe V5.1 (ref. 11017). § 1 Ordenador con tarjeta PCMCIA. § 1 Tarjeta CANcardX V1.0. de Vector Informatik (ref. 07100). § 1 Cable CANcab 1054 de Vecotr Informatik (ref. 22007) 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 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 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 11898 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 11519 (sustituida posteriormente por la ISO 11519-2). En 1995, la norma ISO 11898 fue modificada, para añadir los identificadores de 29-bits, que hasta el momento eran de 11-bits solamente. 13 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 Figura 1.1. Niveles del Protocolo Bus CAN. 14 Soluciones no estándar Espec. Can Bosch ISO Capítulo 1 CAN (Controller Area Network) 1.1.1. 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 11898 para las aplicaciones de alta velocidad y, por el estándar 11519 para las aplicaciones de baja velocidad. Figura 1.2. Niveles de Tensión según el Estándar 11519. Figura 1.3. Niveles de Tensión según el Estándar 11898. 15 Capítulo 1 CAN (Controller Area Network) 1.1.1.1. Características de los Cables (ISO 11898). Los cables según el estándar ISO 11898 deben reunir las características descritas en la figura siguiente. Características Valor 108 ? mínimo, 120 ? Impedancia nominal, 132 ? máximo Resistencia respecto a la longitud 70 m? /m nominal Retardo de línea 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 Capítulo 1 CAN (Controller Area Network) 1.1.1.2. Características de los Cables (ISO 11519-2). Los cables según el estándar ISO 11519-2 deben reunir las características descritas en la figura 1.6. Características Valor Inductancia respecto a la longitud: CAN_L y masa, CAN_H y masa, 30 pF/m nominal CAN_L y CAN_H Resistencia respecto a la longitud 90 m? /m nominal Figura 1.6. Características de los Cables de Señal (ISO 11519-2). 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 Capítulo 1 CAN (Controller Area Network) 1.1.2. 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. 1.2. 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 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 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. 1.2.1. BasicCAN. BasicCAN proporciona un filtro para los mensajes que consiste en un SelectorIdentificador-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 = 0x7F6 RX-ID_Selector = 0x490 x = bits no considerados en la comparación = 0x490 = 0x491 Identificadores Recibidos = 0x498 = 0x499 Figura 1.9. Ejemplo de Selección de los Mensajes Recibidos. 20 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. 1.2.2. 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 Capítulo 1 CAN (Controller Area Network) Figura 1.10. Principales Diferencias entre BasicCAN y FullCAN. 1.3. Características Principales del Protocolo CAN. Las características más importantes del protocolo de comunicaciones CAN son descritas en los apartados siguientes. 1.3.1. 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 11898 y el estándar ISO 11519-2). § 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 Capítulo 1 CAN (Controller Area Network) 1.3.2. 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. 1.3.3. 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. 1.3.4. 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 Capítulo 1 CAN (Controller Area Network) 1.3.5. 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 1.11. Comunicación Broadcast. 1.3.6. 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. 1.3.7. 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 Capítulo 1 CAN (Controller Area Network) puede ser conocida indirectamente, ya que todos los nodos conocen en qué nodo se produce cada mensaje. 1.3.8. 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. 1.3.9. 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. 1.3.10. 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. 1.3.11. 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 Capítulo 1 CAN (Controller Area Network) 1.3.12. 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). 1.3.13. 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: 2tpropagación < tbit 1.3.14. 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 Capítulo 1 CAN (Controller Area Network) 1.4. Mensajes y Tramas del CAN. 1.4.1. 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). 1.4.1.1. Tipos de Controladores. Debido a los diferentes tipos de formato, existen tres tipos de controladores de CAN: § 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. 1.4.2. 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 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. 1.4.2.1. 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 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 Capítulo 1 CAN (Controller Area Network) Formato Estándar IDE Formato Extendido Figura 1.12. Composición de las Tramas. 1.4.2.2. 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. 1.4.2.3. 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 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 1.13. Trama de Error. 31 Capítulo 1 CAN (Controller Area Network) 1.4.2.4. 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. 1.4.3. 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 Capítulo 1 CAN (Controller Area Network) Figura 1.14. 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. 1.5. 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 Capítulo 1 CAN (Controller Area Network) 1.5.1. 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 Si un nodo advierte alguno de los fallos anteriores, inicia la transmisión de una trama de error. 34 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. 1.5.2. 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 <=255 Error Pasivo 128 Secuencias de 11 bits recesivos + TEC = 0 y REC = 0 Anulado TEC >255 Figura 1.15. Evolución entre Estados de Error. 35 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 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. 2.1. 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 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 Capítulo 2 CANoe (CAN Open Environment) 2.3. Editor de Base de Datos CANdb++. 2.3.1. Características Principales del Editor CANdb++. Todos los datos relevantes de un sistema de comunicación procesados en una red de bus CAN (Controller Area Network), normalmente son administrados por una base de datos central de comunicación. CANdb++ es un programa creado por la empresa Vector Informatik, para editar y gestionar bases de datos de comunicación. Este programa actualmente está disponible en dos versiones diferentes: estándar (CANdb++) y extendida (CANdb++ Admin). Las diferencias principales entre ambas versiones las podemos visualizar en la siguiente tabla. Función Versión Versión Standard Extendida Creación y modif. de bases de datos de un vehículo (*.mdc) ? Creación y modif. de bases de datos de una red de bus (*.dbc) ? ? Creación y modificación de atributos definidos por el usuario ? ? Creación y modificación de tablas de valores ? ? Informe de comunicación a través de una matriz ? ? Crear variantes de un objeto ? ? Chequeo de la base de datos creada ? ? Creación y modificación del objeto tipo “Vehicles” Comparación de objetos ? ? ? Comparación de base de datos creando un fichero de texto ? Importar objetos y atributos ? Exportar objetos y base de datos CAN ? ? Administración de versiones para la base de datos CAN ? Generar informes ? Análisis de tiempo (estimación de la carga del bus) ? Figura 2.2. Características Funcionales de las Versiones Estándar y Extendida. 39 Capítulo 2 CANoe (CAN Open Environment) 2.3.2. Ventana Principal. Cuando ejecutamos el programa CANdb++ y creamos una nueva base o abrimos una ya existente, la pantalla que nos aparece es con la que trabajaremos. Como podemos observar en la figura posterior, a la izquierda están clasificados todos los tipos de objetos que existen en un sistema de comunicación y a la derecha la descripción de los objetos “Messages”, que es el parámetro activado. En esta pantalla sólo aparecen los objetos referentes al programa estándar, en el caso que ejecutásemos la versión extendida aparecerían varios tipos más. Figura 2.3. Ventana Principal de la Versión Estandar. 40 Capítulo 2 CANoe (CAN Open Environment) 2.3.3. Tipos de Objetos. Los objetos utilizados por el CANdb++ para diseñar un sistema de buses, están colocados jerárquicamente según su importancia dentro del sistema electrónico de un vehículo: Ø Vehicles: se compone de unidades de Control (ECUs) y de una o más redes de can (Networks). Este tipo de objeto puede ser usado para representar diferentes modelos de coches y sólo se encuentra en la versión CANdb++ Admin. Ø Networks: un vehículo normalmente se compone de varias redes de buses, donde múltiples unidades de control son conectadas a alguna de las redes existentes, o a ambas, cuando la unidad hace la función de intercambio de información entre 2 buses (gateway). Ø Control Units (ECUs): las unidades de control electrónico están distribuidas por toda la red y intercambian información con otras unidades de control a través de sus controladores de bus (Networks Nodes). Ø Environment Variables: variables de entrada y salida de los “Networks Nodes”, tales como interruptores de posición, sensores de señal y señales de actuadores. Estas variables son asignadas a las unidades de control. Ø Node Groups: múltiples controladores de bus pueden ser combinados dentro de un grupo de nodos. Esto nos permite estructurar variantes de redes que se aplicarán dependiendo del nivel de funciones del vehículo. Este objeto al igual que el de “Vehicles”, sólo se encuentra en la versión CANdb++ Admin. 41 Capítulo 2 CANoe (CAN Open Environment) Ø Network Nodes (NN): estos dispositivos son la interfaz de comunicación entre la unidad de control y el bus CAN. En el caso de que un nodo sea definido, automáticamente se crea una unidad de control con el mismo nombre y, es asignado a una de las redes existentes. Ø Messages: como hemos comentado en el capítulo anterior un mensaje se compone de varios campos, como son la identificación, número de datos, tipo de transmisión, control de error y bytes de datos. Ø Signals: los bytes de datos enviados en un mensaje pueden ser divididos en una o más señales, dependiendo de la información a enviar. Figura 2.4. Arquitectura Simplificada de un Vehículo. 42 Capítulo 2 CANoe (CAN Open Environment) 2.3.4. Vínculos entre Objetos. La introducción de un vínculo establece una conexión (relación) entre 2 objetos de tipos diferentes. Por ejemplo, mediante el vínculo de una señal con un mensaje, el usuario puede definir el mensaje en el que la señal deberá ser transmitido. Relación entre los diferentes tipos de Vehicles Networks Objetos Networks ? Control Units (ECUs) ? Environment Variables Control Node Network Units Groups Nodes Messages ? Node Groups ? Network Nodes ? ? Messages ? ? Signals ? Figura 2.5. Vínculos Permitidos. 2.3.5. Creación de una Base de Datos. El objetivo de este apartado es analizar el editor CANdb++ (versión estándar), conocer con más profundidad sus funciones principales y ver como están vinculadas entre sí. Para realizar este estudio, crearemos una nueva base de datos, con datos extraídos de un proyecto existente. Los pasos principales a realizar para crear una nueva base de datos, son los siguientes: 1. Arrancar el programa. 43 Capítulo 2 CANoe (CAN Open Environment) 2. Abrir una base de datos nueva con el comando localizado en el menú File. Por defecto, aparece la pantalla principal comentada anteriormente, con todos los objetos a la izquierda de la pantalla. 3. Crear objetos es tan sencillo como marcar el tipo de objeto que se desea crear y, con el botón derecho del ratón, escoger la opción New. Otra forma de crear un objeto, es copiar uno existente y cambiar los atributos necesarios. 4. Crear vínculos entre objetos. Una vez creado los objetos, debemos vincularlos entre si. Mientras esto no ocurra, delante de cada objeto creado aparecerá una pequeña cruz roja. Los vínculos pueden ser creados a partir de la opción “Drag & Drop” o a partir del menú Edit. Primero se copia uno de los objetos a vincular y luego se selecciona la opción Insert Connection. 5. Visualizar la matriz de comunicación. Esta ventana muestra los vínculos creados entre las señales, los mensajes y los nodos de red. Los mensajes aparecen en azul, resaltando el nodo que los transmite. Figura 2.6. Ejemplo de una Matriz de Comunicación. 6. Crear y asignar Tablas de Valores. Las tablas de valores se utilizan para asignar nombres simbólicos a los valores de las señales o a las variables de entorno. La misma tabla de valores puede ser usada por múltiples señales o variables de 44 Capítulo 2 CANoe (CAN Open Environment) entorno y, en el caso de que no sean asignados a ningún objeto, la tabla de valores será ignorada. Figura 2.7. Descripción de una Tabla de Valores. 7. Crear de atributos definidos por el usuario. Todos los atributos creados por el usuario son asignados a un tipo de objeto y, por defecto, a todos los objetos que cuelgan de ese tipo de objeto. Estos atributos son añadidos a los campos existentes en cada tipo y su valor puede ser modificado en cada objeto o mantener el definido en la ventana de Atributos. Figura 2.8. Ventana de Definición de Atributos. 45 Capítulo 2 CANoe (CAN Open Environment) 8. Chequear la base creada. Una vez creada la base de datos, debemos ejecutar la opción Consistency Check del menú File, para ver todas las incongruencias encontradas por el programa y corregirlas antes de guardar la base de datos. 2.4. Programación con el CAPL Browser. 2.4.1. Características Principales del Editor CAPL Browser. CANoe proporciona un compilador especialmente diseñado para la creación y compilación de programas en CAPL (CAN Access Programming Language). El lenguaje de programación CAPL es un lenguaje pseudo-C que permite programar aplicaciones independientes para el entorno CANoe, emulando el entorno del sistema y el tráfico de datos. También puede ser aplicado para solucionar necesidades de análisis de datos o tráfico de datos independientes del definido en la red global. Desde el punto de vista de un programa definido en CAPL, los mensajes de CAN son interpretados como eventos dentro del bloque del programa, que pueden provocar una reacción del nodo de red. De la misma manera, los cambios en las variables de entorno y las teclas del teclado también pueden provocar reacciones. Mensaje Tipos de Eventos BLOQUE DEL Tecla PROGRAMA EN Temporizador Mensaje CAPL Figura 2.9. Entorno de un Programa en CAPL. 46 Reacción al Evento Capítulo 2 CANoe (CAN Open Environment) 2.4.2. El Lenguaje de Programación CAPL. CAPL es un lenguaje de procedimiento donde la ejecución de los bloques del programa están controlados por eventos y, donde cada evento, conlleva la ejecución de un procedimiento. Por ejemplo, se puede tener un procedimiento asociado a la recepción de un mensaje con la función “on message”, la presión de una tecla durante la ejecución del programa por parte del usuario con la función “on key” o incluso ejecutar procedimientos cíclicos con la función “on timer”. Figura 2.10. Tipos de Eventos Utilizados en CAPL. Un programa de CAPL consta de dos partes: • Declaración de variables. • Declaración de funciones y procedimientos de respuesta a eventos. 2.4.2.1. Declaración de Variables. Los tipos de datos a utilizar como variables en CAPL incluyen enteros (dword, long, word, int, byte y char) y números con coma flotante (float y double) como el lenguaje C. Complementariamente, hay variables propias para utilizar mensajes de CAN, declarándolas como message o timer. 47 Capítulo 2 CANoe (CAN Open Environment) Excepto las variables de tipo timer, las variables se pueden inicializar con un valor determinado en el momento de declararlas: Variables { Int msgCount; //se inicializa con el valor 0 cada vez que se reinicia el programa message 34 EnviarMsj = { //el mensaje EnviarMsj es vinculado al identificador 34 dlc=1, //Data Length Code = 1 byte(0)=1 // inicializa byte 0 a 1 }; } Las variables de tipo timer (base en segundos) o mstimer (base en milisegundos), utilizadas para generar eventos de tiempo, no pueden ser inicializadas en su declaración sino que deben de ser activadas explícitamente con la función setTimer(): Variables{ timer Timer1 //declaración de un timer con base en segundos// mstimer Timer2 //declaración de un timer con base en ms.// } setTimer ( Timer1, 3 ) // el timer tardará 3 segundos en generar un evento// setTimer ( Timer2, 100 ) // el timer tardará 100 ms. en generar un evento// A diferencia del lenguaje C, CAPL no permite la utilización de punteros, para conseguir de esta forma, un programa más robusto. Debido a que la utilidad del CAPL se centra en la descripción del comportamiento de los nodos dentro de la red de bus, las variables de tipo mensaje son muy importantes en cualquier programa. Al declarar un mensaje, se debe declarar también el identificador del mensaje o en su defecto, el nombre del mensaje definido en la base de datos: message 0xA m1; //el mensaje m1 es vinculado al identificador 0xA message EngineData m3; //el mensaje m1 es vinculado al nombre simbólico EngineData message * m4; //este mensaje será vinculado posteriormente 48 Capítulo 2 CANoe (CAN Open Environment) 2.4.2.2. Procedimientos de Eventos. Al producirse un evento, el bloque del programa se ejecuta y el procedimiento involucrado en este evento, genera una respuesta de tipo mensaje. Dos procedimientos de eventos con el mismo nombre no son permitidos en CAPL. Utilizando procedimientos de eventos se puede reaccionar a los siguientes tipos de eventos: Eventos Procedimientos de eventos Recepción de un mensaje de CAN On message {} Presión de una tecla On key {} Iniciación de la medida (antes de On preStart {} comenzar) Al inicio de la medida On start {} Al final de la medida On stopMeasurement {} Controlador de CAN en Error Activo On errorActive {} Controlador de CAN en Error Pasivo On errorPassive {} Controlador de CAN al limite On warningLimit {} Controlador de CAN en Bus Off On busOff {} Expiración de un temporizador On timer {} Recepción de un Error Frame On errorFrame {} Cambio del valor de una variable de On envVar {} entorno. 49 Capítulo 2 CANoe (CAN Open Environment) De la misma manera que se han explicado las diferentes posibilidades de definición de variables de tipo mensaje, el evento de recepción del mensaje se puede definir también de diferentes formas, variando el mensaje que genera este evento: § On message 0x123 Reacción al mensaje con identificador 0x123 § On message EngineData Reacción al mensaje “EngineData” § On message CAN1.123 Reacción al mensaje 123 sólo si se recibe por el chip 1 § On message * Reacción a todos los mensajes § On message CAN2 . * Reacción a todos los mensajes recibidos por el chip 2 § On message 100-200 Reacción a todos los mensajes recibidos con el identificador entre 100 y 200 Para reaccionar a cambios en las variables de entorno, CAPL proporciona el tipo de procedimiento de evento “on envVar”. Una vez el evento provoca la ejecución del programa, se puede obtener el valor de la variable activa o modificarlo con las funciones getValue() y putValue(). 2.5. Editor de Paneles. El editor de paneles es una herramienta para crear o modificar paneles gráficos. Con los paneles creados, el usuario puede variar los valores de las variables de entorno interactivamente durante la ejecución del sistema. Estas variables deben definirse previamente en la base de datos. Cuando ejecutamos el editor de paneles desde el CANoe, las variables de entorno de la base de datos activa son asociadas al editor de paneles. Los elementos que insertamos en el panel son llamados controles. Hay básicamente tres tipos de controles: elementos de visualización, que muestran el estado de las variables 50 Capítulo 2 CANoe (CAN Open Environment) de entorno, otros que los modifican y finalmente, otros que pueden ser utilizados tanto para mostrar como para modificar su valor. Para la creación de controles, es necesario seleccionarlos de la barra que aparece en la parte superior de la ventana del editor de paneles y colocarlos en el marco que delimitan las líneas negras como las que aparecen en la figura siguiente. Una vez insertado el control, se puede asociar a alguna de las variables de entorno existentes en la base datos. Figura 2.11. Ejemplo de Panel de Control. 51 Capítulo 2 CANoe (CAN Open Environment) 2.6. Programa CANoe. Como hemos comentado en previos apartados, la aplicación CANoe es utilizada 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í. Este programa está compuesto por tres ventanas principales para que el usuario pueda configurar y visualizar el sistema deseado: 1.- Configuración de la Simulación. 3.- Ventana de Escritura. 2.- Configuración de la Medida. Figura 2.12. Ventanas Principales del CANoe. 1.- Configuración de la Simulación (Simulation Setup). En esta ventana se configura la red de Can que se desea simular, añadiendo los nodos que tienen que participar. Estos nodos pueden ser de 2 tipos: reales o simulados. 52 Capítulo 2 CANoe (CAN Open Environment) 2.- Configuración de la Medida (Measurament Setup). La monitorización y la evaluación de los datos que circulan por la red se configuran a partir de esta ventana, ya que desde aquí, se puede acceder a las siguientes ventanas: Estadística (Stadistics), Estadística del Bus (Bus Stadistics), Monitorización de tramas (Trace), Datos (Data) y Gráficos (Graphics), además de disponer de una opción para almacenar (Logging) los datos en un fichero tipo ASCII o binario. 3.- Ventana de Escritura (Write Window). La información que se genera sobre el proceso y el estado de red de Can se visualiza en esta ventana de manera automática, como por ejemplo cuando comienza la medida o posibles incidencias del sistema provocadas por programas creados por el usuario. 2.6.1. Configuración de la Simulación. Al iniciar el desarrollo de un sistema de comunicación, la red es completamente simulada y en este caso se puede trabajar sin un bus físico. Pero el programa CANoe ofrece la posibilidad de trabajar con un bus real, conectando dos controladores de Can al bus. Todos los mensajes generados estarán ubicados en el primer controlador y el segundo controlador permitirá que el bus trabaje en modo real. Una vez escogido el tipo de bus físico, se configuran los controladores (reales o simulados) que participarán, apretando el botón derecho encima del recuadro con el nombre Bus Can y escogiendo la opción Hardware Configuration. Figura 2.13. Menú de Configuración de los Parámetros del Bus. 53 Capítulo 2 CANoe (CAN Open Environment) Estos posibles cambios de configuración, son aplicables tanto al bus de alta velocidad como al de baja. Además de configurar la velocidad de transmisión, con la opción Filter se pueden configurar los campos mask y code que algunos controladores Can, como el SJA 1000 o el 82527, tienen. Con estos campos se pueden definir los mensajes que se desean transmitir y recibir. El campo mask indica los bits del ID de arbitraje que deberían ser comparados con el campo code. Si el bit está a 1 en la máscara, este bit será irrelevante para la comparación. En cambio si el bit está a 0, el bit del campo ID es comparado con el correspondiente bit del campo code. Ejemplos: Mensaje de tipo estándar: Code = 0x002, Mask = 0x007 Sólo los mensajes con ID acabado en 0xA (1010) o 0x2 (0010) son aceptados. Mensaje de tipo extendido: Code = 0x0000000A, Mask = 0x0000000F Sólo los mensajes con ID acabado en 0xA (1010) son aceptados. Figura 2.14. Menú de Configuración del Filtro del Controlador de Can. 54 Capítulo 2 CANoe (CAN Open Environment) Después de configurar el hardware del bus Can, se deben insertar los nodos que intervendrán en la simulación. Debido al funcionamiento del protocolo CAN, se necesita al menos tener dos nodos en la red, ya que se debe confirmar la recepción de los mensajes que un nodo envía. Por lo tanto, hace falta añadir dos nodos en la red que transmitan y reciban mensajes. Para insertar dichos nodos, se debe pulsar el botón derecho del ratón sobre la doble línea que sale del nodo que representa el controlador de CAN. El menú que se despliega, ofrece la posibilidad de escoger entre 4 tipos de bloques diferentes: un nodo de red (Network Node), un bloque generador (Generator Block), un bloque generador interactivo (Interactive Generator Block) y un bloque de repetición (Replay Block). Las diferencias entre los diferentes bloques son, básicamente, el número de parámetros configurables. Por ejemplo, está el caso del bloque generador que es el más sencillo, mientras que en el lado opuesto está el nodo de red que ofrece múltiples posibilidades. 2.6.1.1. Bloque Generador. Este tipo de bloque permite enviar todo tipo de señales de forma periódica o esporádica, configurando por un lado el evento que provoca la transmisión y, por el otro, los mensajes que envía. Para configurar el evento se tiene que situar el ratón encima del bloque y pulsar el botón derecho y, escoger la opción “Configuration of triggering”, donde se puede escoger si el mensaje ha de ser enviado como respuesta al apretar una tecla (hay que especificar cuál es), periódicamente (especificando el periodo en milisegundos) o a la recepción de un mensaje (especificando cuál es mediante su identificador o bien buscándolo entre los mensajes de la base de datos). De la misma forma, seleccionando la opción “Configuration of transmit list” se pueden seleccionar todos los mensajes que han de ser transmitidos en la configuración propuesta. 55 Capítulo 2 CANoe (CAN Open Environment) Figura 2.15. Configuración del Periodo y los Mensajes a Transmitir. Con las opciones que se han explicado hasta este apartado, la configuración de mensajes sólo puede realizarse introduciendo el identificador del mensaje, pero el programa CANoe, también ofrece la posibilidad de trabajar con datos simbólicos, esto quiere decir, con el nombre del mensaje que puede ser seleccionado de una lista desplegable. Para poder acceder a los mensajes, señales y variables de entorno de la configuración definida previamente, será necesario asociar las bases de datos pertinentes. 56 Capítulo 2 CANoe (CAN Open Environment) 2.6.1.2. Bloque Generador Interactivo. Estos bloques interactivos se pueden entender como bloques generadores tradicionales, pero con más parámetros que los hacen más flexibles. La principal diferencia radica que en estos bloques interactivos, los mensajes pueden ser definidos y transmitidos on-line, o sea, mientras la simulación está corriendo. Para configurar el bloque, se debe poner ratón encima del mismo, pulsar el botón derecho y, entrar en el menú “Configuration”. A continuación se especifica el identificador del mensaje a enviar y el periodo de transmisión, como se hace con el generador simple. A parte de la posibilidad de controlar las señales on-line, la otra diferencia fundamental es que el “Interactive Generador Block” lleva incorporado una interfaz para modificar el campo de datos que facilita la introducción de datos, siendo este método mucho más intuitivo. De esta manera, se puede saber en todo momento los valores que se han cambiado, ya que en la parte inferior de la ventana, aparecen las señales que contiene el mensaje seleccionado con sus campos correspondientes. Esto sólo es accesible si la base de datos esta asociada al bloque. Figura 2.16. Menú de Configuración de un Bloque Generador Interactivo. 57 Capítulo 2 CANoe (CAN Open Environment) Como se puede observar en la figura anterior, el mensaje puede ser enviado periódicamente, seleccionando la casilla con una X y especificando la frecuencia o pulsando el botón “now” para enviar la trama on-line. A diferencia del bloque generador, el tipo de comunicación (mensaje periódico o esporádico) puede ser diferente para cada mensaje. 2.6.1.3. Nodo de Red. Un nodo de red es un nodo que lleva asociado un programa en lenguaje CAPL, un lenguaje propio de CANoe, obteniendo así un bloque funcional. Las características de estos bloques son definidas por el usuario mediante un programa en CAPL. Estos nodos, conjuntamente con los reales, son los que definen la funcionalidad del sistema. Esta funcionalidad incluye el comportamiento de un nodo respecto las variables de entrada y salida, así como los mensajes a recibir y enviar. Figura 2.17. Asignación de un Nodo de la Base de Datos. 58 Capítulo 2 CANoe (CAN Open Environment) Una vez se ha creado un nodo en CAPL, éste se conecta por defecto a la línea simulada del bus, representada en rojo. Inicialmente, el nodo no tiene ningún nodo de red asignado. Para asignar el bloque a un nodo de la red, se debe desplegar el menú de configuración con el botón derecho del ratón y escoger la opción “Configure”. Ahora se puede escoger un nombre para el nodo, de aquéllos que están definidos en la base de datos. Este requisitito es indispensable para el correcto funcionamiento de la simulación, es decir, es imprescindible que el nodo esté definido en una base de datos. También es necesario indicar que el archivo está asociado al nodo en cuestión. Este archivo selecciona el programa CAPL que describe la funcionalidad del nodo. Para seleccionar el archivo se tiene que abrir el menú que hemos utilizado para asignarle un nodo de la base de datos y pulsar el botón “file...” para buscar la ubicación del programa en CAPL, que aparecerá como un programa con extensión “x-can”. A la derecha del cuadrado que representa el nodo, aparecen dos iconos, un lápiz amarillo y una pila de hojas. Estos iconos son accesos directos a las opciones “Edit” (en el caso del lápiz) y “Compile” (en el case del otro icono). Estos programas creados en CAPL tienen que reaccionar a eventos externos como activaciones de interruptores, señales de sensores,... Para simular estos dispositivos tenemos el Editor de Paneles, con el cual se pueden crear los elementos externos necesarios, para insertarlos posteriormente en la simulación. 59 Capítulo 2 CANoe (CAN Open Environment) 2.6.1.4. Bloque de Repetición. El bloque de repetición se utiliza, como su nombre indica, para volver a enviar o recibir mensajes, los cuales ya han sido registrados en el bus y guardados en ficheros de tipo ASCII o binario. Para configurar estos bloques sólo se necesita situar el ratón encima del bloque deseado y pulsar el botón derecho. Estos ficheros pueden ser transmitidos una vez o cíclicamente. En el caso de las transmisiones cíclicas, éstas se reanudan con la transmisión del primer mensaje, después de que el fichero haya alcanzado su final. Existen tres posibilidades para definir el inicio de la transmisión del primer mensaje del fichero: inmediatamente, según el tiempo guardado en el fichero o con un tiempo específico. Figura 2.18. Configuración de un Bloque de Tipo Replay. 60 Capítulo 2 CANoe (CAN Open Environment) 2.6.1.5. Vincular una Base de Datos a la Simulación. Como hemos explicado anteriormente, CANoe ofrece la posibilidad de trabajar con los datos de manera simbólica. Esto se consigue asociando una base de datos ya creada a la configuración de la simulación. A la derecha de la ventana Simulation Setup, aparece la lista de configurables y la base de datos. Pulsando el botón derecho del ratón sobre la pestaña Databases y seleccionando la opción “Add….”, se abre una ventana de diálogo donde tenemos que seleccionar la base de datos que se quiere añadir. Una vez finalizado los pasos anteriores, ya se puede trabajar con el nombre de los mensajes, las señales y sus parámetros de forma simbólica. A estos datos se podrá acceder a través de listas desplegables. Además, en el caso de un Interactive Generator Block, también se tiene la opción de seleccionar el mensaje a enviar de una lista con el nombre de todas las señales definidas en la base de datos. Figura 2.19. Configuración de un Interactive Block a partir de una Base de Datos. 61 Capítulo 2 CANoe (CAN Open Environment) 2.6.2. Configuración de la Medida. Desde esta ventana se puede configurar la monitorización y la evaluación de los datos que circulan por la red. Para ello disponemos de diferentes opciones y filtros. 2.6.2.1. Monitorización de Tramas. Las tramas que circulan por la red de CAN se monitorizan en esta ventana en tiempo real. Para conseguir una visualización de un conjunto de mensajes determinado, podemos utilizar los filtros comentados anteriormente. Figura 2.20. Ventana de Monitorización de Tramas. La ventana de la figura anterior se puede visualizar de diferentes modos, según el parámetro de tiempo escogido: § Modo cronológico: los mensajes son mostrados ordenadamente según el tiempo de llegada. § Modo cronológico con actualización cíclica: los mensajes son mostrados ordenadamente como en el caso anterior, pero la actualización de la pantalla se realiza para un conjunto de mensajes, ahorrando tiempo de operación. § Modo de posición fija: a cada mensaje con el mismo ID se le asigna una posición en la pantalla. Cuando llega un nuevo mensaje, éste reemplaza al anterior. 62 Capítulo 2 CANoe (CAN Open Environment) § Modo de posición fija con actualización cíclica: el tipo de funcionamiento es parecido al anterior, pero la actualización de la pantalla se realiza para un conjunto de mensajes, ahorrando tiempo de operación. 2.6.2.2. Datos. La ventana de datos sirve para mostrar los valores de las señales de una manera más sencilla. Cuando la señal visualizada está vinculada a una base de datos, la unidad especificada en la base de datos, es mostrada junto a la señal. Los valores obtenidos en el último mensaje recibido, permanecerán visibles hasta que no sean reemplazados por valores de un nuevo mensaje. En el caso de que el nuevo mensaje contenga valores iguales al mensaje anterior, una barra se irá alternando para mostrar este hecho. Como en otros casos, para permitir el proceso de grandes cantidades de datos, se debería activar la opción de actualización cíclica, aunque, para obtener resultados razonables, el periodo debe ser menor de 500 ms. Figura 2.21. Ventana de Datos. 63 Capítulo 2 CANoe (CAN Open Environment) 2.6.2.3. Gráficos. La ventana Gráficos se utiliza para mostrar el valor de la señal deseada respecto al tiempo. Como en el caso de la ventana Datos, si una base de datos es añadida a nuestra aplicación, las señales pueden tratarse como valores físicos. Además de mostrar las señales, esta ventana también ofrece la opción de visualizar el tiempo de respuesta de una variable de entorno. Figura 2.22. Ventana de Gráficos. Los parámetros de las señales mostradas en la ventana anterior son configurados previamente: escala, mínimo, máximo, división, tipo de línea, tiempo de muestreo,... Además, los datos obtenidos de las diferentes señales pueden ser exportados a un fichero. 2.6.2.4. Estadística. El bloque de Estadística se encarga de procesar y mostrar el número de mensajes que circulan por el bus. Una de las funciones principales, es mostrar el promedio de tiempo entre los envíos de los mensajes (segs./mensaje) o los mensajes enviados por segundo (mensajes/seg.) durante una medida. La estadística se realiza para cada identificador de mensaje. 64 Capítulo 2 CANoe (CAN Open Environment) Figura 2.23. Ventanas de Estadística y Monitorización de Tramas. En el menú de configuración, se puede personalizar todas las características de la medida, tanto a nivel visual como de procesamiento de datos. El tiempo medio, el cual define el periodo de refresco de los datos, es más preciso con un valor bajo, pero esto supone un requerimiento muy elevado de la computadora. Un tiempo medio aceptable para aplicaciones estándar es 1000 ms. aprox. Figura 2.24. Informe Estadístico Mostrado en la Ventana de Escritura. 65 Capítulo 2 CANoe (CAN Open Environment) Además de mostrar los datos de una forma gráfica, también se tiene la opción de realizar un informe una vez acabada la simulación. Este informe podrá ser guardado en un fichero tipo texto o excel, o mostrado en la Ventana de Escritura. En este informe, se muestran los diferentes identificadores de mensajes ocurridos durante la medida y, para cada uno de ellos, se muestra el número total de mensajes, el intervalo medio de transmisión, la desviación estándar y el mínimo y máximo tiempo transcurrido entre transmisiones. 2.6.2.5. Estadística del Bus. CANoe adquiere datos estadísticos de los controladores de Can implementados. Los datos adquiridos dependen del hardware utilizado. Los resultados se muestran por pantalla o se graban en un fichero. Estos resultados incluyen el porcentaje de utilización del bus y la máxima carga producida, el número total de datos trasmitidos y recibidos (estándar y extendidos), las tramas de error, las tramas de sobrecarga y, el estado del controlador (Active, Error Passive or Bus Off). La fiabilidad de los resultados puede variar según el intervalo de tiempo entre cada muestra. Figura 2.25. Ventana de Estadística del Bus. 66 Capítulo 2 CANoe (CAN Open Environment) 2.6.2.6. Almacenamiento de Datos. CANoe ofrece la opción de guardar el trafico de datos del bus en un fichero tipo ASCII o binario (genera ficheros de tamaño más reducido), para que puedan ser evaluados posteriormente. Existen tres modos de almacenamiento, según el punto de inicio y final requeridos y, el tiempo de almacenaje: § Modo Completo: todos los datos que circulan por el bus son almacenados en un buffer y seguidamente, guardados en un fichero al finalizar la simulación. § Modo Individual: en este caso sólo los datos que han sucedido en los periodos de tiempos especificados al inicio de la medida, son almacenados en el fichero. § Modo Alterno: este modo se diferencia del anterior en la forma de especificar los periodos de selección de datos. Figura 2.26. Almacenamiento de Datos en un Fichero ASCII. 67 Capítulo 2 CANoe (CAN Open Environment) 2.6.2.7. Filtros. El volumen de datos puede ser selectivamente reducido mediante el uso de filtros. Para la inserción de un filtro sólo debemos situar el ratón encima de alguna de las opciones comentadas en los puntos anteriores y pulsar el botón derecho del ratón. Figura 2.27. Aplicación de Filtros. Una vez escogido el filtro deseado podemos acceder a él para configurarlo. En la figura siguiente se puede observar la ventana de diálogo de los filtros tipo PF (Pass Filter). Figura 2.28. Configuración de un Filtro de Tipo PF. 68 Capítulo 3 NI-CAN (National Instruments-CAN) Capítulo 3. NI-CAN (National Instruments–CAN). National Instruments dispone de diferentes productos de hardware y software, que actúan como interfaz entre aplicaciones programadas en Labview o C/C++ y redes de comunicación CAN de alta y baja velocidad. 3.1. Hardware NI-CAN. 3.1.1. Tipos de Placas y Tarjetas de CAN. Existen 8 tipos de placas y tarjetas a escoger, dependiendo de las características del ordenador en el cual deben ser conectadas: AT-CAN, PCI-CAN, PXI-846x y PCMCIACAN (tarjeta) y, del número de puertos deseado: 1 o 2 puertos. En este proyecto en concreto, se han utilizado 2 tarjetas PCMCIA-CAN/DS con 2 puertos. Todas las placas y tarjetas de CAN utilizan el microprocesador 80386EX de Intel, que se encarga de implementar las características de tiempo crítico proporcionadas por el controlador de software NI-CAN. Dependiendo del número de puertos, se encontrarán integrados uno o dos controladores de CAN, 82527 de Intel. Este controlador funciona de acuerdo al protocolo de comunicación CAN, realizando todas las funciones de comunicación serie, como la transmisión y la recepción de mensajes, la filtración de mensajes,... Los primeros controladores de Intel estaban preparados para soportar tanto el formato de trama estándar como el extendido, según las especificaciones CAN 2.0A y CAN 2.0B. El controlador 82527 ofrece una alta flexibilidad de configuración con muchos microprocesadores: microprocesadores multiplexados de 8 bits, 16 bits o 8 bits no multiplexados. La estructura básica de los buzones utilizados en este dispositivo son de tipo FullCAN, con 14 buzones (buffers) que pueden ser programados para recibir o transmitir mensajes. Además contiene un buzón extra de tipo BasicCAN, que permite la recepción de 69 Capítulo 3 NI-CAN (National Instruments-CAN) mensajes, utilizando una máscara de selección que habrá sido configurada previamente, y que filtrará tanto los mensajes de las tramas estándares como extendidas. Para más información técnica sobre las placas y tarjetas, ver el Apéndice 1. 3.1.2. Tipos de Cables de CAN. La capa física o transceptor de CAN en las placas AT-CAN, PCI-CAN y PXI-846x, está integrado en la misma placa y puede ser alimentado internamente o externamente mediante un puente (jumper). En el caso de las tarjetas PCMCIA-CAN, el transceptor está en el cable que conecta la red de CAN con la tarjeta. Hay 4 tipos de cables disponibles para las tarjetas PCMCIACAN según el número de puertos de la tarjeta y la fuente de alimentación del transceptor. En este proyecto hemos utilizado cables de tipo PCMCIA-CAN/DS, que contienen un transceptor de CAN de baja velocidad y otro de alta velocidad. Y cables de tipo PCMCIACAN/2, que contienen 2 transceptores de CAN de alta velocidad. Todos los cables están preparados para soportar 2 tipos de conexiones, mediante un conector D-Sub 9, que cumple las recomendaciones de la norma DS 102 de CiA (Can in Automation) y otro conector (Combi Connector), donde se pueden conectar cables directamente. Ambos conectores están cortocircuitados internamente para que las señales eléctricas sean las mismas. En todos los casos, el transceptor utilizado para redes de alta velocidad es el dispositivo TJA 1041 de Philips, que es completamente compatible con el estándar ISO 11898 y soporta velocidades de hasta 1Mbits/seg. Para redes de baja velocidad, el transceptor utilizado es el TJA 1054 (Low-Speed/Fault Tolerant transceiver) Para más información sobre los cables PCMCIA, ver el Apéndice 1. 70 Capítulo 3 NI-CAN (National Instruments-CAN) 3.2. Software NI-CAN. Todas las placas y tarjetas comentadas anteriormente, adjuntan varios componentes de software que actúan de interfaz entre la aplicación del usuario, programada en Labview o C/C++ y, la placa o tarjeta. Como las aplicaciones desarrolladas para este proyecto han sido siempre a partir del programa Labview, a continuación explicaremos la interacción entre los diferentes programas para poder recibir o transmitir mensajes en una red CAN. Figura 3.1. Interacción entre las Diferentes Aplicaciones. 71 Capítulo 3 NI-CAN (National Instruments-CAN) El Lenguaje de Interfaz NI-CAN (NI-CAN Language Interface) es una librería de funciones Labview de 32-bits, nican.llb, utilizada por las aplicaciones programadas en Labview para acceder al software nican.dll. El fichero nican.dll es un archivo ejecutable que contiene las librerías de vínculos dinámicos. Estas librerías actúan de interfaz entre todas las funciones de CAN y el controlador de la tarjeta PCMCIA-CAN/DS. El controlador de dispositivo NI-CAN (NI-CAN device driver) facilita al usuario el acceso a la tarjeta y permite a las distintas aplicaciones, el acceso seguro al hardware. Nican.nfw es el software instalado en la memoria ROM de la tarjeta PCMCIACAN. 3.3. Librería de Funciones Labview. 3.3.1. Tipos de Objetos. En las funciones de la librería que nos proporciona NI-CAN existen 2 tipos diferentes de objetos: objetos CAN Network Interface (actúan sobre el buzón de tipo BasicCAN) y objetos CAN (actúan sobre los 14 buzones de tipo FullCAN). Estos objetos se utilizarán dependiendo de las necesidades de cada aplicación. 3.3.1.1. Objetos de Tipo CAN Network Interface. Los objetos de tipo CAN Network Interface contienen una interfaz física a una red de CAN a través de los puertos de CAN localizados en las tarjetas existentes (AT, PCI, PCMCIA o PXI). Con estos objetos se pueden leer y escribir tramas de CAN completas. Cuando una trama de CAN llega desde la red, ésta es almacenada dentro de la cola de lectura del objeto CAN Network Interface y, a partir de las funciones ncRead o ncReadMult, podemos obtener las tramas recibidas desde la cola de lectura. En el caso de querer transmitir alguna trama, también se puede acceder a la cola de escritura a partir de la función ncWrite. Este tipo de objetos será utilizado principalmente en los siguientes casos: 72 Capítulo 3 NI-CAN (National Instruments-CAN) § Verificación del estado de todos los nodos de la red. A través de la cola de escritura se puede transmitir una secuencia específica de tramas para comprobar el correcto funcionamiento de los dispositivos que están en la red. La cola de lectura es útil para almacenar todas las tramas transferidas. § Transferencia arbitraria de tramas de CAN. En el caso que se desconozcan los identificadores de mensajes de las tramas que se van a transmitir o recibir o, que el número de tramas a recibir sea muy elevado. 3.3.1.2. Objetos de Tipo CAN. El identificador de arbitraje de un mensaje es utilizado principalmente para la resolución de colisiones cuando más de una trama está siendo transmitida simultáneamente. Aunque también puede ser utilizado como un simple mecanismo para identificar datos. El objeto de tipo CAN contiene un identificador específico y sus datos asociados. Cada objeto CAN está siempre asociado a un objeto CAN Network Interface, utilizado para identificar la interfaz física en la cual, el objeto CAN es localizado. En una aplicación se pueden configurar múltiples objetos CAN en conjunción con su objeto CAN Network Interface asociado. Este tipo de objetos presenta un mayor número de opciones para acceder a un especifico ID de arbitraje. Un objeto CAN puede ser transmitido periódicamente, después de recibir una trama remota,... La transferencia de datos se realiza como el tipo de objeto anterior, a partir de las funciones ncWrite y ncRead pero, en el caso que los datos quieran ser transmitidos periódicamente, el controlador de dispositivo NI-CAN es el encargado de tratar y transmitir los datos almacenados en la cola de escritura. Este tipo de objetos será utilizado principalmente en los siguientes casos: § Transmisión periódica de una trama de datos para un identificador de mensaje especifico. El objeto CAN transmite los mismos datos repetidamente hasta que otros datos diferentes son proporcionados por la función ncWrite. 73 Capítulo 3 NI-CAN (National Instruments-CAN) § Recepción de datos estableciendo un tiempo de expiración. En el caso que la trama no sea recibida en el intervalo de tiempo especificado, el controlador NICAN notificará el error sucedido. § Trasmisión de datos en el caso de recibir una trama remota (remote frame). Como en el caso anterior también se puede especificar un tiempo de expiración. En general, los objetos CAN serán utilizados en la transferencia de datos con identificadores de mensaje específicos y, especialmente, cuando la transferencia se realice de una forma periódica. 3.3.1.3. Aplicaciones con Solución Híbrida. En muchas aplicaciones no es suficiente con la utilización de un tipo de objeto y es necesario conjuntar ambos tipos para conseguir un mayor rendimiento. Por ejemplo, se pueden utilizar objetos CAN para transmitir datos periódicamente y aplicar un objeto de tipo CAN Network Interface Object para recibir cualquier tipo de tramas. Cuando hay uno o más objetos de tipo CAN abiertos, el objeto CAN Network Interface no puede recibir las tramas que corresponden a los identificadores utilizados por los objetos CAN, ya que éstos tienen una prioridad más alta. El diagrama de flujos siguiente muestra los pasos seguidos cuando una trama es recibida mediante un objeto CAN Network Interface. 74 Capítulo 3 NI-CAN (National Instruments-CAN) Trama Recibida ID de Mensaje pertenece a un Objeto CAN? Si Trama de tipo CAN No No Trama de Datos? Si Estándar Comparador Estándar Habilitado? Trama Ignorada Extendido Estándar o Extendida? No No Comparador Estándar Habilitado? Si Aplicar Máscara Estándar Identificador de Mensaje Aceptado? Si Trama Ignorada No Aplicar Máscara Estándar No Identificador de Mensaje Aceptado? Si Si Añadir Trama dentro de la cola de Lectura del Objeto CAN Netwrok Interface Figura 3.2. Diagrama de Flujo para la Recepción de una Trama. 75 Capítulo 3 NI-CAN (National Instruments-CAN) 3.3.2. Funciones Disponibles en la Librería. Con las tarjetas de CAN se suministra la librería de NI-CAN, que contiene todas las funciones necesarias para actuar sobre los controladores de CAN y así, poder escribir y leer en la red. Las funciones disponibles son las siguientes: § ncAction: realiza las acciones de empezar, acabar o restaurar la comunicación de red de cualquier objeto. En el caso de realizar alguna de estas acciones en un objeto Network Interface, esta acción afectará a todos los objetos CAN abiertos. Por el contrario, si la acción se realiza en un objeto CAN, solo afectará al objeto especificado. § ncCloseObject: como su nombre indica, esta función es utilizada para cerrar cualquier objeto abierto anteriormente, siempre y cuando se especifique dicho objeto. § ncConfig: antes de abrir un objeto, éste debe ser configurado. Dependiendo del tipo de objeto, los parámetros a configurar son diferentes. En el caso de objetos de tipo Network Interface, la configuración se centra tanto en la configuración del controlador de CAN que se va a utilizar, como en la longitud de la cola de escritura y lectura y, la configuración de las máscaras. En cambio, en los objetos de tipo CAN sólo se configuran las colas de transferencia de datos y el tipo de comunicación que va a ser utilizado. § ncCreateOccurrence: esta función notifica el suceso de alguno de los estados siguientes: 1.- Trama recibida, disponible para ser leída con la función ncRead. 2.- La trama escrita con la función ncWrite fue transmitida con éxito. 3.- La comunicación ha sido cortada. 4.- Se ha producido un error. 5.- Advertencia de algo sucedido. 6.- Múltiples tramas recibidas, disponibles para ser leídas con la función ncReadMult. 76 Capítulo 3 NI-CAN (National Instruments-CAN) § ncGetAttribute: para acceder a los datos de la configuración del estado o otra información relacionada con un objeto, podemos aplicar esta función. § ncGetTimer: en el caso de querer acceder al tiempo de sellado (timestamp), esta función será utilizada en lugar de la función anterior. § ncOpenObject: antes de ejecutar esta función, el objeto a utilizar debe haber sido configurado previamente. Esta función abre el objeto que ha sido especificado y devuelve una dirección que es utilizada por funciones posteriores. Aunque el controlador NI-CAN puede ser usado en múltiples aplicaciones simultáneamente, no está permitido abrir el mismo objeto más de una vez. Por ejemplo, si una aplicación abre el objeto CAN0, la segunda aplicación devolvería un error en el caso de querer abrir el mismo objeto. Aunque lo que sí está permitido, es abrir un objeto CAN0::STD14 y que otra aplicación abra el objeto CAN0::STD21 o el CAN0::XTD0x21. § ncRead: dependiendo del tipo de objeto al que se quiere acceder, los parámetros que proporciona esta función son diferentes. En el caso de objetos Network Interface los parámetros son: longitud de los datos, datos, tiempo de sellado, el identificador del mensaje y el tipo de trama, que puede ser de datos, error o remota, aunque este último tipo, debido a las limitaciones del controlador de CAN Intel 82527, el controlador NI-CAN no puede leerlo. En cambio en los objetos CAN, se muestran sólo los datos y el tiempo de sellado, ya que el resto de parámetros ya han sido configurados previamente. § ncReadMult: esta función devuelve múltiples tramas desde la cola de lectura del objeto especificado por la dirección asignada. Esta función es utilizada principalmente con objetos Network Interface, para aplicaciones de análisis donde las tramas de datos necesitan ser adquiridas a una gran velocidad y almacenadas para analizarse posteriormente. § ncReset: en el caso de querer reiniciar la tarjeta de CAN y asegurar que todas las direcciones de los objetos para esta tarjeta están cerrados, se debe ejecutar esta función. Esto afectará a todas las funciones que estén trabajando sobre la misma tarjeta. 77 Capítulo 3 NI-CAN (National Instruments-CAN) § ncSetAttribute: configura el valor del atributo del objeto especificado. No todos los objetos pueden ser configurados con esta función, ya que muchos tienen un acceso restringido de lectura cuando el objeto ha sido abierto. § ncSetTimer: el atributo configurado en esta función, es el de tiempo de sellado. Variando el valor de este atributo el usuario puede trabajar en valor absoluto. § ncWaitforState: el propósito de esta función es esperar a que uno o más estados ocurran en un objeto para dar la señal de aviso. Los estados que pueden ser chequeados son: trama disponible en la cola de lectura, trama transmitida con éxito, estado del objeto especificado, un número específico de tramas están almacenadas en la cola de lectura (previamente se debe haber especificado la cantidad de tramas), si se ha producido un error o si sólo ha sido un aviso. En esta función también hay un parámetro opcional para indicar el tiempo máximo en el que se deben producir los estados especificados. § ncWrite: dependiendo del tipo de objeto al que se quiere acceder, los parámetros que se deben introducir son diferentes. En el caso de objetos Network Interface se debe configurar la longitud de los datos, los datos, el identificador del mensaje y el tipo de trama (remota o de datos). En cambio, en los objetos CAN sólo los datos a transmitir deben ser almacenados en la cola de escritura, ya que el resto de parámetros ya han sido configurados previamente. 78 Capítulo 3 NI-CAN (National Instruments-CAN) 3.3.2.1. Estado de las Funciones. Todas las funciones devuelven un valor que indica el estado de la función ejecutada. Dicho estado pasa de una función a otra a partir del parámetro Error Cluster. Cuando un error es detectado en alguna de las funciones, ésta lo especifica en el parámetro Error Cluster y vuelve al programa principal. El resto de funciones, al leer el error producido en la función anterior ya no se ejecutarán, hasta llegar a la función ncCloseObject que cerrará todos los objetos abiertos. Código Estado Negativo Verdadero Positivo Falso Cero Falso Fuente Nombre de la función donde ha ocurrido el aviso. Nombre de la función donde ha ocurrido el aviso. Vacío. Significado Error. La función no funciona correctamente. Aviso. La función funciona correctamente, pero hay alguna condición que requiere ser chequeada. Correcto. La ejecución de la función se completó correctamente. Figura 3.3. Valores del Parámetro Error Cluster. 3.3.2.2. Buffer de Lectura y Escritura. El controlador NI-CAN soporta el uso de colas, también conocido como FIFO búfers, para mantener el orden de los datos transferidos. Este comportamiento básico de las colas es común para todos los objetos. Hay dos tipos de colas: la cola de lectura y la cola de escritura. La cola de lectura es utilizada para almacenar los datos recibidos de la red de CAN (función ncRead) y, la cola de escritura, está compuesta por los datos que serán transmitidos a la red (función ncWrite). Durante la comunicación, las colas pueden estar en tres estados diferentes: § Colas vacías: en las colas de lectura, si la función ncRead es utilizada estando la cola vacía, los datos devueltos por defecto consistirán en ceros. Si la cola ya ha 79 Capítulo 3 NI-CAN (National Instruments-CAN) sido utilizada previamente, los datos devueltos coincidirán con la lectura anterior, además de devolver un aviso de datos antiguos. En cambio en las colas de escritura, la comunicación sólo se llevará a cabo si hay algún dato almacenado en la cola. § Colas llenas: el comportamiento de ambas colas es similar en este caso, ya que si alguna de las colas está llena (255 tramas), el controlador NI-CAN devolverá un error de desbordamiento y, este nodo será desconectado de la red como indica el protocolo CAN. En el caso de que el número de tramas sea superior a 96, el controlador de NI-CAN detectará un estado de error pasivo (para este caso el protocolo CAN recomienda 127 tramas). § Colas deshabilitadas: las colas de lectura y escritura también pueden deshabilitarse; por ejemplo, para ahorrar memoria. Cuando un nuevo dato llega, éste sobrescribe el dato anterior sin indicar un desbordamiento. 3.4. Modelo de Programación para Aplicaciones de CAN. En este apartado se presentan los pasos a seguir para programar una nueva aplicación utilizando las librerías de CAN del programa Labview. Paso 1.- Configuración de los Objetos. Los objetos deben ser configurados antes de ser utilizados en la aplicación. Cada objeto es configurado llamando a la función ncConfig. Esta función adquiere el nombre del objeto a configurar, junto con una lista de parámetros fijados previamente. Paso 2.- Abrir los Objetos. Todos los objetos utilizados en la aplicación deben ser abiertos con la función ncOpenObject. Esta función devuelve un código para cada objeto abierto, que será utilizado en todas las funciones posteriores que hagan referencia a ese objeto. 80 Capítulo 3 NI-CAN (National Instruments-CAN) Paso 3.- Inicio de la comunicación. Para iniciar la comunicación existen 2 posibilidades: 1.- Al configurar el objeto: la comunicación arranca automáticamente cuando utilizamos la función NcOpenObject si se ha configurado previamente en la función NcConfing. 2.- Cuando el objeto está abierto: la comunicación debe ser iniciada a través del parámetro nc_op_start de la función ncAction. Este método es más indicado, ya que se tiene la posibilidad de reiniciar la tarjeta CAN con el parámetro nc_op_reset de la función ncAction y, eliminar errores residentes de aplicaciones anteriores. Paso 4.- Leer, escribir,... en la red. Una vez configurados y abiertos los objetos, los datos ya pueden ser transferidos a través de la red de CAN. Los datos pueden ser transferidos individualmente o por paquetes. En el caso de la lectura de datos, que se realiza con la función ncRead, disponemos del parámetro desired_state perteneciente a la función ncWaitForState, que nos avisará cuando en la cola de lectura haya datos disponibles, y así evitaremos el chequeo continuo de la cola de lectura. Con la función ncCreateNotification también obtendríamos resultados parecidos. Si sólo queremos leer el dato más reciente y omitir el resto de datos, esta opción debe ser contemplada cuando el objeto es configurado. Paso 5.- Cerrar los objetos. Para finalizar el acceso a la red de CAN, tenemos que cerrar todos los objetos a través de la función ncCloseObject. 81 Capítulo 3 NI-CAN (National Instruments-CAN) INICIO Configurar Objeto (ncConfig) Objetos Configurados? Abrir Objeto (ncOpenObject) Objetos Abiertos? Inicio de Comunicación (ncAction) § § § § Esperar Datos (ncWaitForState, ncCreateNotification) Leer Datos (ncRead) Escribir Datos (ncWrite) ... Programa de CAN Finalizado? Cerrar Objeto (ncCloseObject) Objetos Cerrados? FIN Figura 3.4. Modelo de Programación para Aplicaciones de CAN. 82 Capítulo 3 NI-CAN (National Instruments-CAN) 3.5. Tipos de Comunicación en los Objetos CAN. Los objetos de tipo CAN pueden ser configurados para transferir los datos según los requerimientos deseados: datos periódicos, al recibir una trama remota, cuando se utiliza la función ncWrite,.... 3.5.1. Recepción de Tramas de Datos No Solicitadas. Esta configuración es utilizada cuando la trama de datos recibida no ha sido requerida anteriormente mediante una trama remota. Si la trama de datos es requerida periódicamente, se puede utilizar un temporizador que indica el tiempo de expiración. En el caso que la trama de datos no haya sido recibida en ese periodo, el controlador de NI-CAN informará de lo sucedido, devolviendo un error de tipo nc_err_timeout. Este temporizador es utilizado para verificar que el nodo remoto está transmitiendo correctamente como se esperaba. Otra opción que se puede configurar en este tipo de comunicación es el tipo de datos recibidos, todos los datos o sólo los que varían respecto a los datos anteriores. 3.5.2. Recepción de Tramas de Datos Solicitadas. Esta configuración es utilizada cuando la trama de datos recibida ha sido requerida anteriormente mediante una trama remota. El envío de la trama remota puede ser periódico o espontáneo. En el primer caso es el controlador de NI-CAN quien se encarga de enviar la trama remota periódicamente. En el segundo caso, el usuario envía la trama mediante la función ncWrite con el parámetro longitud de datos puesto a cero. En ambos casos, los datos recibidos de otros nodos son almacenados en la cola de lectura. Como en la recepción de tramas no solicitadas, se puede configurar una opción para recibir todos los datos o sólo los que varían respecto a los datos anteriores. 83 Capítulo 3 NI-CAN (National Instruments-CAN) Figura 3.5. Transferencia de Datos Solicitados. 3.5.3. Transmisión de Tramas de Datos No Solicitadas. Esta configuración es utilizada cuando la trama de datos transmitida no ha sido requerida anteriormente mediante una trama remota. El envío de la trama de datos puede ser periódico o espontáneo. En el primer caso, es el controlador de NI-CAN quien se encarga de enviar la trama periódicamente (el controlador enviará periódicamente el último dato introducido). En el segundo caso, el usuario envía la trama mediante la función ncWrite. Figura 3.6. Trasmisión Periódica de Datos. 84 Capítulo 3 NI-CAN (National Instruments-CAN) 3.5.4. Transmisión de Tramas de Datos Solicitadas. Las tramas de datos transmitidas en este tipo de comunicación, sólo se realizarán si previamente se ha recibido una trama remota requiriendo estos datos. Los datos transmitidos serán los residentes en la cola de escritura. Si la transmisión de datos se realiza periódicamente, se puede utilizar un temporizador que indica el tiempo de expiración. En el caso de que la trama remota previa a la transmisión de datos, no haya sido recibida en ese periodo, el controlador de NI-CAN informará de lo sucedido, devolviendo un error de tipo nc_err_timeout. Este temporizador es utilizado para verificar que el nodo remoto está transmitiendo correctamente como se esperaba. 3.5.5. Transmisión de Tramas de Datos Consecutivas. Esta configuración es utilizada para transmitir una secuencia fija de tramas de datos periódicamente, variando únicamente los valores de los datos. Las tramas transmitidas son las almacenadas en la cola de escritura, desde los datos correspondientes al primer mensaje hasta los últimos introducidos. Al finalizar una secuencia completa, empezará una nueva secuencia con los nuevos valores introducidos. En los casos anteriores, sólo se transmitía repetidamente el último dato introducido en la cola hasta que éste fuera modificado. 85 Capítulo 4 Diseño del Simulador de Redes de CAN Capítulo 4. Diseño del Simulador de Redes de CAN. A partir del entorno Labview y utilizando las librerías englobadas en el software NI-CAN, hemos creado el programa CAN Simulator 2005, para facilitar el desarrollo, la simulación y el análisis de sistemas de comunicación CAN. Dicho programa está compuesto de varias aplicaciones: Ø El Editor de Base de Datos crea las bases de datos, que como el editor CANdb++, contiene la información simbólica de los nodos de red, mensajes y señales. Ø El Visualizador de bus CAN (CAN Bus Monitor) sirve para visualizar todos los mensajes que circulan en un sistema de comunicación CAN. Estos mensajes pueden ser mostrados por pantalla de una forma simbólica a partir de una base de datos creada previamente con el Editor de Base de Datos, o simplemente mostrar el identificador de arbitraje y los datos que lo componen. Ø A diferencia del programa Canoe, no hemos creado ninguna aplicación específica para crear paneles y programar el comportamiento de los nodos a simular, sino que utilizamos el entorno Labview para crear y programar dichos paneles. Cada panel creado será un nodo diferente. Ø A partir de la aplicación Simulador (Simulator) se simulan los sistemas de bus CAN. Cualquier sistema para poder ser simulado debe tener una base de datos asociada. Si además se desea simular el comportamiento de los nodos, será necesario crear tantos paneles como nodos se deseen simular. Labview.exe Bitmaps *.bmp Editor de Base de Datos Paneles Nombre del Nodo.vi Base de Datos *.txt Simulador de CAN Visualizador de Mensajes Figura 4.1. Arquitectura del Programa CAN Simulator 2005. 86 Capítulo 4 Diseño del Simulador de Redes de CAN 4.1. Editor de Base de Datos. En esta aplicación se almacenan todos los datos relevantes de un sistema de comunicación, para ser procesados posteriormente por el resto de aplicaciones creadas. 4.1.1. Estructura de la Aplicación. La aplicación Editor de Base de Datos está compuesta por una serie de programas creados con la herramienta Labview, conocidos como instrumentos virtuales. Figura 4.2. Programas que Componen el Editor de Base de Datos. 87 Capítulo 4 Diseño del Simulador de Redes de CAN En cada sistema de comunicación se creará una base de datos que contendrá tres bloques de datos diferentes: § Datos de los nodos. § Datos de los mensajes. § Datos de las señales. Aunque los datos son almacenados en un fichero tipo texto, cuando éstos son leídos por la aplicación, se guardan en matrices (arrays) vinculadas entre sí. En el caso de los nodos, sólo existe un campo y por lo tanto, todos los datos pueden ser almacenados en una matriz de texto (array of strings). En cambio, en el caso de los mensajes y de las señales, al haber diferentes tipos de datos, éstos deben ser almacenados en matrices de grupos (arrays of clusters). Figura 4.3. Tipos de Datos Incluidos en Nodos, Mensajes y Señales. 88 Capítulo 4 Diseño del Simulador de Redes de CAN 4.1.2. Guardar, Abrir y Importar Fichero. Los programas principales (instrumentos virtuales), save_file y open_file, utilizan funciones y subprogramas parecidos: initialize array, index array, unbundle by name, bundle by name, open_create_replace file, ... La diferencia principal entre ambos programas, es el dato que pasamos por valor a través del terminal function del conector perteneciente al subprograma común, ya que en el caso de querer guardar la base de datos, se debe crear o reemplazar el fichero y, en el caso de abrir, se debe leer. Otra diferencia importante son las funciones format_into_ file y scan_ into_ file, ya que una se encarga de almacenar los datos en un fichero y la otra de leerlos. El programa save_file también llama a otro subprograma, que se encarga de ordenar los mensajes alfabéticamente y las señales según su bit de inicio (start bit), antes de almacenar los datos en el fichero. Figura 4.4. Estructura de los Programas Guardar, Abrir y Importar. 89 Capítulo 4 Diseño del Simulador de Redes de CAN Con el programa import_canoe_database se pueden importar bases de datos con extensión *.dbc, que pertenecen al editor CANdb++ de la herramienta CANoe. Antes de realizar este programa se tuvo que analizar el formato de la base de datos del CANoe. A partir de una base de datos de un sistema de comunicación CAN real, se fueron variando los valores de los diferentes campos (bit de inicio, longitud de la señal, nodo de transmisión,...) hasta identificar todos los parámetros. Figura 4.5. Ejemplo de Base de Datos del CANoe. Todos los nodos que participan en el sistema de comunicación están agrupados tras el identificador BU. Los mensajes aparecen con el identificador BO, y después de cada mensaje están desglosadas todas las señales que pertenecen a ese mensaje, mediante el identificador SG. Cada señal contiene los siguientes parámetros: nombre de la señal, bit de inicio, longitud de la señal en bits, tipo de transmisión (Intel o Motorola), factor, factor de corrección, mínimo, máximo, unidad y nodos que reciben esta señal. 90 Capítulo 4 Diseño del Simulador de Redes de CAN La figura siguiente sólo es un fragmento de código del programa principal que corresponde a la identificación de todos los mensajes existentes en la base de datos. Los parámetros que contiene cada mensaje son: identificador de arbitraje codificado, nombre del mensaje, longitud en número de bytes y nodo que transmite el mensaje. Figura 4.6. Algoritmo Simplificado del Programa Importar. 4.1.3. Configuración de la Red de CAN. Al abrir o importar una base de datos accedemos a otro menú con varias opciones y en el que podemos distinguir varios programas principales: § Network_Nodes_List (Lista de Nodos de Red): muestra por pantalla los nodos que participarán en la red de CAN. Además llama a otros subprogramas para añadir o modificar nodos. 91 Capítulo 4 Diseño del Simulador de Redes de CAN § Messages_List (Lista de Mensajes): muestra por pantalla los mensajes que son transmitidos por cada nodo. Además, llama a otros subprogramas para añadir o modificar mensajes. § Signals_List (Lista de Señales): muestra por pantalla las señales que contiene cada mensaje. Además, llama a otros subprogramas para añadir o modificar señales o algún campo del mensaje si fuera necesario. § Report_Excel_Format (Informe en Formato Excel): estructura y exporta la base de datos (nodos, mensajes y señales) que se encuentra abierta, a la aplicación Excel de Microsoft Office. § Report_Text_Format (Informe en Formato Texto): estructura y exporta la base de datos (nodos, mensajes y señales) que se encuentra abierta, a un fichero de tipo texto. Figura 4.7. Estructura del Menú Configuración. 92 Capítulo 4 Diseño del Simulador de Redes de CAN 4.1.3.1. Lista de Nodos de Red. Para mostrar la lista de nodos hemos utilizado un control de tipo listbox with columns que trabaja con variables de tipo string. Como los nodos están almacenados en un array del mismo tipo, no es necesario convertir la variable. En el panel también hemos añadido 4 controles de tipo botón para poder escoger entre añadir, modificar, borrar o salir. El diagrama de bloques (código de programación) utilizado para borrar un nodo y actualizar los mensajes que hacían referencia a ese nodo, reside en el programa principal. En cambio, el diagrama de bloques para añadir o modificar un nodo, está localizado en dos subprogramas, como podemos observar en la figura anterior. El subprograma Tx_or_Rx_Messages se encarga de filtrar los mensajes que son transmitidos o recibidos por el nodo que está siendo visualizado en ese momento por pantalla. En las figuras siguientes se puede observar el diagrama de bloques de este subprograma según su orden de ejecución. Figura 4.8. Declaración y Inicialización de Variables. 93 Capítulo 4 Diseño del Simulador de Redes de CAN Figura 4.9. Subdiagramas de la Estructura Secuencia. 94 Capítulo 4 Diseño del Simulador de Redes de CAN 4.1.3.2. Lista de Mensajes. Al igual que en el apartado anterior, para mostrar la lista de mensajes hemos utilizado un control de tipo listbox with columns (Messages_List) que trabaja con variables de tipo string. Aunque en este caso, los mensajes están almacenados en un array de clusters, dificultando el traspaso de datos. Por ejemplo, para indicar el nodo que transmite cada mensaje o los nodos que recibe cada mensaje, se utiliza un subprograma (Split_NNode_List) para pasar de una variable de tipo número a un array de strings que contiene el nombre de los nodos. Figura 4.10. Visualización de Mensajes por Pantalla. En el panel también hemos añadido 4 controles de tipo botón, para poder escoger entre añadir, modificar, borrar o salir. El código de programación necesario para borrar un mensaje y todas las señales que lo componen reside en el programa principal. 95 Capítulo 4 Diseño del Simulador de Redes de CAN Figura 4.11. Eliminación de un Mensaje y sus Señales Asociadas. A diferencia de la opción borrar, el código para añadir o modificar un nodo está localizado en tres subprogramas, tal como podemos observar en figuras anteriores. El subprograma Show_Message muestra todos los campos que hacen referencia al mensaje incluyendo las señales que lo componen. Cuando los campos que se desean modificar hacen referencia a los nodos que trasmiten o reciben el mensaje se llama a los otros dos subprogramas. 96 Capítulo 4 Diseño del Simulador de Redes de CAN 4.1.3.3. Lista de Señales. Como en los apartados anteriores, para mostrar la lista de señales hemos utilizado un control de tipo listbox with columns (Signals_List) que trabaja con variables de tipo string. En el panel también hemos añadido 4 controles de tipo botón para poder escoger entre añadir, modificar, borrar o salir. El código de programación necesario para borrar un mensaje y todas las señales que lo componen reside en el programa principal. A diferencia de la opción borrar, el código para añadir o modificar un nodo, está localizado en el subprograma Show_Signal, que a su vez llama a 6 subprogramas más: § Split_NNode_List: es utilizado para pasar de una variable de tipo número a un array de strings que contiene el nombre de los nodos. § Change_Start_&_Length: modifica los campos bit de inicio y longitud de la señal. § Check_Free_Position: chequea los bits libres del mensaje al que pertenece la señal. Figura 4.12. Subprograma Check_Free_Position. 97 Capítulo 4 Diseño del Simulador de Redes de CAN § Check_Signal_Position_in_the_Message: comprueba que los bits que ocupa la señal no están ocupados por otra señal. § Calculate_Max_&_Min: calcula el valor máximo y mínimo que podrá obtener la señal según la longitud de bits, el tipo de número y el factor que ha sido aplicado. § Change_DLC: en algunos casos al incrementar la longitud de bits de la señal o al crear una señal nueva, es necesario incrementar el número de bytes del mensaje. 4.1.3.4. Informe en Formato Excel. Estructura y exporta la base de datos (nodos, mensajes y señales) que se encuentra abierta, a la aplicación Excel de Microsoft Office. Para exportar los datos a la aplicación Excel se utilizan 5 subprogramas diferentes: § Open_Excel: abre la aplicación Excel creando un número de referencia para poder trabajar con los libros. § Open_Book_Excel: abre un libro de Excel creando un número de referencia para poder trabajar con las hojas de cálculo del libro. § Open_Sheet_Excel: abre una hoja de cálculo creando un número de referencia para poder trabajar con las celdas. § Add_Value_in_Cell: modifica el nombre de la hoja de cálculo y añade los valores en sus celdas correspondientes. § Convert_Cell_Reference: es utilizado por el subprograma anterior para convertir los números de las columnas y filas en el formato requerido por la aplicación Excel, letra de columna más número de fila (A1, A2,...). 98 Capítulo 4 Diseño del Simulador de Redes de CAN En la figura siguiente se puede observar un fragmento simplificado del diagrama de bloques del programa Report_Excel_Format. En este fragmento se pueden seguir todos los pasos necesarios para añadir la lista de nodos en una hoja de cálculo y cerrar posteriormente la aplicación de Excel. Figura 4.13. Algoritmo Simplificado del Programa Report_Excel_Format. 4.1.3.5. Informe en Formato Texto. El diagrama de bloques es muy similar al utilizado en el programa save_file, pero convirte los datos en un formato reconocible por el usuario, donde cada campo está identificado con su nombre. 99 Capítulo 4 Diseño del Simulador de Redes de CAN 4.2. Visualizador de Bus CAN. Mediante esta aplicación, pueden visualizarse todos los mensajes que circulan en una red de bus CAN tanto en formato estándar como extendido. 4.2.1. Estructura de la Aplicación. La aplicación está estructurada en tres programas principales: Open_File (comentado en apartados anteriores), Test_Network y Bus_Monitor_Data_Base. La principal diferencia entre los dos últimos programas es la forma de mostrar los mensajes recibidos. El programa Test_Network sólo muestra el identificador de arbitraje, la longitud de los datos, los datos y el tiempo de sellado. En cambio, el otro programa muestra además el mensaje de una forma simbólica y el valor de cualquier señal. Figura 4.14. Programas que Componen el Visualizador de Datos. 100 Capítulo 4 Diseño del Simulador de Redes de CAN 4.2.2. Tipos de Visualizadores. Existen 2 tipos de visualizadores: el Test_Network que funciona sin ninguna base de datos asociada y el Bus_Monitor_Data_Base que a diferencia del anterior, sí que tiene una base datos asociada, la cual ha sido creada con el Editor de Base de Datos o el Candb++ de CANoe. Ambos tipos comparten subprogramas y funciones de la librería de Labview ya que el modelo de programación de la tarjeta NI-CAN es el mismo, además, ambos programas pueden almacenar los mensajes recibidos en un archivo de tipo texto. El programa Test_Network, al ser menos complejo y realizar menos operaciones ya que no tiene ningún filtro de mensajes recibidos y además no es mostrado de forma simbólica por pantalla, consigue una mayor velocidad de lectura de datos. La mayor desventaja que tiene el programa Bus_Monitor_Data_Base ya la hemos comentado anteriormente, pero algunas de las opciones que perjudican la velocidad de proceso del sistema se convierten en ventajas si se quiere realizar filtros de tipo software cuando se están leyendo mensajes de la red o, otro punto importante es si se desea obtener el valor físico de alguna señal. Además los datos guardados en el fichero de texto contienen más información que en el caso anterior. Debido al gran tamaño del diagrama de bloques de los programas principales es muy difícil mostrar los fragmentos más importantes y, hemos preferido enseñar el diagrama de bloques de la función ncRead. Figura 4.15. Función ncRead. 101 Capítulo 4 Diseño del Simulador de Redes de CAN 4.3. Simulador de Bus CAN. A partir de esta aplicación se puede simular el comportamiento de cualquier sistema de bus CAN de baja y alta velocidad. Si además queremos simular el comportamiento real de alguno de los nodos que participan en la simulación, también se puede conseguir a partir de los paneles. Estos paneles son programados por el usuario y actúan de subprogramas de esta aplicación. 4.3.1. Estructura de la Aplicación. La aplicación está estructurada en dos programas principales: Open_File (comentado en apartados anteriores) y Setup_Run_Can_Network. Este segundo programa configura la simulación a partir de las opciones que el usuario requiere, filtrando la base de datos, dejando sólo los nodos que participarán en la simulación y abriendo los paneles creados por el usuario. Una vez configurada la simulación llama a las siguientes funciones y subprogramas: § Función rendezvous: esta función nos permite sincronizar varias tareas en paralelo. En nuestro caso serán dos subprogramas: Trace_Window y Interactive_CAN. § Subprograma Trace_Window: aquí se puede visualizar todos los mensajes enviados por los nodos simulados o reales que participan en la simulación. Además actualiza los valores de las señales de los paneles cuando un mensaje es recibido. § Subprograma Interactive_CAN (CAN_Interactivo): la función de este subprograma es transmitir por la red de CAN todos los mensajes de los nodos que se desean simular. La transmisión será de forma esporádica, periódica o mixta, dependiendo de como se haya configurado el mensaje. 102 Capítulo 4 Diseño del Simulador de Redes de CAN Figura 4.16. Programas que Componen el Simulador. 103 Capítulo 4 Diseño del Simulador de Redes de CAN 4.3.2. Configuración de la Simulación. En este programa, el usuario configura todas las opciones que desea en la simulación: § Configurar la tarjeta NI-CAN: puerto de la tarjeta, velocidad de transmisión, longitud de la cola de lectura. § Crear filtros de tipo hardware: la tarjeta NI-CAN filtrará los mensajes recibidos de acuerdo a la máscara y al selector. § Utilización de paneles en la simulación: el usuario puede crear sus propios paneles y utilizarlos en la simulación. § Almacenamiento de mensajes: los mensajes recibidos pueden ser almacenados en un fichero tipo texto. § Seleccionar nodos: en una simulación no es necesario que participen todos los nodos existentes en la base de datos, sino sólo los que sean necesarios. De todos los puntos descritos anteriormente, uno de los más importantes es el de utilización de paneles en la simulación. Para vincular éstos con la aplicación, este programa, a partir de una dirección dada por el usuario, abre todos los paneles de esa dirección que coincidan con alguno de los nodos que se desea simular. Al abrir los paneles, el programa obtiene una referencia que pasará por valor al subprograma Trace_Window. Figura 4.17. Apertura de los Paneles Existentes. 104 Capítulo 4 Diseño del Simulador de Redes de CAN 4.3.2.1. Función Rendezvous. A partir de esta función solucionamos el problema de tener dos tareas funcionando sincronizadamente. Para que funcione correctamente, los subprogramas deben abrirse una vez abierta la función rendezvous, Ya que ésta devuelve una referencia que debe ser pasada por valor desde el programa principal Setup_Run_Can_Network. Cuando la simulación es detenida, esta función debe ser cerrada, para no tener problemas al querer abrirla de nuevo. Abrir Cerrar Referencia Núcleo Figura 4.18. Estructura de la Función Rendezvous. 4.3.2.2. Trace Window. Este programa actúa de una forma similar al visualizador mostrado en apartados anteriores, pero con una complejidad mayor ya que este programa debe trabajar en paralelo con otro programa y además, debe actualizar los valores de los paneles abiertos según los datos de los mensajes recibidos. Para actualizar estos valores, este subprograma controla los paneles a partir de las referencias recibidas desde el programa principal y, con la función set_control_value, modifica el valor. Como podemos observar en la figura siguiente, los valores deben ser codificados con la función flatten_to_string que convierte cualquier valor a binario string. 105 Capítulo 4 Diseño del Simulador de Redes de CAN Figura 4.19. Decodificación del Mensaje Recibido y Modificación del Valor. 4.3.2.3. CAN Interactivo. Como hemos comentado anteriormente, la función principal de este programa es transmitir todos los mensajes de los nodos que participan en la simulación. Esto lo conseguimos a partir de los objetos tipo CAN que utilizan los buzones FullCAN, y en el caso de comunicaciones mixtas también utilizamos los objetos CAN Network Interface. Al utilizar ambos tipos, deberemos configurar y abrir cada uno de ellos y, en el caso de los objetos tipo CAN, crearemos un array con el nombre Obj_Handle_Out que contendrá todas las referencias, una por cada mensaje abierto. Cuando se quiera variar los datos de algún mensaje se deberá llamar a la función ncWrite, identificando su referencia de objeto. 106 Capítulo 4 Diseño del Simulador de Redes de CAN Figura 4.20. Configuración de los Objetos Tipo CAN y CAN Network Interface. Además con este programa el usuario puede variar los valores de las señales de una forma física, sin tener que conocer las características del mensaje (número de bytes, tipo de comunicación,...) ni el formato de la señal (bit de inicio, longitud de la señal, factor,...). En el caso de que se haya creado algún panel (simula el comportamiento real de un nodo) actualiza los datos que debe transmitir el mensaje a partir de los valores de las señales que recibe de los paneles, a través de la función queue (cola). Referencia Abrir Esperar Figura 4.21. Estructura de la Función Queue. 107 Núcleo Capítulo 5 Guía de Diseño para el Usuario Capítulo 5. Guía de Diseño para el Usuario. En este apartado, se pretende enseñar al usuario los pasos que debe seguir para crear un sistema de comunicación y como realizar las simulaciones, mediante el software que hemos creado y el entorno Labview. Ejecutando el programa CAN Simulator 2005 nos aparecerá un menú con las siguientes opciones: Ø Edit Data Base: se utiliza para crear, modificar y importar bases de datos. Ø Bus Monitor: muestra por pantalla los mensajes recibidos a través del bus CAN. Ø Simulator: se simulan los sistemas de bus CAN. Figura 5.1. Ventana Principal del Programa CAN Simulator 2005. Si no disponemos de ninguna base de datos de tipo texto con el formato específico de este programa, lo primero que deberemos hacer es crearla o importarla desde el programa CANoe. De lo contrario este programa sólo funcionará como visualizador de tramas. 108 Capítulo 5 Guía de Diseño para el Usuario 5.1. Edit Data Base. Todos los datos relevantes de un sistema de comunicación procesados en una red de bus CAN, normalmente son administrados por una base de datos. Esto incluye las unidades de control, los nodos de red, los mensajes y las señales. 5.1.1. Tipos de objetos. Los objetos utilizados por este editor de base de datos para diseñar un sistema de buses, están nombrados a continuación según su importancia dentro del sistema electrónico de un vehículo: Ø Control Units (ECUs): las unidades de control electrónico están distribuidas por toda la red y intercambian información con otras unidades de control a través de sus controladores de bus (Networks Nodes). Ø Network Nodes (NN): estos dispositivos son la interfaz de comunicación entre la unidad de control y el bus CAN. Cuando un nodo es añadido a la red, automáticamente se crea una unidad de control con el mismo nombre. Los controladores de bus son los encargados de enviar y recibir los mensajes. Ø Messages: como hemos comentado en capítulos anteriores un mensaje se compone de varios campos: identificación, número de datos, tipo de transmisión, control de error y de bytes de datos. Ø Signals: los bytes de datos enviados en un mensaje pueden ser divididos en una o más señales dependiendo de la información a enviar. 109 Capítulo 5 Guía de Diseño para el Usuario 5.1.2. Menús del Edit Data Base. Al escoger esta opción en el menú principal entramos en otro menú con las siguientes opciones: Ø New: crea una nueva base de datos. Ø Open: abre una base de datos ya existente. Ø Import Canoe DB: importa los datos necesarios para definir un sistema de comunicación CAN. Indiferentemente de la opción que escojamos nos aparecerá un menú con las siguientes opciones: CAN Network Configuration. Ø Network Nodes: en esta opción se añaden todos los nodos de red. Ø Messages: se crean y se configuran todos los mensajes que serán enviados por la red. Ø Signals: se crean y se configuran todas las señales que componen el mensaje. Report. Ø Text Format: crea un informe de la base de datos activa y lo guarda en un fichero tipo texto. Ø Excel format: crea un informe de la base de datos activa y lo guarda en un libro de Excel (Microsoft Office). 5.1.2.1. Network Nodes. Si se trata de una nueva base de datos, deberíamos empezar definiendo los nodos que participarán en la red de CAN. Al pulsar la opción Network Nodes nos aparece una ventana con los nodos de red y unidades electrónicas. 110 Capítulo 5 Guía de Diseño para el Usuario Figura 5.2. Lista de Nodos de Red. En la parte inferior de la ventana encontramos diferentes comandos para escoger: Ø New Node: crea un nuevo nodo de red. Ø Edit Node: modifica el nodo de red seleccionado. Ø Delete Node: elimina el nodo de red seleccionado pero no los mensajes que transmite. Ø Exit: vuelve a la ventana anterior. Si seleccionamos alguna de las dos primeras opciones, nos aparecerá una nueva ventana con tres carpetas: Definition, Tx Messages y Rx Messages. Si escogemos la opción New Node, deberemos rellenar el campo Network Node Name (no podrá tener más de 25 dígitos) que nos aparece en la carpeta Definition, ya que las otras dos carpetas son de sólo lectura y muestran los mensajes que envía o recibe el nodo. Al pulsar el botón Ok se añade un nuevo nodo de red y una unidad electrónica a la base de datos. 111 Capítulo 5 Guía de Diseño para el Usuario En cambio, si ya tenemos algún nodo en la lista, podemos elegir la opción Edit Node y, nos aparecerá la misma ventana que en el caso anterior pero con todos los datos referentes al nodo seleccionado: nombre del nodo, mensajes enviados y mensajes recibidos. Figura 5.3. Ventana de Inserción y Modificación de Nodos, Carpeta Definition. Figura 5.4. Ventana de Inserción y Modificación de Nodos, Carpeta Tx Messages. En las carpetas Tx Messages y Rx Messages se muestran los siguientes campos: nombre simbólico de los mensajes ordenados alfabéticamente, tipo de mensaje, identificador de arbitraje, número de bytes a transmitir y tipo de comunicación. 112 Capítulo 5 Guía de Diseño para el Usuario 5.1.2.2. Messages. Una vez insertados los nodos de red, pasamos a definir los mensajes que enviará y recibirá cada nodo. Para ello, volvemos a la ventana anterior con el comando Exit y pulsamos el comando Messages. A continuación vemos una nueva ventana que contiene la lista de mensajes y, en la parte inferior de la misma, encontramos varios comandos para seleccionar: Ø New Message: crea un nuevo mensaje. Ø Edit Message: modifica el mensaje seleccionado. Ø Delete Message & Signals: elimina el mensaje seleccionado y las señales que lo componen. Ø Exit: vuelve a la ventana anterior. Figura 5.5. Lista de Mensajes. Si seleccionamos alguna de las dos primeras opciones, nos aparecerá una nueva ventana con cuatro carpetas: Definition, Signals, Transmitters y Receivers. Si escogemos la opción New Message, deberemos rellenar todos los campos de la carpeta Definition: 113 Capítulo 5 Guía de Diseño para el Usuario § Message Name: nombre simbólico del mensaje (máx. 25 dígitos). § Type: formato del mensaje, estándar o extendido. § ID (10-7FF) / ID (0-1FFFFFFF): identificador de arbitraje. Si el formato es estándar, se utilizan 11 bits para crear el identificador. En cambio si es extendido, se utilizan 29 bits. La prioridad del mensaje dependerá de este campo. Cuantos más bits dominantes (0) haya a la izquierda del identificador, mayor prioridad tendrá. § DLC (Length): número de bytes a transmitir. § Communication Type: tipo de comunicación esporádica, periódica o mixta. § Time (ms): este campo aparece en el caso de comunicaciones periódicas o mixtas. Figura 5.6. Ventana de Inserción y Modificación de Mensajes, Carpeta Definition. Una vez rellenados todos los campos podemos pasar a la carpeta Transmitters. En esta carpeta, aparece una lista a la derecha con todos los nodos creados previamente. Debemos seleccionar el nodo que trasmitirá este mensaje y moverlo mediante la flecha hacia la lista de la izquierda. Figura 5.7. Ventana de Inserción y Modificación de Mensajes, Carpeta Transmitters. 114 Capítulo 5 Guía de Diseño para el Usuario La siguiente carpeta que debemos configurar, es la carpeta Receivers. En esta carpeta, aparece una lista a la derecha con todos los nodos creados previamente. Debemos seleccionar los nodos que recibirán este mensaje y moverlos mediante la flecha hacia la lista de la izquierda. Figura 5.8. Ventana de Inserción y Modificación de Mensajes, Carpeta Receivers. Por último, nos queda comentar la carpeta Signals, de sólo lectura que contiene las señales que componen el mensaje. En el caso de añadir un nuevo mensaje, esta carpeta no contendrá ninguna señal. Figura 5.9. Ventana de Inserción y Modificación de Mensajes, Carpeta Signals. En la figura anterior, se pueden observar los siguientes campos: nombre de la señal, bit de inicio, longitud de los datos de la señal, unidad y tipo de valor (boolean, signed y unsigned). 115 Capítulo 5 Guía de Diseño para el Usuario 5.1.2.3. Signals. Una vez introducidos los mensajes, debemos definir las señales que componen esos mensajes. Para ello, volvemos a la ventana anterior con el comando Exit y pulsamos el comando Signals. A continuación vemos una nueva ventana que contiene la lista de señales y, en la parte inferior de la misma, encontramos nuevamente varios comandos para escoger: Ø New Signal: crea una nueva señal. Ø Edit Signal: modifica la señal seleccionada. Ø Delete Signal: elimina la señal seleccionada. Ø Exit: vuelve a la ventana anterior. Figura 5.10. Lista de Señales. Si seleccionamos alguna de las dos primeras opciones, nos aparecerá una nueva ventana con tres carpetas: Definition, Message y Network Nodes. Si escogemos la opción 116 Capítulo 5 Guía de Diseño para el Usuario New Signal, deberemos seleccionar la carpeta Message y escoger de la lista desplegable el mensaje que contiene la señal que vamos a añadir. Figura 5.11. Ventana de Inserción y Modificación de Señales, Carpeta Message. A continuación seleccionamos la carpeta Definition y rellenamos los siguientes campos: § Signal Name: nombre simbólico de la señal (máx. 25 dígitos). § Start bit: bit de inicio. § Length (bit): número de bits de la señal que se actualiza automáticamente cuando seleccionamos un valor booleano. § Byte Order: depende del controlador utilizado, Intel o Motorola. § Value Type: dependiendo del valor físico de la señal, se debe escoger entre valor booleano, valor entero sin signo y valor entero con signo. § Minimum: el mínimo valor que tendrá la señal física. Se actualiza automáticamente cuando variamos el número de bits o el tipo de valor. § Maximum: el máximo valor que tendrá la señal física. Se actualiza automáticamente cuando variamos el número de bits o el tipo de valor. § Factor: es el factor que se aplica a la señal física antes de ser enviada en el mensaje o después de ser recibida. § Unit: unidad de la señal física (km/h, ºC,...). Para facilitar la elección del bit de inicio, hemos añadido un botón de información en la esquina derecha de la carpeta que en el caso de ser pulsado, mostrará los bits libres 117 Capítulo 5 Guía de Diseño para el Usuario del mensaje que ha sido escogido en la carpeta Message. Además, si el bit escogido ya está ocupado por otra señal, aparecerá un mensaje por pantalla denunciando lo sucedido y, proponiendo una alternativa para optimizar los bits libres. Si el número de bits de la señal es mayor que el número de bits libres que dispone el mensaje, aparecerá otro mensaje, proponiendo aumentar el número de bytes de datos del mensaje. Figura 5.12. Ventana de Inserción y Modificación de Señales, Carpeta Definition. Por último nos queda comentar la carpeta Network Nodes, de sólo lectura que contiene dos listas diferentes: una con el nodo que transmite la señal y otra con los nodos que reciben la señal. Una vez introducidas todas las señales, podemos volver a la ventana anterior. Desde aquí, podemos volver al menú Edit Data Base pulsando el comando que contiene el mismo nombre que el menú, o crear algún informe de la base de datos activa en formato texto o excel. Los informes muestran los nodos, mensajes y señales que forman el sistema de comunicación que hemos creado. Cuando pulsemos el botón Edit Data Base, la base de datos se guardará en un fichero tipo texto. 118 Capítulo 5 Guía de Diseño para el Usuario 5.1.2.4. Informes en Formato Texto o Excel. Si todavía estamos en el menú Can Network Configuration, podemos crear un informe con todos los elementos que componen el sistema de comunicación CAN configurado anteriormente. Tanto si pulsamos el comando Text Format como el comando Excel Format, se creará un fichero con toda la información de nodos, mensajes y señales. El fichero texto contendrá toda la información en la misma hoja, con todos los nodos al inicio y después, todos los mensajes con las señales que lo componen. En cambio, en el fichero excel se crearán 3 hojas de cálculo: nodos, mensajes y señales. A continuación se puede observar un ejemplo de cada fichero. Figura 5.13. Informe en Formato Texto. Figura 5.14. Informe en Formato Excel. 119 Capítulo 5 Guía de Diseño para el Usuario 5.2. Simulator. A partir del menú Simulator, se simulan los sistemas de bus CAN. Cualquier sistema para poder ser simulado, debe tener una base de datos asociada. A partir del menú principal, pulsando el comando Simulator, accedemos a otro menú. En este menú sólo hay dos opciones: Ø Full Simulation: accedemos a la ventana de configuración de la red (Setup Configuration). Ø Main Menu: vuelve al menú principal. Si pulsamos el botón Full Simulation, se abrirá una ventana donde seleccionaremos el fichero que contiene la base de datos del sistema de comunicación que queremos simular. Si todavía no hemos creado ninguna base de datos, deberíamos volver al menú principal y escoger la opción Edit Data Base. Figura 5.15. Ventana de Configuración de la Red de CAN. 120 Capítulo 5 Guía de Diseño para el Usuario Una vez abierto el fichero, nos aparecerá la ventana de configuración de la red con las siguientes opciones: § Setup Transmmiter Driver: identificamos el puerto CAN (el puerto asignado dependerá de la configuración de cada ordenador) de la tarjeta NI-CAN que funcionará como transmisor de mensajes, y configuramos la velocidad con la que trabajará la red de CAN. § Setup Receiver Driver: identificamos el puerto de la tarjeta NI-CAN que funcionará como receptor de mensajes, y también tenemos la opción de realizar filtros de tipo hardware. En el campo Rx-ID Mask, identificaremos los bits que se desean comparar, y en el campo Rx-ID Selector, los valores de estos bits (ambos campos son de tipo hexadecimal). Además existe otro campo, en el que variamos la cola de lectura, dependiendo del tráfico de mensajes. Si el trafico es muy alto y el ordenador no tiene tiempo suficiente para procesar todos los mensajes, deberemos colocar este campo a cero para evitar desbordamientos en la cola de lectura. § Use Panels Created Previously: si seleccionamos esta opción, podemos utilizar los paneles de nodos que hayan sido creados previamente. A diferencia del programa Canoe, no hemos creado ninguna aplicación específica para crear paneles y programar el comportamiento de los nodos a simular, sino que utilizamos el entorno Labview para crear y programar dichos paneles. Cada panel creado será un nodo diferente. § Save Trace Window Data: esta opción almacena los mensajes recibidos en un fichero de texto. Esta opción puede crear problemas si el número de mensajes recibidos es muy elevado. § Save only Filtered Messages: como durante la simulación está la opción de utilizar filtros de tipo software, también podemos almacenar sólo los mensajes filtrados. 121 Capítulo 5 Guía de Diseño para el Usuario § Setup Network (Nodes): debemos escoger los nodos que participarán en la simulación, como nodos simulados o como nodos reales, aunque debemos seleccionar sólo los que sean importantes para la simulación que deseamos realizar. Los mensajes de los nodos reales no deben ser enviados por el simulador, pero sí deben ser leídos. 5.2.1. Inicio de la Simulación. Una vez configurada la simulación pulsamos el botón Start. A continuación nos aparecen varias ventanas: Ø Interactive CAN: en esta ventana el usuario puede modificar todos los valores físicos de las señales que pertenecen a los nodos simulados. Ø Trace Window: aquí se visualizan todos los mensajes recibidos. Ø Stop Window: si pulsamos el botón Stop detenemos la simulación. En esta pequeña ventana que aparece en la parte inferior, también se visualizan los campos de la tarjeta que han sido configurados anteriormente. 5.2.1.1. Interactive CAN. La ventana Interactive CAN aparece por defecto en la zona superior. Esta ventana está dividida en dos zonas, con objetivos diferentes. En la parte izquierda observamos dos listas desplegables: § Filter by Node: facilita la búsqueda del mensaje que se desea configurar, al filtrar los mensajes, según el nodo que lo transmite. § Message Name: esta lista se compone de todos los mensajes no filtrados que participan en la simulación. Al seleccionar un mensaje, aparecen las características principales del mensaje (zona izquierda) y las señales que componen dicho mensaje (zona derecha de la pantalla). 122 Capítulo 5 Guía de Diseño para el Usuario En la parte derecha, se encuentran todas las señales que componen el mensaje seleccionado. Para cada señal se puede ver el nombre simbólico, el bit de inicio, el número de bits de la señal, el factor y la unidad. Además, según el tipo de valor de la señal, a la derecha del recuadro, aparece un interruptor (booleano) o una casilla (número entero con signo o sin signo) que contiene el valor de la señal. Cuando este valor es modificado, el campo Data Message que aparece a la derecha de la ventana es actualizado y el mensaje es enviado con los nuevos datos. 5.2.1.2. Trace Window. La ventana Trace Window aparece por defecto en la zona inferior de la pantalla central. Esta ventana está dividida en dos pequeñas ventanas. En la ventana izquierda, podemos observar los mensajes recibidos y, en la ventana derecha, el valor físico de una señal y el tiempo de sellado. La señal debe ser escogida previamente mediante la lista desplegable (Show Signal) que aparece encima de la ventana. En la parte superior de la ventana donde se muestran los mensajes recibidos, hay dos listas desplegables (Filter by Node y Filter by Message) que sirven como su nombre indica, para filtrar los mensajes. Si utilizamos el filtro Filter by Node, se filtrará todos los mensajes que transmite ese nodo de red, si utilizamos el otro filtro, sólo se visualizará el mensaje escogido. Además de mostrarse el nombre del mensaje, también se visualiza el nodo que ha trasmitido el mensaje, el identificador, el número de bytes, los datos recibidos y el tiempo de sellado. 123 Capítulo 5 Guía de Diseño para el Usuario 5.3. Simulación mediante Paneles. Este programa también ofrece la posibilidad al usuario de crear paneles que simulen el comportamiento de un nodo de red. A estos paneles, se le pueden añadir interruptores, leds, simulador de sensores,..., y programarlos para que funcionen en modo real. Para realizar estos paneles, utilizaremos el entorno Labview, creando un programa o instrumento virtual para cada panel. 5.3.1. Funcionamiento del Programa Labview. Cada instrumento virtual (VI) tiene dos ventanas separadas pero relacionadas entre sí. La ventana Panel contiene el panel frontal de nuestro VI y, la ventana Diagram, donde se construye el diagrama de bloques (código del programa). Se puede conmutar entre ambas pantallas con el comando Show Panel / Show Diagram del menú Window. A partir del mismo menú podemos acceder a la paleta de herramientas (Tools Palette), que será común para ambas ventanas. Con esta paleta podemos seleccionar, escribir y modificar texto, añadir cable de conexión entre elementos (en la ventana Diagram), cambiar color,... Además de la paleta antes comentada, también tenemos dos paletas adicionales, una para cada ventana. Si nos encontramos en la ventana Panel, podemos acceder a la Controls Palette (Paleta de Controles) que contiene los menús para añadir objetos en el panel frontal: botones, leds, tablas, matrices (arrays), grupos (clusters),... Los objetos pueden ser de dos tipos: controles (son de lectura y escritura) o indicadores (sólo son de lectura). Si por el contrario, nos encontramos en la ventana Diagram, podemos acceder a la Functions Palette (Paleta de Funciones) que contiene funciones aritméticas, estructuras (while loop, for loop, case, sequence y formula node), conversores, comparadores,... 124 Capítulo 5 Guía de Diseño para el Usuario Figura 5.16. Ventanas del Programa Labview. 5.3.2. Creación de un Panel. Antes de crear un instrumento virtual (panel), debemos tener el nombre del nodo de red que deseamos simular y las señales que pertenecen a ese nodo, tanto señales transmitidas como recibidas. Esta información la podemos obtener de los informes en formato texto o excel. Una vez dentro del programa Labview, podemos configurar las ventanas para que se visualicen ambas por pantalla, a partir del comando Tile Up and Down o Tile Left and Right del menú Window. Si se desea, también se puede ir conmutando de una ventana a la otra a partir del comando Show Panel / Show Diagram, comentado anteriormente. En primer lugar, salvamos el instrumento virtual con el mismo nombre que el nodo de red que queremos simular, en este caso el nodo Airbag_Module. 125 Capítulo 5 Guía de Diseño para el Usuario A continuación, seleccionamos la ventana Panel y añadimos un objeto por cada señal. Si la señal pertenece a un mensaje que es transmitido por ese nodo, añadiremos un objeto de tipo control, en cambio si el mensaje es recibido, será de tipo indicador. Como mucho de los objetos son por defecto de tipo control, deberemos modificar el tipo del objeto una vez insertado en el Panel, seleccionando el objeto y pulsando el botón derecho del ratón. Figura 5.17. Objetos Numéricos y Booleanos. Cada vez que insertamos un objeto, en la ventana Diagram nos aparecerá el terminal de este objeto, que será con el que trabajaremos cuando tengamos que realizar el diagrama de bloques (código de programación). Los objetos insertados tendrán un nombre por defecto, que deberemos cambiar por los nombres de las señales, diferenciando siempre los objetos de tipo control o indicador. Para cambiar el nombre del objeto utilizaremos el comando de la paleta Tools. Las señales que transmite este nodo son: Airbag_Signal (valor booleano), Crash_Signal (valor booleano) y Driver_Belt_Signal (valor booleano). Y la señal que recibe es Ignition_Signal (valor booleano). Además de las señales con valor booleano, también podemos encontrar señales con valor entero sin signo y con signo. En este caso, debemos insertar objetos numéricos. Con el mismo comando podemos insertar el nombre del nodo de red y, cambiar el formato del texto mediante el comando Text Settings, que aparece en la parte superior de la ventana, y los comandos y de la paleta Tools. 126 Capítulo 5 Guía de Diseño para el Usuario Figura 5.18. Panel con las Señales del Nodo Airbag. El siguiente paso, es seleccionar todas las señales de tipo control y duplicarlas a partir de los comandos Copy y Paste. El nombre de las nuevas señales tendrá el formato nombre_2. Este formato lo sustituiremos por nombre_previous. Estas variables las utilizaremos para saber si el valor de la señal ha cambiado o no. Además de insertar estos nuevos objetos o variables, debemos añadir un objeto de tipo string indicator. A este objeto le llamaremos Module_Name Figura 5.19. Panel con Todos los Objetos. 127 Capítulo 5 Guía de Diseño para el Usuario A continuación nos iremos a la ventana Diagram. Aquí añadiremos, mediante el comando de la paleta Tools, los siguientes recuadros: Module Name, Received Signals y Trasmitted Signals. Después marcaremos cada uno de los recuadros y los ampliaremos para mover todos los terminales dentro. De esta forma, podremos identificar rápidamente cuantos objetos intervienen y si nos hemos dejado alguno. En la ventana Panel sólo necesitamos los objetos que pertenecen a las señales, por lo tanto, ocultaremos el resto de objetos seleccionando el terminal, mediante el comando Hide Control, que aparece al pulsar el botón derecho del ratón. Figura 5.20. Panel con Objetos Ocultos. Antes de centrarnos por completo en la ventana Diagram, acabaremos de perfilar algunos detalles en la ventana Panel. Si seleccionamos cualquier objeto y pulsamos el botón derecho, vemos un menú con diferentes comandos para configurar dicho objeto. Para este panel, nos centraremos en los objetos de tipo control. En este menú, tenemos el comando Visible Items, que oculta o muestra algunos parámetros del objeto. Primero mostraremos el parámetro Boolean Text y a continuación, modificaremos su contenido con el siguiente texto: Airbag_Module_Ok, Crash_Signal_OFF y Unfastened_Driver_Belt. Después ocultaremos los parámetros Label de estos objetos. En el caso de controles de tipo numérico, podemos utilizar el comando Data Range, que aparece en el mismo menú, para configurar el valor mínimo y máximo. 128 Capítulo 5 Guía de Diseño para el Usuario Ahora sólo falta adornar la ventana mediante el menú Decorations de la paleta Controls, y reducir el tamaño de la ventana al máximo para no ocupar espacio innecesario al hacer la simulación. Figura 5.21. Panel del Nodo Airbag. Para finalizar la configuración del panel del nodo Airbag, todavía debemos crear el código de programación (diagrama de bloques). En primer lugar, inicializaremos los objetos que hemos insertado. Seleccionando cada terminal y pulsando el botón derecho del ratón, accederemos a un menú. Al escoger el comando Create, nos aparece un submenú con varias opciones, entre las que debemos elegir el comando Local Variable. Una vez creadas las variables locales, debemos insertar constantes de tipo booleano o númerico, dependiendo del tipo de la variable. Estas constantes se pueden encontrar en la paleta Functions. Ahora debemos unir las variables locales y las constantes, mediante el comando de la paleta Tools. En el caso de la variable Module_Name, además de la variable local deberemos insertar los siguientes elementos: 129 Capítulo 5 Guía de Diseño para el Usuario § Invoke Node: seleccionando el terminal Module_Name y mediante el botón derecho del ratón, accedemos al menú Create. Después seleccionamos el elemento creado y volvemos a pulsar el botón derecho del ratón, accediendo al comando VI del menú Select VI Server Class. § Numeric Constant: accederemos a este elemento a partir de la paleta Functions, menú Numeric. El valor de esta constante debe ser 3. § Subtract: menú Numeric de la paleta Functions. § String Length y String Subset: a estos dos elementos podemos acceder a partir del menú String de la paleta Functions. Como en el caso anterior, ahora debemos unir todos estos elementos mediante el comando de la paleta Tools (ver figura siguiente). Figura 5.22. Inicialización de los Objetos. 130 Capítulo 5 Guía de Diseño para el Usuario El siguiente paso es definir el diagrama de bloques para cada señal que debe ser transmitida por el nodo. Para este ejemplo, utilizaremos la misma condición para todas las señales. La señal será transmitida cuando el valor de la señal Igntiniton_Signal sea uno o ON, y el valor de la señal haya variado respecto el estado anterior. Para realizar este diagrama deberemos insertar los siguientes elementos y unirlos (ver figura siguiente): § Local Variables: añadiremos una variable local de tipo lectura para cada señal y una adicional de tipo escritura para el terminal Airbag_Signal_Previous. Las variables pueden ser de dos tipos: escritura (por defecto) y lectura. Podemos conmutar ambos tipos, mediante el comando Change to Read/Write que nos aparecerá seleccionando la variable y pulsando el botón derecho del ratón. § Property Node del terminal Airbag_Signal: este elemento está en el mismo menú que las variables locales. Una vez insertado el elemento creado, debemos seleccionarlo y pulsar el botón derecho del ratón, accediendo a Properties>Label>Text. § Not equal: menú Comparison de la paleta Functions. § And y Boolean to (0,1): a estos dos elementos accederemos mediante el menú Boolean de la paleta Functions. § Format into String: menú String de la paleta Functions. A continuación pulsaremos el botón derecho del ratón, sin haber seleccionado previamente el elemento creado, y añadiremos un parámetro con el comando Add Parameter. § Case: menú Structures de la paleta Functions. § Insert Queue Element: para acceder a este elemento debemos utilizar la paleta Functions, Advanced>Synchronization>Queue. 131 Capítulo 5 Guía de Diseño para el Usuario Los pasos anteriores se deben realizar también para la señal Crash_Signal y Driver_ Belt_Signal. Figura 5.23. Diagrama de Bloques para la Señal Airbag_Signal. Una vez realizado el diagrama de bloques para las tres señales, sólo necesitamos insertar tres nuevos elementos, que serán los encargados de crear y cerrar el enlace, para transferir datos entre este panel y el programa Simulator y, un bucle para que se ejecute el programa hasta que no paremos la simulación. § Create Queue y Destroy Queue: para acceder a estos dos elementos debemos utilizar la paleta Functions, Advanced>Synchronization>Queue. § While Loop: menú Structures de la paleta Functions. 132 Capítulo 5 Guía de Diseño para el Usuario Figura 5.24. Diagrama de Bloques del Panel Airbag_Module. Con el diagrama de bloques concluido, debemos asegurarnos que todo funcione correctamente mediante la ventana de Errores, que nos aparecerá pulsando las teclas Ctrl+L. Si todo está correcto, ya podemos configurar la ventana que nos aparecerá cuando este panel sea llamado. Pulsando las teclas Ctrl+I, accedemos al menú de propiedades del instrumento virtual. Al escoger la propiedad Window Appearance, los campos de la ventana se modifican y aparece el comando Customize. Si lo pulsamos, accederemos a otra ventana, que debe ser configurada como muestra la figura siguiente. 133 Capítulo 5 Guía de Diseño para el Usuario Figura 5.25. Ventana Customize Appearance Window. El panel del nodo Airbag ya está listo para ser utilizado en el programa Simulator. 5.4. Bus Monitor. El Bus Monitor se utiliza para visualizar todos los mensajes que circulan en un sistema de comunicación CAN. Estos mensajes pueden ser mostrados por pantalla de una forma simbólica a partir de una base de datos creada previamente con el Editor de Base de Datos, o simplemente mostrar el identificador de arbitraje y los datos que lo componen. A partir del menú principal, pulsando el comando Bus Monitor, accedemos a un menú con las siguientes opciones: Ø Test Network: se visualizan todos los mensajes recibidos sin tener ninguna base de datos asociada. Ø Open Data Base: se visualizan todos los mensajes recibidos mediante una base de datos. Ø Main Menu: se vuelve al menú principal. 134 Capítulo 5 Guía de Diseño para el Usuario 5.4.1. Test Network. Si pulsamos el comando Test Network, aparece una ventana que demanda el directorio y el nombre del fichero donde se quieren guardar los mensajes recibidos. Esta ventana es opcional y, en el caso que no se quieran guardar los datos, sólo debemos pulsar el comando Cancel. Figura 5.26. Ventana de Elección de Fichero para Guardar Datos. Una vez escogida la opción de guardar los datos o no, se abre una nueva pantalla con una ventana en la zona central y un menú de configuración en el lado izquierdo. En este menú, configuramos el puerto del controlador de CAN que funcionará como receptor de mensajes, y la velocidad con la que trabajará la red de CAN. También tenemos la opción de realizar filtros de tipo hardware. En el campo Rx-ID Mask, identificaremos los bits que se desean comparar, y en el campo Rx-ID Selector, los valores de estos bits (ambos campos son de tipo hexadecimal). Además, existe otro campo en el que variamos la cola de lectura dependiendo del tráfico de mensajes. Si el tráfico es muy alto y el ordenador no tiene tiempo suficiente para procesar todos los mensajes, deberemos colocar este campo a cero, para evitar desbordamientos en la cola de lectura. 135 Capítulo 5 Guía de Diseño para el Usuario En la zona central, tenemos la ventana en blanco con las columnas: identificador de arbitraje, longitud de los datos, datos y tiempo de sellado. En esta ventana se visualizarán todos los mensajes que circulan en una red de bus CAN, tanto en formato estándar como extendido, cuando el comando Start sea pulsado. Si queremos detener el Bus Monitor, deberemos pulsar el comando Stop. Figura 5.27. CAN Bus Monitor – Test Network. 5.4.2. Bus Monitor con Base de Datos. Si pulsamos el comando Open Data Base, aparecen dos ventanas seguidas. En la primera ventana se debe seleccionar el fichero que contiene la base de datos, y en la segunda (opcional), se debe seleccionar el nombre del fichero donde se quieren guardar los mensajes recibidos. 136 Capítulo 5 Guía de Diseño para el Usuario A continuación, se abre una nueva pantalla con un menú de configuración en la parte superior y dos ventanas de diferente tamaño. En este menú, configuramos el puerto del controlador de CAN, que funcionará como receptor de mensajes, y la velocidad con la que trabajará la red de CAN. También tenemos la opción de realizar filtros de tipo hardware. En el campo Rx-ID Mask identificaremos los bits que se desean comparar, y en el campo Rx-ID Selector, los valores de estos bits (ambos campos son de tipo hexadecimal). Además, existe otro campo, en el que variamos la cola de lectura dependiendo del tráfico de mensajes. Si el tráfico es muy alto y el ordenador no tiene tiempo suficiente para procesar todos los mensajes, deberemos colocar este campo a cero, para evitar desbordamientos en la cola de lectura. Figura 5.28. CAN Bus Monitor – Data Base. En la ventana izquierda, podemos observar los mensajes recibidos, y en la ventana derecha, el valor físico de una señal y el tiempo de sellado. La señal debe ser escogida previamente mediante la lista desplegable (Show Signal) que aparece encima de la ventana. 137 Capítulo 5 Guía de Diseño para el Usuario En la parte superior de la ventana donde se muestran los mensajes recibidos, hay dos listas desplegables (Filter by Node y Filter by Message), que sirven como su nombre indica, para filtrar los mensajes. El filtro Filter by Node filtrará todos los mensajes que transmite ese nodo de red. En cambio, el filtro Filter by Message filtará el mensaje escogido. Además de mostrarse el nombre del mensaje, también se visualiza el nodo que ha trasmitido el mensaje, el identificador, el número de bytes, los datos recibidos y el tiempo de sellado. En esta ventana se visualizarán todos los mensajes que circulan en una red de bus CAN, tanto en formato estándar como extendido, cuando el comando Start sea pulsado. Si queremos detener el Bus Monitor deberemos pulsar el comando Stop. 138 Capítulo 6 Test del Programa de Simulación Capítulo 6. Test del Programa de Simulación. A partir de toda la información generada en capítulos anteriores, vamos a hacer 2 ejercicios diferentes para examinar el funcionamiento del software creado. 6.1. Sistema de Comunicación con 3 Nodos. La red de CAN que queremos simular en este apartado, se basa en 3 nodos: Cockpit_SDN, Smart_Cluster y Airbag_Module (comentado en el capítulo anterior). Como hemos comentado en la guía de diseño, lo primero que debemos hacer es crear una base datos que contenga la información de todos los módulos que van a participar en la simulación. 6.1.1. Informe de la Base de Datos del Sistema Simulado. Una vez creada la base de datos, debemos generar un informe con todos los datos del sistema que nos ayudará a crear los paneles para los nodos Smart_Cluster y Airbag_Module. Mensajes que serán transmitidos en el sistema creado: Message Name ABS_Diag Airbag_Diag Crash_Signal Door_Status Engine_Speed_Data Engine_Status Exterior_Temp_Data Fuel_Level_Data Hazard_Status Headlamp_Status Heated_Window_Status Horn_Status Ignition_Status Parking_Brake_Status TPMS_Diag Arbitration ID DLC Type 0x000B0020 1 Extended 0x000D0030 1 Extended 0x00010030 1 Extended 0x00290020 1 Extended 0x00190020 2 Extended 0x00150020 2 Extended 0x002F0020 1 Extended 0x001D0020 1 Extended 0x00050020 1 Extended 0x00090020 1 Extended 0x002B0020 1 Extended 0x00030010 1 Extended 0x000700E0 1 Extended 0x001F0020 1 Extended 0x00230030 1 Extended Communication Sporadic Mixed Sporadic Sporadic Periodic Sporadic Sporadic Sporadic Sporadic Mixed Sporadic Sporadic Sporadic Sporadic Sporadic 139 Time 0 ms 800 ms 0 ms 0 ms 600 ms 0 ms 0 ms 0 ms 0 ms 800 ms 0 ms 0 ms 0 ms 0 ms 0 ms Transmitter Cockpit_SDN Airbag_Module Airbag_Module Cockpit_SDN Cockpit_SDN Cockpit_SDN Cockpit_SDN Cockpit_SDN Cockpit_SDN Cockpit_SDN Cockpit_SDN Smart_Cluster Cockpit_SDN Cockpit_SDN Cockpit_SDN Receivers Smart_Cluster Cockpit_SDN,Smart_Cluster Cockpit_SDN,Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Smart_Cluster Cockpit_SDN Smart_Cluster,Airbag_Module Smart_Cluster Cockpit_SDN,Smart_Cluster Capítulo 6 Test del Programa de Simulación Señales que componen los mensajes anteriores: Message Name ABS_Diag ABS_Diag Airbag_Diag Airbag_Diag Crash_Signal Door_Status Door_Status Door_Status Door_Status Door_Status Door_Status Engine_Speed_Data Engine_Speed_Data Engine_Status Engine_Status Engine_Status Engine_Status Exterior_Temp_Data Fuel_Level_Data Hazard_Status Hazard_Status Hazard_Status Headlamp_Status Headlamp_Status Headlamp_Status Headlamp_Status Headlamp_Status Heated_Window_Status Heated_Window_Status Heated_Window_Status Horn_Status Ignition_Status Parking_Brake_Status TPMS_Diag Signal Name ABS_Signal Brake_Pad_Signal Airbag_Signal Driver_Belt_Signal Crash_Signal Driver_Ajar_Signal Passenger_Ajar_Signal Rear_Left_Ajar_Signal Rear_Right_Ajar_Signal Trunk_Ajar_Signal Hood_Ajar_Signal Speed_Signal RPM_Signal Coolant_Temp_Signal Oil_Signal Alternator_Signal Glow_Plug_Signal Ext_Temperature_Signal Fuel_Level_Signal Hazard_Signal Turn_Left_Signal Turn_Right_Signal Position_Light_Signal Low_Beam_Signal High_Beam_Signal Front_Fog_Signal Rear_Fog_Signal Rear_Defogger_Signal Heated_Windscreen_Signal Cleaning_Level_Signal Horn_Signal Ignition_Signal Parking_Brake_Signal Tyre_Pressure_Signal Start Bit Length Byte Order 0 1 Intel 1 1 Intel 0 1 Intel 1 1 Intel 0 1 Intel 0 1 Intel 1 1 Intel 2 1 Intel 3 1 Intel 4 1 Intel 5 1 Intel 0 8 Intel 8 7 Intel 0 4 Intel 4 1 Intel 5 1 Intel 8 1 Intel 0 7 Intel 0 5 Intel 0 1 Intel 2 1 Intel 3 1 Intel 0 1 Intel 2 1 Intel 3 1 Intel 5 1 Intel 7 1 Intel 0 1 Intel 2 1 Intel 4 1 Intel 0 1 Intel 0 1 Intel 0 1 Intel 0 1 Intel Value Type Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Unsigned Unsigned Unsigned Boolean Boolean Boolean Signed Unsigned Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Factor Min. Max. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 255 100 0 7000 1 0 15 1 0 1 1 0 1 1 0 1 1 -64 63 4 0 100 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 Unit km/h rpm % ºC % 6.1.2. Descripción de los Paneles diseñados. Al crear paneles, podemos agregar condiciones a las señales que debemos enviar o recibir, para simular el comportamiento del nodo en modo real. 6.1.2.1. Panel del Airbag_Module. En el caso del panel Airbag_Module, la condición para enviar cualquiera de los tres mensajes que puede enviar este módulo, es la recepción de la señal Ignition_Signal con valor uno (vehículo arrancado) desde el nodo Cockpit_SDN (ver figura 5.21). 140 Capítulo 6 Test del Programa de Simulación 6.1.2.2. Panel del Smart_Cluster. Por otro lado, tenemos el panel Smart_Cluster que recibe más mensajes pero sólo envía uno. Como el mensaje que envía se considera de seguridad, no es necesario que el coche esté arrancado, sólo que la señal cambie de valor. De todas las señales recibidas, podemos diferenciar 2 tipos: las señales que actúan sobre las cargas que funcionan siempre y, las señales que actúan sobre las cargas que sólo funcionan cuando el coche está arrancado. Las señales que no están condicionadas al estado del vehículo son las siguientes: Hazard_Signal, Position_Light_Signal, Low_Beam_Signal y High_Beam_Signal. El resto de señales sólo deberán ser aplicadas después de la recepción de la señal Ignition_Signal con valor uno (vehículo arrancado). Figura 6.1. Panel del Nodo Smart Cluster. 141 Capítulo 6 Test del Programa de Simulación 6.1.3. Simulación de la Red de Bus CAN. Con la base de datos creada y los paneles (opcional) creados, ya podemos realizar la simulación del sistema de comunicación con bus CAN. Primero simularemos el sistema sin utilizar los paneles creados, y después los añadiremos. En ambos casos, sólo se utilizará una tarjeta PCMCIA-CAN/DS con 2 puertos y un cable PCMCIA-CAN/2, con 2 transceptores de CAN de alta velocidad. 6.1.3.1. Simulación sin Paneles. En el caso de la simulación sin paneles, sólo se muestran 2 ventanas por pantalla. La ventana superior es la que transmite los mensajes y la ventana inferior la que los recibe y los procesa para mostrar el mensaje de forma simbólica y, conocer el valor físico de las señales. Figura 6.2. Simulación de una Red de CAN sin utilizar Paneles. 142 Capítulo 6 Test del Programa de Simulación 6.1.3.2. Simulación con Paneles. Los paneles nos facilitan el seguimiento de las señales, ya que cada panel pertenece a un nodo diferente. En el caso de no haber creado ninguno, también tenemos la opción de realizar filtros de tipo software. Los paneles son instrumentos virtuales que funcionan individualmente, lo que supone un incremento de tiempo en el global de la simulación. Figura 6.3. Simulación de una Red de CAN mediante Paneles 143 Capítulo 6 Test del Programa de Simulación 6.2. Visualización de Mensajes de un Nodo Real. La finalidad de este ejercicio es visualizar las tramas de datos que envía un nodo real. En este caso, hemos utilizado una tarjeta PCMCIA-CAN/DS, conectando uno de los 2 puertos de la tarjeta, al transceptor de baja velocidad del cable PCMCIA-CAN/DS. Al no disponer de la base de datos de dicho módulo, los mensajes sólo pueden ser visualizados en la ventana Test Network. Para observar como variaban los datos transmitidos por el nodo, hemos modificado el valor de una de sus entradas físicas a través de uno de sus terminales. Figura 6.4. Visualización de Tramas Transmitidas por un Nodo Real. 144 Conclusiones Conclusiones. A partir del programa diseñado, CAN SIMULATOR 2005, podemos desarrollar, simular y analizar sistemas de comunicación con bus CAN de baja y alta velocidad. Las ventajas que ofrece este programa respecto al programa CANoe es básicamente en el ámbito de licencias, ya que el programa CANoe necesita una licencia de software para cada sistema de comunicación. En cambio el programa Labview (versión profesional) tiene la herramienta builder que permite crear tantos ejecutables como se desee y poderlos ejecutar en cualquier ordenador, aunque no esté instalada la licencia de Labview. Además, con este programa, también está la opción de importar bases de datos creadas con el editor de base de datos de CANoe y simularlas, omitiendo los paneles. A diferencia del programa Canoe, no hemos creado ningún editor gráfico específico para crear paneles, ni ningún compilador de pseudo-C para programar el comportamiento de los nodos a simular, sino que utilizamos el entorno Labview para crear y programar dichos paneles. Las desventajas principales de este programa respecto al programa CANoe reside en el número de funciones disponibles (gráficos, ventanas de estadística,...), y en la velocidad de simulación cuando utilizamos los paneles creados, ya que estos paneles se ejecutan como instrumentos virtuales individuales, con la misma prioridad que el programa que hemos diseñado, lo que supone un incremento del número operaciones a realizar por el microprocesador, disminuyendo el tiempo de dedicación a la lectura del bus CAN. 145 Apéndice 1 Apéndice 1. Características Técnicas de la Tarjeta NI-CAN. 146 Apéndice 1 Tipo de Conectores Utilizados en el Cable PCMCIA-CAN. Los cables PCMACIA-CAN cumplen las especificaciones de los estándares ISO 11898 y ISO 11519-2. Cable PCMCIA-CAN. Conector D-Sub 9. Conector Combi para Bus CAN Conector Combi para Bus CAN de Alta Velocidad de Baja Velocidad Interconexiones entre ambos Conectores. 147 Apéndice 2 Apéndice 2. Características Técnicas de la Tarjeta CANcardX. 148 Apéndice 2 Características Técnicas del Cable CANcab. 149 Apéndice 2 Características Eléctricas del CANcab 1054 (LOW SPEED) 150 Apéndice 2 Características Eléctricas del CANcab 251 (HIGH SPEED) 151 Bibliografía Bibliografía. Ø CAN Specification Versión 2.0. 1991, Robert Bosch GmbH, D-70442 Stuttgart. Ø Xarxes Industrials. CAN. Pau Martí, Josep M. Fuertes, ESAII, EUPVG, UPC. 2001, Assignatura de Comunicacions Industrials de l’UPC, Vilanova i la Geltrú. Ø Sistemas Multiplexados en el Automóvil. F. Sánchez, E. Mateu, F. Dorca, A. Freixa. 1999, Seminari Sistemes Distribuïts de Control de l’URV, Tarragona. Ø The new Peugeot 607 launches PSA electronic Platform. PSA Peugeot Citroën. 1999, SIA Automotive Engineers’ Seminar. Ø Controller Area Network Presentation. Versión 2.0. 1998, Siemens Microelectronics, Inc. Ø Análisis protocolar del Bus CAN. Documento. Héctor Kaschel y Ernesto Pinto. 2002, Universidad de Santiago de Chile. Ø Sistemas de diagnostico y sincronización de los buses de campo CAN. Documento. Hécctor Kaschel y Ernesto Pinto. 2002, Universidad de Santiago de Chile. Ø CANdb++ Manual Versión 2.7. Vector Informatik GmbH, D-70499 Stuttgart. Ø CANoe Manual Versión 3.2. Vector Informatik GmbH, D-70499 Stuttgart. 152 Bibliografía Ø Labview 6i. Programación gráfica para el control de instrumentación. A. M. Lázaro. 2001, Paraninfo, S.A. Ø NI-CAN Programmer Reference Manual. 2001, National Instruments. Ø NI-CAN User Manual. 2001, National Instruments. Ø http://www.vector-informatik.de Ø http://www.can-cia.de Ø http://www.ni.com 153