capítulo iv - bibing.us.esbibing.us.es/proyectos/abreproy/12219/fichero/capítulo+4... · un...

33
85 Capítulo IV Aplicaciones 4. En este capítulo van a ser descritas las dos aplicaciones creadas para este proyecto así como el entorno de programación con el que han sido creadas. Estas aplicaciones serán ejecutadas en el ordenador de a bordo. Las aplicaciones se han programado en el lenguaje Visual C++ usando la herramienta de desarrollo Microsoft Visual Studio 2010. Esta herramienta es totalmente gratuita y se puede descargar de la página de Microsoft. La primera de las aplicaciones que se describirá se denomina “Aplicación CAN”. A grandes rasgos esta aplicación permitirá: configurar el nodo interfaz (microcontrolador Atmel AT90CAN128 sobre STK 500 + 501), mandar tramas CAN al bus CAN, recibir tramas CAN desde el bus y monitorizar el bus. Con esta aplicación se busca demostrar el correcto funcionamiento tanto del bus CAN como de los nodos de la red. La segunda aplicación creada se denomina “Aplicación OBDII”. Esta aplicación simulará un escáner OBDII real a la ECU (placa de evaluación integrada Olimex AVR H-128-CAN). El nodo interfaz recibirá las órdenes desde la aplicación y enviará tramas OBDII hacia la ECU, la cual recibirá dichas peticiones, las atenderá y responderá con respuestas OBDII. Posteriormente será el nodo interfaz el encargado de extraer la información relevante de las tramas OBDII y enviarla hacia la aplicación para que esta la interprete.

Upload: vuongtram

Post on 07-Mar-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

85

Capítulo IV

Aplicaciones 4.

En este capítulo van a ser descritas las dos aplicaciones creadas para este proyecto así

como el entorno de programación con el que han sido creadas. Estas aplicaciones serán

ejecutadas en el ordenador de a bordo.

Las aplicaciones se han programado en el lenguaje Visual C++ usando la herramienta

de desarrollo Microsoft Visual Studio 2010. Esta herramienta es totalmente gratuita y se

puede descargar de la página de Microsoft.

La primera de las aplicaciones que se describirá se denomina “Aplicación CAN”. A

grandes rasgos esta aplicación permitirá: configurar el nodo interfaz (microcontrolador

Atmel AT90CAN128 sobre STK 500 + 501), mandar tramas CAN al bus CAN, recibir tramas

CAN desde el bus y monitorizar el bus. Con esta aplicación se busca demostrar el correcto

funcionamiento tanto del bus CAN como de los nodos de la red.

La segunda aplicación creada se denomina “Aplicación OBDII”. Esta aplicación simulará

un escáner OBDII real a la ECU (placa de evaluación integrada Olimex AVR H-128-CAN). El

nodo interfaz recibirá las órdenes desde la aplicación y enviará tramas OBDII hacia la ECU,

la cual recibirá dichas peticiones, las atenderá y responderá con respuestas OBDII.

Posteriormente será el nodo interfaz el encargado de extraer la información relevante de

las tramas OBDII y enviarla hacia la aplicación para que esta la interprete.

86

4.1 El entorno de desarrollo Microsoft Visual Studio 2010

Para la programación de las aplicaciones que va a ejecutar el ordenador de a bordo se ha

utilizado Microsoft Visual Studio 2010. La razón del uso de este entorno de programación es

porque el ordenador de a bordo tiene como sistema operativo Windows XP Embedded.

Ambas aplicaciones han sido creadas en lenguaje Visual C++, más concretamente, han sido

creadas como aplicaciones que usan MFC (Microsoft Foundation Classes), más adelante se

ahondará en esta cuestión. Visual C++ engloba el desarrollo de aplicaciones hechas en C, C++ y

C++/CLI en el entorno Windows. Visual C++ incluye además las bibliotecas de Windows

(WinApi), las bibliotecas MFC y el entorno de desarrollo para .NET Framework. Visual C++

cuenta con su propio compilador (de igual nombre) y otras herramientas como IntelliSense,

TeamFoundation Server, Debug,... Además provee de bibliotecas propias de cada versión del

sistema operativo y sockets. Como otros compiladores, se le pueden añadir nuevas bibliotecas

como DirectX, wxWidgets o SDL.

El lenguaje de programación usado por esta herramienta es C++, el cual se complementa

con la creación por parte del usuario de una interfaz gráfica basada en ventanas, botones,

menús desplegables, etcétera.

Otros posibles lenguajes de programación que pueden ser usados en Microsoft Visual

Studio 2010 son: Visual Basic, Visual C# y Visual F#.

4.1.1 El lenguaje C++

C++ es un lenguaje de programación orientado a objetos derivado del lenguaje C, al que se

han añadido cualidades y características de las que carecía, tales como: nuevos tipos de datos,

clases, plantillas, mecanismos de excepciones, sistema de espacios de nombres, funciones

