La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Diseño y realización de un sistema On Board Diagnostics (OBD-II)

Presentaciones similares


Presentación del tema: "Diseño y realización de un sistema On Board Diagnostics (OBD-II)"— Transcripción de la presentación:

1 Diseño y realización de un sistema On Board Diagnostics (OBD-II)
ALUMNO: Oscar Rayo Mansilla ESPECIALIDAD: Electrónica DIRECTOR: Jordi Sellarès González DEPARTAMENTO: Física y Ingeniería Nuclear

2 ÍNDICE 1. INTRODUCCIÓN Motivación del proyecto Antecedentes Objetivos
Descripción general 2. DISEÑOS Diseño del modem interface Construcción del programador JDM2 Mejoras del modem interface Programas de prueba Diseño del software de control 3. RESULTADOS Descripción del funcionamiento Posibles aplicaciones 4. PRESUPUESTO 5. CONCLUSIONES Y MEJORAS Plan de trabajo Objetivos logrados Conclusiones finales Mejoras futuras del sistema La presentación constará de una introducción, de la explicación de los diseños realizados, los resultados obtenidos junto con el presupuesto del proyecto, y por supuesto de las conclusiones y mejoras que podrían aplicarse en un futuro.

3 MOTIVACIÓN DEL PROYECTO
INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) MOTIVACIÓN DEL PROYECTO Diagnóstico técnico de las averías de un vehículo a través de su computadora. Disponibilidad de una solución de bajo coste. Evitar la dependencia de los servicios oficiales del mantenimiento del automóvil. Como todos sabemos hoy en día los vehículos comercializados actualmente incorporan gran cantidad de sistemas electrónicos capaces de gestionar todos los procesos que se dan en el funcionamiento normal de un automóvil, pero la mayoría de usuarios desconocen como funciona y cuales son sus capacidades. Este sistema esta compuesto principalmente de una computador que procesa todos los datos que va obteniendo de los sensores localizados en diferentes puntos del vehículo, para asegurar su correcto funcionamiento. Este es una característica que en los concesionarios no nos informan de ella, ya que en ningún momento nos explican que nuestro coche incorpora una computadora, pero ellos si la utilizan para diagnosticar inmediatamente cualquier avería, mediante herramientas que no están, en principio, a nuestro alcance. Por tanto la motivación del proyecto se origina en posibilidad de disponer de una herramienta de bajo coste que interactúe con este sistema, la computadora o centralita electrónica, evitando así la dependencia de los servicios oficiales.

4 ANTECEDENTES EE.UU. 1996 (OBD-II) Europa 2001 (EOBD)
INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) ANTECEDENTES OBD II Equipamiento autodiagnosticable de abordo OBD-II (Estados Unidos), EOBD (Europa), y JOBD (Japón) Sus características pueden monitorear prácticamente todos los componentes que pueden afectar las emisiones contaminantes Informaciones importantes sobre posibles fallas detectadas EE.UU (OBD-II) Europa (EOBD) El sistema antes mencionado y del que disponen los vehículos se llama OBD II que es la abreviatura de On Board Diagnostics (Diagnóstico de Abordo) II, la segunda generación de los requerimientos de autodiagnostico de abordo y que inicialmente fue implantado en los Estados Unidos de América. 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. Las características del OBD-II están incorporadas en el hardware y el software de la centralita electrónica de los vehículos para monitorear prácticamente todos los componentes que pueden afectar las emisiones y guarda informaciones importantes sobre posibles fallas detectadas para que un operario 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, en Europa a partir del año 2001 se obliga implantar el estándar EOBD.

5 INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) ANTECEDENTES Herramientas y software disponible en el mercado basados en el micro ELM327 Interface con micro ELM327 Actualmente ya existen herramientas y software disponibles para poder llevar a cabo la inspección de un vehículo dotado de OBD-II. 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 muchos modelos de interface disponibles en el mercado, pero todas se basan en este microcontrolador, distribuido por ELM Electronics. Interface con “Bluetooth“ basada en el ELM327 Software de control ScanTool.net

