Aplicación distribuida para la monitorización y diagnosis de automóviles

Texto completo

(1)

(2) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Índice 1.. Resumen .................................................................................................................................. 1. 2.. Abstract.................................................................................................................................... 3. 3.. Introducción ............................................................................................................................. 5. 4.. Diagnosis de automóviles ........................................................................................................ 7. 5.. 6.. 7.. 4.1.. Introducción ..................................................................................................................... 7. 4.2.. Diagnosis electrónica ....................................................................................................... 8. 4.3.. Estado del arte ................................................................................................................ 14. Estándares para la diagnosis del motor en automóviles ........................................................ 17 5.1.. Historia ........................................................................................................................... 17. 5.2.. Redes y protocolos de comunicación ............................................................................. 24. 5.3.. Parámetros almacenados ................................................................................................ 29. 5.4.. Memoria de averías ........................................................................................................ 30. El microcontrolador ELM327 ............................................................................................... 33 6.1.. Introducción ................................................................................................................... 33. 6.2.. Comandos ....................................................................................................................... 36. Diseño del software ............................................................................................................... 47 7.1.. Introducción ................................................................................................................... 47. 7.2.. Diseño gráfico ................................................................................................................ 47. 7.3.. Distribución de la aplicación .......................................................................................... 50. 7.4.. Modelado UML.............................................................................................................. 50. 7.4.1.. Diagrama de casos de uso ....................................................................................... 50. 7.4.2.. Diagrama de despliegue .......................................................................................... 51. 7.4.3.. Diagramas de clases ................................................................................................ 51. 7.4.4.. Diagrama de secuencia ........................................................................................... 56.

(3) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 8.. Desarrollo y pruebas .............................................................................................................. 57. 9.. Conclusiones .......................................................................................................................... 67. 10. Referencias ............................................................................................................................ 69 11. Biografía ................................................................................................................................ 71 12. Listado de acrónimos ............................................................................................................. 73 13. Anexo..................................................................................................................................... 75 13.1.. Listado de comandos AT para ELM327 ..................................................................... 75. 13.2.. Tabla de PIDs del modo 01 ........................................................................................ 77. 13.3.. Listado de códigos de error (DTCs) ........................................................................... 85. 13.4.. Ejemplo de uso de la librería RXTXcomm .............................................................. 131.

(4) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 1.. Resumen. En este proyecto se va desarrollar una aplicación distribuida para la diagnosis y monitorización de automóviles. Se pretende poder realizar estas funciones en prácticamente cualquier automóvil del mercado (con fabricación a partir del año 1996 para el caso de automóviles gasolina y para el año 2000 en el caso de automóviles diésel) de manera remota, aprovechando la conectividad a Internet que actualmente brindan la mayoría de los smartphones. La viabilidad del proyecto reside en la existencia de estándares para la diagnosis de la electrónica del motor. Para poder llevar a cabo esta tarea, se empleará una interfaz de diagnóstico ELM327 bluetooth, que servirá de enlace entre el vehículo y el teléfono móvil del usuario y que a su vez se encargara de enviar los datos que reciba del vehículo a un terminal remoto. De esta manera, se tendrá la aplicación dividida en dos partes: por un lado la aplicación que se ejecuta en el terminal móvil del usuario que actuará como parte servidora, y por el otro la aplicación cliente que se ejecutará en un terminal remoto. También estará disponible una versión de la aplicación servidora para PC. El potencial del proyecto reside en la capacidad de visualización en tiempo real de los parámetros más importantes del motor del vehículo y en la detección de averías gracias a la funcionalidad de lectura de la memoria de averías residente en el vehículo. Así mismo, otras funcionalidades podrían ser implementadas en posteriores versiones de la aplicación, como podría ser el registro de dichos parámetros en una base de datos para su posterior procesado estadístico; de este modo se podría saber el consumo medio, la velocidad media, velocidad máxima alcanzada, tiempo de uso, kilometraje diario o mensual…y un sin fin de posibilidades.. Figura 1. Estructura del sistema.. Página 1 | Resumen.

(5)

(6) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 2.. Abstract. In this project a distributed application for car monitor and diagnostic is going to be developed. The idea is to be able to connect remotely to almost any car (with production starting in 1996 in the case of petrol engines and production starting in 2000 in case of diesel engines) using the Internet connection available in almost every smartphone. The project is viable because of the existence of standards for engine electronic unit connection. In order to do that, an ELM327 bluetooth interface is going to be used. This interface works as a link between the car and the smartphone, and it is the smartphone which sends the received data from the car to a remote terminal (computer). Thus, the application is divided into two parts: the server which is running on smartphone and the client which is running on a remote terminal. Also there is available a server application for PC. The potential of the project lies in the real-time display data capacity of the most important engine parameters and in the diagnostic capacity based on reading fault memory. In addition, other features could be implemented in later versions of the application, as the capacity of record data for future statistic analysis. By doing this, it is possible to know the average fuel consumption, average speed, maximum speed, time of use, daily or monthly mileage…and an endless number of possibilities. You can find the structure of the system on figure 1.. Página 3 | Abstract.

(7)

(8) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 3.. Introducción. Como se ha comentado en el apartado anterior, se pretende realizar el diagnóstico remoto de un vehículo mediante el desarrollo de una aplicación distribuida. Para ello, se utilizará Java como lenguaje de programación, por su versatilidad y compatibilidad multiplataforma, lo que permitirá además poder trabajar con stmartphones corriendo el sistema operativo Android. Por tanto, en este proyecto el desarrollo es puramente software, aprovechando equipos hardware que se encuentran en el mercado. En concreto, intervienen tres componentes hardware: la interfaz de diagnóstico ELM327 bluetooth, un smartphone y un terminal remoto (ordenador). Esta interfaz se basa en un microcontrolador desarrollado por ELM Electronics, que a su vez se ayuda de otros componentes electrónicos que, unidos bajo la misma PCB (Printed Circuit Board), permiten la conexión con el vehículo a través de la toma de diagnóstico OBD-II (Onboard diagnostic II) de 16 pines. Este microcontrolador responde a comandos serie (comandos AT) que recibe por bluetooth y se encarga de generar las tramas de datos en las que incluye las peticiones al vehículo, siguiendo los diferentes estándares que existen para este tipo de comunicaciones. Tras esta breve introducción, se pasarán a explicar conceptos sobre la diagnosis de vehículos que den sentido y valor a la finalidad del mismo, junto con un estudio del estado del arte. Acto seguido, ya introducidos los conceptos básicos, se tratarán los diferentes estándares existentes para la diagnosis de vehículos, es decir, se hablará de los protocolos de comunicación disponibles, las redes que los soportan y de los datos que se pueden obtener del vehículo mediante el uso de estos protocolos basados en un sistema de consulta/respuesta. Estos datos son básicamente parámetros del motor del vehículo y códigos de avería. Pero no todas las peticiones que se harán al vehículo serán de lectura de información, también se implementará la funcionalidad de borrado de la memoria de averías, para eliminar del registro de una avería subsanada o una avería esporádica. Una vez entendido el sistema de diagnosis que incorporan los vehículos, se hablará del microcontrolador ELM327, que juega un papel esencial en el sistema actuando como interfaz entre los dispositivos habituales y el vehículo. A continuación se explicará el diseño software que se ha seguido, entrando en detalle en la implementación que permitirá hacer posible todo lo explicado anteriormente usando los. Página 5 | Introducción.