inline, sobrecarga de operadores, referencias, operadores para manejo de memoria

persistente, y algunas utilidades adicionales de librería (en realidad la librería Estándar C es un

subconjunto de la librería C++). El resultado es que como su antecesor, C++ sigue muy ligado al

hardware subyacente, manteniendo una considerable potencia para programación a bajo

nivel, pero se la han añadido elementos que le permiten también un estilo de programación

con alto nivel de abstracción.

87

Respecto a C, se ha procurado mantener una exquisita compatibilidad hacia atrás por dos

razones: poder reutilizar la enorme cantidad de código C existente, y facilitar una transición lo

más fluida posible a los programadores de C clásico, de forma que pudieran pasar sus

programas a C++ e ir modificándolos de forma gradual. De hecho, los primeros

compiladores C++ lo que hacían en realidad era traducir (preprocesar) a C y compilar después.

Por lo general puede compilarse un programa C con un compilador C++, pero no a la

inversa si el programa utiliza alguna de las características especiales de C++. Algunas

situaciones requieren especial cuidado. Por ejemplo, si se declara una función dos veces con

diferente tipo de argumentos, el compilador C invoca un error de "Nombre duplicado",

mientras que en C++ quizás sea interpretado como una sobrecarga de la primera función (que

sea o no legal depende de otras circunstancias).

En la actualidad, el C++ es un lenguaje versátil, potente y general. Su éxito entre los

programadores profesionales le ha llevado a ocupar el primer puesto como herramienta de

desarrollo de aplicaciones. El C++ mantiene las ventajas del C en cuanto a riqueza de

operadores y expresiones, flexibilidad, concisión y eficiencia. Además, ha eliminado algunas de

las dificultades y limitaciones del C original. La evolución de C++ ha continuado con la aparición

de Java, un lenguaje creado simplificando algunas cosas de C++ y añadiendo otras, que se

utiliza para realizar aplicaciones en Internet.

4.1.2 MFC: Microsoft Foundation Classes

Microsoft Foundation Classes o MFC es un conjunto de clases interconectadas por

múltiples relaciones de herencia, que proveen un acceso más sencillo a las API de Windows.

Aunque se puede usar para crear aplicaciones de escritorio muy simples, es muy útil cuando se

necesita desarrollar interfaces de usuario más complejas con varios controles.

Fueron introducidas por Microsoft en 1992 y desde entonces fueron apareciendo nuevas

versiones con las actualizaciones del entorno de programación Visual C++, gracias a las cuales

éste se convierte en un generador de programas C++ para Windows. Tiene una gran

complejidad añadida debido a la necesidad de que el programador ahora no sólo debe

controlar C/C++, sino que además debe conocer las clases de la MFC para poder utilizar su

potencia. Con el paso del tiempo MFC se ha convertido en la implementación estándar de la

industria para la creación de aplicaciones gráficas en plataformas PC.

88

El MFC es una biblioteca de clases C++ que proporciona una interfaz para la programación

de Windows y al mismo tiempo encapsula el nivel inferior de la API Win32. Proporciona una

gran cantidad de funcionalidades que se encuentran en aplicaciones de Windows, como la

gestión de documentos y la gestión de los distintos puntos de vista sobre los datos del

documento, y a su vez proporciona una interfaz orientada a objetos que solucionan las

complejas tareas que involucran la comunicación a través redes, el acceso a la base de datos y

gestión de documentos compuestos.

4.1.3 Creación de aplicaciones

Una vez descargado e instalado Microsoft Visual Studio, la pantalla de inicio que

muestra el programa es la siguiente:

En esta pantalla tenemos varias opciones: conectar con el servidor Team Foundation,

crear un nuevo proyecto o abrir un proyecto ya creado previamente. En este caso

pulsaremos New Project para crear una nueva aplicación. Al pulsar en New Project la

pantalla que se muestra es la siguiente:

Figura 54: Pantalla de inicio de Microsoft Visual Studio 2010

89

En esta pantalla se nos muestran los diferentes lenguajes de programación que se

pueden usar para crear el nuevo proyecto: Visual Basic, Visual C#, Visual C++ y Visual F#,

así como otro tipo de proyectos como creación de servidores SQL o creación de

instaladores.

En este caso hay que pulsar sobre Visual C++ y se desplegará un menú con diferentes

tipos de aplicaciones que se pueden crear con Visual C++: ATL (para crear una Active

Template Library), CLR (para la creación de librerías), General (para empezar el proyecto

desde cero), MFC, Test (para proyectos que contienen programas de testeo) y WIN32 (para

creación de aplicaciones de consola).

Una vez seleccionado MFC se presentan tres opciones: MFC ActiveX Control (para

crear un control ActiveX que usa la librería MFC), MFC Application (para crear una

aplicación basada en MFC) y MFC DLL (para crear librerías enlazadas dinámicamente que

usan la librería MFC).

Una vez seleccionado MFC Application, habría que elegir el nombre del proyecto, su

