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

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. 1. INTRODUCCIÓN • Motivación del proyecto • Antecedentes • Objetivos • Descripción general • 2. DISEÑOS • Diseño del modem interface • Construcción del programadorJDM2 • 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 ÍNDICE

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

4. 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. 1996 (OBD-II) • Europa 2001 (EOBD)

5. DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) INTRODUCCIÓN Interface con micro ELM327 ANTECEDENTES • Herramientas y software disponible en el mercado basados en el micro ELM327 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. INTRODUCCIÓN DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) • Modem interface, interprete entre la ECU y el puerto USB. DESCRIPCIÓN GENERAL DEL HARDWARE • Protocolos OBD-II: • SAEJ1850PWM • ISO 9141/14230 • SAEJ1850VPW • ISO15765 (CAN) • CABLEADO: • Cable USB tipo A-B • Cable conector J1962 específico OBD-II.

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

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

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

12. 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 24µs Un bit=1 Activo durante 8µs Un bit=0 Activo durante 16µs • Problemas de comunicación en el protocolo “SAEJ1850PWM” a través de una “ECU” de diseño obsoleto BUS+ activo 5v. BUS- activo 0v. Pin 2 conector OBD-II(BUS+) Pin 10 conector OBD-II(Bus-)

13. 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)

14. 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 F1 01 00 0A Trama que el modem envía por defecto Unnable to connect Respuesta real del modem, al no responder la ECU 61 F1 6A 41 0C 0B 88 5C 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. 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 :103C70000350E66EE66A00010028BC6F000E0120CA:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37:103CA0001EF046E90028E96E000E0120EA6E610E59:103CB000EF6E020E0024E96E000E0120EA6E6A0E26:103CC000EF6E030E0024E96E000E0120EA6EF10E85:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A • Localización de la cabecera :103C70000350E66EE66A00010028BC6F000E0120CA:103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2:103C9000000E0120BF6FBEC0E6FFBFC0E6FFDDEC37:103CA0001EF046E90028E96E000E0120EA6EE40EBA:103CB000EF6E020E0024E96E000E0120EA6E100E77:103CC000EF6E030E0024E96E000E0120EA6EF10E85:103CD000EF6E0001030EBC6F00EBE9FF01EBEAFFA2:103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A • Modificación de la cabecera y del “checksum” • Respuesta de la ECU después de la modificación: E4 10 F1 01 00 0A C4 F1 10 7F 01 01 00 00 11 41 • 7F 01: modo de trabajo no compatible

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

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

18. 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 FrameHeader Field: 61 6A F1Data Field: 01 00 CRC: 0AEOF: End Of Frame • Respuesta ECU 61 F1 6A 41 00 0B 88 5C • Respuesta Interface 01 006A F1 61 41 00 0B 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

19. 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” Interactúa con el usuario de la aplicación Facilita el acceso entre capas Gestiona las tramas de datos procedentes del modem

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

21. DISEÑOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) • RunLinux.sh • RunWindows.bat • VisualOBD.jar PUESTA EN MARCHA DEL SOFTWARE Arranque de la aplicación mediante archivos ejecutables • Uso de la librería “RXTXcomm”

22. RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) DESCRIPCIÓN DEL FUNCIONAMIENTO Estado inicial del programa

23. RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Configuración del puerto serie

24. RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Selección del protocolo de comunicación

25. RESULTADOS DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTIC (OBD-II) Inicio de la conexión

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

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

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

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

30. PRESUPUESTO 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: Observamos que nuestro sistema cuesta 232€, frente a los 4000€ que pueden llegar a costar las herramientas que utilizan en cualquier servicio oficial.

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

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.

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