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

1

Í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. Capa Física..........................................................................................15

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. Capa de Enlace....................................................................................18

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

Índice

2

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. Tipos de Controladores........................................................................ 27

1.4.2. Tipos de Tramas..................................................................................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. Arbitraje. .............................................................................................32

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

Índice

3

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

Índice

4

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

Índice

5

4.1.3.5. Informe en Formato Texto................................................................... 99

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

5.2. Simulator. .......................................................................................120

5.2.1. Inicio de la Simulación. ....................................................................122

5.2.1.1. Interactive CAN................................................................................. 122

5.2.1.2. Trace Window. .................................................................................. 123

5.3. Simulación mediante Paneles. ......................................................124

5.3.1. Funcionamiento del Programa Labview. ..........................................124

5.3.2. Creación de un Panel. .......................................................................125

Índice

6

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

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

Índice

7

Características Eléctricas del CANcab 251 (HIGH SPEED)....................151

Bibliografía. ........................................................................................152

Introducción

8

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.

Introducción

9

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

Objetivos

10

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.

Metodología

11

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.

Metodología

12

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.

Capítulo 1 CAN (Controller Area Network)

13

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.


14

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.

Figura 1.1. Niveles del Protocolo Bus CAN.

Capa de Aplicación

Capa Física

Capa de Enlace

Aplicación Perfiles de dispositivos Establecimiento de conexión Contenido de los datos LLC (Logical Link Control) Filtrado de datos Notificación de sobrecarga Gestión de recuperación MAC (medium Access Control) Encapsulamiento de los datos Codificación de la trama Gestión del acceso al medio Detección de errores Señalización de errores Confirmación

PLS (Physical Signalling) Codificación de bits Tiempo de bit Sincronización PMA (Physical Medium Access) Características del emisor/receptor MDI (Medium Dependent Interface) Conectores

Soluciones no estándar Espec. Can Bosch ISO

Niveles del modelo OSI


15

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.


16

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

Impedancia 108 ? mínimo, 120 ?

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.

Figura 1.5. Red de Bus CAN de Alta Velocidad.

120 ? 120 ?


17

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,

CAN_L y CAN_H

30 pF/m nominal

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


18

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.


19

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.

Microprocesador

Memoria E/S

Red de Bus Can

Transceptor

Buzones

Controlador de CAN

Sensores y Actuadores


20

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 Selector-

Identificador-Recibir_Mensaje (RX-ID_Selector) y la correspondiente Mascara-

Identificador-Recibir_Mensaje (RX-ID_Mask), los cuales son definidos por el usuario en

la inicialización de la interfaz BasicCAN.

El identificador de un mensaje que llega se compara con el selector, ignorando los

bits enmascarados por la máscara. Si el identificador concuerda, los datos se guardan en la

parte del buffer correspondiente al buzón Registro-Dato / Identificador-Recibir (RX-ID /

Data-Reg). El registro permite almacenar más de un mensaje, ya que este tipo de filtrado

con máscara, permite que diferentes identificadores pasen el filtrado. Los mensajes serán

leídos en orden FIFO (First in, First out). Cada vez que un mensaje llega, el control del

buffer de recepción de mensajes (RX-Control) genera una interrupción, que hace que el

controlador lea el mensaje. Este mensaje, antes de ser seleccionado, debe pasar por otro

filtro de tipo software.

Figura 1.9. Ejemplo de Selección de los Mensajes Recibidos.

RX-ID_Mask

RX-ID_Selector

x = bits no considerados en la comparación

Identificadores Recibidos

= 0x7F6

= 0x490

= 0x490

= 0x491

= 0x498

= 0x499


21

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.


22

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.


23

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.


24

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.

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

Cables del bus de datos


25

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.


26

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


27

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.


28

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


29

§ 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, ACK-

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


30

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

IDE

Formato Estándar

Formato Extendido


31

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.


32

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.


33

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.


34

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.


35

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

Figura 1.15. Evolución entre Estados de Error.

Error Activo

Error Pasivo

Anulado

REC >127 o TEC >127 y TEC <=255

REC <=127 o TEC <=127

128 Secuencias de 11 bits recesivos + TEC = 0 y REC = 0

TEC >255

Inicio


36

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.

Capítulo 2 CANoe (CAN Open Environment)

37

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.


38

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.


39

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

Standard

Versión

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.


40

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.


41

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.


42

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


43

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

Objetos

Vehicles Networks Control

Units

Node

Groups

Network

Nodes Messages

Networks ?

Control Units (ECUs) ?

Environment Variables ?

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.


44

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


45

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.


46

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.

Figura 2.9. Entorno de un Programa en CAPL.

