para hacer una interface de carro

DISEO Y REALIZACIN DE UN SISTEMA

ON BOARD DIAGNOSTICS (OBD-II)

ALUMNO: OSCAR RAYO MANSILLA

DIRECTOR: JORDI SELLARS GONZLEZ

4 DE JUNIO DE 2009

3

NDICE

1. Introduccin 5

1.1. Justificacin del proyecto5

1.2. Antecedentes..6

1.3. Objetivos..10

1.4. Alcance del proyecto11

1.5. Descripcin general del proyecto12

1.5.1. Descripcin bsica del hardware..12

1.5.2. Descripcin bsica del software...13

2. Diseos realizados 14

2.1. Metodologa utilizada14

2.2. Recursos utilizados..16

2.3. Descripcin del diseo del modem interface.21

2.4. Descripcin del diseo del programador JDM2......25

2.5. Modificaciones del diseo del modem..29

2.6. Diseo de la aplicacin de prueba en C++37

2.7. Diseo de la aplicacin de prueba en JAVA.40

2.8. Diseo de la aplicacin grfica diseada en JAVA.....46

4

3. Resultados 52

3.1. mbito de utilizacin.52

3.2. Validacin de los diseos.52

3.3. Descripcin del funcionamiento.54

3.4. Aplicaciones del proyecto66

4. Comentarios finales 67

4.1. Plan de trabajo67

4.2. Lista de materiales68

4.3. Presupuesto..70

4.4. Objetivos logrados71

4.5. Conclusiones.71

4.6. Mejoras futuras..72

5. Bibliografa 73

6. Anexo 74

5

1. Introduccin

1.1. Justificacin del proyecto

La motivacin principal de este proyecto es llegar a poder disear un sistema

con el que poder diagnosticar las posibles averas de cualquier vehculo sin

tener que recurrir a los costosos servicios oficiales.

Normalmente cuando se nos avera el coche siempre tenemos que acabar

recurriendo a los talleres de reparacin de los cuales dispone el fabricante de

nuestro vehculo, y aunque desconocemos cuales son los medios de los que

disponen para diagnosticar la avera, si sabemos que existe un herramienta que

conectndola al vehculo averigua el problema al instante. Esto se debe a que

estas marcas tan famosas equipan nuestros coches con sistemas electrnicos

capaces de gestionar toda la mecnica y electricidad de que dispone, sin ms

ayuda que la de un modulo electrnico.

En realidad estos mdulos no son ms que una pequea computadora a la cual

si se conoce su funcionamiento se puede acceder aunque su fabricante intente

taparlo, cosa que no les es posible ya que desde hace ya bastantes aos estn

obligados a implementar un estndar de autodiagnstico llamado OBD-II, que

se hizo pblico a consecuencia de las grandes emisiones contaminantes a las

que estamos expuestos, implantando as un mecanismo de control de estas.

Estos mdulos son el objetivo de este proyecto, ya que en el momento que

podamos comunicarnos con ellos podremos saber que le ocurre a nuestro coche

y por tanto cuando tengamos que acudir al taller nosotros sabremos, en parte,

si nos estn estafando, cosa que lamentablemente a veces pasa.

6

1.2. Antecedentes

OBD (On Board Diagnostics) es un sistema de diagnstico a bordo en vehculos

(coches y camiones). Actualmente se emplea OBD-II (Estados Unidos), EOBD

(Europa), y JOBD (Japn) estndar que aportan un control casi completo del

motor y otros dispositivos del vehculo. OBD II es la abreviatura de On Board

Diagnostics (Diagnstico de Abordo) II, la segunda generacin de los

requerimientos del equipamiento autodiagnosticable de abordo de los Estados

Unidos de Amrica. Las caractersticas de autodiagnstico de a bordo estn

incorporadas en el hardware y el software de la computadora de abordo de un

vehculo para monitorear prcticamente todos los componentes que pueden

afectar las emisiones. Cada componente es monitoreado por una rutina de

diagnstico para verificar si est funcionando perfectamente. Si se detecta un

problema o una falla, el sistema de OBD II ilumina una lmpara de advertencia

en el cuadro de instrumentos para avisarle al conductor.

La lmpara de advertencia normalmente lleva la inscripcin "Check Engine" o

"Service Engine Soon". El sistema tambin guarda informaciones importantes

sobre la falla detectada para que un mecnico pueda encontrar y resolver el

problema. En los Estados Unidos de Amrica, todos los vehculos de pasajeros y

los camiones de gasolina y combustibles alternos a partir de 1996 deben contar

con sistemas de OBD II, al igual que todos los vehculos de pasajeros y camiones

de diesel a partir de 1997, en Europa a partir del ao 2001 se obliga implantar el

estndar EOBD. Adems, un pequeo nmero de vehculos de gas fueron

equipados con sistemas de OBD II.

Por tanto la pregunta ahora es, qu fue OBD I?

OBD I fue la primera regulacin de OBD que obligaba a los productores a

instalar un sistema de monitoreo de algunos de los componentes controladores

de emisiones en automviles. Obligatorios en todos los vehculos a partir de

1991, los sistemas de OBD I no eran tan efectivos porque solamente

monitoreaban algunos de los componentes relacionados con las emisiones, y no

eran calibrados para un nivel especfico de emisiones.

Y adems, qu es EOBD?

EOBD es la abreviatura de European On Board Diagnostics (Diagnstico de a

Bordo Europeo), la variacin europea de OBD II. Una de las diferencias es que

no se monitorean las evaporaciones del depsito. Sin embargo, EOBD es un

sistema mucho ms sofisticado que OBD II ya que usa "mapas" de las entradas a

7

los sensores expectadas basados en las condiciones de operacin del motor, y

los componentes se adaptan al sistema calibrndose empricamente. Esto

significa que los repuestos necesitan ser de alta calidad y especficos para el

vehculo y modelo.

Todos los estndares antes mencionados implementan varios modos de trabajo,

es decir, segn la parte de informacin a la que queramos acceder necesitamos

utilizar un modo diferente, dentro de cada uno de ellos podemos usar un

abanico de parmetros muy amplio.

Los modos de trabajo ms extendidos son los siguientes:

Modo 01: Se utiliza para determinar qu informacin del modulo

electrnico (ECU) est a disposicin de la herramienta de exploracin.

Modo 02: Muestra los llamados en este contexto Freeze Frame Data, es

decir, capturas puntuales de informacin que ha ido almacenado la ECU.

Modo 03: Lista los posibles fallos producidos en la mecnica mediante

cdigos de error identificativos (DTC).

Modo 04: Se utiliza para borrar los cdigos de error almacenados (DTC) y

los datos Freeze Frame Data.

Modo 05: Muestra los valores tomados a los sensores de oxigeno y los

resultados de los test que les ha realizado de forma autnoma la ECU.

Modo 06: Se usa para obtener los resultados de los test realizados por la

ECU al sistema de monitoreo no continuo. Existe normalmente un valor

mnimo, mximo y actual de cada uno de los test.

Modo 07: Se usa para solicitar resultados al sistema de control

permanente. Este modo lo suelen utilizar los tcnicos despus de una

reparacin del vehculo, y despus de borrar la informacin de

diagnstico para ver los resultados de las pruebas despus de un solo

ciclo de conduccin, determinando si la reparacin ha solucionado el

problema.

Slo hay tres monitores continuos identificados: combustible, fallo de

encendido, e integridad de los componentes.

En este proyecto solo se va ha hacer uso del modo 01, 03 y 04, aunque teniendo

en cuenta que el modo 01 dispone de ms de 60 PIDs diferentes, no es poco el

trabajo a desarrollar.

8

Actualmente ya existen muchas herramientas y software disponible para poder

llevar a cabo la inspeccin de un vehculo dotado de OBD-II. Existen muchos

tipos de herramientas distintas, pero principalmente la gran diferencia entre

ellas es si pueden o no trabajar de forma autnoma, es decir, si necesitan o no

ser ejecutadas en un ordenador personal bajo un sistema operativo.

Como ejemplo podemos encontrarnos el software llamado ScanMaster, el cual

se puede utilizar de forma completa previo pago de una pequea cantidad de

dinero:

9

Tambin podemos encontrar el software ScanTool.net, el cual ha sido de mucha

utilidad para este proyecto ya que en una de sus versiones ofrece el cdigo

fuente con el que fue diseado:

Estos programas estn diseados para trabajar junto con el microcontrolador

ELM327, es decir, necesitan de este elemento intermedio entre el PC y el

vehculo. Existen en el mercado muchos modelos de interface disponibles en el

mercado, pero todas se basan en este micro. A continuacin podemos ver

algunos ejemplos:

Interface ELM327

10

Interface ELM327 Interface ELM327 con Bluetooth

En las imgenes vemos que los modelos tienen diferentes formas y diferentes

mtodos de conexin, ya que en uno de los casos se realiza por bluetooth,

pero su funcionamiento respecto al estndar OBD-II es idntico.

1.3. Objetivos

Este proyecto abarca una pequea parte del complejo campo de la

autodiagnosis en la automocin, y por tanto no pretende crear un sistema que

pueda substituir a las avanzadas herramientas de las que dispone cualquier

servicio de manteniendo, ya que el estndar OBD-II, aun siendo de libre acceso,

comprende modos de trabajo de los cuales no se tiene informacin en este

proyecto. Mucha de la documentacin que engloba al OBD-II est disponible

previo pago a las respectivas empresas que lo han diseado y estandarizado,

como es el caso de la Sociedad Americana de Ingenieros (SAE) o la Organizacin

Internacional para la Estandarizacin (ISO). Aun no disponiendo de toda la

informacin deseada los objetivos de este proyecto son bastante ambiciosos y

se pueden listar como sigue:

Conseguir una comunicacin estable con cualquier centralita electrnica

(ECU) de cualquier vehculo equipado con OBD-II.

Conseguir desarrollar una aplicacin portable a cualquier sistema

operativo y plataforma utilizando lenguaje JAVA y la estructura de

programacin por capas.

11

Realizar mejoras en el hardware ya existente en el mercado a partir del

cual se construir nuestra interface.

Demostrar que con la informacin disponible en la red, es posible