(9) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. componentes hardware citados. Se presentará un diseño basado en UML (Unified Modeling Language) que permita entender el funcionamiento de la aplicación en detalle mediante diagramas de clases o de secuencia. Así mismo, se hablará de la parte gráfica de la aplicación y de su distribución. Tras explicar el diseño software, serán presentadas las pruebas realizadas de manera simultánea al desarrollo del proyecto y las pruebas finales, así como las conclusiones a las que se ha llegado tras el desarrollo del mismo. Por último, se incluye un apartado biográfico para aquellos lectores que quieran aclarar o ampliar algún concepto de los tratados en este proyecto.. Página 6 | Introducción.

(10) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 4.. Diagnosis de automóviles. 4.1.. Introducción. La diagnosis de automóviles es un gran desconocido para la mayoría de los usuarios, quien normalmente únicamente tiene el conocimiento de que el taller “conecta un ordenador al coche” cuando éste presenta algún aviso luminoso en el cuadro de instrumentos. Lo cierto es que en términos generales no andan muy desencaminados, sin embargo con consideraciones así se estaría navegando en la superficie de algo que en realidad es muy profundo. Actualmente las crecientes demandas de seguridad, eficiencia y fiabilidad han llevado a una alta complejidad técnica en los automóviles del mercado. Hasta los años 70 el mantenimiento de estos vehículos era comúnmente realizado por su propietario o en talleres pequeños, siguiendo un método de comprobación rudimentario basado en probar si algo funciona poniéndolo en marcha. El método era eficaz y suficiente hasta la época por la simplicidad de los sistemas, en los que la electrónica no estaba apenas presente. Fue en esta fecha cuando surgió la preocupación por disminuir la contaminación y aumentar el rendimiento y potencia de los motores, a lo que progresivamente se iría uniendo después la preocupación por la seguridad del conductor como consecuencia de este aumento. Esta evolución ha desembocado en la situación actual, donde sofisticados sistemas electrónicos tienen presencia en el automóvil y es necesario disponer de equipos y profesionales especializados para llevar a cabo las tareas de mantenimiento y reparación. Las tecnologías asociadas a la diagnosis han ido evolucionando de manera paralela a las tecnologías del automóvil. En este sentido, la diagnosis ha ido pasando por diversas etapas, partiendo de una etapa inicial en la que, como ya se ha comentado, las comprobaciones se limitaban a los sistemas más críticos y se hacían de forma rutinaria, y donde los materiales eran limitados y por tanto el factor humano era fundamental, hasta la etapa actual, donde la diagnosis del vehículo es integral, es decir: comprende todos los sistemas del mismo. Esta diagnosis integral, es definida en más detalle como la verificación y evaluación del funcionamiento del conjunto de sistemas del vehículo basadas en pruebas objetivas con la amplitud y precisión máximas que permiten las tecnologías de ensayo y verificación actuales, atendiendo a las restricciones que imponen el coste, el tiempo máximo dedicado al conjunto de las pruebas y la mínima intrusión en los elementos mecánicos del vehículo [1].. Página 7 | Diagnosis de automóviles.

(11) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 2. Ejemplo de diagnosis del automóvil realizada en los primeros años (1940-70). Con la diagnosis integral se pretende comprobar el estado del vehículo respecto a sus condiciones originales, con vistas a detectar cualquier problema que pudiera existir o haber existido. De esta forma, no sólo se facilita el mantenimiento preventivo si no que se lleva a cabo un registro de los problemas que ha tenido o tiene el vehículo, lo cual puede ayudar a mejorar para futuros diseños.. 4.2.. Diagnosis electrónica. La finalidad de este documento es tratar la diagnosis electrónica, es decir, aquella parte de la diagnosis integral que se lleva a cabo de forma electrónica, gracias a la electrónica tanto de los vehículos como de las herramientas de diagnóstico. Antes de adentrarse en profundidad en la diagnosis electrónica, se considera conveniente explicar los sistemas electrónicos del vehículo. Estos sistemas se podrían dividir en tres componentes hardware: sensores, actuadores y unidades de control (ECUs - Electronic Control Units).. Página 8 | Diagnosis de automóviles.

(12) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Los sistemas electrónicos incorporados en el vehículo están continuamente recogiendo datos mediante sensores, y serán las unidades de control las que procesen esa información recibida de los sensores en base a parámetros prefijados para la posterior toma de decisiones. Por tanto, estamos hablando en todo momento de sistemas programados, y es importante señalar que estos sistemas son cruciales puesto que deben tomar decisiones críticas cuestión de milisegundos, estando en juego no sólo la integridad del vehículo sino también la del propio conductor.. Figura 3. Aspecto físico de una ECU de gestión de motor. Estas unidades de control son centralitas electrónicas independientes, se encargan de controlar los distintos subsistemas y están interconectadas entre sí y conectadas a su vez con los actuadores correspondientes a cada una de ellas (del subsistema que gobiernan). Estos subsistemas pueden ser: sistema de frenado airbag, iluminación, motor/inyección… En el caso de detectarse cualquier anomalía, las unidades de control toman las decisiones pertinentes, que pueden ir desde la desconexión de un actuador, sensor o sistema completo, hasta el registro de la propia avería en el registro de averías.. Página 9 | Diagnosis de automóviles.

(13) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 4. Esquema de unidades de control que pueden encontrarse en un coche actual. En el caso de avería en el motor, lo más común es que se active el testigo de avería de motor o MIL (Malfunction Indicator Lamp). Este indicador, que también puede ser llamado check engine light, incluye tres tipos de presentación: •. Destellos ocasionales: cuando el defecto de funcionamiento es momentáneo. Si el defecto es de naturaleza más grave (afectando al producto de emisiones de gases o a la seguridad del vehículo) el parpadeo es más continuo.. •. Destellos constantes: es indicativo de que existe un problema que puede causar un daño serio al motor si éste no es parado inmediatamente. En este caso se detiene el registro de las lecturas de los sensores (denominado freeze frame) y. Página 10 | Diagnosis de automóviles.