BLOQUE DEL

PROGRAMA EN

CAPL

Mensaje

Mensaje Tecla

Temporizador

Reacción al

Evento

Tipos de

Eventos


47

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.


48

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


49

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

comenzar)

On preStart {}

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

entorno.

On envVar {}


50

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


51

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.


52

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:

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.

1.- Configuración de la Simulación.

2.- Configuración de la Medida.

3.- Ventana de Escritura.


53

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.


54

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.


55

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.


56

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.


57

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.


58

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.


59

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.


60

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.


61

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.


62

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.


63

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


64

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.


65

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.


66

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.


67

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.


68

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.

Capítulo 3 NI-CAN (National Instruments-CAN)

69

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 PCMCIA-

CAN (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


70

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 PCMCIA-

CAN 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 PCMCIA-

CAN/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.


71

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.


72

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 PCMCIA-

CAN.

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:


73

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


74

§ 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 NI-

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


75

Figura 3.2. Diagrama de Flujo para la Recepción de una Trama.

Trama Recibida

Trama de tipo CAN

ID de Mensaje pertenece a un Objeto CAN?

Trama de Datos?

Trama Ignorada

Estándar o Extendida?

Comparador Estándar

Habilitado?

Aplicar Máscara Estándar

Identificador de Mensaje

Aceptado?

Trama Ignorada

Comparador Estándar

Habilitado?

Aplicar Máscara Estándar

Identificador de Mensaje

Aceptado?

Añadir Trama dentro de la cola de Lectura del Objeto CAN

Netwrok Interface

No

Si

Si

Estándar

Si

Si Si

No

No

No No

No

Si

Extendido


76

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.


77

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


78

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


79

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 Fuente Significado Negativo Verdadero Nombre de la

función donde ha ocurrido el aviso.

Error. La función no funciona correctamente.

Positivo Falso Nombre de la función donde ha ocurrido el aviso.

Aviso. La función funciona correctamente, pero hay alguna condición que requiere ser chequeada.

Cero Falso Vacío. 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


80

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.


81

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.


82

Figura 3.4. Modelo de Programación para Aplicaciones de 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


83

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.


84

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.


85

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.

Capítulo 4 Diseño del Simulador de Redes de CAN

86

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.

Figura 4.1. Arquitectura del Programa CAN Simulator 2005.

Base de Datos *.txt

Editor de Base de Datos Labview.exe

Bitmaps *.bmp

Simulador de CAN Visualizador de Mensajes

Paneles Nombre del Nodo.vi


87

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.


88

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.


89

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.


90

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.


91

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.


92

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


93

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.


94

Figura 4.9. Subdiagramas de la Estructura Secuencia.


95

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.


96

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.


97

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.


98

§ 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,...).


99

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.


100

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.


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.


101

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.


102

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.


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.


103

Figura 4.16. Programas que Componen el Simulador.


104

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.


105

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.

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.

Abrir

Cerrar Referencia

Núcleo


106

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.


107

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

Figura 4.21. Estructura de la Función Queue.

Núcleo

Referencia

Esperar

Abrir

Capítulo 5 Guía de Diseño para el Usuario

108

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.


109

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.


110

5.1.2. Menús del Edit Data Base.

Al escoger esta opción en el menú principal entramos en otro menú con las


Ø 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


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.


111

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.


112

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.


113

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.


Figura 5.5. Lista de Mensajes.


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:


114

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


115

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


116

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.


Figura 5.10. Lista de Señales.


ventana con tres carpetas: Definition, Message y Network Nodes. Si escogemos la opción


117

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


118

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.


119

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.


120

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.


121

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.


122

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


123

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.


124

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


125

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.


126

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.


127

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.


128

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.


129

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:


130

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


131

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.


132

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.


133

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.


134

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.


135

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.


136

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.


137

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.


138

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.

Capítulo 6 Test del Programa de Simulación

139

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 Arbitration ID DLC Type Communication Time Transmitter ReceiversABS_Diag 0x000B0020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterAirbag_Diag 0x000D0030 1 Extended Mixed 800 ms Airbag_Module Cockpit_SDN,Smart_ClusterCrash_Signal 0x00010030 1 Extended Sporadic 0 ms Airbag_Module Cockpit_SDN,Smart_ClusterDoor_Status 0x00290020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterEngine_Speed_Data 0x00190020 2 Extended Periodic 600 ms Cockpit_SDN Smart_ClusterEngine_Status 0x00150020 2 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterExterior_Temp_Data 0x002F0020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterFuel_Level_Data 0x001D0020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterHazard_Status 0x00050020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterHeadlamp_Status 0x00090020 1 Extended Mixed 800 ms Cockpit_SDN Smart_ClusterHeated_Window_Status 0x002B0020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterHorn_Status 0x00030010 1 Extended Sporadic 0 ms Smart_Cluster Cockpit_SDNIgnition_Status 0x000700E0 1 Extended Sporadic 0 ms Cockpit_SDN Smart_Cluster,Airbag_ModuleParking_Brake_Status 0x001F0020 1 Extended Sporadic 0 ms Cockpit_SDN Smart_ClusterTPMS_Diag 0x00230030 1 Extended Sporadic 0 ms Cockpit_SDN Cockpit_SDN,Smart_Cluster