ubicación y pulsar OK. A continuación aparecerá el asistente que nos ayudará en la

configuración de la aplicación MFC a crear:

Figura 55: Opciones para la creación de un nuevo proyecto en Microsoft Visual Studio 2010

90

En esta pantalla lo único que hay que hacer es pulsar Next. Una vez pulsado aparecerá

una pantalla en la podremos elegir el tipo de aplicación MFC que queremos crear:

Figura 56: Inicio del asistente para la creación de aplicaciones MFC en Microsoft Visual Studio

2010

91

Las opciones que se seleccionarán serán:

Dialog based: para crear una aplicación basada en cuadros de diálogo

Proyect Style: MFC Standard: para que la aplicación tenga una apariencia

MFC clásica.

Use of MFC: Use MFC in a static library: para crear una aplicación

autocontenida y portable gracias a la creación de librerías estáticas. Este

tipo de aplicaciones ocupan más espacio en memoria pero por otro lado

son portables a cualquier ordenador con Windows.

Las otras opciones son referentes a lenguaje, estilo y color con lo que

carecen de importancia para este proyecto.

Una vez seleccionadas estas opciones pulsamos Finish. Si pulsamos Next aparecerán

más pantallas de configuración que no son necesarias para este tipo de aplicaciones.

Una vez pulsado Finish aparecerá el entorno de programación. La pantalla que aparece

por defecto es la pantalla en la que podemos crear el cuadro de diálogo:

Figura 57: Ventana para la elección del tipo de aplicación MFC en Microsoft Visual Studio 2010

92

En esta pantalla se crea el interfaz con la que el usuario va a interactuar. Su

funcionamiento es muy sencillo: basta con arrastrar el componente que queramos que

aparezca en el cuadro de diálogo (botón, Combo Box, Edit Box, Control Box, List Box…)

desde la ventana Toolbox hasta el cuadro de diálogo. Una vez arrastrado podremos

colocarlo en cualquier lugar del cuadro de diálogo y podremos cambiar sus propiedades en

la pestaña Properties. Cada vez que se incluye un elemento en el cuadro de diálogo el

programa añade automáticamente el código necesario para su incursión en el código de la

aplicación.

Para explorar el código basta con pulsar en Solution Explorer:

Figura 58: Pantalla para la creación del cuadro de diálogo en Microsoft Visual Studio 2010

93

En esta ventana podemos explorar los diferentes archivos que conforman la aplicación

como son: ficheros de cabecera (.h), ficheros fuente (.cpp) así como las dependencias

externas (External Dependencies) y los archivos de recursos (Resource Files).

Para añadir un nuevo fichero de cabecera o fichero fuente basta con pulsar botón

derecho sobre Header Files o Source Files y pulsar Add. De esta forma se pueden añadir

ficheros nuevos o ya creados previamente.

Una vez creado el código, para compilarlo basta con pulsar Start Debugging en el

menú Debug, o pulsar en el icono Play de la barra de herramientas o pulsar F5. Una vez

hecho esto comenzará la compilación del código.

Si hubiera algún error o warning al compilar se mostraría en la ventana Output

informando del tipo de error o warning y la línea de código que lo provocó.

Si la compilación es correcta, el archivo ejecutable de la aplicación es creada dentro de

una carpeta llamada Debug ubicada dentro del directorio que seleccionamos

anteriormente para contener el proyecto. Además, la aplicación se ejecuta

automáticamente. De esta manera se tiene acceso directo a la aplicación un vez está

compilada.

Figura 59: Código de la aplicación en Microsoft Visual Studio 2010

94

4.2 La aplicación CAN

Esta aplicación tiene como función principal el envío y recepción de tramas CAN en el

ordenador de a bordo. Gracias a ella se demuestra el correcto funcionamiento del bus así

como se puede adaptar el ordenador de a bordo a la red CAN permitiéndole enviar y recibir

tramas y monitorizar el bus a través del puerto serie de dicho ordenador. De hecho, cualquier

ordenador con un puerto serie o USB (usando un conversor USB/RS232) podría conectarse al

bus CAN usando esta aplicación, y así se evitan problemas de compatibilidad que pueden

aparecer con los buses CAN que traen integrados algunos dispositivos.

La aplicación se conectará al nodo interfaz a través del puerto serie. Las características

CAN de este nodo son configurables por lo que permite al ordenador de abordo conectarse a

diferentes redes CAN usando el puerto serie. Es decir, hará de interfaz entre el ordenador de a

bordo que usa comunicación serie y el bus en el que se usa protocolo CAN.

Para el manejo del puerto serie se ha hecho uso de la clase CSerialPort. Esta clase es

freeware y ofrece un acceso más sencillo a la API de Windows que controla el puerto serie.

Figura 60: Pantalla inicial de la aplicación CAN

95

Para más información visitar http://www.codeproject.com/ y buscar CSerialPort con el

buscador.

