Your SlideShare is downloading. ×
Sistema operativo OBDII
Sistema operativo OBDII
Sistema operativo OBDII
Sistema operativo OBDII
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sistema operativo OBDII

223

Published on

BREVE DESCRIPCION TEORICA

BREVE DESCRIPCION TEORICA

Published in: Automotive
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
223
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×