6 INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) OBJETIVOS Conseguir una comunicación estable con cualquier centralita electrónica (ECU) de cualquier vehículo equipado con OBD-II. Conseguir desarrollar una aplicación portable a cualquier sistema operativo y plataforma utilizando lenguaje JAVA y la estructura de programación “por capas”. Realizar mejoras en el hardware ya existente en el mercado a partir del cual se construirá nuestra interface. Demostrar que con la información disponible en la red, es posible acceder a los sistemas de control que implementan los fabricantes de automóviles en sus vehículos.

7 DESCRIPCIÓN GENERAL DEL HARDWARE
INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DESCRIPCIÓN GENERAL DEL HARDWARE Modem interface, interprete entre la ECU y el puerto USB. Protocolos OBD-II: SAEJ1850PWM ISO 9141/14230 SAEJ1850VPW ISO15765 (CAN) Existen dos partes importantes a diferenciar en el desarrollo de este proyecto: La parte que engloba el hardware necesario formada por un modem interface que hace de intérprete entre la centralita electrónica del automóvil (ECU), y el puerto serie o USB de un ordenador personal. 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 (PC y ECU). Implementa 4 posibles protocolos de comunicación utilizados por el OBD-II: SAEJ1850PWM, ISO 9141/14230, SAEJ1850VPW e ISO15765 (CAN). Dispone del cableado necesario para realizar la conexión al puerto USB del PC y al conector J1962 específico para OBD-II Al inicio del proyecto se construyó un cable OBD-II de forma provisional para hacer pruebas, debido a que es difícil encontrarlos en los comercios. OBD-II 16 PIN(Macho) DB9 PIN(Hembra) (J2850 BUS+) 2 7 (Masa chasis) 4 1+2 (Masa señal)  5 (CAN H)  6 3 (ISO K Line)  7 4 (J2850 BUS- )  10 6 (CAN L)  14 5 (Linea L ISO )  15 8 (Voltaje batería)  16 9 CABLEADO: Cable USB tipo A-B Cable conector J1962 específico OBD-II.

8 DESCRIPCIÓN GENERAL DEL SOFTWARE
INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DESCRIPCIÓN GENERAL DEL SOFTWARE Gestión del modem interface atreves del puerto serie o USB. Configuración del puerto Lecturas de “códigos de error” Selección de protocolos de comunicación Lecturas a tiempo real de los sensores del motor Exploración del tráfico de datos Esta es la parte que engloba el software, y hace referencia a la aplicación realizada mediante JAVA, que funcionará en el PC y que gestionará el modem interface a partir de los datos que se vallan recibiendo y enviando a treves del puerto serie o USB. Permite configurar los parámetros del puerto serie según convenga. Realiza lecturas de “códigos de error” que pueda tener almacenados la centralita electrónica del automóvil. Permite seleccionar los protocolos de comunicación que sean necesarios según el vehículo. Realiza lecturas a tiempo real de los datos que aportan los diferentes sensores del motor del vehículo, rpm, velocidad, carga del motor, etc. Dispone de una consola de texto que monitorea el puerto serie refrescando su contenido según el estado del tráfico de datos entre el PC y el modem interface.

9 DISEÑO DEL MODEM INTERFACE
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DISEÑO DEL MODEM INTERFACE Utilización de un diseño disponible en la red para realizar mejoras Interface basada en el microcontrolador PIC18F2550 Compatibilidad con el micro ELM327 La interface realizada se basa en el microcontrolador PIC18F2550 el cual contiene un firmware compatible con el micro antes mencionado, el ELM327. Este esquema eléctrico se obtuvo de la red para posteriormente realizar las mejoras que se creyó oportunas. 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 señal diferencial de la entrada del PWM. J1850 VPW está controlado por MC El integrado MC33290 maneja el protocolo ISO9141/14230 junto con Q3. Los integrados MCP2515 y MCP2551 controlan el protocolo CAN BUS

10 DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Para realizar la placa de circuito impreso se utilizó el siguiente “layout”: Pistas de la cara inferior del circuito Pistas de la cara superior del circuito Distribución de componentes de la cara superior del circuito Distribución de componentes de la cara inferior del circuito

