Download Diseño y realización de un sistema On Board Diagnostics
Document related concepts
no text concepts found
Transcript
ALUMNO: Oscar Rayo Mansilla ESPECIALIDAD: Electrónica DIRECTOR: Jordi Sellarès González DEPARTAMENTO: Física y Ingeniería Nuclear 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 Diagnóstico técnico de las averías de un vehículo a través de su computadora. Disponibilidad coste. Evitar de una solución de bajo la dependencia de los servicios oficiales del mantenimiento del automóvil. 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. Europa 1996 (OBD-II) 2001 (EOBD) Herramientas y software disponible en el mercado basados en el micro ELM327 Interface con micro ELM327 Software de control ScanTool.net Interface con “Bluetooth“ basada en el ELM327 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. Modem interface, interprete entre la ECU y el puerto USB. Protocolos OBD-II: SAEJ1850PWM ISO 9141/14230 SAEJ1850VPW ISO15765 (CAN) OBD-II 16 PIN(Macho) DB9 PIN(Hembra) (J2850 BUS+) 2 (Masa chasis) 4 (Masa señal) 5 (CAN H) 6 (ISO 9141-2 K Line) 7 (J2850 BUS- ) 10 (CAN L) 14 (Linea L ISO 9141-2) 15 (Voltaje batería) 16 7 1+2 1+2 3 4 6 5 8 9 CABLEADO: Cable USB tipo A-B Cable conector J1962 específico OBD-II. 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 Utilización de un diseño disponible en la red para realizar mejoras Interface basada en el microcontrolador PIC18F2550 Compatibilidad con el micro ELM327 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 inferior del circuito Distribución de componentes de la cara superior del circuito Cumple con el estándar ICSP de Microchip Montaje en placa de baquelita para prototipos Construcción rápida y con pocos componentes Funcionamiento correcto en varios vehículos y diferentes protocolos Problemas de comunicación en el protocolo “SAEJ1850PWM” a través de una “ECU” de diseño obsoleto Pin 2 conector OBD-II(BUS+) Pin 10 conector OBD-II(Bus-) Duración del periodo de un bit Un bit=1 Activo durante 8µs Un bit=0 Activo durante 16µs BUS+ activo 5v. BUS- activo 0v. 24µs 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) 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 Trama que el modem envía por defecto 0A 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 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 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 con la siguiente estructura: programa 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. 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: 01 00 CRC: 0A EOF: End Of Frame Respuesta ECU 61 F1 6A 41 00 0B 88 5C Respuesta Interface 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 01 00 6A F1 61 41 00 0B 88 5C 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 Interactúa con el usuario de la aplicación CAPA DE DOMINIO Facilita el acceso entre capas CAPA DE DATOS Gestiona las tramas de datos procedentes del modem 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 Arranque de la aplicación mediante archivos ejecutables RunLinux.sh RunWindows.bat VisualOBD.jar Uso de la librería “RXTXcomm” Configuración del puerto serie Selección del protocolo de comunicación Labores de manteniendo de cualquier profesional del sector Labores de mantenimiento de uso particular Herramienta para aficionados a la mecánica del automóvil La siguiente tabla especifica el presupuesto detallado en euros: Referencia Material montaje interface Cantidad 1 Precio unitario Precio total 20 20 Material montaje programador 1 5 5 Cable OBD-II a DB9 hembra 1 5 5 Cable USB tipo A-B 1 2 2 Hora trabajo 20 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. 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 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. 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. 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.