(14) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. se almacenan las últimas lecturas en la memoria del ordenador central del vehículo (MCU- Main Control Unit) 1. •. Destello fijo: ocurre cuando se presentan problemas muy graves, y permanece activo mientras el vehículo esté funcionando y no se subsane el problema, siendo necesario en algunos casos el posterior borrado de la memoría de averías.. En este proyecto se trabaja con la MCU o unidad de control de motor, ya que es la única a la que se puede acceder de forma estandarizada. En la figura 5 pueden verse de forma gráfica algunos conceptos tratados hasta ahora en este capítulo de introducción:. Figura 5. Elementos del automóvil que intervienen en la diagnosis. En esta imagen se puede observar un término que aún no se había mencionado: DLC (Data Link Connector). Éste es el conector de diagnóstico mediante el cual es posible conectar el. 1. Dependiendo de la bibliografía es común encontrarse con que la ‘MCU’ es nombrada ‘ECU de control de motor’ o simplemente ‘ECU’.. Página 11 | Diagnosis de automóviles.

(15) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. coche a un equipo de diagnosis externo. Actualmente se trata de un conector de 16 pines denominado de manera estandarizada J1962 o conector OBD-II.. Figura 6. Estructura del conector de diagnosis OBD-II. Por tanto, los sistemas de diagnosis electrónica incorporan tanto elementos hardware (tarjetas electrónicas o ECUs y buses de comunicación) como de software (algoritmos de supervisión e interpretación de las múltiples señales implicadas). Estos sistemas se pueden clasificar en dos grandes categorías: •. On-board Diagnosis Systems (Sistemas de a bordo o internos).. •. Off-board Diagnosis Systems (Sistemas externos).. Ambas no son excluyentes sino que se complementan. Para el primer caso no es necesario disponer de ninguna herramienta, el propio coche alerta en el cuadro de instrumentos de la presencia de un error; mientras que en el segundo caso la diagnosis se realiza empleando una Página 12 | Diagnosis de automóviles.

(16) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. herramienta de diagnosis externa. Es en éste último caso cuando es posible obtener con precisión el error registrado, ya que en el caso de On-board Diagnosis se utiliza un mismo testigo de aviso (MIL) para numerosos códigos de error, sin proporcionar más información acerca del código detectado. La On-board Diagnosis también se utiliza para mostrar avisos de anomalías básicas, como podría ser ‘nivel de carburante bajo’ o ‘puerta abierta’. Este proyecto se centra en los Off-board Diagnosis Systems. En la figura 7 y en la figura 8 pueden verse ambos sistemas.. Figura 7. Ejemplo de On-board Diagnosis en un coche VW Golf de 2002.. Figura 8. Ejemplo de Off-board Diagnosis de BOSCH.. Página 13 | Diagnosis de automóviles.

(17) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 4.3.. Estado del arte. En la actualidad existen muchas herramientas de diagnosis (refiriéndose a Off-board Diagnosis) que se conectan al vehículo mediante el DLC. En algunos casos se componen de una interfaz de conexión con el vehículo que se apoya en un software para ordenador o smartphone, y otros incorporan una consola en la propia interfaz de conexión. En la figura 9 se muestra un ejemplo de herramienta con consola incorporada:. Figura 9. Ejemplo de máquina de diagnosis con consola incorporada. Mientras que, como ya se ha comentado, el otro tipo de herramientas necesitan apoyarse en otros elementos como un PC o smartphone para compensar la ausencia de consola integrada, presentando la siguiente estructura representada en la figura 10.. Figura 10. Estructura de una máquina de diagnosis sin consola incorporada. Página 14 | Diagnosis de automóviles.

(18) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Este proyecto comprende este último caso, con la salvedad de que para la conexión serie en el PC se utiliza la tecnología bluetooth, y éste puede ser sustituido por un smartphone.. Figura 11. Ejemplo de máquina de diagnosis sin consola incorporada. Sin embargo, la mayoría de estas herramientas de Off-board Diagnosis actúan en modo local, el concepto de diagnosis remota (relacionado con la tercera generación de diagnosis de a bordo (OBD-III) que se explica en el apartado 5.1) no está tan extendido. El único ejemplo que se ha encontrado es el de la compañía LAUNCH, que está desarrollando un sistema de diagnosis remota llamado golo. La descripción del producto, extraída de su web [2], es la siguiente: “Es un dispositivo y una plataforma desarrollada por LAUNCH para construir una red social entre usuarios, mecánicos y talleres. Con la red golo obtendremos información y datos del vehículo, ofreciendo al usuario la posibilidad de hacer un chequeo básico de su coche, una diagnosis remota en tiempo real por el taller, o enviar una alarma por avería. La aplicación golo también ofrece un servicio de mensajería instantánea, red social y servicios de ubicación para crear una plataforma global para el mantenimiento y control del vehículo. Con golo estaremos vinculados a nuestro taller de confianza haciendo que cualquier problema que suceda en nuestro vehículo se informe de inmediato a nuestro taller.”. Página 15 | Diagnosis de automóviles.

(19) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Por tanto la finalidad de golo es la diagnosis remota del vehículo por parte del taller mecánico que corresponda, aparte de constituir una red social. La finalidad es similar a la de este proyecto, pero aquí no se pretende crear una red social y aunque el alcance del proyecto no lo permita, la idea es avanzar en otro camino, creando una herramienta estadística o posible caja negra. Además, podría crearse una herramienta que no necesite un teléfono móvil, sino que incorporase un módulo GPRS (con una tarjeta SIM) que envíe directamente los datos a través de internet. Esto podría ser realizable incluso añadiendo un simple Arduino al ELM327, por lo que resultaría viable en un entorno no industrial como en el que se ha desarrollado este proyecto.. Página 16 | Diagnosis de automóviles.

