PDF de programación - DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II)

DISEÑO Y REALIZACIÓN DE UN SISTEMA

ON BOARD DIAGNOSTICS (OBD-II)





ALUMNO: OSCAR RAYO MANSILLA

DIRECTOR: JORDI SELLARÈS GONZÁLEZ

4 DE JUNIO DE 2009



2

ÍNDICE

1. Introducción













5

1.1.

1.2.

1.3.

1.4.

1.5.

Justificación del proyecto…………………………………………5
Antecedentes…………………………………………………………..6
Objetivos………………………………………………………………..10
Alcance del proyecto………………………………………………11
Descripción general del proyecto……………………………12

1.5.1. Descripción básica del hardware……………..12

1.5.2. Descripción básica del software………….…..13



2. Diseños realizados 14

2.1. Metodología utilizada……………………………………………14

2.2. Recursos utilizados………………………………………………..16

2.3. Descripción del diseño del modem interface………….21

2.4. Descripción del diseño del programador JDM2…......25

2.5. Modificaciones del diseño del modem…………………..29

2.6. Diseño de la aplicación de prueba en C++………………37

2.7. Diseño de la aplicación de prueba en JAVA…………….40

2.8. Diseño de la aplicación gráfica diseñada en JAVA.....46









3

3. Resultados

















52

3.1. Ámbito de utilización…………………………………………….52

3.2. Validación de los diseños……………………………………….52

3.3. Descripción del funcionamiento…………………………….54

3.4. Aplicaciones del proyecto………………………………………66



4. Comentarios finales











67

4.1. Plan de trabajo……………………………………………………………67

4.2. Lista de materiales………………………………………………………68

4.3. Presupuesto………………………………………………………………..70

4.4. Objetivos logrados………………………………………………………71

4.5. Conclusiones……………………………………………………………….71

4.6. Mejoras futuras…………………………………………………………..72



5. Bibliografía

6. Anexo

































73

74



4

1. Introducción

1.1. Justificación del proyecto

La motivación principal de este proyecto es llegar a poder diseñar un sistema
con el que poder diagnosticar las posibles averías de cualquier vehículo sin
tener que recurrir a los costosos servicios oficiales.

Normalmente cuando se nos avería el coche siempre tenemos que acabar
recurriendo a los talleres de reparación de los cuales dispone el fabricante de
nuestro vehículo, y aunque desconocemos cuales son los medios de los que
disponen para diagnosticar la avería, si sabemos que existe un herramienta que
conectándola al vehículo averigua el problema al instante. Esto se debe a que
estas marcas tan famosas equipan nuestros coches con sistemas electrónicos
capaces de gestionar toda la mecánica y electricidad de que dispone, sin más
ayuda que la de un modulo electrónico.

En realidad estos módulos no son más que una pequeña 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 años están
obligados a implementar un estándar de autodiagnóstico llamado “OBD-II”, que
se hizo público a consecuencia de las grandes emisiones contaminantes a las
que estamos expuestos, implantando así un mecanismo de control de estas.

Estos módulos 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 están estafando, cosa que lamentablemente a veces pasa.















5

1.2. Antecedentes

OBD (On Board Diagnostics) es un sistema de diagnóstico a bordo en vehículos
(coches y camiones). Actualmente se emplea OBD-II (Estados Unidos), EOBD
(Europa), y JOBD (Japón) estándar que aportan un control casi completo del
motor y otros dispositivos del vehículo. OBD II es la abreviatura de On Board
Diagnostics (Diagnóstico de Abordo) II, la segunda generación de los
requerimientos del equipamiento autodiagnosticable de abordo de los Estados
Unidos de América. Las características de autodiagnóstico de a bordo están
incorporadas en el hardware y el software de la computadora de abordo de un
vehículo para monitorear prácticamente todos los componentes que pueden
afectar las emisiones. Cada componente es monitoreado por una rutina de
diagnóstico para verificar si está funcionando perfectamente. Si se detecta un
problema o una falla, el sistema de OBD II ilumina una lámpara de advertencia
en el cuadro de instrumentos para avisarle al conductor.

La lámpara de advertencia normalmente lleva la inscripción "Check Engine" o
"Service Engine Soon". El sistema también guarda informaciones importantes
sobre la falla detectada para que un mecánico pueda encontrar y resolver el
problema. En los Estados Unidos de América, todos los vehículos 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 vehículos de pasajeros y camiones
de diesel a partir de 1997, en Europa a partir del año 2001 se obliga implantar el
estándar EOBD. Además, un pequeño número de vehículos de gas fueron
equipados con sistemas de OBD II.

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

OBD I fue la primera regulación de OBD que obligaba a los productores a
instalar un sistema de monitoreo de algunos de los componentes controladores
de emisiones en automóviles. Obligatorios en todos los vehículos 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 específico de emisiones.

Y además, ¿qué es EOBD?

EOBD es la abreviatura de European On Board Diagnostics (Diagnóstico de a
Bordo Europeo), la variación europea de OBD II. Una de las diferencias es que
no se monitorean las evaporaciones del depósito. Sin embargo, EOBD es un
sistema mucho más sofisticado que OBD II ya que usa "mapas" de las entradas a

6



los sensores expectadas basados en las condiciones de operación del motor, y
los componentes se adaptan al sistema calibrándose empíricamente. Esto
significa que los repuestos necesitan ser de alta calidad y específicos para el
vehículo y modelo.

Todos los estándares antes mencionados implementan varios modos de trabajo,
es decir, según la parte de información a la que queramos acceder necesitamos
utilizar un modo diferente, dentro de cada uno de ellos podemos usar un
abanico de parámetros muy amplio.
Los modos de trabajo más extendidos son los siguientes:

 Modo 01: Se utiliza para determinar qué información del modulo

electrónico (ECU) está a disposición de la herramienta de exploración.

 Modo 02: Muestra los llamados en este contexto “Freeze Frame Data”, es
decir, capturas puntuales de información que ha ido almacenado la ECU.

 Modo 03: Lista los posibles fallos producidos en la mecánica mediante

códigos de error identificativos (DTC).

 Modo 04: Se utiliza para borrar los códigos 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 autónoma 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
mínimo, máximo 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 técnicos después de una
reparación del vehículo, y después de borrar la información de
diagnóstico para ver los resultados de las pruebas después de un solo
ciclo de conducción, determinando si la reparación ha solucionado el
problema.
Sólo 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 más de 60 PID’s diferentes, no es poco el
trabajo a desarrollar.



7

Actualmente ya existen muchas herramientas y software disponible para poder
llevar a cabo la inspección de un vehículo 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 autónoma, 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 pequeña cantidad de
dinero:

















8

También 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 código
fuente con el que fue diseñado:

Estos programas están diseñados para trabajar junto con el microcontrolador
ELM327, es decir, necesitan de este elemento intermedio entre el PC y el
vehículo. Existen en el mercado muchos modelos de interface disponibles en el
mercado, pero todas se basan en este micro. A continuación podemos ver
algunos ejemplos:



Interface ELM327





9

Interface ELM327 Interface ELM327 con Bluetooth





En las imágenes vemos que los modelos tienen diferentes formas y diferentes
métodos de conexión, ya que en uno de los casos se realiza por “bluetooth”,
pero su funcionamiento respecto al estándar OBD-II es idéntico.





1.3. Objetivos

Este proyecto abarca una pequeña parte del complejo campo de la
autodiagnosis en la automoción, y por tanto no pretende crear un sistema que
pueda substituir a las avanzadas herramientas de las que dispone cualq