La configuración de la conexión serie que se establecerá será la siguiente:

Puerto al que conectar: seleccionado por el usuario en la aplicación.

Velocidad: 115200 bps.

Bit de paridad: No.

Bits de datos: 8 bits.

Bits de parada: 1 bit.

Control de flujo: No.

Una vez establecida la conexión con el nodo interfaz a través del puerto serie, el siguiente

paso es configurar la velocidad de transmisión y los registros de recepción de dicho nodo:

Velocidad de transmisión CAN: 125, 250, 500 Kbps o 1 Mbps.

Tipo de tramas que se esperan recibir: Standard o Extended.

Filtros de aceptación de mensajes.

Cuando el nodo ya está configurado para la recepción el siguiente paso es la configuración

de envío y relleno de datos a enviar:

Tipo de trama que se quiere enviar: Standard o Extended.

ID del receptor.

DLC: longitud de los datos a enviar en número de octetos (1-8).

Datos a enviar.

Acabada la configuración de envío ya se pueden enviar las tramas al bus CAN y recibir

tramas de este. Tanto los datos enviados al bus como los recibidos se presentaran en pantalla

por la aplicación.

A continuación se va a hacer una descripción detallada del funcionamiento de la aplicación

así como del intercambio de mensajes que ocurre entre el nodo interfaz y la aplicación a través

del puerto serie y entre los nodos CAN a través del bus CAN.

4.2.1 Funcionamiento de la aplicación CAN.

4.2.1.1 Diagrama de flujo

96

Figura 61: Diagrama de flujo de la aplicación CAN

97

4.2.1.2 Botón CONNECT

Con este botón se le indica a la aplicación que debe conectarse el puerto COM

seleccionado de la lista. Los pasos serían los siguientes:

1. Seleccionar el puerto COM de la lista al que conectarse.

2. Al pulsar el botón CONNECT la aplicación intentará conectarse al puerto COM

elegido. Con la siguiente configuración:

Velocidad: 115200 bps.

8 bits de datos, sin bit de paridad, 1 bit de parada.

Sin control de flujo de datos (Flow Control).

3. Si no puede conectar al puerto COM, la aplicación presentará mensaje

emergente de error indicando que existe un error al conectar.

4. Si logra conectarse al puerto COM, envía al nodo interfaz $APP1 (para indicarle

que se trata de la aplicación CAN) y espera recibir el asentimiento desde el

nodo interfaz.

5. Cuando recibe el asentimiento ($OK1):

Presenta mensaje emergente indicando éxito al conectar al puerto

COM elegido.

Habilita los botones DISCONNECT y SEND BAUD RATE.

Deshabilita el botón CONNECT.

4.2.1.3 Botón DISCONNECT

Con este botón se le indica a la aplicación que debe desconectarse del puerto COM y

liberarlo. Los pasos serían los siguientes:

1. Al pulsar el botón DISCONNECT la aplicación intentará desconectarse del

puerto COM al que está conectada.

Figura 62: Detalle del botón CONNECT de la aplicación CAN

98

2. Si no logra desconectarse presentará un mensaje de error indicando que

existe un error al desconectar del puerto COM.

3. Si consigue desconectarse del puerto:

Presentará un mensaje emergente de éxito al desconectarse del

puerto serie.

Deshabilitará todos los botones excepto CONNECT.

4.2.1.4 Botón SEND BAUD RATE

Con este botón se le indica a la aplicación que debe de enviar al nodo interfaz el valor

del baud rate elegido de la lista. El nodo interfaz lo almacenará para posteriormente editar

los registros necesarios para establecerlo como el baud rate con el que transmitirá y

recibirá los datos del bus CAN. Los pasos serían:

1. Seleccionar el CAN baud rate de la lista desplegable.

2. Según el baud rate elegido, al pulsar el botón la aplicación enviará al nodo

interfaz:

$CBR1 para un baud rate de 125 Kbps.

$CBR2 para un baud rate de 250 Kbps.

$CBR3 para un baud rate de 500 Kbps.

$CBR4 para un baud rate de 1 Mbps.

Y se pondrá a la espera de recibir del asentimiento desde el nodo interfaz.

3. Cuando recibe el asentimiento desde el nodo interfaz ($OK2):

Presenta mensaje emergente indicando éxito al almacenar el baud

rate elegido en el nodo interfaz.

Deshabilita el botón SEND BAUD RATE.

Habilita el botón SET CAN RECEIVE AND BAUD RATE.

Figura 63: Detalle del botón DISCONNECT de la aplicación CAN

99

4.2.1.5 Botón SET CAN RECEIVE AND BAUD RATE

A través de este botón se le indica a la aplicación que envíe al nodo interfaz los datos

referidos a la configuración del nodo en recepción (tipo de trama a recibir y filtros de

aceptación de mensajes). Cuando el nodo interfaz recibe estos datos edita tanto los

registros referidos a dicha configuración como los registros relacionados con el baud rate.