(20) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 5.. Estándares para la diagnosis del motor en automóviles. 5.1.. Historia. Hasta los años 80 la diagnosis de los automóviles se realizaba casi exclusivamente en los talleres mecánicos (diagnosis visual), y dada la escasa incorporación de sistemas electrónicos en los vehículos, la diagnosis electrónica de sentido. Por aquellas fechas no estaba estandarizada la y tampoco los fabricantes estaban obligados a incorporar sistemas electrónicos para realizarla. La misión del sistema de diagnosis era informar al conductor de algunas anomalías, tales como el estado del motor (temperatura, nivel de aceite) y nivel de combustible, pero nada al respecto del estado sobre los diferentes elementos que incorporaban los vehículos [3]. La diagnosis electrónica se puede decir que nace a inicios de los años 80 (si bien las investigaciones habían comenzado en los años 70), cuando los fabricantes de automóviles empiezan a incorporar dispositivos electrónicos para realizar las funciones de control del motor. La razón fundamental que forzó esta incorporación de dispositivos electrónicos fue la de tener que cumplir con los requerimientos de la Agencia de Protección del Medioambiente (EPA- Environmental Protection Agency) de los Estados Unidos. Para cumplir con el estándar, los fabricantes de automóviles incorporaron motores de inyección electrónica, y con ellos se fueron integrando diferentes sensores para medir el comportamiento de los motores y ajustar en lo posible su funcionamiento con el fin de lograr la mínima polución [3]. A mediados de 1980 organismos reguladores como la Sociedad de Ingenieros de Automóviles (SAE-Society Automobile Engineering) de USA empezaron a considerar que la diagnosis debía contribuir a la reducción de las emisiones de gases producidas por ciertos fallos causados en los automóviles. Por esta razón, decidieron definir estándares que los fabricantes de los automóviles debían tener en cuenta para llevar a cabo la diagnosis a través de la lectura de una memoria de averías, y además poder comprobar el estado de funcionamiento de las unidades de control (ECUs). A continuación se detallan las diferentes generaciones estandarizadas relativas a la diagnosis del automóvil, conocidas como OBD (On Board Diagnostic), que nacen en USA y se extienden a Europa y Asia con denominaciones similares. En definitiva, son normas aceptadas e implantadas (algunas en fase de desarrollo) por los diversos fabricantes de automóviles con proyección internacional.. Página 17 | Estándares para la diagnosis del motor en automóviles.

(21) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. La primera generación de diagnosis de a bordo (OBD-I) data de los comienzos del año 1987, cuando todas las nuevas producciones de vehículos vendidos en California (USA) estaban obligados a incorporar equipos electrónicos que dieran respuesta a las demandas realizadas por las organizaciones americanas EPA y SAE. El objetivo subyacente de dicha diagnosis era minimizar la contaminación atmosférica producida por el parque automovilístico, si bien otros objetivos de gran importancia fueron considerados en la diagnosis, como por ejemplo el de poder notificar a los conductores el estado de su vehículo [3]. Con estos precedentes, en 1988 CARB (California Air Resources Board) definió los requisitos de la primera generación de diagnosis de a bordo (OBD-I).De forma resumida estos requisitos eran: •. Incorporar indicadores luminosos de fallos (MIL) para informar al conductor de la existencia de algún tipo de fallo en el vehículo.. •. Disponer de un conector de diagnóstico (DLC) y de manual de interpretación de códigos de fallos (DTC-Data Trouble Code), leídos de la memoria de a bordo del vehículo, para facilitar a los talleres la traducción de los códigos asociados a los componentes defectuosos.. •. Monitorizar la emisión de los gases de escape y relacionar dicha emisión con los fallos de los componentes eléctricos que controlan el funcionamiento del motor. Además debía tener capacidad para almacenar en una memoria (que formaba parte del ECU) a bordo del vehículo las incidencias relacionadas con los fallos [3].. De todo lo anterior se puede concluir que la primera generación de diagnosis de a bordo (OBD-I) fue fundamentalmente concebida para ser aplicada a todos los sistemas que ante un funcionamiento defectuoso contribuían a un incremento significativo de las emisiones de gases. Dentro de este grupo de sistemas se incluían: •. Todos los sensores importantes del motor: temperatura de refrigeración del motor (ECT - Engine Coolant Temperature), temperatura interna del motor (IAT - Intake Air Temperature), posición de la mariposa (TP - Throttle Position), etc.. •. El sistema de medida de nivel de combustible.. •. Sistema de recirculación de los gases de escape (EGR - Exhaust Gas Recirculation) [3]. Página 18 | Estándares para la diagnosis del motor en automóviles.

(22) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. En la figura 12 se muestran de forma resumida los aspectos más importantes incluidos en el OBD-I:. OBD-I. Incorporación del MIL. DLC +Manual de DTCs. Diversos sensores motor. Monitorización. Nivel de combustible. Comprobación de circuitos abiertos y cortocircuitos. EGR. Figura 12. Diagrama de requerimientos del estándar OBD-I.. En resumen, se puede concluir que la incorporación de la tecnología electrónica en el sector del automóvil permitió afrontar la necesidad de reducir la contaminación producida por los vehículos a motor, informar al conductor del estado de los mismos, y reducir en gran medida los tiempos para la detección de fallos [3]. Sin embargo, cada fabricante usaba el protocolo de comunicación o lenguaje que mejor le parecía y esto provocó un sin número de conectores (DLCs), protocolos de comunicación y distintas formas de diagnosticar cada marca y cada tipo de vehículo. Si bien es cierto que se producía una reducción de la contaminación, la confusión generada porque cada fabricante hiciera las cosas a su manera llevó a las entidades gubernamentales a generar normas también en este sentido. Es por eso que partir de los años 90 se desarrolla toda una propuesta que desemboca en lo que se llama diagnosis de a bordo de segunda generación u OBD-II. Entonces se establece por ley un solo conector de diagnóstico trapezoidal de 16 pines y protocolos de comunicación estandarizados [4].. Página 19 | Estándares para la diagnosis del motor en automóviles.

(23) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. La segunda generación de diagnosis de a bordo (OBD-II) surge por la necesidad de mejorar las prestaciones de OBD-I, siendo los propios grupos reguladores los que impulsaron nuevas mejoras, dando así lugar a la segunda generación de diagnosis de abordo (OBD-II) [3]. El rendimiento y efectividad se ve aumentado en gran medida, la diagnosis incorpora más elementos de sensorización y ahora el sistema no sólo avisa cuando una pieza falla sino que se realizan pruebas de rendimiento y se notifica si no se cumplen los requerimientos. Una de las características más importantes, aparte de la mejora en todos los sentidos en cuanto a rendimiento y efectividad de la diagnosis, es la estandarización del DLC (ver figura 6) y de los códigos de error (ver apartado 5.4). El segundo nivel de diagnosis de a bordo (OBD-II) se impone de forma masiva a partir de 1996, estando los vehículos de turismo y de mercancías ligeros obligados a incorporar las nuevas funcionalidades. A modo de ejemplo, en la figura 12 se muestran algunos de los sensores y actuadores añadidos al sistema de inyección electrónico de combustible para realizar la diagnosis de a bordo (OBD-II) del mismo. Aquí la unidad de control electrónico principal recibe información de diversos sensores: flujo de aire, ángulo de cigüeñal, interruptor de arranque, sensores de velocidad, etc., y actúa enviando órdenes a los actuadores como la bobina de ignición, la válvula de control, etc. [3].. Figura 13. Indicadores MIL típicos. Una particularidad de la segunda generación de diagnosis de a bordo (OBD-II) es el requisito de que todos los sistemas y componentes relacionados con el sistema de expulsión de gases (escape) deben ser monitorizados para detectar cualquier funcionamiento anómalo en alguno de dichos sistemas o componentes, y que pudieran dar lugar a un incremento significativo en la emisión de gases nocivos (Noxious exhaust-gas). Además, todos los componentes utilizados Página 20 | Estándares para la diagnosis del motor en automóviles.