acceder a los sistemas de control que implementan los fabricantes de

automviles en sus vehculos.

1.4. Alcance del proyecto

El alcance de este proyecto incluye la creacin de un sistema que implementa

una parte de las grandes posibilidades que ofrece el OBD-II, pudindose usar

como una herramienta orientativa a la hora de diagnosticar una posible avera.

Este sistema utiliza por un lado un modem interface que adecua las seales

procedentes de la centralita electrnica que se encuentra en el vehculo (ECU), a

las seales que necesita un puerto USB de cualquier ordenador. A partir de aqu,

un software de control gestionara toda la informacin recibida. Muchos de los

mtodos de diagnostico existentes utilizan este planteamiento pero ninguno de

ellos, por lo menos oficialmente, utiliza una aplicacin desarrollada en JAVA

que, por lo tanto, permita ejecutarse en la mayora de los sistemas operativos

existentes, incluyendo el famoso Linux y adems en diferentes tipos de

plataformas.

Para desarrollar el hardware se utilizaran diseos de interfaces ya existentes a

partir de los cuales se crear la que se utilizara en este proyecto, es decir, se

recapitularan los esquemas elctricos de los que se dispongan y sobre el PCB

elegido se aadirn las posibles mejoras que pudieran aportar otros diseos.

Esta parte del trabajo tambin conlleva la construccin y puesta en marcha de

un programador de microcontroladores, necesario para implementar el

firmware a partir del cual el micro utilizado en la interface funcionar.

Po otro lado el software ha desarrollar tiene un papel igual o ms importante,

ya que para conseguir disear la aplicacin de control sobre el modem

interface, se necesitan realizar los primeros programas de prueba que servirn

para constatar las bases del funcionamiento de la ltima y definitiva aplicacin

que interactuar con el modem. Este ltimo programa constar de diferentes

apartados y opciones en un entorno visual que mostrar los resultados de una

forma fcilmente comprensible dejando as todo el proceso de clculo en

segundo plano.

12

1.5. Descripcin general del proyecto

En este proyecto como se ha ido comentado a lo largo de este documento se

pretende elaborar un sistema capaz de comunicarse con la electrnica que

gestiona cualquiera de los vehculos dotados con el estndar OBD-II, y para

llevarlo acabo ha sido necesario trabajar sobre diferentes aspectos que estn

involucrados en el proceso de comunicacin. Por tanto principalmente existen

dos partes importantes a diferenciar en el desarrollo de este proyecto:

La parte que engloba el hardware necesario, que nos es ms que un

modem interface que hace de intrprete entre la centralita electrnica

del automvil (ECU), y el puerto USB de un ordenador personal.

La parte que engloba el software, que se refiere a la aplicacin que

funcionar en el PC y que gestionar el modem interface a partir de los

datos que se vallan recibiendo y enviando atreves del puerto USB.

1.5.1 Descripcin bsica del hardware (Modem interface)

Para disear el modem interface se recurri a diseos ya existentes y de libre

disposicin en la red, con el fin de conseguir construir una interface que

aportase las mejoras que de forma individual cada diseo implementa.

Esta interface contiene como elemento principal un microcontrolador

(PIC18F2550) que es el encargado de gestionar la comunicacin entre los dos

perifricos en cuestin, es decir, recoge la informacin que obtiene del puerto

USB y la interpreta segn el protocolo en que se est comunicando con la ECU.

Esto se debe a que el estndar OBD-II implementa 4 posibles protocolos en su

capa fsica, SAEJ1850PWM, ISO 9141/14230, J1850 VPW, ISO 15765 (CAN).

Para que el micro pueda realizar estas funciones se dispone adems de un

firmware que implementa las capacidades antes descritas, lo que lleva por tanto

a realizar su grabacin en el micro, y adems a la construccin de un

programador con el cual realizar este proceso.

Otro aspecto importante a resaltar es la necesidad de construir un cable

especfico para realizar la conexin entre la ECU y la interface durante las

primeras pruebas, ya que las centralitas electrnicas disponen de un conector

exclusivo para este uso, y por tanto es muy difcil de encontrar en el mercado

material compatible.

13

1.5.2 Descripcin bsica del software (Interface Visual)

Para realizar la aplicacin que gestionar el modem y todos los datos que sern

enviados y recibidos a travs de l, se deben realizar primero unos pasos previos

para poder familiarizarse con las rutinas que deberemos utilizar. Como inicio de

este proceso se debe comenzar por averiguar cul es el mecanismo que siguen

otras aplicaciones que ya implementan este mecanismo, y para poder hacerlo

existe una aplicacin, mencionada anteriormente (ScanTool), que ofrece el

cdigo fuente mediante lenguaje C++. A travs de este cdigo es posible extraer

las rutinas bsicas con las que se realiza la comunicacin con el micro y la ECU,

esto permite que nosotros mismos realicemos un programa de prueba con el

que observar cual es la estructura bsica que debemos seguir.

Debido a que el objetivo es realizar el software utilizando JAVA, ya que nos

permitir hacer portable nuestro trabajo a diferentes plataformas, el programa

anterior no es aun suficiente para poder afrontar la implementacin de la

aplicacin definitiva, y por tanto es necesario realizar otro programa de prueba

que contenga la misma estructura que el anterior pero con cdigo JAVA.

Para poder llevar a cabo este objetivo es necesario utilizar la librera

RXTXcomm como librera nativa para realizar las comunicaciones por los

puertos serie, ya que los medios que ofrece la API de Java respecto a este tipo

de comunicaciones estn obsoletos.

Una vez sabemos utilizar los recursos existentes de Java, se puede empezar a

desarrollar el software que nos ofrecer las opciones y caractersticas que

queremos implementar en la aplicacin definitiva.

El objetivo es que el programa pueda permitirnos, a travs de una interface

visual, realizar las siguientes tareas:

Opciones para poder configurar los parmetros del puerto serie segn convenga.

Opciones para poder seleccionar los protocolos de comunicacin que sean necesarios segn el vehculo.

Realizar lectura de cdigos de error que pueda tener almacenados la centralita electrnica del automvil.

Realizar lecturas a tiempo real de los datos que aportan los diferentes sensores del motor del vehculo, rpm, velocidad, carga del motor, etc.

Disponer de una consola de texto que monitoree el puerto serie refrescando su contenido segn el estado del trfico de datos entre el PC y el modem interface.

14

2. Diseos

2.1. Metodologa utilizada

Durante el desarrollo de este proyecto se ha seguido en parte la filosofa de la

ingeniera inversa para alcanzar algunos de los objetivos, aunque tambin se

han seguido las pautas de diseos anteriores de disponibilidad libre que realizan

las mismas funciones, ya que encontrar cual es el camino que se sigue para

realizar los procesos adecuadamente en un sector tan cerrado

tecnolgicamente como el del automvil puede llegar a ser muy desesperante.

Este proyecto consta principalmente de un parte de software y otra de

hardware. En lo que hace referencia a la parte fsica, es decir, el hardware, se ha

utilizado un diseo de libre uso disponible en la red, a partir del cual se

construye bsicamente la interface. Este aparato tambin se comercializa

actualmente con el nombre de ALLProAdapter por la empresa OBDDiag.net y es

una versin compatible de otra interface llamada ELM327, que originalmente es

utilizada por muchos software disponibles de pago, y del cual tambin se

disponen de los diseos electrnicos, los cuales tambin se han aprovechado

para realizar el diseo final de la circuitera del modem interface basado en el

PIC18F2550.

El primer paso ha sido comprobar que los programas que existen como

antecedentes funcionen correctamente sobre el hardware montado. De esta

manera se tiene la garanta de que el hardware (interface con PIC18F2550 con

conexin USB), funciona correctamente y de que los programas en los que nos

basaremos para la realizacin del proyecto son funcionales. De no ser as,

podramos basarnos en herramientas que no serian tiles.

Una vez verificados estos puntos, el primer objetivo siempre ha sido conseguir

efectuar algn tipo de comunicacin con el dispositivo (PIC18F2550) desde el

PC, ya que uno de los problemas comunes a todos los dispositivos de este tipo

es conocer la forma de comunicarse desde el nivel ms bsico, es decir,

constatar que el micro controlador reacciona o contesta de alguna manera

delante de un estimulo producido mediante una lnea de comunicaciones

digital.

Existe un software para el diagnostico de vehculos llamado ScanTool.net, que

en una de sus versiones ofrece el cdigo fuente, muy til para el propsito de

este proyecto. Este programa ha sido, para este proyecto, la base para poder

iniciar la bsqueda de los pasos que se siguen a la hora de realizar una

comunicacin desde el PC hasta la centralita electrnica del vehculo, atreves

del puerto de comunicaciones serie.

15

Adems del software de control y el hardware a controlar hay que tener en

cuenta que los microcontroladores necesitan un driver para que el sistema

operativo que lo gestiona pueda controlarlo. Dado que el PIC18F2550 lo fabrica

la compaa Microchip, se pens en que posiblemente esta proporcionara su

driver, y aunque as es, lo proporciona mediante la instalacin de un paquete

de herramientas llamado USB Framework package, el cual obliga a instalar

adems del driver muchas otras utilidades que en principio no son necesarias

para este caso. La empresa que ofrece libremente la informacin para montar la

interface, OBDDiag.net, tambin proporciona el driver que se necesita, en forma

de fichero INF, y es suficiente para que Windows XP o Vista la detecte sin

problemas. Tambin se pudo averiguar que en otros sistemas operativos,

como por ejemplo Linux, este microcontrolador est contemplado y en las

mismas distribuciones de Linux ya se incorpora el driver necesario.

Por tanto, despus de montar la interface y verificar su funcionamiento

mediante el software ya existente, se procedi a intentar una comunicacin

utilizando recursos propios, es decir, sin recurrir a la funcionalidad de los

programas anteriores. Utilizando el cdigo fuente antes mencionado, el cual se

basa en C++, se diseo un programa de prueba que consegua comunicarse de

forma bsica con el microcontrolador, pero que aport mucha informacin para

realizar el proyecto.

Una vez lograda la comunicacin se procedi a intentar obtener el mismo

resultado pero utilizando la plataforma Java. Bsicamente el programa de