11 CONSTRUCCIÓN DEL PROGRAMADOR JDM2
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) CONSTRUCCIÓN DEL PROGRAMADOR JDM2 Cumple con el estándar ICSP de Microchip Montaje en placa de baquelita para prototipos Construcción rápida y con pocos componentes Es necesario disponer de un programador para realizar el grabado del firmware en el microcontrolador (PIC18F2550). Este programador debe cumplir con el estándar ICSP que es el que ofrece la empresa Microchip para poder introducir los firmwares en los microcontroladores que ellos fabrican. El circuito se montó en una placa de baquelita específica para realizar prototipos siguiendo el esquema eléctrico que se observa 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. Por otro lado vemos como el cable procedente del puerto RS-232 del PC, está conectado en su respectivo conector DB9. Este es el “pineado” que utiliza el programador y por tanto el estándar ICSP, en la gama del PIC18F2XXX.

12 MEJORAS DEL MODEM INTERFACE
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) MEJORAS DEL MODEM INTERFACE Funcionamiento correcto en varios vehículos y diferentes protocolos Duración del periodo de un bit µs Un bit= Activo durante 8µs Un bit= Activo durante 16µs Problemas de comunicación en el protocolo “SAEJ1850PWM” a través de una “ECU” de diseño obsoleto BUS+ activo v. BUS- activo v. Pin 2 conector OBD-II(BUS+) Una vez montado y probado se obtuvieron problemas de comunicación en el protocolo “SAEJ1850PWM “, por lo que se procedió a obtener una captura de la trama binaria mediante un osciloscopio digital obtenida a partir del “BUS” de dicho protocolo: Primera grafica: Resultado de la trama enviada a través del pin 2 (BUS+) del conector OBD-II Segunda grafica: Resultado de la trama enviada a través del pin 10 (BUS-) del conector OBD-II Este protocolo dispone de dos líneas de comunicación, el BUS+ y BUS-, y se caracteriza por utilizar la modulación del ancho de pulso (PWM) como mecanismo de codificación de bits. El periodo de cada bit tiene una duración 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. Pin 10 conector OBD-II(Bus-)

13 Modificación del circuito por obtener tensiones incorrectas en el BUS+
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Modificación del circuito por obtener tensiones incorrectas en el BUS+ Componentes que gestionan el protocolo SAEJ1850PWM Q1(Canal-N) Q2(Canal-P) Resultado de la modificación del circuito Q1(NPN) Q2(PNP) Debido a que el “BUS+”nunca lograba llegar a los +5V, solo hasta los 4’4 aproximadamente, se procedió a modificar la electrónica que gestiona el protocolo J1850PWM. Los encargados de ajustar las tensiones que adoptan el “BUS+” y el “BUS-” son los Mosfets Q1 y Q2 (Q2 P-channel y Q1 N-channel) junto con las resistencias R7 y R6 Partiendo de otro diseño 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 Ω. Además se incorporaron resistencias de protección a las bases de los transistores de 1KΩ

14 61 6A F1 01 00 0A Unnable to connect 61 F1 6A 41 0C 0B 88 5C
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Las especificaciones del protocolo indican que las tensiones del BUS están dentro de los márgenes Posibilidad de errores en las tramas enviadas 61 6A F A Trama que el modem envía por defecto Unnable to connect Según las especificaciones del protocolo SAEJ1850PWM los niveles de tensión antes mencionados estaban, aun así, dentro de los márgenes permitidos, por lo que se pensó que posiblemente el problema también podía venir causado por errores en las tramas enviadas, La cabecera de la trama (Header Field), especifica las direcciones de memoria que identifican a los módulos electrónicos de la ECU, por tanto se pensó que posiblemente esta cabecera debía ser modificada por otra que indicase las direcciones correctas. El protocolo SAEJ1850PWM menciona a la cabecera 6A 61 F1, como generalmente las mas utilizada, pero también menciona otras posibilidades, como por ejemplo la cabecera E4 10 F1. Respuesta real del modem, al no responder la ECU 61 F1 6A C 0B C Trama con la que debería responder la ECU La cabecera del trama (Header Field) especifica direcciones de memoria Solución mediante la modificación de la cabecera