(24) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. en el control del sistema de escape y los que afectan a la diagnosis deben ser monitorizados [3].. Figura 14. Diagrama de secuencia de los elementos que intervienen en la diagnosis. Es evidente que OBD-II es una versión mejorada de su predecesor OBD-I. Las ECUs son las encargadas de monitorizar el estado de los diferentes subsistemas que conforman el vehículo para identificar y definir los diferentes fallos; además se encargan de avisar al conductor (mediante el MIL) del posible funcionamiento anómalo de alguno de los componentes del vehículo, y proporcionar los códigos de error y datos identificativos correspondientes. Estos datos permiten determinar con precisión el componente que está fallando, permitiendo un ahorro de tiempo y coste en su subsanación. Este ahorro es muy significativo si se compara con los métodos tradicionales utilizados en la reparación del automóvil basados en “comparar y cambiar” (guess-and-replace repairs). Es importante destacar que mientras OBD-I y OBD-II han sido desarrollados y estandarizados por las asociaciones de automóviles y de medioambiente estadounidenses, en Europa se estandarizó un sistema de diagnosis similar al estadounidense OBD-II, y conocido como. Página 21 | Estándares para la diagnosis del motor en automóviles.

(25) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. EOBD-I. Dicho estándar se empezó a aplicar a partir de 2001, y en consecuencia todos los automóviles fabricados en Europa a partir del 1 de enero de 2001 incorporan un sistema de diagnosis de a bordo para monitorizar las emisiones de gases del motor [3]. La tercera generación de diagnosis de a bordo (OBD-III) es conocida como la diagnosis del futuro. El importante avance que están experimentando las Tecnologías de la Información y de las Comunicaciones (TICs) hace que ya se esté caminando hacia un nuevo concepto de diagnosis, en el que los fallos del vehículo son enviados (vía radio terrestre o vía satélite) a un Centro de Soporte Remoto (CSR) que los analiza. El centro se encarga de notificar al cliente las acciones a tomar para solucionar el problema (taller al que se debe dirigirse, etc.).Así mismo, el CSR envía al taller la información necesaria para llevar a cabo la reparación y las pruebas a posteriori (una vez subsanada la avería). También existe una conexión con la Central de Datos donde se almacenan todos los históricos en una base de datos. Todo esto justifica que OBD-III se empiece a conocer como diagnosis remota. Es evidente que la característica más significativa de OBD-III es la capacidad de comunicación del vehículo con el mundo exterior (tanto a corta como a larga distancia). En este sentido se están proponiendo diferentes alternativas tecnológicas y estrategias que permitan leer los datos almacenados por OBD-II y enviarlos a Centros de Atención al Cliente, Centros de Datos, Servicios Móviles de Mantenimiento, etc. [3]. Desde el punto de vista de las comunicaciones, algunas de las propuestas que se están realizando son: •. Lectores en los bordes de carreteras (Roadside readers): Este tipo de tecnología fue probada por la CARB en 1994. Permite leer hasta ocho carriles de tráfico y con velocidades de los vehículos de hasta 160 km/h. Las unidades lectoras a ubicar en los bordes de las carreteras pueden ser fijas o móviles. Cuando la unidad lectora detecta un fallo en un vehículo, tiene la capacidad de enviar el Número de Identificación de Vehículo (VIN - Vehicle Identification Number) más los códigos de los fallos (DTCs) al “centro de procesamiento”.. •. Estaciones de redes locales o satélites (Local Networks or Satellite Stations): Esta tecnología todavía no ha sido probada por la CARB, pero podría permitir la localización y servicio de monitorización de vehículos. El sistema está basado en los satélites utilizados para la comunicación en telefonía móvil o para el posicionamiento global de sistemas terrestres dotados del correspondiente receptor. El vehículo recibiría una petición vía radio del centro de supervisión, y aquél enviaría su localización Página 22 | Estándares para la diagnosis del motor en automóviles.

(26) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. (obtenida vía GPS, por ejemplo), la fecha, la hora, los datos de VIN y de OBD-III. El centro de supervisión se encargaría de recibir la información de fallos (DTC) y analizarlos para enviar posibles pruebas adicionales o recomendaciones de reparación a los talleres, reduciendo así el tiempo de respuesta ante fallos [3]. Otros aspectos a tener presentes y que están ligados al concepto de OBD-III, son los relacionados con los estándares y normas. Así, por ejemplo, todas las tecnologías implicadas, incluida la citada relativa a los lectores ubicados en los laterales de las carreteras, requerirán de una licencia de la Comisión Federal de Comunicaciones (FCC), ya que la posibilidad de interferencias con otras señales en la misma banda es considerable. En definitiva, los aspectos relacionados con los operadores comerciales, el cumplimiento de la ley, la jurisdicción entre las agencias de estado, los sistemas de autopista de vehículos inteligentes, etc., se deberán resolver antes de que OBD-III sea una realidad [3].. Figura 15. Etapas significativas en la evolución de la diagnosis estandarizada [3].. Página 23 | Estándares para la diagnosis del motor en automóviles.

(27) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. En Europa se ha desarrollado, en paralelo a las versiones OBD-II y OBD-III americanas, los estándares EOBD y EOBD-II conocidos como la primera y segunda generación del sistema europeo de diagnosis “Enhanced On-board Diagnostics” respectivamente. Se trata de normalizar las prestaciones que los fabricantes deben ofrecer para el acceso a los parámetros de diagnosis e información técnica adicional de un automóvil. En definitiva, tanto el EOBD como el todavía en desarrollo EOBD-II, son adaptaciones de las generaciones de diagnosis americanas, al contexto de la industria europea [3].. 5.2.. Redes y protocolos de comunicación. Como se ha visto en apartados anteriores, existe un fuerte incremento de presencia de la electrónica en la industria del automóvil. Este incremento trae consigo un mayor grado de exigencia para las instalaciones eléctricas, que deben soportar cada vez más elementos conectados a ellas y que pretenden interconectarse entre sí. Esto se traduce en un incremento de tamaño y complejidad, lo cual afecta negativamente al coste de producción, a la habitabilidad, a la fiabilidad y a la búsqueda de averías. La solución ante el problema reside en la reducción del volumen del cableado, empleando lo que se conoce como multiplexado. El multiplexado consiste en intercambiar informaciones entre varios equipamientos sobre un único canal de transmisión. Se trata de colocar en red los diferentes calculadores o centralitas electrónicas que incorpora el vehículo, como si de una red informática se tratase. Este canal único recibe el nombre de bus y por él se intercambian datos y señales de control. Además de las ventajas que se deducen de los inconvenientes de no contar con el multiplexado, se producen otras como las siguientes: •. Evitar la instalación múltiple de sensores. Los valores medidos por algunos sensores pueden ser compartidos por varias unidades.. •. Un enriquecimiento de funciones debido a la posibilidad de comunicación entre las unidades de mando de distintos equipamientos y una mayor coordinación y sincronización.. •. Facilidad de diagnosis mediante el conexionado al bus de un instrumento de diagnosis que funcione con la lógica adecuada.. Para comunicarse entre sí las diferentes unidades de mando y que éstas puedan intercambiarse esos datos y señales de control, hace falta definir tres elementos básicos:. Página 24 | Estándares para la diagnosis del motor en automóviles.