Los pasos seguidos por la aplicación serían los siguientes:

1. Seleccionar el tipo de tramas CAN que se espera recibir: Standard o Extended.

2. Rellenar los campos de los filtros de aceptación de mensajes correspondientes

al modo elegido. A continuación se presenta una tabla en la que se indican los

valores que deben tener los filtros de aceptación para un filtrado completo de

mensajes (el nodo sólo aceptará los mensajes que estén dirigidos a él) o para

una aceptación completa (el nodo aceptará todos los mensajes). Cualquier

otro valor contenido entre los indicados en la tabla provocará un filtrado

parcial de los mensajes que aceptará el nodo.

MODO STANDARD MODO EXTENDED

FILTRADO COMPLETO

FILTRO 1: 0xFF

FILTRO 2: 0x07

FILTRO 1: 0xFF

FILTRO 2: 0xFF

FILTRO 3: 0xFF

FILTRO 4: 0x1F

ACEPTACIÓN COMPLETA

FILTRO 1: 0x00

FILTRO 2: 0x00

FILTRO 1: 0x00

FILTRO 2: 0x00

FILTRO 3: 0x00

FILTRO 4: 0x00

Tabla 22: Valores de los filtros de aceptación de mensajes para filtrado completo o

aceptación completa

Figura 64: Detalle del botón SEND BAUD RATE de la aplicación CAN

100

3. Si se elige modo Standard, al pulsar el botón SET CAN RECEIVE AND BAUD

RATE, la aplicación envía al nodo interfaz: $CRM1 + $X1X2X3X4 donde:

• $CRM1 indica modo de trama que se espera recibir: Standard.

• X1X2 (M1 Filter 1): valor del registro CANIDM1 (00-FF).

• X3X4 (M1 Filter 2): valor del registro CANIDM2 (00-07).

Y se pondrá a la espera del asentimiento desde el nodo interfaz.

4. Si se elige modo Extended, al pulsar el botón, la aplicación envía al nodo

interfaz: $CRM2 + $X1X2X3X4 + $X5X6X7X8 donde:

$CRM2 indica modo de trama que se espera recibir: Extended.

X1X2 (M2 Filter 1): valor del registro CANIDM1 (00-FF).

X3X4 (M2 Filter 2): valor del registro CANIDM2 (00-FF).

X5X6 (M2 Filter 3): valor del registro CANIDM3 (00-FF).

X7X8 (M2 Filter 4): valor del registro CANIDM4 (00-1F).

Y se pondrá a la espera del asentimiento desde el nodo interfaz.

5. Cuando recibe el asentimiento ($OK3):

Presenta mensaje emergente indicando éxito al configurar el baud rate

y los filtros de aceptación del nodo interfaz.

Deshabilita el botón SET CAN RECEIVE AND BAUD RATE.

Habilita los botones SEND DATA y READ.

Figura 65: Detalle del botón SET CAN RECEIVE AND BAUD RATE y los campos relacionados

101

4.2.1.6 Botón SEND DATA

Con este botón se le indica a la aplicación que debe enviar los datos de configuración

referidos al envío de datos así como los propios datos a enviar a la red CAN. Los pasos que

sigue la aplicación para enviar datos al bus son los siguientes:

1. Seleccionar el tipo de trama a enviar: Standard o Extended.

2. Si se selecciona modo Standard:

• Escribir la dirección de envío, Send ID: 000-7FF (11 bits).

• Seleccionar el tamaño de los datos a enviar, DLC: 1-8 (octetos).

• Escribir el valor, en hexadecimal, de los datos a enviar (00-FF).

3. Si se selecciona modo Extended:

• Escribir la dirección de envío, Send ID: 00000000-1FFFFFFF (29 bits).

• Seleccionar el tamaño de los datos a enviar, DLC: 1-8 (octetos).

• Escribir el valor, en hexadecimal, de los datos a enviar (00-FF).

4. Si se selecciona modo Standard, al pulsar el botón SEND DATA la aplicación

enviará al nodo interfaz: $CSM1 + $0X1X2X3 + $DLCY + $D11D12D21D22 + … +

$Dy1Dy2 , donde:

• $CSM1 indica modo de trama a enviar: Standard.

• 0X1 valor del registro de dirección CANIDT2.

• X2X3 valor del registro de dirección CANIDT1.

• Y valor del DLC (1-8).

• Dx1Dx2 valor hexadecimal del octeto a enviar DATA x.

Una vez que el nodo interfaz recibe la configuración de envío y los datos a

enviar, monta la trama CAN necesaria (trama Standard) y la envía hacia el

nodo ECU. La aplicación se pone a la espera de la respuesta proveniente del

nodo ECU que le llega a través del nodo interfaz y una vez recibida la

representa en el Data Log.

5. Si se selecciona modo Extended, al pulsar el botón SEND DATA la aplicación enviará

al nodo interfaz: $CSM1 + $X1X2X3X4 + $X5X6X7X8 + $DLCY + $D11D12D21D22 + … +