prueba en este caso tiene la misma estructura que en C++, pero utilizando los

recursos de los que dispone Java. El paso ms importante aqu fue encontrar

que mtodos utiliza Java para comunicarse con el puerto Serie, y aunque los

que proporciona Sun Microsystems, empresa diseadora de esta plataforma de

programacin, estn obsoletos, no fue difcil encontrar otros actualizados y

perfectamente compatibles con su mquina virtual. Esta funcionalidad la

proporciona el paquete RXTXcomm junto con la instalacin de la maquina

virtual de Java.

Como ltimo objetivo se plante realizar un software que ofreciese muchas ms

funcionalidades de configuracin sobre la interface, utilizando un entorno

grafico y mucho mas intuitivo. Este software engloba toda la capacidad de

comunicacin de los programas anteriores pero aadiendo todo el potencial

que ofrece un entorno visual diseado con java, lo cual dota al programa de

muchas opciones de configuracin y operatibilidad sobre la interface y por tanto

sobre la centralita electrnica de cualquier vehculo, que, al fin y al cabo, es lo

que se pretende controlar.

16

2.1 Recursos utilizados

Para realizar este proyecto se han utilizado recursos de diferente tipo segn si

nos referimos a la parte de software o a la de hardware, pero siempre

recurriendo como fuente principal de informacin a la que se dispone en la red.

Para montar la interface se recurri a la web OBDDiag.net, donde se describen

todos los materiales, software, firmware del micro y diseo del PCB necesarios

para construirla. Paralelamente tambin se sac informacin de la web ELM

Electronics, donde mediante los datasheet que ofrecen (ELM327DS.pdf y

ELM320DS.pdf), describen como fabricar un interface para conectarse a la

centralita electrnica (ECU) de cualquier vehculo utilizando los

microcontroladores que ellos suministran. El datasheet ELM327DS, es el

documento que expone todas las posibles ordenes y respuestas que se reciben

y envan al modem interface ELM327 y por tanto tambin al microcontrolador

que se utiliza en este proyecto, ya que este incorpora un firmware compatible

que contiene la misma estructura bsica que el original, el ELM327.

En el siguiente listado se pueden ver todos los posibles comandos que el

ELM327 implementa, y por tanto, aunque no todos los comandos que utiliza la

interface utilizada en este proyecto:

18

A continuacin podemos ver uno de los esquemas elctricos que aporta ELM

Electronics, utilizando su microcontrolador ms famoso, el antes mencionado

ELM327, el cual utilizan muchas interfaces del mercado, ya que es capaz de

manejar y gestionar los protocolos de comunicacin ms utilizados en el

estndar OBD-II:

Detalle del esquema elctrico de un intrprete de OBD a RS232

19

Para realizar el software de control se utilizo como base de inicio el software

que proporciona la empresa ScanTool.net, la cual ofrece en una de sus

versiones su cdigo fuente. Este cdigo fuente se trat con el tan extendido

programa de desarrollo DEV-C++, y posteriormente tambin se desarrollaron

con l los primeros diseos de prueba con los se empez la comunicacin con la

interface.

Una vez se empez a programar utilizando la plataforma JAVA y su mquina

virtual, la cual est disponible en la web de Sun Microsystems y se puede

descargar mediante el paquete JDK 6 Update 13, se pas a utilizar otra

herramienta para programar con este lenguaje llamada Eclipse en su versin

3.2.2, y fue muy til para desarrollar el entorno grfico del que dispone el

software de control que se ha creado en este proyecto.

Un recurso muy importante tambin fue toda la informacin que se aporta en

RXTX.org, donde se explica el funcionamiento de la librera RXTXcomm.jar, que

es la que se utiliza en JAVA para manejar los puertos serie. En esta web se

ofrecen claros ejemplos de cmo utilizar y configurar los mtodos de los que se

dispone, en especial haciendo hincapi en uno de ellos que ser adjuntado en el

anexo del proyecto.

20

Por otro lado para poder entender cmo funcionan los protocolos de

comunicacin que utiliza el estndar OBDII (On Borad Diagnostics II), se extrajo

mucha informacin de la enciclopedia libre Wikipedia, donde en uno de sus

documentos (OBD-II PIDs), explica cuales y como son los formatos de trama de

datos que utiliza este estndar, adems de documentos como (ASCII), que

detalla las equivalencias del cdigo ascii entre valores decimales y hexadecimal.

Detalle de equivalencias cdigo ASCII

Detalle de la informacin aportada en el documento OBD PIDs

21

2.3. Descripcin del diseo del modem interface

La primera parte del proyecto que se empez a disear y construir es el modem

interface que se utiliza como aparato para interconectar el PC con la centralita

electrnica del vehculo. Este aparato consta de tres partes a diferenciar, el

cable USB que comunica el PC con el modem, el cable OBD-II que comunica la

centralita electrnica del vehculo con el modem y el modem propiamente

dicho. En los cables no hubo ningn proceso de montaje, se podan comprar ya

hechos, pero si se intento fabricar el del conector OBD-II, ya que es difcil

encontrarlos en los comercios especializados, pero se acab desechando por su

poca durabilidad ya que despus de unas pocas pruebas empez a deteriorarse.

Cable OBD-II a DB9 hembra Cable USB tipo A-B

En la siguiente tabla se puede apreciar la correspondencia entre los pines del

conector OBD-II y el DB9:

OBD-II 16 PIN(Macho) DB9 PIN(Hembra)

(J2850 BUS+) 2 7

(Chassis Ground) 4 1+2

(Signal Ground) 5 1+2

(CAN High J-2284) 6 3

(ISO 9141-2 K Line) 7 4

(J2850 BUS- ) 10 6

(CAN Low J-2284) 14 5

(ISO 9141-2 L Line) 15 8

(Battery Power) 16 9

22

Por tanto el trabajo importante aqu estaba en la fabricacin del modem. Para

poder construirlo se acudi a una tienda especializada donde disponan de

todos los componentes electrnicos necesarios, los cuales se procedieron a

instalar en el PCB creado a partir del siguiente layout de doble cara:

23

Este aparato contempla la posibilidad de utilizar 4 protocolos de comunicacin

distintos a nivel de capa fsica, ya que a lo largo de los aos las diferentes

centralitas electrnicas que montan los fabricantes de vehculos as lo han

dispuesto, aunque a partir del ao 2004, en Europa, la mayora de fabricantes

empezaron a implementar solo el protocolo CAN Bus. Cualquiera de los

vehculos fabricados en EE.UU. a partir del 1996, fueron obligados a disponer de

un puerto OBD2, y en Europa a partir del ao 2001, tambin se obligo a

implantar este tipo de conexin. La norma OBD2 comprende cuatro protocolos

de comunicacin distintos:

ISO 9141/14230

J1850 PWM

J1850 VPW

ISO 15765 (CAN)

VPW (Variable Pulse Width) fue originalmente introducido por General Motors,

mientras que PWM (Pulse Width Modulation) pertenece al grupo Ford. ISO 9141

y la posterior encarnacin ISO 14230 (AKA Keyword 2000) es el que la mayora

de vehculos europeos y asiticos utilizaban. Todos los nuevos modelos a partir

2007/2008 slo pueden implementar el protocolo CAN Bus. La siguiente imagen

es la de un conector tpico OBD2 de 16 pines instalado en cualquier vehculo:

Segn el protocolo de comunicacin que utilice el vehculo los pines habilitados

en el conector sern diferentes.

El protocolo ISO 9141/14230 utiliza los pines 6 y 15, el protocolo J1850 PWM

utiliza el 2 y el 10, el protocolo J1850 VPW utiliza solo el pin 2, y el protocolo ISO

15765 (CAN), el pin 6 y 14. Todos los protocolos utilizan como fuente de

alimentacin los pines 4 y 5 (masa chasis y masa seal respectivamente), y el pin

16 (+12V).

24

Para entender el funcionamiento interno del modem habra que empezar por

describir las partes de las que se compone su circuitera. En la siguiente imagen

se puede observar el esquema elctrico de la interface:

En el esquema se observa que el microcontrolador utilizado es el PIC18F2455,

pero por dificultades a la hora de adquirirlo se opt por el PIC18F2550, que es

perfectamente compatible adems de aportar un poco mas de memoria. Este

micro es el encargado de gestionar todo los componentes perifricos del

circuito y de mantener la comunicacin entre ellos, es decir, recibe la

informacin procedente del puerto USB al que est conectado, la transfiere a

los elementos del circuito que proceda y viceversa, ya que la comunicacin es

bidireccional.

La parte del circuito que se ocupa de manejar el protocolo CAN BUS, son los

integrados MCP2515 y MCP2551, el integrado MC33290 maneja el protocolo

ISO9141/14230 junto con Q3, J1850 VPW est controlado por MC33390 y el par

de Mosfets (Q2 P-channel y Q1 N-channel) controlan el bus J1850PWM junto

un comparador interno del PIC18F2550 y las resistencias R4 y R5 que crean la

seal diferencial de la entrada del PWM.

25

2.4 Descripcin del diseo del programador JDM2

Despus de la explicacin anterior es obvio deducir que el elemento ms

importante aqu es el microcontrolador PIC18F2550, pero por si solo no tiene

ninguna funcionalidad a no ser que se le introduzca el firmware adecuado, por

esta razn se tuvo que construir exclusivamente para este fin un programador

compatible con el protocolo ICSP (In-Circuit Serial Programming). Este tipo de

programador, llamado JDM2, es muy famoso en la red ya que se construye con

pocos componentes e implementa el estndar ICSP que es el que ofrece la

empresa Microchip para poder introducir los firmwares en los

microcontroladores que ellos fabrican. El esquema elctrico del programador es

de fcil adquisicin en cualquier web de electrnica y se representa con el

siguiente esquema:

26

El circuito se mont en una placa de baquelita especfica para realizar

prototipos, y se sigui el siguiente layout:

Detalle del programador JDM2 en su parte superior

Detalle del programador JDM2 en su parte inferior (lado soldadura)

27

Adems del programador necesitamos poder conectarlo a una PC que disponga

de puerto serie, ya que a travs de este puerto se comunicar con el software