15 Respuesta de la ECU después de la modificación: E4 10 F1 01 00 0A
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Modificación de la cabecera (Header Field) accediendo directamente al firmware del microcontrolador :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6E610E59 :103CB000EF6E020E0024E96E000E0120EA6E6A0E26 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Localización de la cabecera :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6EE40EBA :103CB000EF6E020E0024E96E000E0120EA6E100E77 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Modificación de la cabecera y del “checksum” Para poder modificar las cabeceras se tubo que acceder al firmware que contiene el microcontrolador ya que no es posible modificarlas con ninguna orden específica. Utilizando el software (Hex Workshop Hex Editor), se intentó averiguar donde se encontraban los bytes que definían las cabeceras en cuestión, y después de una búsqueda muy extensa se encontraron y modificaron con los nuevos valores. A continuación se pueden observar los fragmentos de código donde se encontraban. Vemos que los bytes están situados en diferentes líneas de código hexadecimal, lo cual dificultó aun mas la búsqueda. Ahora podemos ver los datos de las cabeceras modificados, lo que llevó también a recalcular el “checksum” de cada línea. La suma de verificación o “checksum” es una forma de control de redundancia, una medida muy simple para proteger la integridad de datos, verificando que no hayan sido corruptos. Una vez realizado el nuevo gravado del firmware en el microcontrolador se procedió a intentar la comunicación con la ECU, este fue el resultado. 7F 01 indica respuesta negativa, es decir, según el estándar OBD-II una respuesta negativa significa que la centralita electrónica no dispone de información sobre el modo de trabajo requerido, que es el “Modo 01”. 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. Modo 01: Se utiliza para determinar qué información del modulo electrónico (ECU) está a disposición de la herramienta de exploración. Respuesta de la ECU después de la modificación: E4 10 F A C4 F F 7F 01: modo de trabajo no compatible

16 PROGRAMAS DE PRUEBA Realización de pequeños programas de prueba
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) PROGRAMAS DE PRUEBA Realización de pequeños programas de prueba Utilización del código fuente de ScanTool.net Mediante la herramienta Dev-C++ se diseñó un pequeño programa con la siguiente estructura: main(): Arranca el hilo de ejecución. init(): Carga las librerías y abre el puerto. deinit(): Descarga las librerías y cierra el puerto. read_comport(): Lee el puerto serie. open_comport(): Abre el puerto serie. close_commport(): Cierra el puerto serie. send_command(): Escribe en el puerto serie Programa de prueba utilizando la plataforma JAVA public static void main(): Método que inicia la ejecución del programa. public void Conectar(): Establece la conexión 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(): Método que realiza la espera necesaria a la respuesta del puerto. El desarrollo del software se empezó a elaborar realizando pequeños programas de prueba a partir del software libre ScanTool.net, que en una de sus versiones ofrece el código fuente. Utilizando la herramienta Dev-C++ y este código, el cual se basa en C++, se localizaron los métodos y funciones que se sospechaban eran los responsables de mantener la comunicación mediante el puerto serie. El programa se implementó con los siguientes métodos. A partir de aquí se siguió la misma estructura para realizar otro programa de prueba pero utilizando la plataforma JAVA, que era el objetivo del proyecto. Se utilizó la librería nativa “RXTXcomm” para realizar la comunicaciones con el puerto serie:

17 Programa de prueba diseñado en C++
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Programa de prueba diseñado en C++

18 Ejemplo del tratamiento de las tramas digitales recibidas y enviadas:
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Ejemplo del tratamiento de las tramas digitales recibidas y enviadas: Comando a enviar: ”01 00” Código ASCII:” 48,49,48,48” Mas retorno de carro“01 00\r” Código ASCII:” 48,49,48,48,13 Si el protocolo a utilizar es SAEJ1850PWM: SOF: Start Of Frame Header Field: 61 6A F1 Data Field: CRC: 0A EOF: End Of Frame Respuesta ECU F1 6A B 88 5C Respuesta Interface A F B 88 5C Trama recibida en el puerto serie (Código ASCII) 48,49,48,67,13,10,54,65,70,49,54,49,52,49,48,48,48,66,56,56,53,67,13,10,62,-1 Tanto en JAVA como en C++, el tratamiento de las tramas digitales recibidas y enviadas en el puerto serie se traducen en valores decimales según el código ASCII, a partir de su equivalente en binario y posteriormente en hexadecimal. Un ejemplo de su tratamiento sería el siguiente: Comando a enviar: ”01 0C” equivalencia código ASCII:” 48,49,48,67” Este comando sirve para pedirle a la centralita electrónica del vehículo (ECU), a cuantas revoluciones por minuto (rpm), está girando el motor. Se le añade a la trama el retorno de carro para indicar fin de trama: “01 0C\r” código ASCII:” 48,49,48,67,13” y el método write() de la clase SerialPort la envía al puerto serie. Posteriormente cuando la interface la ha recibido esta la envía a la ECU según el siguiente formato de trama si el protocolo a utilizar es SAEJ1850 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: A F C 0B 88 0A Respuesta ECU C Respuesta A F C 0B 88 0A Interface Se puede observar que la interface le añade a la trama el comando solicitado Trama recibida del puerto serie atreves del método 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,10,62,-1

