DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ

Transcripción

1 DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ 4 DE JUNIO DE 2009

2 2

3 ÍNDICE 1. Introducción Justificación del proyecto Antecedentes Objetivos Alcance del proyecto Descripción general del proyecto Descripción básica del hardware Descripción básica del software Diseños realizados Metodología utilizada Recursos utilizados Descripción del diseño del modem interface Descripción del diseño del programador JDM Modificaciones del diseño del modem Diseño de la aplicación de prueba en C Diseño de la aplicación de prueba en JAVA Diseño de la aplicación gráfica diseñada en JAVA

4 3. Resultados Ámbito de utilización Validación de los diseños Descripción del funcionamiento Aplicaciones del proyecto Comentarios finales Plan de trabajo Lista de materiales Presupuesto Objetivos logrados Conclusiones Mejoras futuras Bibliografía Anexo 74 4

5 1. Introducción 1.1. Justificación del proyecto La motivación principal de este proyecto es llegar a poder diseñar un sistema con el que poder diagnosticar las posibles averías de cualquier vehículo sin tener que recurrir a los costosos servicios oficiales. Normalmente cuando se nos avería el coche siempre tenemos que acabar recurriendo a los talleres de reparación de los cuales dispone el fabricante de nuestro vehículo, y aunque desconocemos cuales son los medios de los que disponen para diagnosticar la avería, si sabemos que existe un herramienta que conectándola al vehículo averigua el problema al instante. Esto se debe a que estas marcas tan famosas equipan nuestros coches con sistemas electrónicos capaces de gestionar toda la mecánica y electricidad de que dispone, sin más ayuda que la de un modulo electrónico. En realidad estos módulos no son más que una pequeña computadora a la cual si se conoce su funcionamiento se puede acceder aunque su fabricante intente taparlo, cosa que no les es posible ya que desde hace ya bastantes años están obligados a implementar un estándar de autodiagnóstico llamado OBD-II, que se hizo público a consecuencia de las grandes emisiones contaminantes a las que estamos expuestos, implantando así un mecanismo de control de estas. Estos módulos son el objetivo de este proyecto, ya que en el momento que podamos comunicarnos con ellos podremos saber que le ocurre a nuestro coche y por tanto cuando tengamos que acudir al taller nosotros sabremos, en parte, si nos están estafando, cosa que lamentablemente a veces pasa. 5

6 1.2. 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 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 a 6

7 los 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. En este proyecto solo se va ha hacer uso del modo 01, 03 y 04, aunque teniendo en cuenta que el modo 01 dispone de más de 60 PID s diferentes, no es poco el trabajo a desarrollar. 7

8 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 previo pago de una pequeña cantidad de dinero: 8

9 También podemos encontrar el software ScanTool.net, el cual ha sido de mucha utilidad para este proyecto 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. A continuación podemos ver algunos ejemplos: Interface ELM327 9

10 Interface ELM327 Interface ELM327 con Bluetooth En las imágenes vemos que los modelos tienen diferentes formas y diferentes métodos de conexión, ya que en uno de los casos se realiza por bluetooth, pero su funcionamiento respecto al estándar OBD-II es idéntico Objetivos Este proyecto abarca una pequeña parte del complejo campo de la autodiagnosis en la automoción, y por tanto no pretende crear un sistema que pueda substituir a las avanzadas herramientas de las que dispone cualquier servicio de manteniendo, ya que el estándar OBD-II, aun siendo de libre acceso, comprende modos de trabajo de los cuales no se tiene información en este proyecto. Mucha de la documentación que engloba al OBD-II está disponible previo pago a las respectivas empresas que lo han diseñado y estandarizado, como es el caso de la Sociedad Americana de Ingenieros (SAE) o la Organización Internacional para la Estandarización (ISO). Aun no disponiendo de toda la información deseada los objetivos de este proyecto son bastante ambiciosos y se pueden listar como sigue: 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. 10

11 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 Alcance del proyecto El alcance de este proyecto incluye la creación de un sistema que implementa una parte de las grandes posibilidades que ofrece el OBD-II, pudiéndose usar como una herramienta orientativa a la hora de diagnosticar una posible avería. Este sistema utiliza por un lado un modem interface que adecua las señales procedentes de la centralita electrónica que se encuentra en el vehículo (ECU), a las señales que necesita un puerto USB de cualquier ordenador. A partir de aquí, un software de control gestionara toda la información recibida. Muchos de los métodos de diagnostico existentes utilizan este planteamiento pero ninguno de ellos, por lo menos oficialmente, utiliza una aplicación desarrollada en JAVA que, por lo tanto, permita ejecutarse en la mayoría de los sistemas operativos existentes, incluyendo el famoso Linux y además en diferentes tipos de plataformas. Para desarrollar el hardware se utilizaran diseños de interfaces ya existentes a partir de los cuales se creará la que se utilizara en este proyecto, es decir, se recapitularan los esquemas eléctricos de los que se dispongan y sobre el PCB elegido se añadirán las posibles mejoras que pudieran aportar otros diseños. Esta parte del trabajo también conlleva la construcción y puesta en marcha de un programador de microcontroladores, necesario para implementar el firmware a partir del cual el micro utilizado en la interface funcionará. Po otro lado el software ha desarrollar tiene un papel igual o más importante, ya que para conseguir diseñar la aplicación de control sobre el modem interface, se necesitan realizar los primeros programas de prueba que servirán para constatar las bases del funcionamiento de la última y definitiva aplicación que interactuará con el modem. Este último programa constará de diferentes apartados y opciones en un entorno visual que mostrará los resultados de una forma fácilmente comprensible dejando así todo el proceso de cálculo en segundo plano. 11