(28) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. •. El soporte por el que circula la información, cualquiera que sea su naturaleza (cables eléctricos, fibra óptica, onda, etc.), se llama bus de información.. •. La magnitud física que soporta la información (tensión, intensidad de corriente, ondas luminosas, ondas de radio, etc.).. •. Las reglas y el formato de transmisión de datos entre los elementos de una red (codificación, velocidad de transmisión, analógica o digital, etc.), denominado protocolo de comunicación.. Figura 16. Comparación de red multiplexada con red no multiplexada. Sin la presencia del protocolo adecuado las centralitas electrónicas no podrían comunicarse correctamente. En este proyecto la interfaz que se usa para comunicarse con el vehículo aísla completamente del protocolo implementado por el fabricante, por lo que simplemente se hablará, sin entrar profundidad, de los tres protocolos más importantes actualmente.. Página 25 | Estándares para la diagnosis del motor en automóviles.

(29) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 17. Necesidad de protocolo de comunicación entre unidades de control. Distintos fabricantes de automóviles desarrollaron sus propios protocolos, aunque lamentablemente incompatibles entre sí. De los varios protocolos existentes, tres destacan en su aplicación en el mundo del automóvil: 1. Protocolo CAN (Controller Area Network). Fue desarrollado por Robert Bosch y se perfila hoy en día como líder mundial en sistemas multiplexados, siendo de gran aceptación por parte de fabricantes. En cuanto a sus características, destacamos: •. Simplicidad de concepción.. •. Alta velocidad, hasta 1Mbits/s.. •. Bajo coste de conexión por estación.. •. Amplio soporte de componentes electrónicos.. •. Eficacia y seguridad en su funcionamiento.. 2. Protocolo VAN (Vehicle Area Network). Fue desarrollado principalmente por dos constructores franceses (el grupo PSA y Renault) e impulsado por el Gobierno francés. Actualmente se encuentra en desuso por parte de estos fabricantes, que lo han sustituido por el protocolo CAN. El protocolo VAN presenta las siguientes características: •. Presenta buenas prestaciones, es simple y económico.. •. Su velocidad de trasmisión es de 250 Kbit/s.. •. Es el protocolo más eficiente. Página 26 | Estándares para la diagnosis del motor en automóviles.

(30) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 3. Protocolo SAE J1850. Desarrollado en EE.UU, es utilizado por fabricantes como Ford, Chrysler o General Motors. Entre sus características destaca: •. Su velocidad de trasmisión es de 41,6 Kbit/s.. •. Es apto sólo para aplicaciones de velocidad baja y media.. •. Es la tecnología más económica, gracias al soporte aportado por GM y Ford, así como de importantes suministradores de componentes (Intel, Motorola, Texas...) determinando su rápida expansión y abaratamiento.. Es importante señalar que en los EE.UU se hizo obligatorio en el año 2008 (para los vehículos fabricados o importados) el uso de un protocolo de comunicación universal para todos los vehículos, por lo menos en lo que a diagnóstico de motor se refiere. Se trata del antes mencionado protocolo CAN.. Figura 18. Ejemplo de red multiplexada. Para entender la necesidad de comunicación entre los elementos electrónicos que incorpora el vehículo, se muestra a continuación el desarrollo de la comunicación en caso de colisión:. Página 27 | Estándares para la diagnosis del motor en automóviles.

(31) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 1. La unidad de airbag hace saltar los airbags e informa a la unidad de motor. 2. La unidad de motor desactiva la bomba de combustible e informa a la unidad de red de abordo. 3. La unidad de red de abordo procede a encender las luces de intermitencia y las luces de habitáculo e informa a la unidad central de confort. 4. La unidad central de confort transmite a las unidades de puertas la orden de desbloqueo de puertas.. Figura 19. Desarrollo de la comunicación en caso de colisión. Sin embargo, a veces el protocolo utilizado para la comunicación entre las unidades electrónicas del vehículo (red de comunicación interna) no es el mismo que el utilizado para la conexión con una herramienta de diagnosis externa. Para la diagnosis, los protocolos más comunes son: •. ISO 9141-2. De forma resumida, se puede decir que es el estándar impuesto por los organismos europeos para satisfacer los requisitos del OBD-II. Con ello CARB aceptó el ISO 141-2 para el OBD-II como requisito fundamental en los vehículos fabricados en Europa y Asia.. Página 28 | Estándares para la diagnosis del motor en automóviles.

(32) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. •. ISO/DIS14230-4 (Keyword Protocol 2000 o KWP2000). Se trata de una versión nueva del protocolo ISO 9141. Es utilizado por fabricantes de todos los continentes, con mayor presencia en Asia y Europa.. •. SAE J1850, que presenta dos variantes: VPW Variable (Variable Pulse Width) y PWM (Pulse Width Modulatión).. •. CAN. Es el menos implementado en la actualidad pero sin duda se trata de la tendencia futura.. 5.3.. Parámetros almacenados. La MCU del vehículo registra numerosos parámetros, así como una memoria de averías. La función que implementa el software desarrollado en este proyecto es la lectura en tiempo real de dichos parámetros, así como las funciones de lectura y borrado de la memoria de averías. Los estándares requieren que cada comando OBD que se envía al vehículo cumpla con un formato establecido. El primer byte enviado (conocido como mode) describe el tipo de dato que se solicita con el comando, mientras que el segundo byte (y posiblemente, un tercero o más) especifica la información que realmente se solicita. Los bytes que siguen después del byte mode son conocidos como parameter identification o bytes numéricos PID. Estos modes y PIDs están descritos en detalle en estándares como el SAE J1979 o el ISO 15031-5 y también pueden ser definidos por los fabricantes de vehículos. El estándar SAE J1979 define actualmente 10 posibles modos de comprobación (modes o test modes), que son: 01 - show current data. 02 - show freeze frame data. 03 - show diagnostic trouble codes. 04 - clear trouble codes and stored values. 05 - test results, oxygen sensors. 06 - test results, non-continuously monitored. 07 - show ‘pending’ trouble codes.. Página 29 | Estándares para la diagnosis del motor en automóviles.