$Dy1Dy2 , donde:

$CSM2 indica modo de trama a enviar: Extended.

X1X2 valor del registro de dirección CANIDT1.

X3X4 valor del registro de dirección CANIDT2.

X5X6 valor del registro de dirección CANIDT4.

X7X8 valor del registro de dirección CANIDT3.

102

Y valor del DLC (1-8).

Dx1Dx2 valor hexadecimal del octeto a enviar DATA x.

Al igual que antes, una vez que el nodo interfaz recibe la configuración de

envío y los datos a enviar, monta la trama CAN necesaria (trama Extended) y la

envía hacia el nodo ECU. La aplicación se pone a la espera de la respuesta

proveniente del nodo ECU que le llega a través del nodo interfaz y una vez

recibida la representa en el Data Log.

6. Mientras la respuesta no llegue el botón SEND DATA permanece deshabilitado.

7. Una vez recibida la respuesta se habilita el botón SEND DATA y se presentan los

datos recibidos en el Data Log.

4.2.1.7 Botones READ y STOP

Con el botón READ le indicamos a la aplicación que se ponga en modo escucha, de esta

manera la aplicación monitoriza el bus y presenta por pantalla las tramas que viajan por

este. Al pulsar el botón STOP la aplicación deja de monitorizar el bus.

Los pasos que la aplicación seguirá serán los siguientes:

Figura 66: Detalle botón SEND DATA y los campos relacionados

103

1. Al pulsar el botón READ, la aplicación manda una trama especial para que la ECU

comience a enviar tramas de forma continua.

2. La aplicación entra en modo de escucha y va presentando en el Data Log las

tramas que va recibiendo.

3. Mientras dura la operación de lectura:

• Los botones READ y SEND DATA son deshabilitados.

• El botón STOP es habilitado.

4. Al pulsar el botón STOP, la aplicación manda otra trama especial para que la ECU

deje de enviar tramas de forma continua.

5. La aplicación sale del modo de escucha. Los botones READ y SEND DATA son

habilitados mientras que el botón STOP es deshabilitado.

4.2.1.8 El Data Log

En el Data Log se presentarán tanto los datos enviados (TX) como los datos recibidos

(RX).

Si los datos recibidos son la respuesta a una trama enviada por la aplicación, el Data

Log presenta tanto la trama enviada como la recibida.

Si los datos recibidos provienen de la lectura del bus a través del botón READ, el Data

Log presentará los datos en orden de llegada, siendo el último dato representado el último

recibido.

En ambos casos los datos se presentan en formato hexadecimal.

Figura 67: Detalle de los botones READ y STOP

104

4.2.1.9 Diagrama de paso de mensajes

A continuación se muestra un ejemplo de comunicación en el que la aplicación envía

una trama CAN hacia la ECU y recibe la respuesta proveniente de esta. La respuesta será

un eco a la trama enviada por la aplicación modificando el valor de los campos de datos

sumándole uno a cada uno de ellos.

Figura 68: Detalle del Data Log

105

Figura 69: Diagrama de paso de mensajes entre aplicación CAN, nodo interfaz y nodo ECU

106

4.3 La aplicación OBDII

La función principal de esta aplicación es la simulación de un escáner OBDII. La

aplicación enviará a través del nodo interfaz (microcontrolador AT90CAN128 en STK 500 +

501) las peticiones OBDII al nodo ECU (placa de evaluación integrada Olimex AVR H-128-

CAN). El nodo ECU responderá a las peticiones OBDII con unos valores preestablecidos.

Estos valores simularán los valores que tendría almacenados una ECU real provenientes de

los sensores del vehículo.

Al igual que la aplicación CAN, esta aplicación se conectará al nodo interfaz a través del

puerto serie. En este caso la configuración del nodo interfaz es más simple:

Nodo en modo promiscuo (sin filtrado de mensajes): el nodo interfaz

se configura de tal manera que acepta todos los mensajes.

Modo de trama CAN: Standard o Extended.

Baud rate: 250 o 500 Kbps. Estas son las dos velocidades usadas en los

escáneres OBD II reales.

Igual que en la aplicación CAN, para el manejo del puerto serie se ha hecho uso de la clase

CSerialPort. La configuración de la conexión serie que se establecerá será la siguiente:

Figura 70: Pantalla inicial de la aplicación OBDII

107

Puerto al que conectar: seleccionado por el usuario en la aplicación.

Velocidad: 115200 bps.

Bit de paridad: No.

Bits de datos: 8 bits.

Bits de parada: 1 bit.

Control de flujo: No.

La comunicación entre el nodo interfaz y la ECU se basará en el envío de peticiones y

respuestas OBDII a través del bus CAN. La aplicación simulará un escáner OBDII en modo de

operación 01 (Show Current Data) en el que la ECU muestra los valores actuales que tiene

almacenados en memoria.