12 1.5. Descripción general del proyecto En este proyecto como se ha ido comentado a lo largo de este documento se pretende elaborar un sistema capaz de comunicarse con la electrónica que gestiona cualquiera de los vehículos dotados con el estándar OBD-II, y para llevarlo acabo ha sido necesario trabajar sobre diferentes aspectos que están involucrados en el proceso de comunicación. Por tanto principalmente existen dos partes importantes a diferenciar en el desarrollo de este proyecto: La parte que engloba el hardware necesario, que nos es más que un modem interface que hace de intérprete entre la centralita electrónica del automóvil (ECU), y el puerto USB de un ordenador personal. La parte que engloba el software, que se refiere a la aplicación que funcionará en el PC y que gestionará el modem interface a partir de los datos que se vallan recibiendo y enviando atreves del puerto USB 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 (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. 12

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

14 2. Diseños 2.1. Metodología utilizada Durante el desarrollo de este proyecto se ha seguido en parte la filosofía de la ingeniería inversa para alcanzar algunos de los objetivos, aunque también se han seguido las pautas de diseños anteriores de disponibilidad libre que realizan las mismas funciones, ya que encontrar cual es el camino que se sigue para realizar los procesos adecuadamente en un sector tan cerrado tecnológicamente como el del automóvil puede llegar a ser muy desesperante. Este proyecto consta principalmente de un parte de software y otra de hardware. En lo que hace referencia a la parte física, es decir, el hardware, se ha utilizado un diseño de libre uso disponible en la red, a partir del cual se construye básicamente la interface. Este aparato también se comercializa actualmente con el nombre de ALLProAdapter por la empresa OBDDiag.net y es una versión compatible de otra interface llamada ELM327, que originalmente es utilizada por muchos software disponibles de pago, y del cual también se disponen de los diseños electrónicos, los cuales también se han aprovechado para realizar el diseño final de la circuitería del modem interface basado en el PIC18F2550. El primer paso ha sido comprobar que los programas que existen como antecedentes funcionen correctamente sobre el hardware montado. De esta manera se tiene la garantía de que el hardware (interface con PIC18F2550 con conexión USB), funciona correctamente y de que los programas en los que nos basaremos para la realización del proyecto son funcionales. De no ser así, podríamos basarnos en herramientas que no serian útiles. Una vez verificados estos puntos, el primer objetivo siempre ha sido conseguir efectuar algún tipo de comunicación con el dispositivo (PIC18F2550) desde el PC, ya que uno de los problemas comunes a todos los dispositivos de este tipo es conocer la forma de comunicarse desde el nivel más básico, es decir, constatar que el micro controlador reacciona o contesta de alguna manera delante de un estimulo producido mediante una línea de comunicaciones digital. Existe un software para el diagnostico de vehículos llamado ScanTool.net, que en una de sus versiones ofrece el código fuente, muy útil para el propósito de este proyecto. Este programa ha sido, para este proyecto, la base para poder iniciar la búsqueda de los pasos que se siguen a la hora de realizar una comunicación desde el PC hasta la centralita electrónica del vehículo, atreves del puerto de comunicaciones serie. 14

15 Además del software de control y el hardware a controlar hay que tener en cuenta que los microcontroladores necesitan un driver para que el sistema operativo que lo gestiona pueda controlarlo. Dado que el PIC18F2550 lo fabrica la compañía Microchip, se pensó en que posiblemente esta proporcionara su driver, y aunque así es, lo proporciona mediante la instalación de un paquete de herramientas llamado USB Framework package, el cual obliga a instalar además del driver muchas otras utilidades que en principio no son necesarias para este caso. La empresa que ofrece libremente la información para montar la interface, OBDDiag.net, también proporciona el driver que se necesita, en forma de fichero INF, y es suficiente para que Windows XP o Vista la detecte sin problemas. También se pudo averiguar que en otros sistemas operativos, como por ejemplo Linux, este microcontrolador está contemplado y en las mismas distribuciones de Linux ya se incorpora el driver necesario. Por tanto, después de montar la interface y verificar su funcionamiento mediante el software ya existente, se procedió a intentar una comunicación utilizando recursos propios, es decir, sin recurrir a la funcionalidad de los programas anteriores. Utilizando el código fuente antes mencionado, el cual se basa en C++, se diseño un programa de prueba que conseguía comunicarse de forma básica con el microcontrolador, pero que aportó mucha información para realizar el proyecto. Una vez lograda la comunicación se procedió a intentar obtener el mismo resultado pero utilizando la plataforma Java. Básicamente el programa de prueba en este caso tiene la misma estructura que en C++, pero utilizando los recursos de los que dispone Java. El paso más importante aquí fue encontrar que métodos utiliza Java para comunicarse con el puerto Serie, y aunque los que proporciona Sun Microsystems, empresa diseñadora de esta plataforma de programación, están obsoletos, no fue difícil encontrar otros actualizados y perfectamente compatibles con su máquina virtual. Esta funcionalidad la proporciona el paquete RXTXcomm junto con la instalación de la maquina virtual de Java. Como último objetivo se planteó realizar un software que ofreciese muchas más funcionalidades de configuración sobre la interface, utilizando un entorno grafico y mucho mas intuitivo. Este software engloba toda la capacidad de comunicación de los programas anteriores pero añadiendo todo el potencial que ofrece un entorno visual diseñado con java, lo cual dota al programa de muchas opciones de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo, que, al fin y al cabo, es lo que se pretende controlar. 15

16 2.1 Recursos utilizados Para realizar este proyecto se han utilizado recursos de diferente tipo según si nos referimos a la parte de software o a la de hardware, pero siempre recurriendo como fuente principal de información a la que se dispone en la red. Para montar la interface se recurrió a la web OBDDiag.net, donde se describen todos los materiales, software, firmware del micro y diseño del PCB necesarios para construirla. Paralelamente también se sacó información de la web ELM Electronics, donde mediante los datasheet que ofrecen (ELM327DS.pdf y ELM320DS.pdf), describen como fabricar un interface para conectarse a la centralita electrónica (ECU) de cualquier vehículo utilizando los microcontroladores que ellos suministran. El datasheet ELM327DS, es el documento que expone todas las posibles ordenes y respuestas que se reciben y envían al modem interface ELM327 y por tanto también al microcontrolador que se utiliza en este proyecto, ya que este incorpora un firmware compatible que contiene la misma estructura básica que el original, el ELM327. En el siguiente listado se pueden ver todos los posibles comandos que el ELM327 implementa, y por tanto, aunque no todos los comandos que utiliza la interface utilizada en este proyecto: 16

17 17

18 A continuación podemos ver uno de los esquemas eléctricos que aporta ELM Electronics, utilizando su microcontrolador más famoso, el antes mencionado ELM327, el cual utilizan muchas interfaces del mercado, ya que es capaz de manejar y gestionar los protocolos de comunicación más utilizados en el estándar OBD-II: Detalle del esquema eléctrico de un intérprete de OBD a RS232 18

19 Para realizar el software de control se utilizo como base de inicio el software que proporciona la empresa ScanTool.net, la cual ofrece en una de sus versiones su código fuente. Este código fuente se trató con el tan extendido programa de desarrollo DEV-C++, y posteriormente también se desarrollaron con él los primeros diseños de prueba con los se empezó la comunicación con la interface. Una vez se empezó a programar utilizando la plataforma JAVA y su máquina virtual, la cual está disponible en la web de Sun Microsystems y se puede descargar mediante el paquete JDK 6 Update 13, se pasó a utilizar otra herramienta para programar con este lenguaje llamada Eclipse en su versión 3.2.2, y fue muy útil para desarrollar el entorno gráfico del que dispone el software de control que se ha creado en este proyecto. Un recurso muy importante también fue toda la información que se aporta en RXTX.org, donde se explica el funcionamiento de la librería RXTXcomm.jar, que es la que se utiliza en JAVA para manejar los puertos serie. En esta web se ofrecen claros ejemplos de cómo utilizar y configurar los métodos de los que se dispone, en especial haciendo hincapié en uno de ellos que será adjuntado en el anexo del proyecto. 19

20 Por otro lado para poder entender cómo funcionan los protocolos de comunicación que utiliza el estándar OBDII (On Borad Diagnostics II), se extrajo mucha información de la enciclopedia libre Wikipedia, donde en uno de sus documentos (OBD-II PIDs), explica cuales y como son los formatos de trama de datos que utiliza este estándar, además de documentos como (ASCII), que detalla las equivalencias del código ascii entre valores decimales y hexadecimal. Detalle de equivalencias código ASCII Detalle de la información aportada en el documento OBD PID s 20

21 2.3. Descripción del diseño del modem interface La primera parte del proyecto que se empezó a diseñar y construir es el modem interface que se utiliza como aparato para interconectar el PC con la centralita electrónica del vehículo. Este aparato consta de tres partes a diferenciar, el cable USB que comunica el PC con el modem, el cable OBD-II que comunica la centralita electrónica del vehículo con el modem y el modem propiamente dicho. En los cables no hubo ningún proceso de montaje, se podían comprar ya hechos, pero si se intento fabricar el del conector OBD-II, ya que es difícil encontrarlos en los comercios especializados, pero se acabó desechando por su poca durabilidad ya que después de unas pocas pruebas empezó a deteriorarse. Cable OBD-II a DB9 hembra Cable USB tipo A-B En la siguiente tabla se puede apreciar la correspondencia entre los pines del conector OBD-II y el DB9: OBD-II 16 PIN(Macho) DB9 PIN(Hembra) (J2850 BUS+) 2 7 (Chassis Ground) (Signal Ground) (CAN High J-2284) 6 3 (ISO K Line) 7 4 (J2850 BUS- ) 10 6 (CAN Low J-2284) 14 5 (ISO L Line) 15 8 (Battery Power)

22 Por tanto el trabajo importante aquí estaba en la fabricación del modem. Para poder construirlo se acudió a una tienda especializada donde disponían de todos los componentes electrónicos necesarios, los cuales se procedieron a instalar en el PCB creado a partir del siguiente layout de doble cara: 22

23 Este aparato contempla la posibilidad de utilizar 4 protocolos de comunicación distintos a nivel de capa física, ya que a lo largo de los años las diferentes centralitas electrónicas que montan los fabricantes de vehículos así lo han dispuesto, aunque a partir del año 2004, en Europa, la mayoría de fabricantes empezaron a implementar solo el protocolo CAN Bus. Cualquiera de los vehículos fabricados en EE.UU. a partir del 1996, fueron obligados a disponer de un puerto OBD2, y en Europa a partir del año 2001, también se obligo a implantar este tipo de conexión. La norma OBD2 comprende cuatro protocolos de comunicación distintos: ISO 9141/14230 J1850 PWM J1850 VPW ISO (CAN) VPW (Variable Pulse Width) fue originalmente introducido por General Motors, mientras que PWM (Pulse Width Modulation) pertenece al grupo Ford. ISO 9141 y la posterior encarnación ISO (AKA Keyword 2000) es el que la mayoría de vehículos europeos y asiáticos utilizaban. Todos los nuevos modelos a partir 2007/2008 sólo pueden implementar el protocolo CAN Bus. La siguiente imagen es la de un conector típico OBD2 de 16 pines instalado en cualquier vehículo: Según el protocolo de comunicación que utilice el vehículo los pines habilitados en el conector serán diferentes. El protocolo ISO 9141/14230 utiliza los pines 6 y 15, el protocolo J1850 PWM utiliza el 2 y el 10, el protocolo J1850 VPW utiliza solo el pin 2, y el protocolo ISO (CAN), el pin 6 y 14. Todos los protocolos utilizan como fuente de alimentación los pines 4 y 5 (masa chasis y masa señal respectivamente), y el pin 16 (+12V). 23

24 Para entender el funcionamiento interno del modem habría que empezar por describir las partes de las que se compone su circuitería. En la siguiente imagen se puede observar el esquema eléctrico de la interface: En el esquema se observa que el microcontrolador utilizado es el PIC18F2455, pero por dificultades a la hora de adquirirlo se optó por el PIC18F2550, que es perfectamente compatible además de aportar un poco mas de memoria. Este micro es el encargado de gestionar todo los componentes periféricos del circuito y de mantener la comunicación entre ellos, es decir, recibe la información procedente del puerto USB al que está conectado, la transfiere a los elementos del circuito que proceda y viceversa, ya que la comunicación es bidireccional. La parte del circuito que se ocupa de manejar el protocolo CAN BUS, son los integrados MCP2515 y MCP2551, el integrado MC33290 maneja el protocolo ISO9141/14230 junto con Q3, J1850 VPW está controlado por MC33390 y 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. 24

25 2.4 Descripción del diseño del programador JDM2 Después de la explicación anterior es obvio deducir que el elemento más importante aquí es el microcontrolador PIC18F2550, pero por si solo no tiene ninguna funcionalidad a no ser que se le introduzca el firmware adecuado, por esta razón se tuvo que construir exclusivamente para este fin un programador compatible con el protocolo ICSP (In-Circuit Serial Programming). Este tipo de programador, llamado JDM2, es muy famoso en la red ya que se construye con pocos componentes e implementa el estándar ICSP que es el que ofrece la empresa Microchip para poder introducir los firmwares en los microcontroladores que ellos fabrican. El esquema eléctrico del programador es de fácil adquisición en cualquier web de electrónica y se representa con el siguiente esquema: 25

26 El circuito se montó en una placa de baquelita específica para realizar prototipos, y se siguió el siguiente layout : Detalle del programador JDM2 en su parte superior Detalle del programador JDM2 en su parte inferior (lado soldadura) 26

27 Además del programador necesitamos poder conectarlo a una PC que disponga de puerto serie, ya que a través de este puerto se comunicará con el software que enviará el firmware al micro. La aplicación que se utilizó para programar el microcontrolador fue PICPgm Develop. Programer que es un software gratuito y de fácil manejo; solo hay que seleccionar el archivo que contenga el firmware y una vez cargado cliquear en la opción de gravado. Siguiendo el datasheet del microcontrolador se conectó al programador según el siguiente detalle: Los pines detallados en la imagen son los que utiliza el programador JDM2 y por tanto el estándar ICSP, para comunicarse con el PIC. Vemos que además de los pines de comunicación (MCLR, PGC y PGD), también utiliza el puerto serie para alimentarse mediante los pines 8 y 19 para masa, y el 20 para los +5 V necesarios. El pin 26 (PGM), no está implementado en el programador ya que este solo se utiliza en el caso que se realice una programación en modo Low- Voltage ICSP, y en este caso se realiza en modo High-Voltage ICSP. 27

28 La conexión realizada para proceder a programar el micro fue la siguiente: 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. Alrededor del micro hay un cable que puentea dos pines, esto se debe a que el microcontrolador necesita dos puntos de masa. Por otro lado vemos como el cable procedente del puerto serie está conectado en su el respectivo conector DB9. También vemos que el programador está dotado de un diodo led de color rojo, el cual es de suma utilidad a la hora de detectar alguna anomalía en el proceso de gravado. 28

29 2.5 Modificaciones del diseño del modem Una vez se había montado la interface y se procedió a comprobar su correcto funcionamiento con software ya existente, se observó que funcionaba correctamente en todos los vehículos chequeados los cuales utilizaban diferentes protocolos de comunicación, exceptuando uno de los casos que no se obtenía respuesta de su centralita electrónica. Se sospechó que posiblemente la interface no funcionaba correctamente y se procedió a analizar con un osciloscopio las señales que producía respecto al protocolo J1850PWM. Para realizar las mediciones se tuvo recurrir a un osciloscopio digital con una capacidad de muestro de hasta 1GHz, herramienta que aseguraba el visionado más que correcto de la señal, ya que además esta era de tipo no periódica y por tanto con un osciloscopio analógico es prácticamente imposible capturarla. El resultado fue el siguiente: Resultado de la trama enviada a través del pin 2 (BUS+) del conector OBD-II Resultado del trama enviada a través del pin 10 (BUS-) del conector OBD-II 29

30 Para entender el resultado de estas graficas es preciso hacer una descripción del comportamiento de la capa física del protocolo j1850pwm. 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. Por tanto se deduce que en estado de reposo el BUS+ se encuentra a 0 V y el BUS- a 5 V, a medida que se van enviando los bits los buses van cambiando de estado quedando siempre entre ellos con tensiones invertidas, lo que se traduce en un mecanismo de protección contra interferencias exteriores. Hecha esta explicación podemos darnos cuenta de que la gráfica que representa el BUS+ desvela un pequeño problema eléctrico, ya que mientras que el BUSreacciona rápidamente colocándose a 0 V, el BUS+ nunca llega a lograr los 5 V, quedándose siempre en los 4,4 V aproximadamente. Aunque este no sería un problema para realizar la comunicación satisfactoriamente según las especificaciones del protocolo SAEJ1850PWM, ya que se encuentra dentro de los márgenes eléctricos permitidos, se procedió a modificar la electrónica que se ocupa de implementar esta codificación. 30

31 En el esquema eléctrico observamos que los encargados de ajustar estas tensiones 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Ω. Por tanto la modificación resultaría según el siguiente esquema: 31

32 Debido a que se constató que el problema no venia causado por el hardware se empezó a investigar si podía venir dado por errores en las tramas enviadas. Según el estándar J1850 PWM el formato de trama es el siguiente: A partir de los documentos que explican las características de este protocolo se averiguo que las diferentes partes de la trama tienen las siguientes funciones: SOF: Start of frame Header Field: Son los encargados de especificar mediante 3 bytes los siguientes parámetros: El primer byte especifica el modo en que se van a comunicar la centralita con la interface, y según el documento SAE J2178 este byte de cabecera se denomina de tipo mapeado, eso significa que cada bit tiene un significado. Los 8 bit se identifican así: BIT ID P P P H K Y Z Z Los tres más significativos (7, 6 y 5) indican la prioridad del mensaje y puede tomar los siguientes valores: Bit 7 Bit 6 Bit Prioridad máxima Prioridad mínima 32

33 El bit 4 (H) indica si la cabecera es de 3 bytes o uno: H=0 Tres bytes H=1 Un byte El bit 3 (K) indica si se utiliza "In-Frame response"? : K=0 Requerido K=1 No requerido El bit 2 (Y) indica si la dirección usada es física o funcional: Y=0 Funcional Y=1 Física Los bit 0 y 1 (Z, Z) se usan junto con K e Y para definir el tipo de mensaje: Msg. KKYZ Respuesta(K) Dirección(Y) Tipo de mensaje Requerido Funcional Function Requerido Funcional Broadcast Requerido Funcional Function Query Requerido Funcional Function Read Requerido Física Nodo a Nodo Requerido Física Reservado-MFG Requerido Física Reservado-SAE No requerido Física Reservado-MFG No requerido Funcional Function Command/Status No requerido Funcional Funcion Request/Query No requerido Funcional FunctionExt.Command/Status No requerido Funcional Function Ext. Request/Query No requerido Física Nodo a Nodo No requerido Física Reservado-MFG No requerido Física No disponible No requerido Física Reservado-MFG 33

34 El segundo byte representa a la dirección de memoria elegida que identifica a la centralita (ECU). El tercer byte representa a la dirección de memoria elegida que identifica a la interface o herramienta de chequeo. Data Field: Es la información que se quiere hacer llegar al micro de la ECU. CRC: Chequeo de redundancia cíclica de la trama. Conociendo ya la estructura de este protocolo se pensó que una solución al problema sería modificar los Header Field ya que posiblemente no serian los adecuados. A partir de aquí se procedió a averiguar cuáles eran los que utilizaba nuestra interface, y esto se consiguió mediante el comando ATH1, el cual le indica al modem que muestre las cabeceras (Headers) de todas las tramas, después observando una de las tramas se vio que la cabecera utilizada por defecto era 6A 61 F1. En el documento antes mencionado (J2178), se indicaba que esta cabecera es generalmente la más utilizada en muchas de las centralitas que implementan el protocolo J1850PWM, pero también hacía referencia a otra posible cabecera a utilizar, que era E4 10 F1. La cabecera 6A 61 F1 especifica el uso de 0x61 ( ) como primer byte que significa prioridad 3, tres bytes de cabecera, tipo de mensaje 2, usando dirección funcional que es el segundo byte de la cabecera, es decir, 0x6A. La cabecera E4 10 F1 especifica el uso de 0xE4 ( ) como primer byte que indica prioridad 7 (mínima), tres bytes de cabecera, tipo de mensaje 4, con dirección física y nodo a nodo. En principio para proceder a cambiar las cabeceras se dispone del comando ATSH, pero por causas aún desconocidas no era reconocido por nuestra interface, a pesar de que en el firmware del microcontrolador se vio que estaba implementado, mediante un software para editar ficheros de este tipo. Utilizando este mismo software (Hex Workshop Hex Editor), se intento 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. 34

35 En la siguiente captura podemos observar el fragmento de código donde se encontraban estos datos, fue un tarea laboriosa ya que este fichero solo contiene tramas hexadecimales, y es el resultado de la compilación de un código fuente al que no se tenía acceso. :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6E6A0E59 :103CB000EF6E020E0024E96E000E0120EA6E610E26 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Además de reemplazar estos bytes también se tuvo que recalcular el checksum de cada línea modificada ya que este cambiaba, y el resultado fue el siguiente: :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6EE40EBA :103CB000EF6E020E0024E96E000E0120EA6E100E77 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Con el firmware ya modificado se procedió a volver reescribirlo en el microcontrolador utilizando el programador antes descrito. Una vez preparada la interface se volvió a intentar la comunicación con la centralita en cuestión que nos daba problemas. El resultado fue muy interesante ya que esta vez si nos contestó pero de la forma no esperada. La trama enviada fue la siguiente: E4 10 F A Y su respuesta: C4 F1 10 7F El dato a resaltar es el 7F 01, que indica respuesta negativa, es decir, según el documento J2178 una respuesta negativa significa que la centralita electrónica no dispone de información sobre el modo de trabajo requerido, que es el Modo

36 El estándar OBD-II contempla varios modos de trabajo, entre ellos el modo 01, modo 03, modo 07, modo 04, modo 09, modo 22 y bastantes más. Cada uno de ellos se ocupa de una parte de la información que puede aportar la ECU. El modo más extendido entre todas las centralitas es el modo 01. Cada modo además especifica sus parámetros PID (Parameter ID), en caso del modo 01 uno puede ser el parámetro 00, que es el que se utiliza en nuestro caso. Este parámetro sirve para decirle a la ECU que nos muestre cuales son los PID que pueden ser utilizados en este modo de entre los PID que se encuentran numerados del 1 al 20. Después de consultar nuevamente el documento J2178 se averiguó que cuando el modo 01 no está disponible en la centralita lo más probable es que se implementara en su lugar el modo 22. Este fue el final de la investigación ya que el modo 22 utiliza una longitud de trama más larga que el 01, cosa para la cual nuestro hardware (el microcontrolador de la interface), no está preparado, ya que no se implemento en su firmware esta funcionalidad. 36

37 2.6 Diseño de la aplicación de prueba en C++ Hasta ahora se ha explicado el diseño utilizado para crear la parte de hardware de la que se compone el proyecto, pero anteriormente se ha hecho referencia también a la parte de software que es la que tiene más peso y elaboración. El desarrollo del software se empezó a elaborar 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 primer paso fue averiguar cuál era la función que realizaba las operaciones necesarias para realizar las comunicaciones con el PIC. Tras encontrarla y incorporarla a un programa de prueba, se procedió a compilar la función, tras esto el mismo compilador mencionaba cuales eran las funciones y variables que llamaba este método para poder comunicarse, y por lo tanto poder buscarlas en el código anterior para reunirlas en el programa de prueba. Una vez que se tenían todas las funciones y variables en el mismo fichero se podía compilar el código sin obtener errores, averiguando así cómo se comportaba el hilo de ejecución. Después de saber cuál era la rutina de ejecución, se sacaron todas las órdenes o variables que no son imprescindibles por realizar una comunicación básica, dejando la clase reducida al máximo para tener una visión simple del proceso comunicación dejando a la vista claramente las funciones necesarias. Finalmente el programa de prueba podía realizar la comunicación enviando órdenes al PIC (atz, 0100, etc...) obteniendo los mensajes enviados y los recibos con una visualización por consola. A continuación aparece el código del programa de prueba: 37

38 38

39 Este programa utiliza la librería allegro como base, un librería muy utilizada para desarrollar videojuegos, y por tanto era necesario indicarle al compilador que la cargase con -lalleg, aunque también necesita cargar la librería iostream y la winalleg, necesaria si se trabaja en Windows. Las funciones implementadas son: 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. 39

40 close_commport(): Cierra el puerto serie. send_command(): Escribe en el puerto serie Diseño de la aplicación de prueba en JAVA El segundo diseño se centra en la elaboración de otro programa de prueba a partir de lenguaje JAVA, ya que era necesario averiguar las capacidades de este lenguaje a la hora de comunicarse con el puerto serie. Como primer apunte se ha de decir que se utilizó el IDE para programar en Java Eclipse. Para poder comunicarse con el puerto serie es necesario incluir las librerías adecuadas en el paquete de la API de java instalada en el PC, es decir, en el paquete autoinstalable JDK-JRE que ofrece gratuitamente Sun Microsystems, ya que este no incluye librerías con esta funcionalidad. Para este fin existe una librería llamada RXTXcomm, disponible en que mediante métodos nativos dota a Java de la capacidad para comunicarse con el puerto serie y paralelo, y además puede utilizarse en cualquier sistema operativo, haciendo hincapié en Windows, ya que aunque Sun ofrece una API para este fin (Javacomm), no da soporte para este sistema operativo, quedándose ya esta API obsoleta y aconsejando RXTXcomm. Descargando y descomprimiendo el zip donde se incluyen los ficheros necesarios de RXTX, debemos de copiar RXTXcomm.jar en la ruta c:\archivos de programa\java\jre\lib\ext, rxtxserial.dll y rxtxparallel.dll en c:\archivos de programa\java\jre\bin. Si en lugar de Windows nos encontramos en Linux las rutas donde situar los ficheros es diferente. En Linux debemos de copiar RXTXcomm.jar en /usr/lib/jvm/jre/lib/ext, los archivos librxtparallel.so y librxtxserial.so hay que copiarlos en /usr/lib/jvm/jre/lib/i386 si el sistema es de 32 bits. Con esto el compilador ya tendrá las librerías disponibles y podremos utilizarla en el código que programemos. RXTX.org dispone de una web donde se explica el funcionamiento de la librería y sus métodos, además ofrece ejemplos claros de cómo ponerla en marcha. 40

41 El programa de prueba que se elaboró en esta fase del proyecto fue el siguiente: import gnu.io.commportidentifier; import gnu.io.nosuchportexception; import gnu.io.portinuseexception; import gnu.io.serialport; import gnu.io.unsupportedcommoperationexception; import java.io.ioexception; import java.io.inputstream; import java.io.outputstream; import java.util.date; import java.util.enumeration; public class Principal { CommPortIdentifier idpuerto; String NombrePuerto; String ordre="atz"; String stringrebut; SerialPort port; OutputStream DadesEscriu; InputStream FluxDades; Date temps,temps2; StringBuffer respuesta; public Principal(){ public void conectar(){ int j=0; for(enumeration i=commportidentifier.getportidentifiers();i.hasmoreelements();){ idpuerto = (CommPortIdentifier) i.nextelement(); System.out.print(j++ +". " + idpuerto.getname()+"\n"); //Se examinan todos los puertos disponibles try { idpuerto.getportidentifier("com2"); port = ( SerialPort )idpuerto.open("visualobd",2000); port.setserialportparams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //Se abre el puerto seleccionado catch (PortInUseException e) { e.printstacktrace(); System.out.println("Puerto en uso."); catch (NoSuchPortException e) { e.printstacktrace(); System.out.println(e); catch (UnsupportedCommOperationException e) { e.printstacktrace(); System.out.println(e); 41

42 public void enviar(){ temps=new Date(); int data; try { DadesEscriu = port.getoutputstream(); for(int i=0;i<ordre.length();i++){ data= ordre.codepointat(i); System.out.println(data); DadesEscriu.write(data);//Se escribe en el Puerto serie if((i+1) == ordre.length()){ DadesEscriu.write(13); //Solamente necessita el retorno de carro, //sin el salto de linea. System.out.println("Enviat atz:"); catch (IOException e) { e.printstacktrace(); System.out.println(e); public void recibir(){ respuesta=new StringBuffer(); while((timer()-temps.gettime())<3000){ char z; int reb=0; try { FluxDades = port.getinputstream(); while(reb>-1){ reb=fluxdades.read();//se lee el Puerto serie z=(char) reb; respuesta.append(z); System.out.println(respuesta);//Se imprime la respuesta por consola port.close(); catch (IOException e) { e.printstacktrace(); System.out.println(e); public static void main(string[] args) { Principal prin=new Principal(); prin.conectar(); prin.enviar(); prin.recibir(); public long timer(){ temps2 = new Date(); return temps2.gettime(); 42

43 Estructuralmente el programa se asemeja al diseño en C++, y por tanto implementa métodos funcionalmente muy parecidos: 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. 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. Unos ejemplos de trama de datos y su tratamiento sería el siguiente: Comando a enviar: atz -> equivalencia código ASCII: 97,116,122 Este comando sirve para hacer un reset del micro. Se le añade a la trama el retorno de carro para indicar fin de trama: atz\r ->código ASCII: 97,116,122,13 y el método write() de la clase SerialPort la envía al puerto serie. Trama recibida del puerto serie atreves del método read() de la clase SerialPort: 97,116,122,13,10,69,76,77,51,50,55,32,118,49,46,49,32,99,111,109,112, 97,116,105,98,108,101,13,10,62,-1 Equivalencia de la trama según el código ASCII: atz ELM327 v1.1 compatible El último número (-1), indica que no se está recibiendo ningún dato, y sirve como referencia para saber que la trama ha finalizado, además el micro marca el fin de la trama con el numero 62 ( equivalente a > ). 43

44 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 J1850 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: 6A F C 0B 88 0A -> Respuesta ECU 01 0C -> Respuesta 6A 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,1 0,62,-1 44

45 Por tanto en la respuesta obtenida podemos diferenciar que: 010C: Comando requerido 6A F1 61: Cabecera de la trama(especifica direcciones de memoria, prioridades, tipo de conexión, etc..) 410C: Confirmación de que se ha contestado al comando requerido sumando 40 a 01, quedando 410C. 0B 88: El dato que interesa para calcular las rpm. Según el documento OBD Pid s anteriormente mencionado, si pasamos a decimal estos valores quedando en 11 y 136, y aplicamos esta fórmula (( A 256) + B) ( ) = = 738, obtenemos las revoluciones por 4 4 minuto del motor a tiempo real. 0A: Chequeo de redundancia cíclica de la trama (CRC). 45

46 2.5. Diseño de la aplicación grafica diseñada en JAVA El diseño final y definitivo de este proyecto consistía en realizar un software multiplataforma diseñado mediante la conocida estructura de programación por capas, para poder 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, entorno grafico y el potencial que aporta un entorno visual diseñado con JAVA, 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. Este software intenta ser compatible con cualquier plataforma que disponga de una conexión USB o RS-232, de ahí su implementación mediante JAVA, pero debido a que para realizar las comunicaciones con dichos puertos se ha utilizado un librería nativa (RXTXcomm.jar), es posible que existan algunas incompatibilidades de un plataforma a otra, cosa que se debería consultar en la web de RXTXcomm. Básicamente el programa ofrece cinco apartados bien diferenciados: La pantalla principal de inicio: Es la ventana que vemos cuando inicia el programa, en ella realizamos y vemos las operaciones principales, como son realizar la conexión/desconexión con la interface y siempre viendo en una consola de texto los datos que se están enviando y recibiendo a tiempo real. La opción de configuración del puerto: En esta sección del programa podemos configurar todos los parámetros necesarios del puerto serie, para poder realizar una conexión. La opción de selección del protocolo de comunicación: Esta funcionalidad del programa permite que el usuario pueda elegir manualmente el protocolo con el que se quiere comunicar con la ECU de su vehículo. La opción de Lectura de códigos de error: Esta opción ofrece la posibilidad de poder averiguar si nuestro vehículo ha sufrido o sufre algún fallo técnico, a través de la obtención de un código identificativo que especifica la avería y que proporciona la ECU. La opción de mediciones a tiempo real: Esta parte del programa proporciona información de los diferentes sensores de los que dispone el motor de nuestro vehículo, mostrando datos como la temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. 46

47 Para realizar el software se utilizó la estructura de programación por capas: capa de datos, capa de dominio y capa de presentación. Cada capa tiene una función dentro del programa y una serie de clases que cumplen con la función que se les ha asignado. A continuación se explica la función y clases que contiene cada capa: 1. Capa de Datos: Es la encargada de gestionar todas las tramas de datos que se intercambian la computadora y la interface. Su objetivo es recoger ya sean datos recibidos o enviados, adecuarlos y tratarlos para poder o bien mandárselos a la interface a través del puerto serie o recibirlos y mandárselos a las capas superiores. En esta capa podemos encontrar las siguientes clases: 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. 2. Capa de Dominio: Es la encargada de hacer de intermediario entre la capa de datos y la inmediatamente superior a la de dominio, que en este caso es la de presentación. Ofrece la capacidad de trabajo de la capa de datos, de una forma mucho más accesible para sus capas superiores. En esta capa encontramos la clase ControladorDominioConexión, la cual contiene todos los métodos necesarios para manejar todas las clases que se encuentran en la capa de datos. 47

48 Capa de Presentación: Esta capa se encarga de gestionar toda la parte visual del programa y contiene todas las clases y controladores necesarios para poder llevar a cabo esta tarea. Concretamente estas son las clases que contiene: 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. Por lo extenso del código de este último programa, se incorporará al final del proyecto como documento adjunto. En esta aplicación la clase más importante y difícil de desarrollar es la clase ControladorConexion, ya que es la que capacita al software de la capacidad de utilizar varios hilos de ejecución. Esta clase implementa la interface Runnable con su respectivo método Run(), el cual está en permanente escucha a los mensajes que se envían desde el puerto serie, y por tanto permite liberar al hilo principal para poder realizar otras funciones simultáneamente. Otra de las clases que implementa un nuevo hilo de ejecución es la clase ControladorMediciones, la cual se encarga de mostrar los datos de la lectura a tiempo real de los diferentes sensores de los que dispone la centralita en el vehículo. Por tanto en la aplicación trabajan 3 hilos de ejecución: Hilo principal: Se mantiene a la espera para realizar las funciones que reclame el usuario. Hilo de la clase ControladorConexion: Escucha permanentemente el puerto serie consiguiendo así no perder ningún posible dato y una velocidad de respuesta mucho más alta. Hilo de la clase ControladorMediciones: Refresca constantemente en pantalla los datos que va recibiendo el método run() de la clase ControladorConexión. 48

49 Cuando se procedió a probar el software sobre diferentes sistemas operativos con la intención de asegurar su funcionalidad, ventaja que tiene JAVA sobre otros lenguajes ya que utiliza una maquina virtual, se observó que en Windows funcionaba correctamente ya que sobre este se había realizado la programación, pero sobre Linux se obtuvo un resultado inesperado. Se observó que en Linux el programa arrancaba y funcionaba de forma correcta, pero en el momento que se procedía a desconectarlo del puerto serie el programa quedaba totalmente bloqueado. Después de muchas pruebas se averiguó que las librerías nativas RXTXcomm.jar que utiliza esta aplicación se comportaban de diferente forma según el sistema operativo en el que estuviéramos trabajando. El problema se encontraba en el método run() de la clase ControladorConexión(), ya que este utiliza la clase SerialPort constantemente para escuchar el puerto serie. Observando el siguiente fragmento de código podemos hacernos una idea de la situación: public void run(){ boolean datos=false; String tramarecibida; Thread thisthread = Thread.currentThread(); while(hilo == thisthread){ char z; int longitudtrama=0; int reb=0; try { datosrecibidos = port.getinputstream(); while((reb=datosrecibidos.read())>-1){ z=(char) reb; if(reb==62){ break; if(reb!=-1){ tramarecibidainicial.append(z); DestruirHilo=true; catch (IOException e1) { estado("no response."); Vemos que la línea subrayada, datosrecibidos.read(), es la orden que se encarga de acceder al puerto y cuando el hilo de ejecución llega a ella en Windows la lee una vez y sigue su transcurso dentro del método run() hasta el siguiente ciclo de bucle donde lo volvería a leer, pero en Linux no sucede los mismo, el hilo de ejecución se detiene en esta línea esperando un nuevo mensaje del puerto y por tanto bloqueando su posible cierre desde el hilo principal, es decir, como el hilo que se ejecuta en run() nunca libera al objeto port, cuando accedemos al mismo objeto desde el hilo principal de la clase este provoca un bloqueo de la aplicación ya que nunca tendrá permiso para cerrarlo. Esto se solucionó enviando un mensaje cualquiera al puerto y cambiando en el mismo instante la condición del bucle while (hilo=null), para que el hilo de run() saliese de su estado de escucha y acabara extinguiéndose ya que la condición del bucle ya no se cumplía. 49

50 Como aporte final a esta aplicación se procedió a empaquetarla en un archivo.jar, lo que facilita mucho su puesta en marcha y portabilidad a cualquier otra plataforma o sistema operativo. Pero uno de los inconvenientes que presentaba esta aplicación era que para poder comunicarse con los puertos de comunicación necesitaba la librería nativa RXTXcomm, y por tanto, 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 resulta ser un problema, pero si para alguien que solo quiera hacer unas cuantas pruebas. La solución fue crear una carpeta donde se introduciría el archivo JAR, los archivos adjuntos necesarios como los JPG y TXT, y otra carpeta donde incluiríamos la librería nativa RXTXcomm. 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. La carpeta se llama VisualOBDJar y contiene los siguientes archivos: VisualOBD.jar: Archivo comprimido que contiene todo el código de la aplicación. RunLinux.sh: Archivo ejecutable para Linux. RunWindows.bat: Archivo ejecutable para Windows. VisualOBD4_1 y AboutVisualOBD: Archivos de tipo JPG. CodigodErrores.txt: Archivo de texto utilizado como base de datos. Leeme.txt: Archivo de texto que contiene una breve explicación de cómo arrancar el software. lib: Carpeta que contiene la librería nativa RXTXcomm con los respectivos archivos rxtxparallel.dll, rxtxserial.dll, librxtxserial.so, y librxtxparallel.so necesarios para realizar su carga en el sistema operativo través de la máquina virtual. 50

51 Para poder realizar la carga de la librería nativa correctamente se tuvo que modificar el archivo MANIFEST que contiene el paquete VisualOBD.jar quedando de la siguiente forma: Y a los archivos RunWindows.bat y RunLinux.sh se les introdujo los siguientes comandos: 51