que enviar el firmware al micro. La aplicacin que se utiliz para programar el

microcontrolador fue PICPgm Develop. Programer que es un software gratuito

y de fcil manejo; solo hay que seleccionar el archivo que contenga el firmware

y una vez cargado cliquear en la opcin de gravado.

Siguiendo el datasheet del microcontrolador se conect al programador segn

el siguiente detalle:

Los pines detallados en la imagen son los que utiliza el programador JDM2 y por

tanto el estndar ICSP, para comunicarse con el PIC. Vemos que adems de los

pines de comunicacin (MCLR, PGC y PGD), tambin utiliza el puerto serie para

alimentarse mediante los pines 8 y 19 para masa, y el 20 para los +5 V

necesarios. El pin 26 (PGM), no est implementado en el programador ya que

este solo se utiliza en el caso que se realice una programacin en modo Low-

Voltage ICSP, y en este caso se realiza en modo High-Voltage ICSP.

28

La conexin realizada para proceder a programar el micro fue la siguiente:

En la imagen podemos ver como el cableado procedente del programador est

etiquetado con el nombre de los pines a los cuales debe ser conectado.

Alrededor del micro hay un cable que puentea dos pines, esto se debe a que el

microcontrolador necesita dos puntos de masa. Por otro lado vemos como el

cable procedente del puerto serie est conectado en su el respectivo conector

DB9. Tambin vemos que el programador est dotado de un diodo led de

color rojo, el cual es de suma utilidad a la hora de detectar alguna anomala en

el proceso de gravado.

29

2.5 Modificaciones del diseo del modem

Una vez se haba montado la interface y se procedi a comprobar su correcto

funcionamiento con software ya existente, se observ que funcionaba

correctamente en todos los vehculos chequeados los cuales utilizaban

diferentes protocolos de comunicacin, exceptuando uno de los casos que no se

obtena respuesta de su centralita electrnica. Se sospech que posiblemente la

interface no funcionaba correctamente y se procedi a analizar con un

osciloscopio las seales que produca respecto al protocolo J1850PWM.

Para realizar las mediciones se tuvo recurrir a un osciloscopio digital con una

capacidad de muestro de hasta 1GHz, herramienta que aseguraba el visionado

ms que correcto de la seal, ya que adems esta era de tipo no peridica y por

tanto con un osciloscopio analgico es prcticamente imposible capturarla.

El resultado fue el siguiente:

Resultado de la trama enviada a travs del pin 2 (BUS+) del conector OBD-II

Resultado del trama enviada a travs del pin 10 (BUS-) del conector OBD-II

30

Para entender el resultado de estas graficas es preciso hacer una descripcin del

comportamiento de la capa fsica del protocolo j1850PWM. Este protocolo

dispone de dos lneas de comunicacin, el BUS+ y BUS-, y se caracteriza por

utilizar la modulacin del ancho de pulso (PWM) como mecanismo de

codificacin de bits. El periodo de cada bit tiene una duracin de 24 s y su

estado se expresa de la siguiente forma:

Un bit=1, se representa con un estado activo de 8us dentro de un

periodo.

Un bit=0, se representa con un estado activo de 16us dentro de un

periodo.

El BUS+ est activo cuando toma el valor de 5v.

El BUS- est activo cuando toma el valor de 0v.

Por tanto se deduce que en estado de reposo el BUS+ se encuentra a 0 V y el

BUS- a 5 V, a medida que se van enviando los bits los buses van cambiando de

estado quedando siempre entre ellos con tensiones invertidas, lo que se

traduce en un mecanismo de proteccin contra interferencias exteriores.

Hecha esta explicacin podemos darnos cuenta de que la grfica que representa

el BUS+ desvela un pequeo problema elctrico, ya que mientras que el BUS-

reacciona rpidamente colocndose a 0 V, el BUS+ nunca llega a lograr los 5 V,

quedndose siempre en los 4,4 V aproximadamente. Aunque este no sera un

problema para realizar la comunicacin satisfactoriamente segn las

especificaciones del protocolo SAEJ1850PWM, ya que se encuentra dentro de

los mrgenes elctricos permitidos, se procedi a modificar la electrnica que se

ocupa de implementar esta codificacin.

31

En el esquema elctrico observamos que los encargados de ajustar estas

tensiones son los Mosfets Q1 y Q2 (Q2 P-channel y Q1 N-channel) junto con las

resistencias R7 y R6. Partiendo de otro diseo disponible en la red que

implementa el mismo protocolo, se cambiaron los Mosfets por transistores PNP

y NPN (PNP->2N3906 y NPN->2N3904) y las resistencias R6 y R7 de 22k por

resistencias de 2K7 . Adems se incorporaron resistencias de proteccin a las

bases de los transistores de 1K.

Por tanto la modificacin resultara segn el siguiente esquema:

32

Debido a que se constat que el problema no venia causado por el hardware se

empez a investigar si poda venir dado por errores en las tramas enviadas.

Segn el estndar J1850 PWM el formato de trama es el siguiente:

A partir de los documentos que explican las caractersticas de este protocolo se

averiguo que las diferentes partes de la trama tienen las siguientes funciones:

SOF: Start of frame

Header Field: Son los encargados de especificar mediante 3 bytes los

siguientes parmetros:

El primer byte especifica el modo en que se van a comunicar la

centralita con la interface, y segn el documento SAE J2178 este byte

de cabecera se denomina de tipo mapeado, eso significa que cada bit

tiene un significado. Los 8 bit se identifican as:

BIT 7 6 5 4 3 2 1 0

ID P P P H K Y Z Z

Los tres ms significativos (7, 6 y 5) indican la prioridad del mensaje y

puede tomar los siguientes valores:

Bit 7 Bit 6 Bit 5

0 0 0 0 Prioridad mxima

0 0 1 1

0 1 0 2

0 1 1 3

1 0 0 4

1 0 1 5

1 1 0 6

1 1 1 7 Prioridad mnima

33

El bit 4 (H) indica si la cabecera es de 3 bytes o uno:

H=0 Tres bytes H=1 Un byte

El bit 3 (K) indica si se utiliza "In-Frame response" ? :

K=0 Requerido K=1 No requerido

El bit 2 (Y) indica si la direccin usada es fsica o funcional:

Y=0 Funcional Y=1 Fsica

Los bit 0 y 1 (Z, Z) se usan junto con K e Y para definir el tipo de

mensaje:

Msg. KKYZ Respuesta(K) Direccin(Y) Tipo de mensaje

0 0000 Requerido Funcional Function

1 0001 Requerido Funcional Broadcast

2 0010 Requerido Funcional Function Query

3 0011 Requerido Funcional Function Read

4 0100 Requerido Fsica Nodo a Nodo

5 0101 Requerido Fsica Reservado-MFG

6 0110 Requerido Fsica Reservado-SAE

7 0111 No requerido Fsica Reservado-MFG

8 1000 No requerido Funcional Function Command/Status

9 1001 No requerido Funcional Funcion Request/Query

10 1010 No requerido Funcional FunctionExt.Command/Status

11 1011 No requerido Funcional Function Ext. Request/Query

12 1100 No requerido Fsica Nodo a Nodo


14 1110 No requerido Fsica No disponible


34

El segundo byte representa a la direccin de memoria elegida que

identifica a la centralita (ECU).

El tercer byte representa a la direccin de memoria elegida que

identifica a la interface o herramienta de chequeo.

Data Field: Es la informacin que se quiere hacer llegar al micro de la

ECU.

CRC: Chequeo de redundancia cclica de la trama.

Conociendo ya la estructura de este protocolo se pens que una solucin al

problema sera modificar los Header Field ya que posiblemente no serian los

adecuados. A partir de aqu se procedi a averiguar cules eran los que utilizaba

nuestra interface, y esto se consigui mediante el comando ATH1, el cual le

indica al modem que muestre las cabeceras (Headers) de todas las tramas,

despus observando una de las tramas se vio que la cabecera utilizada por

defecto era 6A 61 F1. En el documento antes mencionado (J2178), se indicaba

que esta cabecera es generalmente la ms utilizada en muchas de las centralitas

que implementan el protocolo J1850PWM, pero tambin haca referencia a otra

posible cabecera a utilizar, que era E4 10 F1.

La cabecera 6A 61 F1 especifica el uso de 0x61 (01100001) como primer byte

que significa prioridad 3, tres bytes de cabecera, tipo de mensaje 2, usando

direccin funcional que es el segundo byte de la cabecera, es decir, 0x6A.

La cabecera E4 10 F1 especifica el uso de 0xE4 (11100100) como primer byte

que indica prioridad 7 (mnima), tres bytes de cabecera, tipo de mensaje 4, con

direccin fsica y nodo a nodo.

En principio para proceder a cambiar las cabeceras se dispone del comando

ATSH, pero por causas an desconocidas no era reconocido por nuestra

interface, a pesar de que en el firmware del microcontrolador se vio que estaba

implementado, mediante un software para editar ficheros de este tipo.

Utilizando este mismo software (Hex Workshop Hex Editor), se intento

averiguar donde se encontraban los bytes que definan las cabeceras en

cuestin, y despus de una bsqueda muy extensa se encontraron y

modificaron con los nuevos valores.

35

En la siguiente captura podemos observar el fragmento de cdigo donde se

encontraban estos datos, fue un tarea laboriosa ya que este fichero solo

contiene tramas hexadecimales, y es el resultado de la compilacin de un

cdigo fuente al que no se tena acceso.

:103C70000350E66EE66A00010028BC6F000E0120CA

:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2

:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37

:103CA0001EF046E90028E96E000E0120EA6E6A0E59

:103CB000EF6E020E0024E96E000E0120EA6E610E26

:103CC000EF6E030E0024E96E000E0120EA6EF10E85

:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2

:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A

Adems de reemplazar estos bytes tambin se tuvo que recalcular el

checksum de cada lnea modificada ya que este cambiaba, y el resultado fue

el siguiente:

:103C70000350E66EE66A00010028BC6F000E0120CA

:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2

:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37

:103CA0001EF046E90028E96E000E0120EA6EE40EBA

:103CB000EF6E020E0024E96E000E0120EA6E100E77