4.3.1 Modos de operación OBDII y PIDs

Existen diez modos diferentes de operación OBDII. Todos ellos están basados en el envío,

por parte de la herramienta de escáner, de tramas CAN que contienes diversos datos que

conforman el PID (Parameter ID). Esta aplicación simulará el comportamiento del modo 01 y

usará los primeros 79 PIDs de este modo.

MODO (Hex) DESCRIPCIÓN

01 Show current data

02 Show freeze frame data

03 Show stored Diagnosis Trouble Codes (DTCs)

04 Clear stored Diagnosis Trouble Codes and stores values

05 Test results, oxygen sensor monitoring

06 Test results, other components/system monitoring

07 Show pending Diagnosis Trouble Codes

08 Control operation of on-board component/system

09 Request vehicle information

0A Permanent Diagnosis Trouble Codes

Tabla 23: Modos de operación OBDII

Los PIDs son códigos usados para requerir datos a la ECU del vehículo. El estándar SAE

J/1979 define los PIDs estándar para todos los vehículos, pero los fabricantes pueden añadir

108

PIDs específicos para sus vehículos. La ECU recibirá la trama CAN con el PID, mirará el PID code

que tiene dicha petición y lo responderá con los valores que obtiene de los sensores.

Las respuestas a los PIDs pueden contener 1, 2 o 4 octetos de datos (A, B, C y D) y para

cada PID hay una fórmula que aplicar a dichos octetos de datos para obtener un valor legible

para el usuario del escáner.

A continuación se muestra la estructura de una petición OBDII de modo 01 (CAN

Standard):

El DLC de estas tramas siempre es 8. Los octetos que no se usan se rellenan con

0x55 (1010101 en binario) para no perder la sincronía de bits.

El primer octeto de datos indica el número de datos adicionales en la trama. Para

las peticiones siempre es 0x02.

El segundo octeto de datos indica el modo de operación OBDII. Para este modo

siempre es 0x01.

El tercer octeto de datos indica el código PID. Este valor le indica a la ECU cual es la

petición a la que quiere que esta le responda. La ECU leerá el código PID de la

petición, buscará en sus registros el valor o los valores del parámetro requerido y

responderá con una respuesta OBDII.

La siguiente imagen corresponde a la estructura de una respuesta OBDII de modo 01 (CAN

Standard):

Al igual que las peticiones OBDII, el DLC de estas tramas siempre es 8, siendo

rellenados los octetos no usados con 0x55.

El primer octeto de datos indica el número de octetos de datos adicionales. En

este caso este octeto puede valer desde 3 a 6 dependiendo de la petición.

Figura 71: Estructura de una petición OBDII en Modo 01

Figura 72: Estructura de una respuesta OBDII en Modo 01

109

El segundo octeto representa el modo de operación más 0x40. En este caso sería:

0x01 + 0x40 = 0x41.

El tercer octeto es el código PID, se usa para identificar a que petición corresponde

la respuesta.

El cuarto octeto representa el valor del parámetro requerido por la petición.

Los octetos 4, 5 y 6 se usan para representar también los valores del parámetro

requerido por peticiones que necesitan más de un octeto para obtener el valor.

A continuación se va a presentar una tabla con algunos PIDs estándar definidos en el SAE

J/1979. Para ver la tabla completa ir a la dirección web http://en.wikipedia.org/wiki/OBD-

II_PIDs

PID

Code

Bytes de datos

devueltos

Descripción

Valor

mínimo

Valor

máximo

Unidad

Fórmula

0x0A 1 Fuel Pressure 0 765 kPa A*3

0x0C 2 Engine RPM 0 16383,75 Rpm ((A*256)+B)/4

0xD 1 Vehicle Speed 0 255 Km/h A

0x21

2

Distance traveled

with malfunction

indicator lamp on

0

65535

Km

(A*256)+B

0x24

4

O2S1_WR_lambda:

Equivalence Ratio

Voltage

0

0

1,999

7,999

N/A

V

((A*256)+B)/32768

((C*256)+D)*8192

Tabla 24: Ejemplos de PIDs estándar

4.3.2 Funcionamiento de la aplicación OBDII

4.3.2.1 Diagrama de flujo

110

Figura 73: Diagrama de flujo de la aplicación OBDII

111

4.3.2.2 Botón CONNECT

Al igual que en la aplicación CAN, con este botón se le indica a la aplicación que debe

conectarse el puerto COM seleccionado de la lista. Los pasos serían los siguientes:

1. Seleccionar el puerto COM de la lista al que conectarse.

2. Al pulsar el botón CONNECT la aplicación intentará conectarse al puerto COM

elegido. Con la siguiente configuración:

Velocidad: 115200 bps.

8 bits de datos, sin bit de paridad, 1 bit de parada.

Sin control de flujo de datos (Flow Control).

3. Si no puede conectar al puerto COM, la aplicación presentará mensaje

emergente de error indicando error al conectar.