(33) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 08 - special control mode. 09 - request vehicle information. 0A - request permanent trouble codes. No es obligatorio que los vehículos soporten todos los modos, y dentro de ellos, no es obligatorio tampoco soportar todos los posibles PIDs (los primeros vehículos equipados con OBDII soportaban muy pocos). Dentro de cada modo, el PID 00 está reservado para mostrar que PIDs están disponibles en dicho modo y es obligatorio para todos los vehículos. En este proyecto solamente se van a utilizar los modos 01, 03 y 04, que son los más comunes y útiles. Se puede encontrar un listado con todos los PIDs del modo 01 en el apartado 13.2.. 5.4.. Memoria de averías. Como ya se ha comentado, la MCU posee una memoria de averías. En ella se registran las averías indicando como mínimo el código de error que las identifica, y dependiendo del fabricante, otros datos adicionales como parámetros del vehículo en el momento en el que se produjo el error (esto se conoce como freeze frame) o si se trata de una avería esporádica o permanente. Esta memoria puede ser leída y borrada con los modos 03 y 04 respectivamente, y se recomienda implementar en el software de diagnosis una confirmación antes del borrado, puesto que se trata de un proceso irreversible. Las averías están identificadas por un código de error estandarizado. El estándar SAE J2012 de 1996 define un código de cinco dígitos en el cual cada dígito representa un valor predeterminado. Todos los códigos son presentados de igual forma para facilitar su interpretación. Algunos de estos son definidos por este estándar y otros son reservados para uso de los fabricantes. El código tiene el siguiente formato: YYXXX (ej: P0308), donde YY, los dos primeros dígitos, representan la función del vehículo y la organización responsable de definir el código, de acuerdo a la siguiente tabla:. Página 30 | Estándares para la diagnosis del motor en automóviles.

(34) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Tabla 1. Función del vehículo y organización responsable en el DTC. Códigos del tren de potencia (motor y transmisión): P0XXX Genéricos (SAE) P1XXX Específicos fabricante P2XXX Genéricos (SAE) P30XX-P33XX Específicos fabricante P34XX-P39XX Genéricos (SAE) Códigos del chasis (incluye ABS): C0XXX C1XXX C2XXX C3XXX. Genéricos (SAE) Específicos fabricante Específicos fabricante Reservado para uso futuro. Códigos de red de abordo (incluye A/C y airbag): B0XXX Genéricos (SAE) B1XXX Específicos fabricante B2XXX Específicos fabricante B3XXX Reservado para uso futuro. Códigos de comunicación en la red (cableado): U0XXX Genéricos (SAE) U1XXX Específicos fabricante U2XXX Específicos fabricante U3XXX Reservado para uso futuro. El tercer dígito representa una función específica del vehículo: •. 0 - El sistema electrónico completo.. •. 1 y 2 - Control de aire y combustible.. •. 3 - Sistema de encendido.. •. 4 - Control auxiliar de emisiones.. •. 5 - Control de velocidad y ralentí.. •. 6- Circuito de salidas de la ECU.. •. 7 y 8- Transmisión.. El cuarto y quinto dígito sirven para definir con detalle el error encontrado, dentro de la clasificación anterior. Por ejemplo, el código P0308 indica un problema en la electrónica de motor (P) definido por SAE (0) y común a cualquier vehículo, que relacionado con el sistema de encendido (3) y concretamente representa un problema en el cilindro 8 (08).. Página 31 | Estándares para la diagnosis del motor en automóviles.

(35)

(36) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 6.. El microcontrolador ELM327. 6.1.. Introducción. Casi todos los automóviles producidos hoy en día requieren disponer, por ley, de una interfaz de conexión para un equipo de diagnosis externo. La transmisión de datos en estas interfaces sigue varios estándares, pero ninguno de ellos es directamente utilizable por PCs o smartphones. El ELM327 está diseñado para actuar como puente entre esa interfaz o puerto OBD-II y una interfaz serie RS232 estándar. Producido por ELM Electronics, el ELM327 es un microcontrolador programado que además de ser capaz de detectar e interpretar de manera automática nueve protocolos OBD, proporciona soporte para comunicaciones de alta velocidad, un modo low power sleep y compatibilidad con el estándar J1929 para camiones y autobuses. Además, es completamente configurable, en caso de que se desee modificar para ajustarse a necesidades concretas. Basado en el microcontrolador PIC18F2480 de Microchip Technology, es una de las interfaces PC-OBD más conocidas e implementadas del mercado. En resumen, el ELM327 abstrae la programación de bajo nivel y presenta una interfaz sencilla que se puede llamar a través de una UART, típicamente por una herramienta de diagnóstico o un programa informático (como es el caso que se trata en este proyecto) mediante una conexión serie RS232. Estas herramientas o programas pueden implementar las siguientes funciones: •. Lectura de parámetros en tiempo real.. •. Lectura de la memoria de averías.. •. Borrado de la memoria de averías.. El ELM327 soporta 12 protocolos diferentes (dos de ellos ajustables por el usuario): 0 - Automatic. 1 - SAE J1850 PWM (41.6 kbaud). 2 - SAE J1850 VPW (10.4 kbaud). 3 - ISO 9141-2 (5 baud init, 10.4 kbaud).. Página 33 | El microcontrolador ELM327.

(37) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 4 - ISO 14230-4 KWP (5 baud init, 10.4 kbaud). 5 - ISO 14230-4 KWP (fast init, 10.4 kbaud). 6 - ISO 15765-4 CAN (11 bit ID, 500 kbaud). 7 - ISO 15765-4 CAN (29 bit ID, 500 kbaud). 8 - ISO 15765-4 CAN (11 bit ID, 250 kbaud). 9 - ISO 15765-4 CAN (29 bit ID, 250 kbaud). A - SAE J1939 CAN (29 bit ID, 250* kbaud). B - USER1 CAN (11 bit ID, 125 kbaud). C - USER2 CAN (11 bit ID, 50 kbaud). Aunque no es objetivo de este proyecto profundizar en la parte hardware, en la figura 20 se muestra un diagrama de bloques de la interfaz ELM327 que puede servir al lector como ayuda a entender la estructura y funcionamiento de la misma:. Figura 20. Diagrama de bloques del ELM327. Así mismo, en la figura 21 se muestra un ejemplo de PCB implementando el microcontrolador de ELM Electronics:. Página 34 | El microcontrolador ELM327.

(38) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 21. Ejemplo de PCB de ELM327 con PIC18F2480 y módulo Bluetooth (BC417+29lv800c). El aspecto final que podría tener la interfaz se muestra en la figura 22:. Figura 22. Aspecto físico de una interfaz ELM327.. Página 35 | El microcontrolador ELM327.