140

Señales que componen los mensajes anteriores:

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

Message Name Signal Name Start Bit Length Byte Order Value Type Factor Min. Max. UnitABS_Diag ABS_Signal 0 1 Intel Boolean 1 0 1ABS_Diag Brake_Pad_Signal 1 1 Intel Boolean 1 0 1Airbag_Diag Airbag_Signal 0 1 Intel Boolean 1 0 1Airbag_Diag Driver_Belt_Signal 1 1 Intel Boolean 1 0 1Crash_Signal Crash_Signal 0 1 Intel Boolean 1 0 1Door_Status Driver_Ajar_Signal 0 1 Intel Boolean 1 0 1Door_Status Passenger_Ajar_Signal 1 1 Intel Boolean 1 0 1Door_Status Rear_Left_Ajar_Signal 2 1 Intel Boolean 1 0 1Door_Status Rear_Right_Ajar_Signal 3 1 Intel Boolean 1 0 1Door_Status Trunk_Ajar_Signal 4 1 Intel Boolean 1 0 1Door_Status Hood_Ajar_Signal 5 1 Intel Boolean 1 0 1Engine_Speed_Data Speed_Signal 0 8 Intel Unsigned 1 0 255 km/hEngine_Speed_Data RPM_Signal 8 7 Intel Unsigned 100 0 7000 rpmEngine_Status Coolant_Temp_Signal 0 4 Intel Unsigned 1 0 15 %Engine_Status Oil_Signal 4 1 Intel Boolean 1 0 1Engine_Status Alternator_Signal 5 1 Intel Boolean 1 0 1Engine_Status Glow_Plug_Signal 8 1 Intel Boolean 1 0 1Exterior_Temp_Data Ext_Temperature_Signal 0 7 Intel Signed 1 -64 63 ºCFuel_Level_Data Fuel_Level_Signal 0 5 Intel Unsigned 4 0 100 %Hazard_Status Hazard_Signal 0 1 Intel Boolean 1 0 1Hazard_Status Turn_Left_Signal 2 1 Intel Boolean 1 0 1Hazard_Status Turn_Right_Signal 3 1 Intel Boolean 1 0 1Headlamp_Status Position_Light_Signal 0 1 Intel Boolean 1 0 1Headlamp_Status Low_Beam_Signal 2 1 Intel Boolean 1 0 1Headlamp_Status High_Beam_Signal 3 1 Intel Boolean 1 0 1Headlamp_Status Front_Fog_Signal 5 1 Intel Boolean 1 0 1Headlamp_Status Rear_Fog_Signal 7 1 Intel Boolean 1 0 1Heated_Window_Status Rear_Defogger_Signal 0 1 Intel Boolean 1 0 1Heated_Window_Status Heated_Windscreen_Signal 2 1 Intel Boolean 1 0 1Heated_Window_Status Cleaning_Level_Signal 4 1 Intel Boolean 1 0 1Horn_Status Horn_Signal 0 1 Intel Boolean 1 0 1Ignition_Status Ignition_Signal 0 1 Intel Boolean 1 0 1Parking_Brake_Status Parking_Brake_Signal 0 1 Intel Boolean 1 0 1TPMS_Diag Tyre_Pressure_Signal 0 1 Intel Boolean 1 0 1


141

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.


142

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.


143

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


144

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.

Conclusiones

145

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.

Apéndice 1

146

Apéndice 1.

Características Técnicas de la Tarjeta NI-CAN.

Apéndice 1

147

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

de Alta Velocidad

Conector Combi para Bus CAN

de Baja Velocidad

Interconexiones entre ambos Conectores.

Apéndice 2

148

Apéndice 2.

Características Técnicas de la Tarjeta CANcardX.

Apéndice 2

149

Características Técnicas del Cable CANcab.

Apéndice 2

150

Características Eléctricas del CANcab 1054 (LOW SPEED)

Apéndice 2

151

Características Eléctricas del CANcab 251 (HIGH SPEED)

Bibliografía

152

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.

Bibliografía

153

Ø 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

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

Documents

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