19 DISEÑO DEL SOFTWARE DE CONTROL
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DISEÑO DEL SOFTWARE DE CONTROL Realización de un software multiplataforma mediante lenguaje JAVA Utilización de la programación estructurada “multihilo” Diseñado en base a la estructura de programación “por capas” CAPA DE PRESENTACIÓN CAPA DE DOMINIO CAPA DE DATOS Interactúa con el usuario de la aplicación El diseño final y definitivo de este proyecto consiste en realizar un software multiplataforma mediante lenguaje JAVA y diseñado en base a la conocida estructura de programación “por capas”. Con esta aplicación conseguimos unir de forma correcta toda la capacidad de comunicación que se había conseguido en los programas de prueba anteriores con la necesidad de ofrecer muchas más opciones, lo cual dota al programa de muchas posibilidades de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo. Capa de datos: Es la encargada de gestionar todas las tramas de datos que se intercambian el puerto serie del PC y el modem interface Capa de dominio: Ofrece la capacidad de trabajo de la capa de datos, de una forma mucho más accesible para la capa de presentación Capa de presentación: Se encarga de gestionar toda la parte visual del programa que interactúa con el usuario de la aplicación. Facilita el acceso entre capas Gestiona las tramas de datos procedentes del modem

20 Capa de Datos: Capa de Dominio: Capa de Presentación:
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) PROGRAMACIÓN ESTRUCTURADA “POR CAPAS” Capa de Datos: Clase Conexión Clase ControladorConexión Clase lecturaTXTErrores Clase MuestraIDs Capa de Dominio: Clase ControladorDominioConexión Capa de Presentación: Clases ControladorPrincipal y VistaPrincipal Clases ControladorErrores y VistaCodigosError Clases ControladorMediciones y VistaMediciones Clases ControladorProtocolo y VistaProtocolo Capa de datos: Clase Conexión: Es la encargada de encapsular todos los atributos de los que se compone una conexión que se realiza atreves del puerto serie: velocidad, dataBits, stopBits, paridad, nombrePuerto, protocolo. Clase ControladorConexión: Contiene todos los métodos necesarios para realizar la conexión, 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 información que recibe con la que dispone para poder reconocerla, como es el caso de la lectura de los códigos de error. Clase MuestraIDs: Captura los identificadores de trama del protocolo CAN Bus Capa de dominio: Clase ControladorDominioConexión: Contiene todos los métodos necesarios para manejar todas las clases que se encuentran en la capa de datos. Capa de presentación: ControladorPrincipal y VistaPrincipal: Gestionan la carga de todas las demás clases de la capa de presentación y proporcionan las operaciones básicas del programa, como son poder iniciar o detener un conexión con la interface y seleccionar las diferentes opciones del programa. ControladorErrores y VistaCodigosError: Estas clases se ocupan de gestionar la presentación en pantalla de los códigos de error proporcionados por la ECU. ControladorMediciones y VistaMediciones: Se ocupan de gestionar la presentación en pantalla de los datos referentes a valores que proporcionan los sensores del vehículo, tales como temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc.… ControladorProtocolo y VistaProtocolo: Gestionan la presentación en pantalla de las opciones disponibles a la hora de seleccionar un protocolo de comunicación. ControladorPSerie y VistaConfiguración: Presentan en pantalla todas las opciones que requiere el puerto serie para ser configurado. Además permiten realizar una búsqueda de estos.