:103CC000EF6E030E0024E96E000E0120EA6EF10E85

:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2

:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A

Con el firmware ya modificado se procedi a volver reescribirlo en el

microcontrolador utilizando el programador antes descrito. Una vez preparada

la interface se volvi a intentar la comunicacin con la centralita en cuestin

que nos daba problemas. El resultado fue muy interesante ya que esta vez si nos

contest pero de la forma no esperada.

La trama enviada fue la siguiente:

E4 10 F1 01 00 0A

Y su respuesta:

C4 F1 10 7F 01 01 00 00 11 41

El dato a resaltar es el 7F 01, que indica respuesta negativa, es decir, segn el

documento J2178 una respuesta negativa significa que la centralita electrnica

no dispone de informacin sobre el modo de trabajo requerido, que es el

Modo 01.

36

El estndar OBD-II contempla varios modos de trabajo, entre ellos el modo 01,

modo 03, modo 07, modo 04, modo 09, modo 22 y bastantes ms. Cada uno de

ellos se ocupa de una parte de la informacin que puede aportar la ECU. El

modo ms extendido entre todas las centralitas es el modo 01.

Cada modo adems especifica sus parmetros PID (Parameter ID), en caso del

modo 01 uno puede ser el parmetro 00, que es el que se utiliza en nuestro

caso. Este parmetro sirve para decirle a la ECU que nos muestre cuales son los

PID que pueden ser utilizados en este modo de entre los PID que se encuentran

numerados del 1 al 20.

Despus de consultar nuevamente el documento J2178 se averigu que cuando

el modo 01 no est disponible en la centralita lo ms probable es que se

implementara en su lugar el modo 22. Este fue el final de la investigacin ya que

el modo 22 utiliza una longitud de trama ms larga que el 01, cosa para la cual

nuestro hardware (el microcontrolador de la interface), no est preparado, ya

que no se implemento en su firmware esta funcionalidad.

37

2.6 Diseo de la aplicacin de prueba en C++

Hasta ahora se ha explicado el diseo utilizado para crear la parte de hardware de la

que se compone el proyecto, pero anteriormente se ha hecho referencia tambin a la

parte de software que es la que tiene ms peso y elaboracin. El desarrollo del

software se empez a elaborar a partir del software libre ScanTool.net, que en una de

sus versiones ofrece el cdigo fuente. Utilizando la herramienta Dev-C++ y este

cdigo, el cual se basa en C++, se localizaron los mtodos y funciones que se

sospechaban eran los responsables de mantener la comunicacin mediante el puerto

serie. El primer paso fue averiguar cul era la funcin que realizaba las operaciones

necesarias para realizar las comunicaciones con el PIC. Tras encontrarla y incorporarla

a un programa de prueba, se procedi a compilar la funcin, tras esto el mismo

compilador mencionaba cuales eran las funciones y variables que llamaba este

mtodo para poder comunicarse, y por lo tanto poder buscarlas en el cdigo anterior

para reunirlas en el programa de prueba. Una vez que se tenan todas las funciones y

variables en el mismo fichero se poda compilar el cdigo sin obtener errores,

averiguando as cmo se comportaba el hilo de ejecucin. Despus de saber cul era

la rutina de ejecucin, se sacaron todas las rdenes o variables que no son

imprescindibles por realizar una comunicacin bsica, dejando la clase reducida al

mximo para tener una visin simple del proceso comunicacin dejando a la vista

claramente las funciones necesarias. Finalmente el programa de prueba poda

realizar la comunicacin enviando rdenes al PIC (atz, 0100, etc...) obteniendo los

mensajes enviados y los recibos con una visualizacin por consola. A continuacin

aparece el cdigo del programa de prueba:

39

Este programa utiliza la librera allegro como base, un librera muy utilizada

para desarrollar videojuegos, y por tanto era necesario indicarle al compilador

que la cargase con -lalleg, aunque tambin necesita cargar la librera

iostream y la winalleg, necesaria si se trabaja en Windows. Las funciones

implementadas son:

main(): Arranca el hilo de ejecucin.

init(): Carga las libreras y abre el puerto.

deinit(): Descarga las libreras y cierra el puerto.

read_comport(): Lee el puerto serie.

open_comport(): Abre el puerto serie.

40

close_commport(): Cierra el puerto serie.

send_command(): Escribe en el puerto serie.

2.7. Diseo de la aplicacin de prueba en JAVA

El segundo diseo se centra en la elaboracin de otro programa de prueba a

partir de lenguaje JAVA, ya que era necesario averiguar las capacidades de este

lenguaje a la hora de comunicarse con el puerto serie.

Como primer apunte se ha de decir que se utiliz el IDE para programar en Java

Eclipse. Para poder comunicarse con el puerto serie es necesario incluir las

libreras adecuadas en el paquete de la API de java instalada en el PC, es decir,

en el paquete autoinstalable JDK-JRE que ofrece gratuitamente Sun

Microsystems, ya que este no incluye libreras con esta funcionalidad.

Para este fin existe una librera llamada RXTXcomm, disponible en

www.RXTX.org, que mediante mtodos nativos dota a Java de la capacidad para

comunicarse con el puerto serie y paralelo, y adems puede utilizarse en

cualquier sistema operativo, haciendo hincapi en Windows, ya que aunque Sun

ofrece una API para este fin (Javacomm), no da soporte para este sistema

operativo, quedndose ya esta API obsoleta y aconsejando RXTXcomm.

Descargando y descomprimiendo el zip donde se incluyen los ficheros

necesarios de RXTX, debemos de copiar RXTXcomm.jar en la ruta c:\Archivos de

programa\Java\jre\lib\ext, rxtxSerial.dll y rxtxParallel.dll en c:\Archivos de

programa\Java\jre\bin. Si en lugar de Windows nos encontramos en Linux las

rutas donde situar los ficheros es diferente. En Linux debemos de copiar

RXTXcomm.jar en /usr/lib/jvm/jre/lib/ext, los archivos librxtParallel.so y

librxtxSerial.so hay que copiarlos en /usr/lib/jvm/jre/lib/i386 si el sistema es de

32 bits. Con esto el compilador ya tendr las libreras disponibles y podremos

utilizarla en el cdigo que programemos.

RXTX.org dispone de una web donde se explica el funcionamiento de la librera y

sus mtodos, adems ofrece ejemplos claros de cmo ponerla en marcha.

41

El programa de prueba que se elabor en esta fase del proyecto fue el siguiente:

import gnu.io.CommPortIdentifier; import gnu.io.NoSuchPortException; import gnu.io.PortInUseException; import gnu.io.SerialPort; import gnu.io.UnsupportedCommOperationException; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.util.Date; import java.util.Enumeration;

