BREVE DESCRIPCION TEORICA

1. SISTEMA OPERATIVO OBD-II
OBD II ofrece varias ventajas sobre los tradicionales tubos de escape basada en las inspecciones de
emisiones. OBD II alerta al conductor, al iluminar la MIL, de una gestión del motor o un problema
de control de emisiones, una vez que ha sido encontrado. Hay circunstancias en las que el sistema
OBD II puede detectar un problema antes de que el conductor advierta el problema operativo. El
diagnóstico precoz y la reparación a tiempo puede evitar reparaciones adicionales, e incluso más
caras. OBD II también proporciona al técnico de reparación de la información (códigos de
diagnóstico de fallos, información de congelación de fotogramas) específicos para la condición de
falla de las emisiones que llevó a MIL iluminación. Esta información permite una reparación más
centrada y más rápida posible.
Cada vez que un motor no está funcionando tan eficientemente como sea posible, el rendimiento
se puede perder, el combustible se puede perder, y las emisiones atmosféricas es probable que
aumenten. Las reparaciones OBD II pueden resultar en un ahorro de combustible considerable.
OBD II inspecciones tardará menos tiempo en completarse que las inspecciones del tubo de
escape base tradicional, y son capaces de evaluar las emisiones por evaporación (es decir, las fugas
de las mangueras) problemas que no son posibles para los mayores, pre-vehículos OBD II.
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

2. 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 alos 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.
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 si se compra en el mercado. También podemos encontrar el
software ScanTool.net, el cual puede ser de mucha utilidad para proyectos de estudio; 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. Ejemplo: Interface ELM327.

3. Descripción básica del hardware (Modem interface)
Para diseñar el modem interface se recurrió a diseños ya existentes y de libre
disposición en la red, con el fin de conseguir construir una interface que
aportase las mejoras que de forma individual cada diseño implementa.
Esta interface contiene como elemento principal un microcontrolador
(PIC18F2550) que es el encargado de gestionar la comunicación entre los dos
periféricos en cuestión, es decir, recoge la información que obtiene del puerto
USB y la interpreta según el protocolo en que se esté comunicando con la ECU.
Esto se debe a que el estándar OBD-II implementa 4 posibles protocolos en su
capa física, SAEJ1850PWM, ISO 9141/14230, J1850 VPW, ISO 15765 (CAN).
Para que el micro pueda realizar estas funciones se dispone además de un
firmware que implementa las capacidades antes descritas, lo que lleva por tanto
a realizar su grabación en el micro, y además a la construcción de un
programador con el cual realizar este proceso.
Otro aspecto importante a resaltar es la necesidad de construir un cable
específico para realizar la conexión entre la ECU y la interface durante las
primeras pruebas, ya que las centralitas electrónicas disponen de un conector
exclusivo para este uso, y por tanto es muy difícil de encontrar en el mercado
material compatible.
Descripción básica del software (Interface Visual)
Para realizar la aplicación que gestionará el modem y todos los datos que serán
enviados y recibidos a través 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 cuál es el mecanismo que siguen
otras aplicaciones que ya implementan este mecanismo, y para poder hacerlo
existe una aplicación, mencionada anteriormente (ScanTool), que ofrece el
código fuente mediante lenguaje C++. A través de este código es posible extraer
las rutinas básicas con las que se realiza la comunicación con el micro y la ECU,
esto permite que nosotros mismos realicemos un programa de prueba con el
que observar cual es la estructura básica 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 implementación de la
aplicación definitiva, y por tanto es necesario realizar otro programa de prueba
que contenga la misma estructura que el anterior pero con código JAVA.
Para poder llevar a cabo este objetivo es necesario utilizar la librería
“RXTXcomm” como librería 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 están obsoletos.
Una vez sabemos utilizar los recursos existentes de Java, se puede empezar a
desarrollar el software que nos ofrecerá las opciones y características que
queremos implementar en la aplicación definitiva.
El objetivo es que el programa pueda permitirnos, a través de una interface
visual, realizar las siguientes tareas:
Opciones para poder configurar los parámetros del puerto serie según convenga.

4. Opciones para poder seleccionar los protocolos de comunicación que sean
necesarios según el vehículo.
Realizar lectura de códigos de error que pueda tener almacenados la
centralita electrónica del automóvil.
Realizar lecturas a tiempo real de los datos que aportan los diferentes
sensores del motor del vehículo, rpm, velocidad, carga del motor, etc.
Disponer de una consola de texto que monitoree el puerto serie refrescando
su contenido según el estado del tráfico de datos entre el PC y el modem
interface.