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

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