21 PUESTA EN MARCHA DEL SOFTWARE
DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) PUESTA EN MARCHA DEL SOFTWARE Arranque de la aplicación mediante archivos ejecutables RunLinux.sh RunWindows.bat VisualOBD.jar Se procedió a empaquetar la aplicación en un archivo “.jar”, lo que facilita mucho su puesta en marcha y portabilidad a cualquier otra plataforma o sistema operativo. Para poder comunicarnos con los puertos de serie necesitamos la librería nativa “RXTXcomm”, y esta no viene incluida en las librerías 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 programación no es un problema, pero si para alguien que solo quiera hacer unas cuantas pruebas. La solución es crear una carpeta donde se introduciría el archivo “JAR”, los archivos adjuntos necesarios como los “JPG” y “TXT”, y otra carpeta donde incluimos la librería nativa “RXTXcomm”, para que se cargada automáticamente. Además de lo anterior se crearon dos archivos ejecutables (RunLinux.sh y RunWindows.bat), que se utilizan según en el sistema operativo en el que estemos. Uso de la librería “RXTXcomm”

22 DESCRIPCIÓN DEL FUNCIONAMIENTO
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DESCRIPCIÓN DEL FUNCIONAMIENTO Estado inicial del programa Si arrancamos RunWindows.bat o RunLinux.sh, nos aparecerá el siguiente entorno visual.

23 Configuración del puerto serie
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Configuración del puerto serie 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 demás parámetros según sea necesario. Después solo queda cliquear en “Apply” para confirmar los cambios.

24 Selección del protocolo de comunicación
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Selección del protocolo de comunicación Vemos que podemos seleccionar el protocolo de comunicación o dejar seleccionada la opción “Automatic detection of communication protocol”, para que sea autodetectado. Esta sección también nos proporciona la posibilidad de modificar las cabeceras de las tramas que se van a enviar. Cada opción (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 parámetro y por tanto modificar el que se envía por defecto.

25 Inicio de la conexión RESULTADOS
DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Inicio de la conexión Iniciamos la conexión 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”->” B 00 11” y “0100”->”86 F B 00 11”, lo que quiere decir que se ha realizado la conexión correctamente y que la ECU contestó adecuadamente informando de los PID’s (Parameter ID’s) que tiene disponibles para ser inspeccionados.

26 Conexión no consolidada
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Conexión no consolidada

27 Lectura de “códigos de error”
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Lectura de “códigos de error”

28 Lectura de sensores a tiempo real
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Lectura de sensores a tiempo real

29 POSIBLES APLICACIONES
RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) POSIBLES APLICACIONES Labores de manteniendo de cualquier profesional del sector Labores de mantenimiento de uso particular Herramienta para aficionados a la mecánica del automóvil Labores de manteniendo de cualquier profesional del sector que se encuentre con uno vehículo averiado con OBD-II y que después de su reparación verifique con esta herramienta si el problema se ha subsanado correctamente asegurándose de que la ECU no devuelve ningún código de error o de que el sensor en cuestión ofrece unas lecturas correctas según especificaciones del fabricante. Cualquier poseedor de un vehículo 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 “Códigos de Error” obteniendo el posible código que nos describirá brevemente a que se debe el problema. Aquellas personas que por puro interés quieren conectarse a su automóvil para observar los datos que la centralita electrónica 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 mecánica.

30 PRESUPUESTO DEL PROYECTO
DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) PRESUPUESTO DEL PROYECTO La siguiente tabla especifica el presupuesto detallado en euros: Referencia Cantidad Precio unitario Precio total Material montaje interface Material montaje programador Cable OBD-II a DB9 hembra Cable USB tipo A-B Hora trabajo 1 20 5 2 10 200 Total 232 Observamos que nuestro sistema cuesta 232€, frente a los 4000€ que pueden llegar a costar las herramientas que utilizan en cualquier servicio oficial.