(39) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. 6.2.. Comandos. La interfaz ELM327 reconoce un tipo de comandos denominados comandos AT o comandos Hayes. El conjunto de comandos Hayes es un lenguaje desarrollado por la compañía Hayes Communications que prácticamente se convirtió en estándar abierto de comandos para configurar y parametrizar módems. Los caracteres ‘AT’, que preceden a todos los comandos, significan ‘atención’, e hicieron que se conociera también a este conjunto de comandos como comandos AT. Midiendo la longitud de los bits se puede determinar en detalle la velocidad de transmisión. Un aparato que implemente el conjunto de comandos Hayes se considera compatible Hayes. Parte del conjunto de comandos Hayes fue incluido por la ITU-T en el protocolo V.25ter, actual V.250. La adopción de este estándar hizo el desarrollo de controladores específicos para distintos módems superfluo. Si los bytes que se envían a la interfaz ELM327 no comienzan con las letras ‘A’ y ‘T’, ésta entiende que se trata de un comando OBD dirigido al coche. Cada pareja de bytes ASCII son comprobados para asegurarse de que se trata de dígitos hexadecimales válidos, y posteriormente se convierten en data bytes para transmitirse al vehículo. Los comandos OBD son enviados al coche encapsulados en data packets. La mayoría de los estándares requieren tres bytes de cabecera y un byte de checksum en cada mensaje OBD, y el ELM327 se encarga de añadir esos bytes extra al comando OBD. Los valores por defecto para estos bytes extra son adecuados para la mayoría de los casos pero existe la opción de ajustarlos manualmente.. Figura 23. Trama del mensaje OBD para la mayoría de los estándares.. Página 36 | El microcontrolador ELM327.

(40) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 24. Trama del mensaje OBD para el estándar CAN. La mayoría de los comandos OBD no tienen una longitud mayor de uno o dos bytes, pero algunos pueden ser más largos. El ELM327 limitará el límite de bytes que pueden ser enviados al máximo permitido por los estándares (normalmente siete bytes o catorce dígitos hexadecimales). Intentar enviar más bytes ocasionará un error y el comando será ignorado, mostrando por pantalla un signo de interrogación (?) a modo de mensaje de error. Los dígitos hexadecimales son usados para todos los intercambios de datos con el ELM327 porque es el formato de datos más usado en los estándares OBD. La mayoría de los listados de peticiones OBD usan notación hexadecimal, y este también es el formato más utilizado para mostrar los resultados de las peticiones. Para entender esta notación con fluidez se requiere de cierta práctica. La forma más sencilla de probar la interfaz es mediante un terminal de consola, como pueden ser putty o HyperTerminal, ajustando previamente los parámetros de conexión (COM port, baud rate, number of databits and number of parity bits). Como ejemplo de petición al vehículo, suponer que se desea enviar el comando ‘A6’ (en decimal 166); habría que teclear ‘A6’ y añadir un retorno de carro (return key). Estos tres caracteres serían enviados al ELM327 mediante un puerto RS232 (en nuestro caso bluetooth, implementando un puerto serie virtual) y éste los iría almacenando tal y como se fueran recibiendo hasta recibir el tercer carácter (retorno de carro), y entonces comenzaría a evaluar los otros dos. Se daría cuenta de que ambos son dígitos hexadecimales válidos y los convertiría en un byte (con valor hexadecimal 166). Los bytes de cabecera y checksum serían añadidos ahora y el total de cinco bytes sería enviado al vehículo. Es importante señalar que el retorno de carro es sólo una señal para el ELM327 y no se envía al vehículo. Después de enviar el comando, el ELM327 escuchará el bus OBD en busca de una respuesta dirigida a él. Si la dirección del mensaje coincide, los bytes recibidos son enviados al usuario mediante el puerto RS232, mientras que los mensajes con direcciones no coincidentes son ignorados (aunque pueden ser visualizados con el comando ‘AT BD’). El ELM327 continuará esperando mensajes dirigidos a él hasta que no encuentre ninguno durante el tiempo (timeout) establecido mediante el comando ‘AT ST’. Es decir, mientras que Página 37 | El microcontrolador ELM327.

(41) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. el ELM327 siga recibiendo mensajes, el timeout se irá reiniciando y la búsqueda seguirá en curso. Señalar que el IC (Integrated circuit) siempre responderá a las peticiones con alguna respuesta, incluso para decir ‘NO DATA’, que significa que no había ningún mensaje encontrado o sí los había pero no coincidían con el criterio de recepción. Existen multitud de comandos AT para el ELM327, en el apartado 13.1 se muestra una lista con todos ellos. Para obtener una descripción completa de cada uno se puede recurrir al datasheet del ELM327 2. En este proyecto se tratarán sólo los comandos necesarios para establecer una conexión con el vehículo, obviando aquellos comandos cuya finalidad sea adaptar los parámetros de la interfaz a necesidades puntuales. Después de configurar la conexión PC-ELM327 en el terminal de consola, una prueba básica podría ser el envío del comando ‘AT RV’. Este comando devuelve el valor de la tensión de alimentación que está recibiendo la interfaz (por parte del vehículo) en formato ‘XX.X(V)’, donde las ‘X’ representan el valor numérico con un decimal de precisión y los paréntesis encierran la unidad de medida; un ejemplo sería el siguiente: Enviado: >AT RV Recibido: 12.6V > El ELM327 no discrimina mayúsculas y minúsculas, ni tampoco espacios, por lo que la petición anterior podría haber sido ‘atrv’ o ‘ATRV’, por ejemplo. Es importante señalar también que la presencia del carácter ‘>’ no es casual, en el mensaje enviado indica que hay conexión con la interfaz y ésta está lista para recibir el comando, y en el mensaje recibido marca el final del mensaje. Una imagen puede ayudar a ver mejor esta idea:. 2. Apartado AT commands de [5].. Página 38 | El microcontrolador ELM327.

(42) Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación Universidad Politécnica de Madrid Proyecto Fin de Grado Título: Aplicación distribuida para la monitorización y diagnosis de automóviles Alumno: Gonzalo Bernias Vaquero Tutor: Francisco Javier Estaire Estaire. Figura 25. Prueba de conexión desde terminal de consola (HyperTerminal). Es trivial deducir que en este intercambio de mensajes no ha intervenido el vehículo, quien se ha limitado a brindar tensión de alimentación al ELM327. Para enviar comandos que requieran una respuesta por parte del vehículo, es necesario asegurarse de que el contacto (llave en la última posición del clausor antes del arranque) está dado, porque en caso contrario la mayoría de los vehículos no responden las peticiones, devolviendo un mensaje de error ‘SEARCHING…UNABLE TO CONNECT’ tal como se muestra en la figura 26:. Figura 26. Error al acceder a la ECU.. Página 39 | El microcontrolador ELM327.