public class Principal { CommPortIdentifier idpuerto; String NombrePuerto; String ordre="atz"; String stringRebut; SerialPort port; OutputStream DadesEscriu; InputStream FluxDades; Date temps,temps2; StringBuffer respuesta;

public Principal(){}

public void conectar(){ int j=0; for(Enumeration i=CommPortIdentifier.getPortIdentifiers();i.hasMoreElements();){ idpuerto = (CommPortIdentifier) i.nextElement(); System.out.print(j++ +". " + idpuerto.getName()+"\n"); //Se examinan todos los puertos disponibles }

try { idpuerto.getPortIdentifier("COM2"); port = ( SerialPort )idpuerto.open("VisualOBD",2000); port.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //Se abre el puerto seleccionado } catch (PortInUseException e) { e.printStackTrace(); System.out.println("Puerto en uso."); } catch (NoSuchPortException e) { e.printStackTrace(); System.out.println(e); } catch (UnsupportedCommOperationException e) { e.printStackTrace(); System.out.println(e); } }

42

public void enviar(){ temps=new Date(); int data; try { DadesEscriu = port.getOutputStream(); for(int i=0;i

43

Estructuralmente el programa se asemeja al diseo en C++, y por tanto

implementa mtodos funcionalmente muy parecidos:

public static void main(): Mtodo que inicia la ejecucin del programa.

public void Conectar(): Establece la conexin con el puerto serie indicado.

public void Enviar(): Escribe la trama de datos a enviar en el puerto serie.

public void recibir(): Lee la trama de datos recibida del puerto serie.

Public long timer(): Mtodo que realiza la espera necesaria a la respuesta

del puerto.

Tanto en JAVA como en C++, el tratamiento de las tramas digitales recibidas y

enviadas en el puerto serie se traducen en valores decimales segn el cdigo

ASCII, a partir de su equivalente en binario y posteriormente en hexadecimal.

Unos ejemplos de trama de datos y su tratamiento sera el siguiente:

Comando a enviar: atz-> equivalencia cdigo ASCII:97,116,122

Este comando sirve para hacer un reset del micro.

Se le aade a la trama el retorno de carro para indicar fin de trama:

atz\r->cdigo ASCII:97,116,122,13 y el mtodo write() de la clase

SerialPort la enva al puerto serie.

Trama recibida del puerto serie atreves del mtodo read() de la clase

SerialPort:

97,116,122,13,10,69,76,77,51,50,55,32,118,49,46,49,32,99,111,109,112,

97,116,105,98,108,101,13,10,62,-1

Equivalencia de la trama segn el cdigo ASCII: atz

ELM327 v1.1 compatible

El ltimo nmero (-1), indica que no se est recibiendo ningn dato, y

sirve como referencia para saber que la trama ha finalizado, adems el

micro marca el fin de la trama con el numero 62 ( equivalente a >).

44

Comando a enviar: 01 0C-> equivalencia cdigo ASCII: 48,49,48,67

Este comando sirve para pedirle a la centralita electrnica del vehculo

(ECU), a cuantas revoluciones por minuto (rpm), est girando el motor.

Se le aade a la trama el retorno de carro para indicar fin de trama:

01 0C\r->cdigo ASCII: 48,49,48,67,13 y el mtodo write() de la clase

SerialPort la enva al puerto serie.

Posteriormente cuando la interface la ha recibido esta la enva a la ECU

segn el siguiente formato de trama si el protocolo a utilizar es J1850

PWM:

SOF: Start Of Frame

Header Field: 6A 61 F1

Data Field: 01 0C (Comando que se ha especificado antes)

CRC: 0A

EOF: End Of Frame

La ECU contesta con la siguiente trama y la interface la recoge para

enviarla al puerto serie:

6A F1 61 41 0C 0B 88 0A -> Respuesta ECU

01 0C -> Respuesta

6A F1 61 41 0C 0B 88 0A Interface

Se puede observar que la interface le aade a la trama el comando

solicitado

Trama recibida del puerto serie atreves del mtodo read() de la clase

SerialPort:

48,49,48,67,13,10,54,65,70,49,54,49,52,49,48,67,48,66,56,56,48,65,13,1

0,62,-1

45

Por tanto en la respuesta obtenida podemos diferenciar que:

01 0C: Comando requerido

6A F1 61: Cabecera de la trama(Especifica direcciones de memoria,

prioridades, tipo de conexin, etc..)

41 0C: Confirmacin de que se ha contestado al comando requerido

sumando 40 a 01, quedando 41 0C.

0B 88: El dato que interesa para calcular las rpm. Segn el documento

OBD Pids anteriormente mencionado, si pasamos a decimal estos

valores quedando en 11 y 136, y aplicamos esta frmula

( )( ) ( ) 7384

136256114

256=

+=

+ BA, obtenemos las revoluciones por

minuto del motor a tiempo real.

0A: Chequeo de redundancia cclica de la trama (CRC).

46

2.5. Diseo de la aplicacin grafica diseada en JAVA

El diseo final y definitivo de este proyecto consista en realizar un software

multiplataforma diseado mediante la conocida estructura de programacin

por capas, para poder unir de forma correcta toda la capacidad de

comunicacin que se haba conseguido en los programas de prueba anteriores

con la necesidad de ofrecer muchas ms opciones, entorno grafico y el potencial

que aporta un entorno visual diseado con JAVA, lo cual dota al programa de

muchas posibilidades de configuracin y operatibilidad sobre la interface y por

tanto sobre la centralita electrnica de cualquier vehculo.

Este software intenta ser compatible con cualquier plataforma que disponga de

una conexin USB o RS-232, de ah su implementacin mediante JAVA, pero

debido a que para realizar las comunicaciones con dichos puertos se ha utilizado

un librera nativa (RXTXcomm.jar), es posible que existan algunas

incompatibilidades de un plataforma a otra, cosa que se debera consultar en la

web de RXTXcomm.

Bsicamente el programa ofrece cinco apartados bien diferenciados:

La pantalla principal de inicio: Es la ventana que vemos cuando inicia el

programa, en ella realizamos y vemos las operaciones principales, como

son realizar la conexin/desconexin con la interface y siempre viendo

en una consola de texto los datos que se estn enviando y recibiendo a

tiempo real.

La opcin de configuracin del puerto: En esta seccin del programa

podemos configurar todos los parmetros necesarios del puerto serie,

para poder realizar una conexin.

La opcin de seleccin del protocolo de comunicacin: Esta funcionalidad

del programa permite que el usuario pueda elegir manualmente el

protocolo con el que se quiere comunicar con la ECU de su vehculo.

La opcin de Lectura de cdigos de error: Esta opcin ofrece la posibilidad

de poder averiguar si nuestro vehculo ha sufrido o sufre algn fallo

tcnico, a travs de la obtencin de un cdigo identificativo que

especifica la avera y que proporciona la ECU.

La opcin de mediciones a tiempo real: Esta parte del programa

proporciona informacin de los diferentes sensores de los que dispone

el motor de nuestro vehculo, mostrando datos como la temperatura,

velocidad, revoluciones por minuto, cantidad de aire absorbido, etc.

47

Para realizar el software se utiliz la estructura de programacin por capas:

capa de datos, capa de dominio y capa de presentacin. Cada capa tiene una

funcin dentro del programa y una serie de clases que cumplen con la funcin

que se les ha asignado. A continuacin se explica la funcin y clases que

contiene cada capa:

1. Capa de Datos: Es la encargada de gestionar todas las tramas de datos

que se intercambian la computadora y la interface. Su objetivo es

recoger ya sean datos recibidos o enviados, adecuarlos y tratarlos para

poder o bien mandrselos a la interface a travs del puerto serie o

recibirlos y mandrselos a las capas superiores. En esta capa podemos

encontrar las siguientes clases:

Clase Conexin: Es la encargada de encapsular todos los atributos de los que se compone una conexin que se realiza atreves del puerto serie: velocidad, dataBits, stopBits, paridad, nombrePuerto, protocolo.

Clase ControladorConexin: Contiene todos los mtodos necesarios para realizar la conexin, contiene mucha de la estructura conseguida en los programas de prueba.

Clase lecturaTXTErrores: Clase que permite acceder a archivos de

tipo TXT, con el objetivo de que el programa disponga de una memoria permanente. Alguna de las funcionalidades de las que dispone el software necesita cotejar la informacin que recibe con la que dispone para poder reconocerla, como es el caso de la lectura de los cdigos de error.

Clase MuestraIDs: Captura los identificadores de trama del

protocolo CAN Bus.

2. Capa de Dominio: Es la encargada de hacer de intermediario entre la capa de datos y la inmediatamente superior a la de dominio, que en este caso es la de presentacin. Ofrece la capacidad de trabajo de la capa de datos, de una forma mucho ms accesible para sus capas superiores. En esta capa encontramos la clase ControladorDominioConexin, la cual contiene todos los mtodos necesarios para manejar todas las clases que se encuentran en la capa de datos.

48

Capa de Presentacin: Esta capa se encarga de gestionar toda la parte visual del programa y contiene todas las clases y controladores necesarios para poder llevar a cabo esta tarea. Concretamente estas son las clases que contiene: ControladorPrincipal y VistaPrincipal: Gestionan la carga de todas las dems clases de la capa de presentacin y proporcionan las operaciones bsicas del programa, como son poder iniciar o detener un conexin con la interface y seleccionar las diferentes opciones del programa. ControladorErrores y VistaCodigosError: Estas clases se ocupan de gestionar la presentacin en pantalla de los cdigos de error proporcionados por la ECU. ControladorMediciones y VistaMediciones: Se ocupan de gestionar la presentacin en pantalla de los datos referentes a valores que proporcionan los sensores del vehculo, tales como temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. ControladorProtocolo y VistaProtocolo: Gestionan la presentacin en pantalla de las opciones disponibles a la hora de seleccionar un protocolo de comunicacin. ControladorPSerie y VistaConfiguracin: Presentan en pantalla todas las opciones que requiere el puerto serie para ser configurado. Adems permiten realizar una bsqueda de estos.

Por lo extenso del cdigo de este ltimo programa, se incorporar al final del proyecto como documento adjunto. En esta aplicacin la clase ms importante y difcil de desarrollar es la clase ControladorConexion, ya que es la que capacita al software de la capacidad de utilizar varios hilos de ejecucin. Esta clase implementa la interface Runnable con su respectivo mtodo Run(), el cual est en permanente escucha a los mensajes que se envan desde el puerto serie, y por tanto permite liberar al hilo principal para poder realizar otras funciones simultneamente. Otra de las clases que implementa un nuevo hilo de ejecucin es la clase ControladorMediciones, la cual se encarga de mostrar los datos de la lectura a tiempo real de los diferentes sensores de los que dispone la centralita en el vehculo. Por tanto en la aplicacin trabajan 3 hilos de ejecucin:

Hilo principal: Se mantiene a la espera para realizar las funciones que reclame el usuario.

Hilo de la clase ControladorConexion: Escucha permanentemente el puerto serie consiguiendo as no perder ningn posible dato y una velocidad de respuesta mucho ms alta.

Hilo de la clase ControladorMediciones: Refresca constantemente en pantalla los datos que va recibiendo el mtodo run() de la clase ControladorConexin.

49

Cuando se procedi a probar el software sobre diferentes sistemas operativos con la intencin de asegurar su funcionalidad, ventaja que tiene JAVA sobre otros lenguajes ya que utiliza una maquina virtual, se observ que en Windows funcionaba correctamente ya que sobre este se haba realizado la programacin, pero sobre Linux se obtuvo un resultado inesperado. Se observ que en Linux el programa arrancaba y funcionaba de forma correcta, pero en el momento que se proceda a desconectarlo del puerto serie el programa quedaba totalmente bloqueado. Despus de muchas pruebas se averigu que las libreras nativas RXTXcomm.jar que utiliza esta aplicacin se comportaban de diferente forma segn el sistema operativo en el que estuviramos trabajando. El problema se encontraba en el mtodo run() de la clase ControladorConexin(), ya que este utiliza la clase SerialPort constantemente para escuchar el puerto serie. Observando el siguiente fragmento de cdigo podemos hacernos una idea de la situacin: public void run(){ boolean datos=false; String tramaRecibida; Thread thisThread = Thread.currentThread(); while(hilo == thisThread){ char z; int longitudTrama=0; int reb=0; try { datosRecibidos = port.getInputStream(); while((reb=datosRecibidos.read())>-1){ z=(char) reb; if(reb==62){ break; } if(reb!=-1){

tramaRecibidaInicial.append(z); } } DestruirHilo=true; } catch (IOException e1) { estado("No response."); } Vemos que la lnea subrayada, datosRecibidos.read(), es la orden que se encarga de acceder al puerto y cuando el hilo de ejecucin llega a ella en Windows la lee una vez y sigue su transcurso dentro del mtodo run() hasta el siguiente ciclo de bucle donde lo volvera a leer, pero en Linux no sucede los mismo, el hilo de ejecucin se detiene en esta lnea esperando un nuevo mensaje del puerto y por tanto bloqueando su posible cierre desde el hilo principal, es decir, como el hilo que se ejecuta en run() nunca libera al objeto port, cuando accedemos al mismo objeto desde el hilo principal de la clase este provoca un bloqueo de la aplicacin ya que nunca tendr permiso para cerrarlo. Esto se solucion enviando un mensaje cualquiera al puerto y cambiando en el mismo instante la condicin del bucle while(hilo=null), para que el hilo de run() saliese de su estado de escucha y acabara extinguindose ya que la condicin del bucle ya no se cumpla.

50

Como aporte final a esta aplicacin se procedi a empaquetarla en un archivo .jar, lo que facilita mucho su puesta en marcha y portabilidad a cualquier otra plataforma o sistema operativo. Pero uno de los inconvenientes que presentaba esta aplicacin era que para poder comunicarse con los puertos de comunicacin necesitaba la librera nativa RXTXcomm, y por tanto, esta no viene incluida en las libreras de la maquina virtual que se instala por defecto, lo que obliga a tener que instalarla manualmente. Para cualquier persona que est familiarizada con la programacin no resulta ser un problema, pero si para alguien que solo quiera hacer unas cuantas pruebas. La solucin fue crear una carpeta donde se introducira el archivo JAR, los archivos adjuntos necesarios como los JPG y TXT, y otra carpeta donde incluiramos la librera nativa RXTXcomm. Adems de lo anterior se crearon dos archivos ejecutables (RunLinux.sh y RunWindows.bat), que se utilizan segn en el sistema operativo en el que estemos. La carpeta se llama VisualOBDJar y contiene los siguientes archivos:

VisualOBD.jar: Archivo comprimido que contiene todo el cdigo de la aplicacin.

RunLinux.sh: Archivo ejecutable para Linux.

RunWindows.bat: Archivo ejecutable para Windows.

VisualOBD4_1 y AboutVisualOBD: Archivos de tipo JPG.

CodigodErrores.txt: Archivo de texto utilizado como base de datos.

Leeme.txt: Archivo de texto que contiene una breve explicacin de cmo arrancar el software.

lib: Carpeta que contiene la librera nativa RXTXcomm con los

respectivos archivos rxtxParallel.dll, rxtxSerial.dll, librxtxSerial.so, y librxtxParallel.so necesarios para realizar su carga en el sistema operativo travs de la mquina virtual.

51

Para poder realizar la carga de la librera nativa correctamente se tuvo que modificar el archivo MANIFEST que contiene el paquete VisualOBD.jar quedando de la siguiente forma:

Y a los archivos RunWindows.bat y RunLinux.sh se les introdujo los siguientes comandos:

52

3. Resultados

3.1. mbito de utilizacin

Este proyecto se basa en un sistema para el chequeo del estado tcnico de

cualquiera de los vehculos que actualmente se comercializan o se han

comercializado desde 1996 en EEUU y 2001 en Europa, y por tanto su mbito de

utilizacin se puede extender bastante, incluso como pequea herramienta para

los profesionales del sector o para cualquier persona que disponga de un

vehculo dotado con el sistema On Board Diagnostics-II (OBD-II), que tenga

inters en indagar sobre el estado de su automvil.

Esta herramienta podra ser muy til, por ejemplo, para un pequeo taller

mecnico donde su presupuesto para adquirir un aparato de diagnostico es

reducido, y utilizando el sistema descrito aqu podra solucionarle muchos

problemas sin tener que hacer un gran desembolso econmico.

Actualmente todos los vehculos de cualquiera de los fabricantes, estn

obligados por ley a implementar este estndar, como un mecanismo que facilite

a todo el sector del mantenimiento, el rpido diagnostico de las averas, lo que

garantiza que el sistema que se ha desarrollado ser til en un mbito muy

extenso.

Tambin hay que decir que es necesario que el usuario tenga un mnimo de

conocimientos sobre la materia para comprender los resultados que muestra el

programa de diagnostico durante el chequeo del vehculo, lo que quizs hace

que se reduzca en parte el mbito de uso.

Por otro lado en este proyecto se profundiza bastante en el tratamiento de las

comunicaciones realizadas a travs del puerto serie utilizando los lenguajes C++

y JAVA, informacin que puede ser muy til en todo aquel mbito que necesite

de esta conexin.

3.2. Validacin de los diseos

Una vez terminado el proceso de diseo, el siguiente paso ha sido validar el

proyecto realizando pruebas en diferentes vehculos de diferentes marcas,

teniendo la certeza de que estos estaban equipados con estndar OBD-II. Cada

modelo chequeado dispona de un protocolo de comunicacin diferente a nivel

de capa fsica, con lo que se consegua comprobar que todos los protocolos que

implementa la interface funcionan.

53

Las pruebas realizadas se realizaron con xito en los siguientes coches:

Citroen C3 1.4 HDI:

Fabricado en 2004

Equipado con OBD-II y implementa el protocolo ISO 14230-4 KWP2000

Seat Toledo 1.9 TDI:

Fabricado en 2001

Equipado con OBD-II y implementa el protocolo ISO 9141-2

VolksWagen Golf 1.9 TDI:

Fabricado en 2002


Audi A3 1.9 TDI:

Fabricado en 2001


Toyota Prius (Motor hibrido)

Fabricado en 2006

Equipado con OBD-II y implementa el protocolo ISO 15765-4 CAN BUS

Seat Leon 1.9 TDI:

Fabricado en 2008

Equipado con OBD-II y implementa el protocolo ISO 15765-4 CAN BUS

Ford Focus TDDi:

Fabricado en 2002

Equipado con OBD-II y implementa el protocolo SAE J1850PWM

Opel Astra 1.6i:

Fabricado en 2001

Equipado con OBD-II y implementa el protocolo SAE J1850VPW

Opel Astra 2.0 DTI:

Fabricado en 2003


Ford Escort 1.8 TD:

Fabricado en 1998, equipado con OBD-II, implementa el protocolo SAE

J1850PWM, pero no es compatible con nuestro trabajo por incorporar un

modo de trabajo (Modo 22) no contemplado en el proyecto por su poco

uso.

54

3.3. Descripcin del funcionamiento

A continuacin se describen los pasos a seguir para poner en marcha el sistema

a la hora hacer un chequeo sobre un vehculo. El primer paso es localizar en el

coche el conector OBD-II, ya que cada modelo lo puede incorporar en un lugar

diferente.

Una vez localizado debemos conectar nuestro cable OBD-II el cual proviene de

nuestra interface. Disponiendo de un ordenador porttil o de uno de sobremesa

cercano al lugar donde estemos trabajando, conectamos la interface al puerto

USB. El montaje sera el siguiente si se realiza en un Citroen C3 del ao 2004, ya

que con respecto a otro modelo puede variar la localizacin del conector OBD-II.

55

A partir de aqu podemos arrancar nuestro PC, una vez cargado el sistema

operativo entramos dentro de la carpeta que contiene el software del proyecto

llamada VisualOBDJar. En esta carpeta encontramos dos archivos ejecutables, el

RunLinux.sh y RunWindows.bat, los cuales sern utilizamos segn en el sistema

operativo en que estemos trabajando.

En este caso arrancamos RunWindows.bat y nos aparecer el siguiente entorno

visual:

56

El siguiente paso es realizar la conexin, y para ello debemos arrancar el motor

del coche, seleccionar los parmetros de configuracin del puerto serie

(Options->Serial Port Configuration):

Cliqueando en Search for available ports obtendremos un lista de los puertos

que tenemos disponibles. Posteriormente en la parte superior seleccionaremos

el puerto en el que est conectada la interface, y modificaremos los dems

parmetros segn sea necesario. Despus solo queda cliquear en Apply para

confirmar los cambios.

57

Ahora debemos seleccionar el protocolo de comunicacin (Options-

>Communication protocol configuration). En el caso de no conocer el protocolo

que se va utilizar, el sistema lo detectar automticamente:

Vemos que podemos seleccionar el protocolo de comunicacin o dejar

seleccionada la opcin Automatic detection of communication protocol, para

que sea autodetectado. Esta seccin tambin nos proporciona la posibilidad de

modificar las cabeceras de las tramas que se van a enviar. Cada opcin (Priority,

ECU Addres, Tool address) se corresponde con un byte dentro de la trama, esto

aumenta las posibilidades de xito en el momento de conectarse con la ECU, ya

que aunque muchos modelos de centralitas se comunican de la misma forma,

necesitan que se les especifique este parmetro y por tanto modificar el que se

enva por defecto.

58

El siguiente paso es iniciar la conexin cliqueando en Connect, si el proceso se ha

realizado con xito obtendremos la siguiente respuesta:

Observamos que en la consola de texto nos aparecen los comandos

0100->41 00 98 1B 00 11 y 0100->86 F1 10 41 00 98 1B 00 11, lo que

quiere decir que se ha realizado la conexin correctamente y que la ECU

contest adecuadamente informando de los PIDs (Parameter IDs) que tiene

disponibles para ser inspeccionados.

59

En caso de que la conexin con la ECU sea fallida este sera el resultado:

Observamos que en la consola de texto se nos comunica que en los comandos

0100->Unable to connect, no hubo respuesta ya que la captura se trata de

un simple prueba sin conexin a la ECU.

Los dems comandos AT, son contestados correctamente porque son datos

procedentes nicamente de la interface, es decir, solo incumben a parmetros

que tienen que ver con el microcontrolador de la interface sin tener en cuenta a

la ECU.

60

Ahora podemos ver un ejemplo de la informacin que nos dara el programa en

el caso de que el vehculo tuviera almacenados 4 cdigos de error indicando as

que se han producido estos fallos tcnicos. Para acceder a esta informacin solo

hay que cliquear en Read error codes, estando por supuesto el sistema

correctamente conectado a la ECU:

Este es un ejemplo simulado por eso en la consola de texto seguimos

obteniendo un resultado negativo cuando se envan los comandos

0100,0101 y 03. El programa nos indica si la luz de chequeo MIL

(Malfunction Indicator Light) situada en el cuadro de mandos, est encendida y

cuantos cdigos de error tiene almacenados la ECU. Adems se detallan cuales

son los cdigos de error y una descripcin del significado de estos.

Si adems quisiramos borrar estas fallas almacenadas en la memoria de la

centralita, tendramos que cliquear en Clear error codes, y nos aparecera una

advertencia de seguridad que nos avisara del paso que vamos a realizar, ya que

si borramos esta informacin accidentalmente no la podramos recuperarla.

61

Otra funcionalidad del programa es la lectura de datos a tiempo real de los

sensores que tiene instalados el motor. La cantidad de informacin que

podemos obtener, depende de la ECU, ya que segn el modelo de esta, puede

ofrecer ms o menos datos de los sensores que gestiona en la mecnica del

motor. Un ejemplo sera el siguiente:

En la imagen se observan por un lado los datos que se van recibiendo en

formato numrico, es decir, carga del motor, temperatura del refrigerante,

revoluciones por minuto, velocidad actual, temperatura y cantidad de aire

absorbido MAF (Mass Air Flow), y en la consola de texto se observan los mismos

datos pero en formato hexadecimal, que es como la interface los va enviando a

nuestro software. Esta ltima caracterstica nos permite localizar rpidamente

cualquier incidencia en el proceso de transferencia de datos o en el

procesamiento de la centralita electrnica ya que de no ser as sera mucho ms

difcil detectar el problema.

62

En esta captura se observan ms datos aportados por la ECU:

Se puede observar que se nos proporciona informacin sobre la cantidad de

kilmetros que hemos circulado con algn problema tcnico indicado con la luz

de chequeo MIL (Malfunction Indicator Lamp) encendida.

Otro dato importante es el de la presin que hay en el circuito de inyeccin de

combustible en estado de motor a ralent, proporcionada por la bomba

inyectora a los cilindros. Parece un dato desproporcionado ya que 22070Kpa

equivalen a 220,7 bar de presin, pero teniendo en cuenta que la tecnologa hoy

utilizada puede llegar hasta los 2000 bar en el rgimen de motor ms alto, es

bastante aceptable.

63

En esta otra imagen se observan las mismas lecturas pero realizadas a un

rgimen de motor ms alto, se ha pasado de estar en 751rpm a 1613.

Observamos que la temperatura de refrigerante es menor que en la captura

anterior, esto se debe a que se tomaron los datos anteriormente. Lo importante

a sealar es que adems de ver cambios en la rpm, tambin los hay en MAF

Air Flow Rate ya que el motor necesita absorber ms aire. En Calculated

engine load value los datos tambin varan, este dato nos informa sobre la

carga a la que est sometido el motor en ese preciso momento con respecto a la

carga total que podra soportar, y aunque lo lgico sera que aumentase a mas

revoluciones el resultado es todo lo contrario, disminuye. Esto se debe a que

aunque el motor gira a ms vueltas, este no debe ejercer ningn esfuerzo ya

que se encuentra parado y por tanto no encuentra ninguna fuerza contraria al

sentido de giro.

64

Una imagen muy determinante para constatar que las lecturas son correctas es

la siguiente:

Observamos que el cuenta revoluciones del panel de instrumentos del vehculo,

est marcando alrededor de las 1500 rpm, dato que se confirma observando la

pantalla del ordenador porttil donde aparece una lectura de 1510 rpm. Se

observa tambin que hay coincidencia en la velocidad, que es de 0 km/h ya que

nos encontrbamos parados.

65

Hasta ahora el software se ha presentado funcionando bajo sistema operativo

Windows XP, pero tambin es capaz de funcionar en otros sistemas operativos,

como por ejemplo Linux. En la siguiente imagen podemos apreciarlo:

En la imagen vemos funcionar el software diseado en este proyecto bajo sistema operativo Linux, concretamente en la distribucin Ubuntu en su versin 8.04, con la maquina virtual de JAVA instalada. Respecto a Linux hay que hacer una pequea aclaracin sobre la deteccin de

los puertos serie. En este sistema operativo los puertos serie se suelen

identificar con nombres como ttyS0, ttyACM0 o ttyUSB0, a diferencia de

los COM1, COM2, COM3, etc., de Windows y adems se ubican en un carpeta

llamada /dev. Por tanto cuando arrancamos el programa en Linux

seleccionamos una de estas opciones y no tendremos ningn problema si

nuestra interface se conecta directamente al puerto RS-232, ya que la detectar

como /dev/ttySO, que es la referencia de dispositivo que siempre es detectada

de forma correcta.

66

Muchas de las interface compatibles utilizan el puerto USB, como es nuestro

caso, y en Windows las detecta tambin como puerto COM y no encontramos

problemas, pero en Linux estas interface son detectadas como /dev/ttyACM0, y

aqu es donde podemos tener impedimentos, porque este error viene causado

por la librera nativa RXTXcomm, la cual no contempla este tipo de puertos.

Para poder solucionarlo podemos ejecutar la siguiente lnea de comando en un

terminal de Linux, con la intencin de hacer un linkado simblico de la interface

/dev/ttyACM0 con una referencia que si reconozca la librera, por ejemplo

/dev/ttyS0:

>ln -sf /dev/ttyS0 /dev/ttyACM0

Despus de ejecutar este comando podremos seleccionar el dispositivo ttyS0

como si se tratase de ttyACM0, y la comunicacin se realizar sin ningn tipo

de problema.

3.4. Aplicaciones del proyecto

Como se ha ido viendo durante todo el desarrollo de la memoria, las

aplicaciones de este sistema de diagnosis son bastante obvias. El sistema

diseado es aplicable al chequeo del estado tcnico de cualquiera de los

vehculos que actualmente se comercializan o se han comercializado desde el

ao 1996 en EEUU y 2001 en Europa. Es a partir de estas fechas cuando se

oblig a los fabricantes a implantar el estndar OBD-II, y aunque anteriormente

los vehculos tambin estaban equipados con un sistema de este tipo

precisamente llamado OBD, es decir, el mismo sistema pero en su primera

versin, este no estaba estandarizado entre todos los fabricantes y por tanto

cada uno de ellos implementaba sus propios mecanismos para realizar la auto

diagnosis de sus modelos, lo que lleva a descartar este proyecto en aplicaciones

referentes a este tipo de vehculos.

Por tanto como ejemplo este sistema se puede aplicar en las labores de

manteniendo de cualquier profesional del sector que se encuentre con uno de

los vehculos mencionados anteriormente averiado y que despus de su

reparacin verifique con esta herramienta si el problema se ha subsanado

correctamente asegurndose de que la ECU no devuelve ningn cdigo de error

o de que el sensor en cuestin ofrece unas lecturas correctas segn

especificaciones del fabricante.

67

Otro ejemplo podra ser el que se da normalmente cuando cualquier poseedor

de un vehculo con OBD-II observa que en el cuadro de instrumentos se le ha

encendido una luz llamada Check Engine y se pregunta el porqu de este fallo.

En lugar de recurrir al servicio de mantenimiento inmediatamente podemos

proceder a realizar una lectura de Codigos de Error obteniendo el posible

cdigo que nos describir brevemente a que se debe el problema.

Otra de las facetas en las que se puede incluir este sistema es entre aquellas

personas que por puro placer o inters quieren conectarse con su automvil

para observar los datos que la centralita electrnica les puede ofrecer, con fines

de simple curiosidad.

Como vemos esta herramienta, aunque no est dotada de todo el potencial

posible que ofrece el OBD-II, si aporta una funcionalidad muy til entre los

posibles usuarios interesados por la mecnica.

4. Comentarios finales

4.1 Plan de trabajo

El plan de trabajo de este proyecto se ha ido desarrollando segn los siguientes

puntos:

1. Conseguir todos los componentes y materiales electrnicos necesarios

para construir el modem interface y el programador de PICs.

2. Montar la interface y el programador segn el PCB y esquemas elctricos

especificados en el proyecto.

3. Montar un cable OBD-II para ser utilizado provisionalmente durante las

primeras pruebas.

4. Comprobar el correcto funcionamiento de la interface y familiarizarse

con los comandos AT que permiten configurar el microcontrolador

PIC18F2550.

5. Instalar en un ordenador porttil los sistemas operativos WindowsXP y

Linux Ubuntu 8.04 con la respectiva maquina virtual de JAVA.

6. Instalar software compatible con la interface para comprobar su correcto

funcionamiento.

68

7. Conectar la interface a diferentes vehculos para asegurar su

funcionalidad.

8. Programar aplicaciones de prueba en C++ y Java.

9. Programar aplicacin utilizando JAVA con un entorno visual lo

suficientemente potente que permita gobernar la interface y la

centralita electrnica de forma estable.

10. Verificar el correcto funcionamiento de la aplicacin sobre la interface

mediante pruebas.

11. Verificar el correcto funcionamiento de la aplicacin sobre la centralita

electrnica de los vehculos mediante pruebas.

12. Verificar el correcto funcionamiento de la aplicacin en diferentes

sistemas operativos, Windows y Linux.

4.2 Listado de materiales

Listado de los materiales para montar el modem interface:

J1 Conector USB tipo B

J2 Conector DB-9 Macho

Q1,Q3 Transistor 2N7000

Q2 Transistor BS250/VP2106

IC1 PIC18F2455

IC2 MC33290

IC3 MC33390/MC33990

IC4 MCP2551/PCA82C250

IC5 MCP2515

X1 Cristal, 16.000Mhz

X2 Cristal, 20.000Mhz

D1 LED verde 5 mm

D2 LED Amarillo 5mm

69

D3 LED rojo 5mm

D4,D5 Diodo 1N4148

R1,R4,R5,R8 10K Ohm

R2,R3 330 Ohm

R6,R7 22K Ohm

R9,R10 510 Ohm

R11,R12 100 Ohm

C1,C2,C4,C5 15pF

C3,C8,C9 0.1uF

C6 0.47uF

C10,C11 560pF

C7 10uF 16V

IC Socket Socket para PIC18F2550 28 pin

Listado de materiales para montar el programador:

J1 Conector DB9 Hembra

D1, D2, D6, D7 Diodo 1N4149

D4 Diodo Zener 6.2 V

D5 Diodo Zener 5.1 V

D3 LED Rojo 5 mm

Q1, Q2 Transistor 2N3904

C1, C4 33pF

C2 100F 16V

C3 22F 6.3V

R3 100

R1 1.5K

R2 10K

70

Listado se software y hardware utilizado durante el proyecto:

Bloodshed Dev-C++: Programa utilizado para desarrollo de software en

C++.

Eclipse 3.2: Programa utilizado principalmente para desarrollo de

software en JAVA.

ScanTool: Programa de diagnostico OBD-II basado en microcontrolador

ELM327.

Hex Workshop: Programa para la edic

para hacer una interface de carro

Documents