4. Si logra conectarse al puerto COM:

Envía al nodo interfaz: $APP2 (para indicarle que se trata de la

aplicación OBDII).

Presenta mensaje emergente indicando éxito al conectar al puerto

COM elegido.

Habilita los botones DISCONNECT y SET.

Deshabilita el botón CONNECT.

4.3.2.3 Botón DISCONNECT

Con este botón se le indica a la aplicación que debe desconectarse del puerto COM y

liberarlo. Los pasos serían los siguientes:

1. Al pulsar el botón DISCONNECT la aplicación intentará desconectarse del

puerto COM al que está conectada.

2. Si no logra desconectarse presentará un mensaje de error indicando error al

desconectar del puerto COM.

3. Si consigue desconectarse del puerto:

Figura 74: Detalle botón CONNECT de la aplicación OBDII

112

Presentará un mensaje emergente de éxito al desconectarse del

puerto serie.

Deshabilitará todos los botones excepto CONNECT.

4.3.2.4 Botón SET

Con este botón enviamos al nodo interfaz la configuración elegida para que configure

sus registros correspondientes. Los pasos a seguir serían:

1. Seleccionar el modo de tramas CAN a enviar y recibir: Standard o Extended.

2. Seleccionar el baud rate a usar: 250 o 500 Kbps.

3. Según los valores elegidos, al pulsar el botón la aplicación enviará un mensaje

al nodo interfaz que este reconocerá y se configurará. Para cada mensaje el

nodo interfaz mandará un asentimiento específico indicando que la

configuración se realizó con éxito.

Para Standard a 250 Kbps: $CC1. Asentimiento: $11111111.

Para Standard a 500 Kbps: $CC2. Asentimiento: $22222222.

Para Extended a 250 Kbps: $CC3. Asentimiento: $33333333.

Para Extended a 500 Kbps: $CC4. Asentimiento: $44444444.

4. Si hay algún error en la configuración del nodo interfaz, la aplicación imprimirá

en el ECU Data Log “Error al configurar el bus CAN”.

5. Si recibe el asentimiento de configuración realizada con éxito, la aplicación

imprimirá en el ECU Data Log “Conectado al bus CAN a x Kbps. Modo y”,

dependiendo de la configuración elegida.

6. Llegados a este punto, la aplicación deshabilita el botón SET y habilita el botón

START.

Figura 75: Detalle botón DISCONNECT de la aplicación OBDII

Figura 76: Detalle botón SET de la aplicación OBDII

113

4.3.2.5 Botón START

Este botón tiene dos funciones dependiendo si se selecciona Test Single Item o si se

selecciona Complete Scan.

4.3.2.5.1 Test Single Item

Para realizar el test de un solo elemento lo pasos serían:

1. Seleccionar Test Single Item.

2. Elegir el elemento que queremos testear de la lista ECU Detection Items.

3. Al pulsar START la aplicación enviará al nodo interfaz el PID Code del elemento

($ PID Code) seleccionado para que este monte la trama OBDII y la envíe hacia

la ECU.

4. Una vez el nodo interfaz recibe la respuesta de la ECU, extrae los datos de la

trama CAN y los envía a la aplicación.

5. Con los datos recibidos del nodo interfaz, la aplicación extrae los datos del

valor del parámetro y les aplica la fórmula correspondiente. Una vez tiene los

datos en sus unidades correspondientes los presenta junto con su descripción

en el ECU Data Log.

114

4.3.2.5.2 Complete Scan

Para realizar el escáner completo bastaría con:

1. Seleccionar Complete Scan.

2. Al pulsar START, la aplicación comenzará a enviar al nodo interfaz los PIDs code

de todos los elementos de la lista secuencialmente, e irá presentando las

respuestas recibidas en el ECU Data Log.

3. Mientras dura el escaneo completo el botón START está deshabilitado y el

botón STOP habilitado.

Figura 77: Aplicación OBDII tras realizar varios Test Single Item

115

Figura 78: Aplicación OBDII tras realizar un escaneo completo

4.3.2.6 Botón STOP

Este botón está activo durante el escaneo completo y su función es detener el envío de

peticiones OBDII hacia el nodo interfaz. En el momento que se para el escaneo completo

este botón se desactiva y se vuelve a activar el botón START.

4.3.2.7 El ECU Data Log

En el ECU Data Log se presentarán los datos recibidos desde la ECU en un formato

legible para el usuario. Estos datos se presentan con su descripción, su PID code (en

decimal) y con sus unidades de medida correspondientes. Además también indica si hubo

algún error al configurar el nodo interfaz y en caso de éxito la configuración elegida.

116

Figura 79: ECU Data Log

4.3.2.8 Diagrama de paso de mensajes

A continuación se presenta un diagrama de paso de mensajes entre la aplicación, el

nodo interfaz y el nodo ECU cuando la aplicación realiza un Test Single Item.

117

Figura 80: Diagrama de paso de mensajes en aplicación OBDII