31 PLAN DE TRABAJO Conseguir todos los componentes y materiales.
CONCLUSIONES Y MEJORAS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) PLAN DE TRABAJO Conseguir todos los componentes y materiales. Montar la interface y el programador. Comprobar el correcto funcionamiento de la interface. Instalación de los sistemas operativos WindowsXP y Linux Ubuntu 8.04 con la respectiva maquina virtual de JAVA. Instalar software compatible con la interface para comprobar su correcto funcionamiento. Conectar la interface a diferentes vehículos para asegurar su funcionalidad. Programar aplicaciones de prueba en C++ y Java. Programar aplicación con entorno visual. Verificar el correcto funcionamiento de la aplicación visual. Verificar el correcto funcionamiento de la aplicación sobre la centralita electrónica. Verificar el correcto funcionamiento de la aplicación en diferentes sistemas operativos, Windows y Linux. Conseguir todos los componentes y materiales electrónicos necesarios para construir el modem interface y el programador de PIC’s. Montar la interface y el programador según el PCB y esquemas eléctricos especificados en el proyecto. Comprobar el correcto funcionamiento de la interface y familiarizarse con los comandos “AT” que permiten configurar el microcontrolador PIC18F2550. Instalar en un ordenador portátil los sistemas operativos WindowsXP y Linux Ubuntu 8.04 con la respectiva maquina virtual de JAVA. Instalar software compatible con la interface para comprobar su correcto funcionamiento. Conectar la interface a diferentes vehículos para asegurar su funcionalidad. Programar aplicaciones de prueba en C++ y Java. Programar aplicación utilizando JAVA con un entorno visual lo suficientemente potente que permita gobernar la interface y la centralita electrónica de forma estable. Verificar el correcto funcionamiento de la aplicación sobre la interface mediante pruebas. Verificar el correcto funcionamiento de la aplicación sobre la centralita electrónica de los vehículos mediante pruebas. Verificar el correcto funcionamiento de la aplicación en diferentes sistemas operativos, Windows y Linux.

32 CONCLUSIONES Y MEJORAS
DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) OBJETIVOS LOGRADOS Conseguir que el montaje de la interface funcione correctamente. Poder acceder a las centralitas electrónicas (ECU), según el estándar OBD-II. Consolidar la comunicación con el modem a través del puerto serie mediante aplicaciones de software de propio desarrollo en C++ y JAVA. Conseguir descifrar las tramas digitales para obtener una información fácilmente comprensible en pantalla de los datos enviados por la ECU. Finalizar el desarrollo de la aplicación visual en JAVA con todas las opciones previstas. Estabilizar la aplicación visual en JAVA sin que se produzca ningún error ya sea de comunicación con la interface o de manejo respecto al usuario. Conseguir que la aplicación visual en JAVA funcione correctamente tanto en Windows como en Linux.

33 CONCLUSIONES Y MEJORAS
DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) CONCLUSIONES FINALES El lenguaje de programación JAVA es una herramienta muy potente, ya que permite que una misma aplicación pueda funcionar de igual forma en diferentes sistemas operativos y plataformas. Es posible acceder a la centralita electrónica de un vehículo utilizando montajes sencillos y ordenadores personales. En realidad está al alcance de cualquier usuario particular. La ingeniería inversa sobre un “firmware” (desensamblado), tiene limitaciones y para realizar cambios significativos es necesario disponer del código fuente, sino estamos limitados a pequeñas modificaciones. Los fabricantes de automóviles han implementado el estándar OBD-II obligados por EE.UU. i U.E de una forma bastante compatible como lo demuestra el que un pequeño dispositivo genérico como el que se ha realizado, funcione en un amplio rango de vehículos. El hecho de disponer de un microcontrolador programable disminuye la dependencia en la plataforma, ya que solo es necesario que disponga de conexión USB, y a partir de aquí el papel de las plataformas es de gestionar una conexión serie. El procesado de los protocolos los realiza el micro. Las conclusiones finales a las que se

34 MEJORAS FUTURAS DEL SISTEMA
CONCLUSIONES Y MEJORAS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) MEJORAS FUTURAS DEL SISTEMA Internacionalizar el software de control con la intención de que pueda mostrar la información en varios idiomas ya que en esta primera versión solo se muestran en ingles. Implementar todos los modos de trabajo del estándar OBD-II en el software de control. Dotar a la interface de una botonera y un pequeño “display” para poder realizar las funciones más simples de forma autónoma, como por ejemplo la lectura y borrado de los códigos de error DTC. Implementar en el software de control una opción de autoayuda para poder entender y manejar el sistema de forma más rápida. Esta mejora sería muy útil porque los datos que se manejan son bastante abstractos. Crear un paquete instalador que automáticamente sitúe los ficheros necesarios del software para acelerar su puesta en marcha.

35 Turno de preguntas


Descargar ppt "Diseño y realización de un sistema On Board Diagnostics (OBD-II)"

Presentaciones similares


Anuncios Google