UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL
FACULTAD DE CIENCIAS DE LA INGENIERÍA
CARRERA DE INGENIERÍA AUTOMOTRIZ
ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN
SCANNER AUTOMOTRIZ PARA VEHÍCULOS
VOLKSWAGEN GOL, PROGRAMADO CON
ARDUINO PARA VISUALIZAR EN ANDROID.
TRABAJO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO AUTOMOTRIZ
FÉLIX ANDRÉS ANDRADE SÁNCHEZ
DIRECTOR: ING. ALEXANDER PERALVO, MSc.
Derechos de autor
DECLARACIÓN
Yo FÉLIX ANDRÉS ANDRADE SÁNCHEZ, declaro que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento.
La Universidad Tecnológica Equinoccial puede hacer uso de los derechos correspondientes a este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su reglamento y por la normativa institucional vigente.
_________________________ Félix Andrade
CERTIFICACIÓN
Certifico que el presente trabajo que lleva por título “ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN SCANNER AUTOMOTRIZ PARA VEHÍCULOS VOLKSWAGEN GOL, PROGRAMADO CON ARDUINO PARA VISUALIZAR EN ANDROID”.
Que, para aspirar al título de Ingeniero Automotriz fue desarrollado por Félix Andrade, bajo mi dirección y supervisión, en la Facultad de Ciencias de la Ingeniería; y cumple con las condiciones requeridas por el reglamento de Trabajos de Titulación artículos 18 y 25.
___________________ Ing. Alexander Peralvo, MSc.
AGRADECIMIENTO
A mi padre, ejemplo de vida superación y Fortaleza, porque siempre brindarme su apoyo y brindarme la determinación para alcanzar cada meta trazada. Por darme ejemplo de cómo ser un hombre a carta cabal, brindarme su vocación e incondicionalidad. Por nunca dudar de mí, y jamás permitirme dudar de él.
A mi madre mi mejor amiga mi confidente, quien con su dedicación y su amor incondicionales, me ha forjado como persona, profesional, amigo y ser
humano. Quien con sus palabras ha logrado levantar mi ánimo en innumerables ocasiones y jamás me ha permitido dar un paso hacia atrás.
A mi hermana Karla quien jamás ha dudado de mi ni de mis decisiones y me ha apoyado incondicionalmente, en cada paso que he dado con quien he celebrado triunfos y me ha consolado en la derrota.
A mi hermana Domenica quien ilumina mi mundo y mi día a día con su sonrisa y su personalidad libre y descomplicada, quien ha quitado peso de mis hombros con tan solo un abrazo. Y a su corta edad me ha ensenado a brindarle una sonrisa a la vida.
A mis amigo y hermano Patricio, quien me demostró que los amigos son parte de la familia. Que me ha apoyado incansablemente en este proyecto, me ha ayudado y empujado para llegar hasta aquí. A mi amigo Christian quien me ha apoyado, a lo largo del camino con su determinación y conocimientos. A ustedes les dedico mi esfuerzo y mis logros, porque sin ustedes nada de esto fuese remotamente posible. FÉLIX ANDRÉS ANDRADE SANCHEZ
V
INDICE DE CONTENIDOS
DECLARACIÓN III
CERTIFICACIÓN IV
RESUMEN XIV
ABSTRACT XVI
1. INTRODUCCIÓN 1
2. MARCO TEÓRICO 4
2.1. OBD II 5
2.1.1. DEFINICIÓN 5
2.1.2. PROTOCOLO 5
2.1.2.1. TIPOS DE CÓDIGOS 8
2.2. ARDUINO 8
2.2.1. DEFINICIÓN 8
2.2.2. PROTOCOLO DE COMUNICACIÓN 9
2.2.2.1. Serial 9
2.2.3. APLICACIONES 9
2.3. CABLE DE INTERFAZ USB A OBD II 10
2.3.1. PROTOCOLO DE COMUNICACIÓN 10
2.3.2. CLASIFICACIÓN DE PROTOCOLOS DE COMUNICACIÓN 11
2.3.3. VAG-COM Y SU USO 11
2.4. COMUNICACIÓN BLUETOOTH 12
2.4.1. BLUETOOTH 12
2.4.2. OBJETIVOS 12
2.4.3. CLASIFICACIÓN 12
2.5. VISUALIZACIÓN DE DATOS 13
VI
2.5.1.1. Monitor Serial Arduino 13
2.5.1.2. Protocolo Rs232 14
2.6. VISUALIZACIÓN EN ANDROID 14
2.6.1. ANDROID 14
2.6.2. CARACTERÍSTICAS. 15
2.7. SENSORES 16
2.7.1. DEFINICIÓN 16
2.7.2. TIPOS DE SENSORES EN EL VEHÍCULO 16
2.7.2.1. Sensores De Temperatura 16
2.7.2.2. Sensores De Presión 17
2.7.2.3. Sensores De Velocidad 17
2.7.2.4. Sensores De Golpeteo, Sonido O Ruido 17
2.7.3. SENSORES A ESTUDIAR EN EL VEHÍCULO 18
2.7.3.1. Sonda Lambda 18
2.7.3.2. Sensor De Temperatura De Refrigerante 20
2.7.3.3. Sensor De Golpeteo (Ks) 22
2.7.3.4. Sensor De Temperatura De Admisión (Iat) 24
2.7.3.5. Sensor De Aceleración (Tps) 26
3. METODOLOGÍA 29
3.1. ADQUISICIÓN DE DATOS 30
3.1.1. ELM 327 30
3.1.2. DEFINICION 30
3.1.3. APLICACIONES 30
3.1.4. CARACTERISTICAS 31
3.1.5. DIAGRAMA DE CONEXIÓN 31
3.1.6. CARACTERÍSTICAS ELÉCTRICAS. 32
3.1.7. COMUNICACIÓN CON EL ELM327 32
3.1.8. COMANDOS 33
3.1.8.1. Comandos At 33
3.1.8.2. Comandos Obd 34
3.1.8.3. Comandos Específicos Para Iso, J1850 Y Can. 37
3.1.9. COMUNICÁNDOSE CON EL VEHÍCULO 39
VII
3.1.12. BORRANDO CÓDIGOS DE FALLA. 49
3.2. OBDII 51
3.2.1. FUNCIONES DEL OBDII 51
3.2.2. FUNCIONES DE DIAGNÓSTICO DEL OBDII EN VEHÍCULOS A
GASOLINA 52
3.2.3. FUNCIONES DE DIAGNÓSTICO DEL OBDII EN VEHÍCULOS A
DIESEL 52
3.2.4. FUNCIONAMIENTO DE EMERGENCIA 53
3.2.4.1. Sensor Del Pedal Del Acelerador 54
3.2.4.2. Catalizador 54
3.2.4.3. Tensión En La Batería 54
3.2.4.4. Sensor De Temperatura Del Motor. 54
3.2.5. FORMATO DEL MENSAJE DEL OBDII 54
3.2.6. DETECCIÓN DE ERRORES. 57
3.2.7. REDES DE COMUNICACIÓN EL VEHÍCULO. 59
3.2.8. ACCESOS DEL SISTEMA OBDII 63
3.2.8.1. Acceso A Datos En Vivo Del Sistema A Bordo 63
3.2.9. ACCESO A DATOS CONGELADOS 65
3.2.10. ACCESO A CÓDIGOS DE FALLA 65
4. DISEÑO E IMPLEMENTACIÓN DEL PROTOTIPO 67
4.1. DISEÑO DEL PROTOTIPO 68
4.1.1. ARDUINO DUE 68
4.1.2. SPARK FUN OBDII- UART 68
4.1.2.1. Elm327 69
4.1.2.2. Mcp2551 71
4.1.3. CABLE OBDII- RS232 73
4.1.4. LCD 20 X 4 CON I2C 73
4.1.5. DIAGRAMA EXPLICATIVO DE CONEXIÓN 74
4.1.6. DIAGRAMA DE CONEXIÓN DE HARDWARE Y COMUNICACIÓN
VIII
4.1.7. APP INVENTOR 75
4.2. IMPLEMENTACIÓN DEL PROTOTIPO 76
4.3. MANUAL DE PROCEDIMIENTOS 79
4.3.1. INSTALACIÓN DE LA APLICACIÓN EN ANDROID 79
4.3.2. USO DE LA APLICACIÓN Y EL PROTOTIPO. 84
5. ANÁLISIS DE RESULTADOS ¡ERROR! MARCADOR NO DEFINIDO.
5.1. CHEVROLET AVEO 2009 88
5.2. KIA SPORTAGE 2011 90
5.3. FORD ECOSPORT 2007 94
6. CONCLUSIONES Y RECOMENDACIONES 98
6.1. CONCLUSIONES 99
6.2. RECOMENDACIONES 100
GLOSARIO DE TÉRMINOS 101
ANEXOS 102
ANEXO 1 103
ANEXO 2 109
ANEXO 3 113
ANEXO 4 116
ANEXO 5 121
ANEXO 6 127
IX
ÍNDICE DE FIGURAS
Figura.1 Distribución De Pines En OBDII 6
Figura.2 Clasificación De Bluetooth 13
Figura.3 Tipos De Sensores 18
igura.4 Conexión Sonda Landa 19
Figura.5 Onda Sonda Landa 20
Figura.6 Conexión ECT 21
Figura.7 Onda ECT 22
Figura.8 Ubicación Del KS 23
Figura.9 Conexión Del KS 23
Figura.10 Onda Del KS 24
Figura.11 Conexión Del IAT 25
Figura.12 Onda Del IAT 25
Figura.13 Conexión Del TPS 26
Figura.14 Onda Del TPS 27
Figura.15 Diagrama De Conexión 31
X Figura.17 Estructura Tradicional De Mensajes Del OBDII Para Normas
Saej1850, Iso9141-2 E Iso14230-4 55
Figura.18 Estructura Tradicional De Mensajes Del OBDII Para Norma
Iso15765-4 56
Figura.19 Ubicación De La Luz Indicadora (Check Engine) 57
Figura.20 Ubicación Del Puerto OBDII 58
Figura.21 Diagrama Explicativo De La Red De Comunicación Para Diagnosis
E Información De Un Vehículo 59
Figura.22 Diagrama Explicativo De Función De Buses En La Red De
Comunicaciones De Un Vehículo 61
Figura.23 Clasificación De Buses De Comunicación Interna En El Vehículo
63
Figura.24 Solicitud Y Respuesta Para Accesos De Datos A Bordo 64 Figura.25 Solicitud Y Respuesta Para Accesos A Códigos De Falla 66
Figura.26 Arduino Due 68
Figura.27 SparkFun OBDII – UART 69
Figura.28 Esquema De Aplicación Tradicional Del Elm327 70
Figura.29 Mcp2551 71
Figura.30 Distribución De Pines Mcp2551 72
Figura.31 Cable OBDII – Rs232 73
XI Figura.34 Diagrama De Conexión De Hardware Y Comunicación Bluetooth
` 75
Figura.35 App Inventor 76
Figura.36 Caja De Proyectos Tipo H Modificada 77 Figura.37 Postes De Anclaje Para Placas Electrónicas 77 Figura.38 Placas Montadas Y Conexiones En Las Mismas 78
Figura.39 Prototipo Final 78
Figura.40 Aplicación Provista En El Cd 79
Figura.41 Ajustes Android 80
Figura.42 Aplicación En Gestor De Archivos Android 81 Figura.43 Instalación De La Aplicación 82 Figura.44 Pantalla Inicial De La Aplicación 83 Figura.45 Pantalla Principal De Aplicación 84
Figura.46 Dispositivos Bluetooth 85
Figura.47 Prueba Datos A Bordo, Chevrolet Aveo 88 Figura.48 Solicitud De Vector Y Número De Códigos De Falla En Chevrolet
Aveo 89
XII Figura.50 Forzado De Error Kia Sportage 91 Figura.51 Solicitud Vector Y Número De Errores Kia Sportage 92 Figura.52 Solicitud Scanner A, Kia Sportage 92
Figura.53 Borrar DTC Kia Sportage 93
Figura.54 Prueba Datos A Bordo, Ford Ecosport 94 Figura.55 Forzado De Error Ford Ecosport 95 Figura.56 Solicitud Vector Y Número De Errores Ford Ecosport 96 Figura.57 Solicitud Scanner A, Ford Ecosport 96
XIII
ÍNDICE DE TABLAS
Tabla.1 Distribución De Pines En OBDII 7
Tabla.2 Voltaje Vs Porcentaje De Apertura (TPS) 27 Tabla.3 Resistencia Vs Porcentaje De Apertura (TPS) 28 Tabla.4 Características Eléctricas Elm327 32
Tabla.5 Comandos Generales At Elm327 34
Tabla.6 Comandos OBDII Elm327 36
Tabla.7 Tabla De Conversión 37
Tabla.8 Comandos Específicos Para J1850 37
Tabla.9 Comandos Específicos Para ISO 38
Tabla.10 Comandos Específicos Para CAN 38 Tabla.11 Comandos Específicos Para J1939 39 Tabla.12 Tabla De Interpretación De DTC 48 Tabla.13 Estándares Más Utilizados En Comunicación Interna Del Vehículo
XIV
RESUMEN
Se diseñó y construyó un scanner automotriz con la capacidad de obtener códigos de diagnóstico en vehículos indistintamente del modelo o el fabricante de los mismos. Abarcando todos las variedades dentro de los vehículos incluyendo camionetas, autos, sedan hatchback, o SUV sin importar la cilindrada de los mismos o disposición del motor.
El presente trabajo cumplió con requisitos ergonómicos, técnicos y de seguridad con el fin de que las pruebas que se realicen con el presente proyecto sean cómodas y brinden resultados fiables, con este trabajo los alumnos de Ingeniería Automotriz de la Universidad Tecnológica Equin occial lograran diagnosticar con mayor facilidad y sin necesitad de un libro de códigos los vehículos y después de reparar los mismos incluso se podrá realizar el reset de los códigos de falla desde su teléfono Android.
Facilitando la obtención de conocimientos en lo que a diagnostico automotriz, y el uso del scanner automotriz se refiere; fortaleciendo ampliamente el conocimiento teórico obtenido en las aulas con conocimiento práctico, de modo que este scanner aparte de ser útil en el diagnostico será útil en la formación profesional de los alumnos de la carrera de Ingeniería Automotriz dado que la práctica brinda beneficios y conocimientos que prácticamente son imposibles de obtener dentro de una aula de clases.
XV realizaron diversas pruebas con diversos fallos generados intencionalmente en varios vehículos, logrando resultados fiables en todas y cada una de las pruebas por lo que se puede aseverar que scanner automotriz funciona en cada variedad de los vehículos.
XVI
ABSTRACT
I designed an automotive scanner that was built with the ability to obtain diagnostic codes in vehicles. Encompassing all varieties of vehicles including sedan, hatchback, even SUV vehicles. And you don’t have to consider the engine or any other factor, the only one factor to consider is that the vehicle has to have an OBDII port.
This work meets ergonomic requirements , technical and security in order that the tests made with this project are comfortable and provide reliable results , with this prototype Automotive Engineering Technology University Equinoccial students are able to diagnosing more easily and without needing a codebook vehicles even you can do the reset of the trouble codes.
Facilitating the apprehension of knowledge when it comes to automotive diagnostics, automotive and scanner usage refers broadly strengthen the theoretical knowledge gained in the classroom with the knowledge obtained in the practice, so this scanner apart from being useful in the diagnosis will be useful in training student 's career since automotive engineering practice and knowledge provides benefits that are virtually impossible to get inside a classroom.
This automotive scanner will be made by programming a card with microcontroller, providing directly the fault rather than diagnosis code corresponding widely facilitating the detection of the fault and obviously the repair process, if the automotive scanner apart from fulfilling the role of tool serves to information, two pillars that are valuable and useful in the automotive engineering career .
XVII automotive scanner works in every variety of vehicles.
2 como: actividades de exploración terrestre, manipulación y transporte de material peligroso, transporte, o en la industria petrolera, minera, agricultura, construcción e incluso en medicina.
La electrónica automotriz, es una de las áreas más complejas y completas de la ingeniería, en razón de que involucra distintas disciplinas entre ellas: la mecánica, la electrónica, teoría de control, programación y procesamiento de señales, lo cual la convierte en uno de los ejemplos más claros de aplicación de la Ingeniería Automotriz.
En virtud de los avances tecnológicos, que se han desarrollado en las últimas décadas, se pueden diferenciar avances en diagnóstico automotriz: los scanner y los osciloscopios.
Ambos tipos de sistemas poseen cosas en común, cuando de su estudio se trata, debido a que requieren algoritmos de control necesarios para poder realizar una tarea dada, complementando a esto los distintos dispositivos que requiere el mismo para que se le pueda dotar de cierta inteligencia para cumplir dichas tareas.
De modo que con el presente trabajo se busca incursionar en la investigación y desarrollo en este campo dentro de la industria automotriz en el país y en la universidad.
3 Logrando así una incursión tecnológica en nuestro ámbito a bajo costo, los principales beneficiarios vendrían a ser tanto clientes como ingenieros y artesanos en el campo automotriz.
Cabe recalcar que a lo largo del presente trabajo previo a la obtención del título, se han encontrado varias limitaciones, como también la posibilidad de la ampliación del tema, es decir la extensión del presente trabajo, las limitaciones que se han encontrado están fundamentadas en los protocolos soportados, cualquier protocolo que no se encuentre especificado en el presente trabajo no es compatible con el microcontrolador ELM 327, de modo que si un vehículo posee dicho protocolo en su ECU, no es viable el monitoreo de datos en dicho vehículo.
Pero por el otro lado se ha logrado expandir el tema, logrando abarcar una, mayor cantidad de marcas y modelos, de modo que en lugar de limitar a la marca Volkswagen y al modelo GOL, se ha conseguido el desarrollo y diseño de un escáner multimarca, compatible con muchos vehículos en el parque automotor ecuatoriano.
5
2.1. OBD II
2.1.1. DEFINICIÓN
OBD II (On Board Diagnostics Second Generation) Diagnostico a Bordo, segunda generación. Por facilidad y comprensión en el presente trabajo se utilizaran las siglas OBD II.
OBD II es una mejora basado en Sistema OBD. Este sistema nos brinda diagnóstico electrónico del vehículo y viene integrado en el mismo. Tiene la capacidad de supervisar y evaluar las funciones del motor con el fin de evitar exceso de emisiones generando códigos de fallas, a través de los sensores la lógica del sistema OBDII tiene la capacidad de responder de diversas formas dependiendo del estado de conducción, clima, temperatura, etc. La información es recogida por los sensores que son varios y distribuidos por todo el vehículo cada uno con una función diferente y específica y en base a esta información generar una respuesta y lograr controlar las emisiones hacia el medio ambiente, también posee un modo de conducción segura o modo de emergencia en el cual el consumo de gasolina se reduce y el vehículo alcanza velocidades de máximo treinta kilómetros por hora este modo se genera cuando la PCM con tecnología OBDII detecta algún fallo grave en el vehículo, y este modo provee seguridad a los ocupantes del vehículo y reduce las emisiones durante la falla hasta llegar a un taller o centro de servicio del vehículo.
2.1.2. PROTOCOLO
6 detenidamente podremos advertir la ausencia de pines, ya que solo algunos de los orificios poseen contactos y otros simplemente son agujeros sin función alguna.
Los pines que establecen la comunicación entre el scanner y la PCM se encuentras en diversos lugares, pero con la normalización de OBDII tienen 3 pines los mismos que generalmente se encuentran en el mismo sitio y que poseen la misma función estos pines son aquellos que se encuentran en la posición 4,5, y 16.
Figura 1. Distribución de pines en OBDII (Tarnok, 2013)
Pin #4: tierra al Chasis del vehículo.
Pin #5: Tierra o negativo del computador del vehículo. Pin #16: Positivo directo desde la batería.
7 En la actualidad los scanner automotrices poseen una fuente de alimentación propia, pero del mismo modo esta alimentación se ve apoyada por la energía que proporciona el conector de diagnóstico, en el uso de funciones especiales tales como iluminación de pantalla.
Se considera que los demás pines, aparte de los pines 4, 5 y 16, corresponden a pines de comunicación con el scanner, o pines para activar funciones especiales, por ejemplo la inducción de un “Auto Diagnóstico”.
Los vehículos OBDII poseen uno de estos protocolos. Cada uno de estos 4 protocolos utiliza distintos pines de comunicación en el conector OBDII, sin embargo siempre son los mismos para cada protocolo.
Por ello se puede formar una “regla” para identificar si un vehículo utiliza alguno de estos protocolos; y si es así, el vehículo debe cumplir con la norma OBDII.
Tabla 1. Distribución de pines en OBDII (Tarnok, 2013)
Protocolo Pines de Comunicación
VPW 2 (y 15 opcional)
ISO-9141 7 y 15
PWM 2 y 10
CAN 6 y 14
8 Código B Sistemas de la carrocería.
Código C Sistemas del chasis.
Código U Comunicaciones de la red.
Código P Sistemas del tren de potencia [Motor y Transmisión].
2.2. ARDUINO
2.2.1. DEFINICIÓN
Arduino es una plataforma de electrónica abierta para la creación de prototipos basada en software y hardware flexibles y fáciles de usar. Se cre ó para artistas, diseñadores, aficionados y cualquiera interesado en crear entornos u objetos interactivos. (2013).
Arduino toma información del entorno a través de sus pines de entrada de una gran variedad de sensores y envía señales hacia actuadores como luces, motores, etc.
El microcontrolador de las diversas placas Arduino se programa mediante un lenguaje basado en Wiring el mismo que es conocido como lenguaje Arduino y fue desarrollado por los mismos fabricantes de dicha placa.
9 2.2.2. PROTOCOLO DE COMUNICACIÓN
2.2.2.1. Serial
Este tipo de protocolo se usa con el fin de establecer comunicación entre Arduino y un computador u otro dispositivo. Las placas Arduino en todas sus variedades cuentan con por lo menos un puerto serial el mismo que también es denominado UART o USART: Serial.
Se comunica a través de los pines digitales 0 (RX) y 1 (TX), así como con el ordenador mediante USB. Por lo tanto, si se utiliza estas funcione, no pueden ser usados los pines 0 y 1 como entrada o salida digital. (Arduino, 2013). Se puede monitorear el puerto serial mediante el programa oficial de Arduino llamado Arduino y así generar comunicación con la placa.
La placa Arduino Mega tiene tres puertos adicionales de serie: Serial1 en los pines 19 (RX) y 18 (TX), Serial2 en los pines 17 (RX) y 16 (TX), Serial3 en los pines 15 (RX) y 14 (TX). Para utilizar estos pines para comunicarse con el ordenador personal, necesitarás un adaptador USB adicional a serie, ya que no están conectados al adaptador USB-Serie de la placa Arduino Mega. Para usarlos para comunicarse con un dispositivo serie externo TTL, conecta el pin TX al pin RX del dispositivo, el RX al pin TX del dispositivo, y el GND de tu Arduino Mega a masa del dispositivo. (No conectes estos pines directamente a un puerto serie RS232, que operan a +/- 12V y esto puede dañar la placa Arduino. (Arduino, 2013).
2.2.3. APLICACIONES
La placa Arduino se ha usado como base en millones de aplicaciones en el mundo dado que es tecnología abierta y versátil:
10 Arduinome: Es un controlador de gran utilidad en el ámbito musical
uniendo instrumentos, sintetizadores etc.
Humane Reader: Este es un proyecto cuyo costo es bajo el mismo que provee señal de televisión logrando tener a disponibilidad contenidos de hasta 5000 archivos de video.
The Humane PC: Es un simulador de computadora u ordenador el mismo que funciona usando como núcleo una placa Arduino y usa un monitor de tv y un teclado de computadora de escritorio.
Ardupilot: Es un proyecto basado en Arduino el mismo que brinda hardware y software para aeronaves no tripuladas.
ArduinoPhone: Es un teléfono celular basado en Arduino siendo este el corazón del mismo.
2.3. CABLE DE INTERFAZ USB A OBD II
2.3.1. PROTOCOLO DE COMUNICACIÓN
Existen varios protocolos de comunicación del sistema OBDII para comunicarse con los distintos scanner en el mundo y del mismo modo con el scanner que se fabricará.
11 2.3.2. CLASIFICACIÓN DE PROTOCOLOS DE COMUNICACIÓN
ISO 9141-2 este tipo de protocolo es usado en vehículos Europeos,
Asiáticos y Chrysler con variantes (Key Word Protocol es la Palabra Clave).
SAE J1850 VPW que significa Ancho de Pulso Variable (Variable
Pulse Width) este protocolo es utilizado por General Motors USA (General Motors).
SAE J1850 PWM que indica Modulación Ancho de Pulso (Pulse
Width Modulatión) este protocolo lo usa Ford USA. KWP 1281 y KWP 2000 utilizado por el grupo VAG. ISO 14230 que lo utiliza Renault.
2.3.3. VAG-COM Y SU USO
12 2.4.1. BLUETOOTH
Es conocido como Bluetooth el protocolo de comunicaciones el cual fue diseñado especialmente para dispositivos que posean un bajo consumo, que no requieran un gran alcance de emisión y basados en emisión y recepción de bajo costo.
La tecnología Bluetooth es una tecnología basada en las redes e inalámbricas (WPAN) las misma que nos brinda la posibilidad de transmitir datos de manera inalámbrica mediante un enlace de radiofrecuencia entre varios dispositivos en una banda ISM de dos punto cuatro GHz (2,4 GHz).
2.4.2. OBJETIVOS
o Hacer más sencilla la comunicación entre equipos fijos y móviles.
o Eliminar cables y conexiones para generar comodidad y armonía visual.
o Brindar la oportunidad de generar pequeñas redes sin la presencia de cables con el fin de sincronizar datos entre equipos personales.
2.4.3. CLASIFICACIÓN
13 elementos a conectarse no se ven obligados a estar alineados incluso pueden estar separados por muros siempre y cuando la potencia de transmisión sea suficiente. Estos dispositivos se clasifican en base a su potencia de transmisión como "Clase 1", "Clase 2" o "Clase 3" y cabe recalcar que son compatibles entre sí.
Figura 2. Clasificación de Bluetooth (hetpro, 2014)
2.5. VISUALIZACIÓN DE DATOS
2.5.1. VISUALIZACIÓN EN ENTORNO DE WINDOWS 2.5.1.1. Monitor serial Arduino
La comunicación del computador con los diversos microcontroladores es de suma importancia, debido a esto se ha incorporado un módulo el mismo que posee propiedades necesarias para el intercambio de la información.
14
Asincrónico (full-dúplex).
Sincrónico-Maestro (half-dúplex).
Sincrónico-Esclavo (half-dúplex).
2.5.1.2. Protocolo RS232
Este protocolo es ampliamente conocido en los ordenadores personales es un protocolo de comunicación, este protocolo es usado por los puertos COM del computador. Los puertos físicos tienen acceso atreves de conectores DB-25 o DB9, machos y hembras y con el avance de la tecnología a través de los puertos usb disponibles en cualquier computador. La norma RS232 se estableció para comunicar un computador con un modem.
2.6. VISUALIZACIÓN EN ANDROID
2.6.1. ANDROID
Android es un sistema operativo para dispositivos móviles basado en el núcleo Linux. Inicialmente fue desarrollado por Google y luego por la Open Handset Alliance (liderada por la propia Google). La presentación de la plataforma Android se realizó el 5 de noviembre de 2007 junto con la fundación Open Handset Alliance, un consorcio de 48 compañías de hardware, software y telecomunicaciones comprometidas a la promoción de estándares abiertos para dispositivos móviles.
15 2.6.2. CARACTERÍSTICAS.
Framework de aplicaciones: permite reusar y reemplazar componentes.
Máquina virtual Dalvik: Optimizada para dispositivos móviles. Navegador integrado: Basado en el motor de código abierto
WebKit.
Gráficos optimizados, con una biblioteca de gráficos 2D; gráficos 3D basado en la especificación OpenGL ES 1.0 (aceleración por hardware opcional).
SQLite para almacenamiento de datos estructurados.
Soporte para medios con formatos comunes de audio, vídeo e imágenes planas (MPEG4, H.264, MP3, OGG, AAC, AMR, JPG, PNG, GIF).
Telefonía GSM (dependiente del hardware).
Bluetooth, EDGE, 3G, y WiFi (dependiente del hardware).
Cámara, GPS, brújula, y acelerómetro (dependiente del hardware).
Ambiente rico de desarrollo incluyendo un emulador de dispositivo, herramientas para depurar, perfiles de memoria y rendimiento, y un complemento para el IDE Eclipse.
Pantalla táctil.
Android Market permite que los desarrolladores pongan sus aplicaciones, gratuitas o de pago, en el mercado a través de esta aplicación accesible desde todos los teléfonos con Android. (Castellanos, 2014)
16 inalámbrica Bluetooth, logrando así la eliminación de cables en lo que a visualización respecta.
2.7. SENSORES
2.7.1. DEFINICIÓN
Un sensor es un dispositivo el mismo que posee la capacidad de detectar magnitudes que pueden ser físicas o químicas, y que son transformadas y transmitidas como variables eléctricas, estas magnitudes físicas o químicas son conocidas como variables de instrumentación.
Las variables de instrumentación pueden ser magnitudes como: temperatura, intensidad, presión, movimiento, vibración, etc.
Esta información es enviada a la ECU en magnitudes eléctricas, como voltaje, o resistencia, lo que permite que la ECU monitoree constantemente el funcionamiento del vehículo variando así el comportamiento de los actuadores de acuerdo a los datos recibidos de los sensores, estos datos son comparados con patrones que la ECU tiene almacenado en su software.
2.7.2. TIPOS DE SENSORES EN EL VEHÍCULO 2.7.2.1. Sensores de Temperatura
DEFINICIÓN
17 que brindan de este modo se envía variaciones de voltaje a la ECU o PCM, lo que representa acciones en los actuadores.
2.7.2.2. Sensores de presión
DEFINICIÓN
Estos sensores miden presión directamente, a través de la deformación de una membrana o por un sensor de fuerza, lo que quiere decir que mientras mayor sea la presión en la membrana mayor será el voltaje, y en el vehículo esto se refleja en que mientras mayor número de RPM tenemos Mayor es el voltaje.
2.7.2.3. Sensores de velocidad
DEFINICIÓN
Son captadores magnéticos es decir funcionan por medio de la generación de voltaje cuando el mismo gira, es decir genera corriente alterna la misma que es interpretada como una señal por la PCM mientras más rápido gire mayor es el voltaje y la frecuencia.
2.7.2.4. Sensores de golpeteo, sonido o ruido
DEFINICIÓN
18
Figura 3. Tipos de Sensores (Rodríguez, 2014)
2.7.3. SENSORES A ESTUDIAR EN EL VEHÍCULO 2.7.3.1. Sonda lambda
DEFINICIÓN
Este sensor es un tipo de batería de dióxido de zirconio, el mismo que posee la facultad de transportar una corriente muy pobre entre sus electrodos, uno de los electrodos estará en contacto con el aire atmosférico y el otro en contacto con los gases de escape,
19 FUNCIONAMIENTO
Este sensor es el encargado de verificar la cantidad de oxígeno en los gases del escape, censa por medio de una reacción química.
El contenido de O2 en los gases de escape en relación con el aire de referencia producen una tensión eléctrica entre ambas superficies.
Esta tensión puede ser, con una mezcla rica (lambda <1) de 800 a 1000 mV (0.8 a 1.0 voltios) con una mezcla pobre (Lambda >1), la tensión estaría en valores de 100 mV (0.01 Voltios), el margen cuando se da una variación entre mezcla rica y pobre, esta entre 450 y 500 mV (0.45 a 0.50 Voltios).
UBICACIÓN
El sensor se encuentra ubicado en el tubo de escape inmediatamente después del múltiple.
DIAGRAMA DE CONEXIÓN DEL SENSOR
20
Figura 5. Onda sonda lambda (Andrade F. , 2011)
2.7.3.2. Sensor de temperatura de refrigerante
DEFINICIÓN
Este sensor es un termistor, el mismo que mide los cambios de temperatura que se generan en el motor basándose en la temperatura del refrigerante, este sensor es vital para acciones que toman los actuadores como los inyectores, o para la distribución variable, el tiempo de inyección, etc.
FUNCIONAMIENTO
21 La computadora (ECM) toma como referencia los valores del voltaje para activar o desactivar al bulbo o directamente el electro-ventilador.
Un mal funcionamiento en este sensor, puede ser la causa de rechazo en Coorpaire.
UBICACIÓN
El sensor se encuentra ubicado en las cañerías del refrigerante es decir se lo puede encontrar en el sistema de refrigeración entre el retorno del motor y el radiador, en contacto pleno con el líquido refrigerante.
DIAGRAMA DE CONEXIÓN DEL SENSOR
22
Figura 7. Onda ECT (Andrade F. , 2011)
2.7.3.3. Sensor de golpeteo (KS)
DEFINICIÓN
El sensor de golpeteo es un sensor que se encuentra ubicado en el bloque del motor, este es un generador de voltaje el mismo que se encarga de controlar las vibraciones anormales que puedan generarse en el motor, es el encargado de regular el encendido generando así menos vibración mejor potencia y menor consumo, un combustible con un bajo grado de octanaje generaría detonación.
FUNCIONAMIENTO
Este sensor está conformado por un elemento de piezoeléctrico, que chequea la vibración del bloque de cilindros enviando esta señal a la PCM.
23 UBICACIÓN
Este sensor se encuentra ubicado en la parte central del block, en un motor en v tendría un sensor a cada lado.
Figura 8. Ubicación del KS (e-auto.com.mx, 2014)
DIAGRAMA CONEXIÓN DEL SENSOR
24
Figura 10. Onda sonda KS (e-auto.com.mx, 2014)
2.7.3.4. Sensor de temperatura de admisión (IAT)
DEFINICIÓN
Este sensor es un termistor, el mismo que mide la temperatura del aire que ingresó a la cámara de combustión de los cilindros del vehículo, este sensor es vital para acciones que toman los actuadores como los inyectores, o para la distribución variable, el tiempo de inyección, etc.
FUNCIONAMIENTO
25 resistencia, así también a menor temperatura mayor tensión y resistencia. Y lo que hace es enviar la información a la PCM para que ajuste la mezcla de combustible con mayor precisión.
UBICACIÓN
El sensor se encuentra ubicado antes de la aleta de aceleración y después del filtro de aire, cerca del depurador.
DIAGRAMA DE CONEXIÓN DEL SENSOR
Figura 11. Conexión del IAT (Mandy Concepcion, 2014)
ONDA EN EL OSCILOSCOPIO
26 DEFINICIÓN
Este sensor es de tipo potenciómetro es decir que varía su resistencia de acuerdo a su posición, se encuentra ubicado sobre la mariposa, tienen 3 cables, el cursor recorre la pista pudiéndose conocer según la tensión dicha la posición del cursor, su función es determinar la posición de la mariposa enviando la información hacia la unidad de control.
FUNCIONAMIENTO
Este sensor es de tipo potenciómetro es decir que es una resistencia variable de modo que mientras mayor sea el porcentaje de apertura de la aleta de la mariposa mayor será tanto la resistencia como el voltaje la función de este sensor es informar a la ECU la carga que se le está solicitando al motor .
UBICACIÓN DEL SENSOR
El sensor se encuentra ubicado en la aleta de la aceleración de modo que ira alojado en el lado opuesto de donde se aloja el cable del acelerador. DIAGRAMA DE CONEXIÓN DEL SENSOR
27 ONDA EN EL OSCILOSCOPIO
Figura 14. Onda del TPS (Andrade F. , 2011)
TABLA VOLTAJE VS PORCENTAJE DE APERTURA
Tabla 2. Voltaje vs porcentaje de apertura (TPS) (Andrade F. , 2011)
Voltaje % de apertura
4.38 100
4,10 90
3,73 80
3,39 70
3,18 60
2,75 50
2,30 40
1,96 30
1,38 20
1,24 10
28
Tabla 3. Resistencia vs porcentaje de apertura (TPS) (Andrade F. , 2011)
Resistencia % de apertura
2.46 100
2.36 90
2,30 80
2,20 70
2,15 60
2,03 50
2,00 40
1,90 30
1,65 20
1,56 10
30 3.1.1. ELM 327
En la actualidad prácticamente el cien por ciento de los vehículos, por regulación y normativa, brindan la posibilidad de conectar un dispositivo de diagnóstico sea un scanner automotriz o prototipos de diagnóstico del vehículo desarrollados basándose en open source o hardware libre.
Los datos transferidos se basan en distintos protocolos y cabe recalcar que ninguno de ellos nos brindara acceso a la información si lo que hacemos es realizar una conexión directa entre el computador y el vehículo o el vehículo y otro dispositivo inteligente.
3.1.2. DEFINICION
El ELM327 es un interpretador el mismo que está diseñado para ser utili zado como un interpretador en la comunicación serial entre el OBDII (On – Board Diagnostics) que posee el vehículo y el receptor en este caso el Arduino.
El ELM327 es capaz de detectar automáticamente 9 de los protocolos OBD que hay en el mercado automotriz, provee soporte para comunicación de alta velocidad, aparte de ser completamente modificable según las necesidades requeridas por el programador.
3.1.3. APLICACIONES
Visualización de datos en tiempo real (pruebas de ruta). Escaneo de DTC.
31 3.1.4. CARACTERISTICAS
Modo de inactividad.
Interfaz con comunicación serial RS232 (universal). Totalmente configurable con comandos AT.
3.1.5. DIAGRAMA DE CONEXIÓN
32
Tabla 4. Características eléctricas ELM327 (elmelectronics, 2014)
3.1.7. COMUNICACIÓN CON EL ELM327
33 maneras de generar una “comunicación serial del tipo virtual“ los dispositivos más comunes son USB a DB9, pero en este caso dado que queremos realizar la visualización es un dispositivo móvil la conexión física la realizará a través de un Arduino DUE.
Independientemente de la manera física de realizar la conexión el ELM327 necesitará una manera para enviar y recibir datos, el método simple para realizar esto es el uso de un programa que permita el monitoreo serial, tanto de datos enviados como recibidos, el mismo que nos brinda la posibilidad de enviar datos a la ECU.
Pero en este proyecto él envió de datos se realizará automáticamente a través del Arduino y la orden del envió de datos se la dará desde el dispositivo móvil. Cabe recalcar que si la conexión se la realiza de manera correcta los 4 leds de la placa se energizaran indicando el envío y recepción de datos tanto con el emisor (teléfono móvil) y el receptor (OBDII) y viceversa.
3.1.8. COMANDOS 3.1.8.1. Comandos AT
Muchos parámetros dentro del ELM327, pueden ser ajustados con el fin de modificar su manera de responder, aunque estos parámetros no tienen la necesidad de ser modificados si se ha logrado la comunicación con el vehículo.
Estos comandos generalmente empiezan con las letras “A“ o “T“.
En la siguiente tabla se muestra un resumen de los códigos AT siendo estos los más importantes.
34
Mendez, 2014)
3.1.8.2. Comandos OBD
35 Los Comandos OBD se envían en realidad al vehículo, incrustados en un paquete de datos. La mayoría de las normas requieren de tres bytes de cabecera y un byte de suma de comprobación de error, con cada mensaje del OBD, y el ELM327 agrega estos bytes adicionales a su mandato de bytes.
Los valores iniciales (por defecto) para estos bytes adicionales son por lo general apropiados para la mayoría de las solicitudes, la mayoría de los comandos de OBD están compuestos por uno o dos bytes de longitud, pero algunos pueden ser más largos.
El ELM327 limitará el número de bytes que se pueden enviar al máximo número permitido por las normas (generalmente siete bytes o 14 dígitos hexadecimales). Los intentos de enviar más bytes resultarán en un error - el comando completo es entonces ignorado y como respuesta se tendrá un solo signo de interrogación impreso. Los dígitos hexadecimales se utilizan para todos los datos con el fin de generar un intercambio con el ELM327 porque es el formato de datos utilizado usualmente en los estándares OBDII. La mayoría de las solicitudes utilizan notación hexadecimal, y es el formato utilizado usualmente para los resultados a mostrar.
36
37
Tabla 7. Tabla de conversión (elmelectronics, 2014)
3.1.8.3. Comandos específicos para ISO, J1850 y CAN.
Son aquellos comandos que son exclusivos para configurar los protocolos para ISO, J1850 Y CAN, estos códigos son exclusivos dadas las
características de dichos protocolos.
Tabla 8. Tabla de comandos específicos para J1850 (Caizatoa & Mendez, 2014)
38
& Mendez, 2014)
39
Tabla 11. Tabla de comandos específicos para J1939 (Caizatoa & Mendez, 2014)
3.1.9. COMUNICÁNDOSE CON EL VEHÍCULO
Las normas requieren que cada comando OBD o solicitud que se envía al vehículo debe cumplir con un formato. El primer byte enviado (conocido como el 'modo') describe el tipo de datos que se solicita, mientras que el segundo byte (y, posiblemente, un tercero o más) especifica la información real que se requiere.
Los bytes que siguen después del byte "modo" se conoce como el "identificación de parámetros "o bytes de número de PID "parameter identification". Los modos y PIDs se describen en detalle en los documentos tales como el SAE J1979, o las normas ISO 15031-5, y también puede ser definido por los fabricantes de vehículos. La norma SAE J1979 define actualmente diez posibles modos de prueba de diagnóstico, que son:
40 6. Resultados de prueba, no continuamente monitoreados.
7. Mostrar códigos de problemas 'pendientes'. 8. Modo de control especial.
9. Petición de Información del vehículo.
10. (0A) Solicitar los códigos de problemas permanentes.
Los vehículos no necesariamente deben soportar todos los modos, y dentro de los modos, no están obligados a soportar todos los PID posibles (algunos vehículos del primer OBD sólo admiten un número muy pequeño de ellos). Dentro de cada modo, PID 00 está reservada para mostrar cuales PID son compatibles con dicho modo. Modo 01, PID 00 debe ser compatible con todos los vehículos y se puede acceder a ella de la siguiente manera.
Asegúrese de que su interfaz ELM327 en este caso la placa “SparkFun” está correctamente conectada al vehículo, y energizada. La mayoría de los vehículos no responderá sin la llave de encendido en la posición de “contacto”, así que se debe girar el encendido del vehículo a la posición contacto, pero no es necesario arrancar el motor. Si la placa no ha sido reconocida lo que se debe hacer es resetear el ELM mediante el comando.
: > AT Z
Pero este reseteo se lo realizara automáticamente en este proyecto.
Verá el flash LED de la interfaz, y luego la placa responderá con el fin de demostrar que la conexión se realizó correctamente. Ahora, se puede elegir un protocolo con el que el ELM327 debe trabajar, pero por lo general es más fácil sólo se tiene que seleccionar el protocolo '0', que hará que se detecte uno automáticamente.
41 Eso es todo lo que se necesita hacer para preparar el ELM327 para la comunicación con el vehículo.
Emitir el modo 01 PID 00 con el comando: > 01 00
El ELM327 debería responder "searching" (buscando un protocolo), entonces debería imprimir una serie de números, similares a estos:
41 00 BE 1F B8 10
El 41 significa una respuesta para la petición del modo 01 (01 + 40 = 41), mientras que el segundo número (00) repite el número PID solicitado.
En el modo 02, la petición es contestada con un 42, el modo 03 con un 43, etc. Los siguientes cuatro bytes (BE, 1F, B8, y 10) representan los datos solicitados, en este caso muestra los PID que son compatibles con este modo (1 = compatible, 0 = no). Aunque esta información no es muy útil, prueba que la conexión funciona. Otro ejemplo es la solicitud al motor de la actual temperatura del refrigerante (ECT). La temperatura del refrigerante es PID 05 de modo de 01, y se puede solicitar de la siguiente manera:
> 01 05 La respuesta será de la forma: 41 05 7B
El 41 05 muestra que se trata de una respuesta a una solicitud de Modo 1 para el PID 05, mientras que la 7B son los datos deseados.
42
Un último ejemplo muestra una petición para el motor rpm. Esta es PID 0C en modo 01, se lo solicitaría así:
> 01 0C
Si el motor está en marcha, la respuesta podría ser: 41 0C 1A F8:
El valor devuelto (1A F8) es en realidad un número hexadecimal de dos bytes que se debe convertir a un valor decimal para ser útil, al convertirlo, obtenemos un valor de 6904, que parece ser un valor muy alto para las revoluciones del motor.
Eso es porque se envía rpm en incrementos de 1/4 rpm! Para convertir a la velocidad real del motor, tenemos que dividir el 6,904 para 4.
Un valor de 1726 rpm es mucho más razonable, cabe recalcar que se debe tener en cuenta que estos ejemplos se solicitaron al vehículo sin tener en cuenta el tipo de protocolo de OBD que el vehículo utiliza.
43 Si no hay respuesta dentro de un cierto tiempo, se supone que la ECU ha terminado su respuesta. Este mismo temporizador también se utiliza cuando la espera de la primera respuesta, y si nunca llega, será impreso el mensaje "NO DATA".
Hay una manera de acelerar la recuperación de información, si se conoce cuántas respuestas serán enviadas.
Al decirle al ELM327 cuántas líneas de datos debe recibir, él sabe cuándo la respuesta termina, por lo que no hay que pasar por el tiempo de espera final, a la espera de datos que no van a venir.
Sólo se debe añadir un dígito hexadecimal después de la solicitud OBD de bytes, este valor del dígito es el que proporciona el número máximo de respuestas a obtener. Por ejemplo, si se sabe que sólo hay una respuesta que viene solicitud de la temperatura del motor, se puede enviar:
> 01 05 1
El ELM327 responderá inmediatamente después de la obtención de sólo una respuesta.
44 esta función.
Como ejemplo, la solicitud para el número de identificación del vehículo (VIN) este número es de 17 dígitos de largo, y por lo general toma 5 líneas de datos para ser representado. Se obtiene con el modo 09, PID 02, y debe ser solicitada con:
> 09 02 O con: > 09 02 5
Se sabe que hay cinco líneas de datos que vienen si por error se envía 09 02 1, esto podría causar problemas.
Esta capacidad de especificar el número de respuestas se sumó con el programador en mente, una rutina de interfaz puede determinar cuántas respuestas esperar para una solicitud específica, y luego almacenar ese información para su uso con las solicitudes posteriores. Ya que sabiendo el número que se puede añadir a las peticiones, el tiempo de respuesta puede ser optimizado. Para la obtención de códigos de problemas, los ahorros realmente no resultan útiles, y es más fácil simplemente hacer una solicitud, sin tener en cuenta cuántas líneas de respuesta se espera.
3.1.10. INICIACIÓN DEL BUS
45 El ELM327 realizará esta iniciación del bus de manera automática, pero generalmente no, hasta la necesidad del envió de una solicitud. Si la iniciación del bus se produce durante una búsqueda automática, no se mostrara ningún informe de estado, pero si se tiene la Opción de apagado automático (y está configurado para los protocolos 3, 4, o 5), entonces se mostrara un mensaje similar a este:
BUS INIT: ...
Los tres puntos sólo aparecen cuando un lento inicio proceso se lleva a cabo una iniciación rápida no muestra los puntos.
Esto será seguido por la expresión 'OK' lo que indica que la inicialización fue exitosa, o bien un mensaje de error para indicar que hay un problema. (El error más común encontrado es el no girar la llave del vehículo a la posición "Contacto" antes de intentar comunicarse con el vehículo).
Una vez que el bus se ha iniciado, las comunicaciones deben llevarse a cabo con regularidad (por lo general al menos una vez cada cinco segundos), o el bus volverá a un bajo consumo de energía y entrará Modo "inactivo" o "sleep". Si no está enviando las solicitudes de datos con la suficiente frecuencia, el ELM327 generará solicitudes para asegurarse de que el bus se mantiene "despierto".
Nunca se verán las respuestas a dichas solicitudes, pero se verá el encendido del LED de transmisión el mismo que titila periódicamente a medida que estas solicitudes están siendo enviadas.
46 con el comando AT WM, si se quisiera cambiarlo o modificarlo. Pero generalmente esto no se realiza ya que el mensaje que viene por defecto trabaja perfectamente con la mayoría de sistemas.
3.1.11. INTERPRETANDO LOS CÓDIGOS DE FALLA DEL VEHÍCULO
Probablemente el uso más común para ELM327 es la obtención de los actuales códigos de diagnóstico o conocidos como (DTC). Mínimamente, esto requiere que se realice la petición o solicitud de un modo 03, pero primero se debe determinar cuántos códigos de problemas están actualmente almacenados.
Esto se realiza con una petición de modo 01 PID 01 de la siguiente manera: > 01 01
Una respuesta típica podría ser: 41 01 81 07 65 04 .El 41 01 significa una respuesta a la solicitud, y el byte siguiente de datos (81) es el número de problemas actual códigos. Como es lógico no existirán 81 (hexadecimal) o 129 (decimal) códigos de problemas actuales, si el vehículo está en absoluto estado operacional.
47 calcular el número de códigos almacenados cuando el MIL está encendida, sólo hay que restar 128 (o 80 hex) a partir del número.
Es decir 81-80= 1 lo que indicaría que el vehículo posee un código de falla o de error y este fue el que estableció el encendido del Check Engine.
Los bytes restantes en la respuesta proporcionan información sobre los tipos de pruebas compatibles con ese módulo en particular. En este caso, sólo habrá una línea a la respuesta, pero si existen códigos almacenados en otros módulos, cada uno de ellos podría haber proporcionado una línea de respuesta.
Aunque por lo general la respuesta siempre contara de un solo vector, es decir una sola línea de respuesta.
El siguiente paso es solicitar los códigos de problemas reales con una petición de modo 03 (no hay PID necesario):
> 03
La respuesta a obtener sería similar a esta: 43 01 33 00 00 00 00
El '43' en la respuesta anterior simplemente indica que esta es una respuesta a una petición de modo 03.
Los otro 6 bytes en la respuesta tienen que ser leídos en pares para mostrar los códigos de problemas (lo anterior debe ser interpretado de la siguiente manera 0133, 0000, y 0000).
48 significativos de cada código de error del vehículo, también contiene información adicional.
Por comodidad y viabilidad es más lógico utilizar la tabla siguiente para interpretar los bits adicionales en el primer dígito de la siguiente manera:
Tabla 12.- Tabla de Interpretación de DTC (elmelectronics, 2014)
49 Se debe considerar que el protocolo de la norma ISO 15765-4 (CAN) es muy similar, pero añade un byte de datos extra (en la segunda posición), que muestran cuantos códigos de falla (DTC) existen. Para ofrecer algunos ejemplos más, si se recibió el código D023, debería reemplazar la D con U1, y el código de falla resultante sería U1023. Del mismo modo, si se recibe 1.152 en realidad el código de falla o error vendría a ser el P1152.
3.1.12. BORRANDO CÓDIGOS DE FALLA.
El ELM327 es capaz de borrar los códigos de falla en el diagnóstico del vehículo, ya que esto sólo requiere la emisión de un comando de acceso al modo 04. Las consecuencias deberían siempre ser tomadas en cuenta antes de enviarlo, sin embargo, aparte de que el indicador del "Check Engine" será restablecerá o será reseteado, la emisión de una solicitud de modo 04 hará lo siguiente:
Reseteo del número de códigos de error.
Borrar los códigos de problemas de diagnóstico.
Borrar todos los datos almacenados que hayan sido congelados. Borrar el DTC que inició el problema.
Borrar todos los datos de la prueba del sensor de oxígeno. Borrar información del modo 06 y 07.
No borra códigos de problemas permanentes (modo 0A) (éstos se restablecen por la ECU solamente).
50
Figura 16. Guía para detección y borrado de códigos de error (Andrade F. , 2014)
>AT SP 0 OK
>0101
PARA OBSERVAR EL NÚMERO DE CÓDIGOS (SEGUNDO DIGITO DEL TERCER BITE)
>03 PARA OBSERVAR LOS CODIGOS DE ERROR( SE IGNORA EL 43 Y LOS DEMAS
BYTES SE LEEN EN PARES)
SE ARREGLA EL VEHÍCULO
>04
51
3.2. OBDII
3.2.1. FUNCIONES DEL OBDII
Los cuantificadores principales que dictan como debe estar funcionando y su correcto funcionamiento son:
1. Velocidad. 2. Carga.
3. Temperatura del motor. 4. Consumo de combustible. 5. Temperatura ambiente. 6. Caudal de aire.
7. Emisiones. (González Melis, 2014)
Cabe recalcar que con el fin de identificar y tener en constante monitoreo a dichos cuantificadores, lo fabricantes optaron por la inserción de sensores en los vehículos mismos sensores que fueron detallados brevemente en capítulos anteriores.
Estos sensores envían y reciben constantemente información de la ECU o de las ECUS con las que cuenta el vehículo con el fin de garantizar un correcto funcionamiento del vehículo y detectar fallas en el mismo.
52 GASOLINA
Estas dependen de disponibilidad en el vehículo del número de ECUS y de que parámetros quiere controlar y monitorear remotamente el fabricante.
Monitoreo del catalizador.
Pruebas de sonda lambda o sensor de oxígeno, basadas en la tensión de la onda.
Si el vehículo incorpora se realiza monitoreo del aire secundario del mismo.
Sistema de recuperación en los vapores de la combustión. Pruebas de fugas.
Sistemas de comunicación entre las ECUS del vehículo Control del sistema electrónico del vehículo.
Monitoreo contaste de sensores y actuadores del sistema electrónico del vehículo, los mismos que controlan fluyo de inyección y otros parámetros del vehículo incluyendo las emisiones generadas por el mismo.
3.2.3. FUNCIONES DE DIAGNÓSTICO DEL OBDII EN VEHÍCULOS A DIESEL
Estas dependen de disponibilidad en el vehículo del número de ecus y de que parámetros quiere controlar y monitorear remotamente el fabricante.
53 Circulación de gases de escape.
Sistemas de comunicación entre las ECUS del vehículo Control del sistema electrónico del vehículo.
La verificación de fallos en los sensores,
Los cortocircuitos positivos e interrupciones de línea, se puede detectar supervisando lo siguiente señales:
En las señales de entrada se revisa:
Verificación de la tensión de alimentación del sensor. Verificación del rango admisible.
Comprobaciones de integridad con otros componentes.
Los sensores más importantes son redundantes (pedal acelerador), comparándose directamente entre sí.
En las señales de salida:
Supervisión del circuito de corriente en las etapas finales.
Comprobación de los efectos del actuador sobre el sistema en los momentos en que se activa.
3.2.4. FUNCIONAMIENTO DE EMERGENCIA
54 Si existiera una falla, este entraría en modo de funcionamiento de emergencia, este modo consiste en bloquear el acelerador con el fin de que el motor no sobrepase las 1500rpm en la mayoría de los casos.
3.2.4.2. Catalizador
En caso de existir dos bloques lo que se procede a realizar es una comparación de los dos sensores de oxígeno, garantizando su correcto funcionamiento.
3.2.4.3. Tensión en la batería
En caso de que un fallo exista en la el valor de la tensión de la batería, el modo de emergencia procede a sustituir este valor por un valor preestablecido hasta que la línea quede perfecta.
3.2.4.4. Sensor de temperatura del motor.
Si existiera un falló en el sensor de temperatura, el valor que recibe la ECU se sustituye por un valor de 40 grados centígrados. Y si existe interrupción en la línea de comunicación entre el sensor y la ECU se activan los electroventiladores tratando de contrarrestar un posible sobrecalentamiento.
3.2.5. FORMATO DEL MENSAJE DEL OBDII
55 hecho de escanear cada una de ellas individualmente por lo cual se realiza el escaneo de las mismas en conjunto a través del puerto OBDII.
El sistema OBDII proporción bastante flexibilidad con el fin de que las ECUS se conecten entre si y el sistema OBDII tenga la posibilidad de conocer que dispositivo envía el mensaje que dispositivo envía la solicitud y que dispositivo responde, gracias a esto se tiene la capacidad de detectar fallas individuales y específicas.
Cabe recalcar que el sistema OBDII no es el encargado de detectar las fallas en los vehículos, el sistema OBDII se encarga exclusivamente de informar que existe uno.
La información que describe la prioridad del receptor y el transmisor usualmente es necesaria para el receptor, incluso antes de que conozca el tipo de pedido que contiene el mensaje. Para asegurar que esta información se obtiene primero, los sistemas OBD la transmiten al comienzo en el encabezado del mensaje. (Caizatoa & Mendez, 2014)
Figura 17. Estructura tradicional de mensajes del OBDII para normas SAE J1850, ISO 9141-2 e ISO 14230-4 (Rodriguez,
56 para proporcionar detalles acerca de la prioridad, del receptor y transmisor llamados también dirección blanco y dirección fuente respectivamente. (Caizatoa & Mendez, 2014)
.
Datos: Son hasta 7 los bytes que se utilizaran en este campo con la finalidad de envían información.
Byte de comprobación: Da lugar a comprobar la integridad de los datos que se ha recibido.
Figura 18. Estructura tradicional de mensajes del OBDII para norma ISO 15765-4 (CAN) (Rodriguez, 2014)
Esta es una estructura prácticamente idéntica a la anterior la única diferencia se sitúa en los bytes de encabezado.
Encabezado: En este caso dichos bytes tienen diferente nomenclatura o denominación ya que se los conoce como (BITS ID) y estos constan de once o de veintinueve bytes.
57 Protocolo de control de información (PCI): Este byte es el encargado de dar a notar o informar si la trama de datos es simple o se extiende y al mismo tiempo puede informar la longitud de los datos.
3.2.6. DETECCIÓN DE ERRORES.
El sistema OBDII como se mencionó antes no es el encargado de realizar la comprobación de sensores y actuadores pero si de informar si existe algún error en el sistema electrónico o mecánico del vehículo, y a la vez es el encargado de almacenar los códigos de falla generados por el escaneo periódico de las ECUS, el mismo que viene en forma de código, este código indica donde se ha producido el error y a que se puede deber haciendo sumamente más fácil la detección del fallo y la reparación del mismo.
El vehículo informa al conductor el aparecimiento de un error o la detección de un código de falla, a través de una luz indicadora en el tablero del vehículo la misma que es conocida en la industria automotriz como “check engine”, cabe recalcar que a pesar del fallo en la mayoría de los casos el vehículo seguirá funcionando.
58 del Check Engine, de modo que la única manera posible y técnicamente adecuada es realizar el escaneo del vehículo, solicitando los DTC del vehículo, por medio de un escanear automotriz conectando el mismo al puerto OBDII, reparar el vehículo y proceder al borrado de los mismo igualmente a través de un escáner automotriz conectado al puerto OBDII.
Existen 3 tipos de señales emitidas por el Check Engine.
Encendida constantemente: esto indica que la falla es grave y no se apagara hasta que el problema sea resuelto.
Parpadeo constante: esto indica que el problema es sumamente grave y puede causar un serio daño al motor si no se lo apaga inmediatamente.
Encendido intermitente de la luz. Esto indica que hay problemas de las funcionamiento, temporal ya que si el vehículo completa 3 ciclo de manejo sin presentar el mismo problema o sin que el mismo sea detectado por la ECU, el Check Engine se apagara y la lectura será borrada.
59 3.2.7. REDES DE COMUNICACIÓN EL VEHÍCULO.
Con el avance de la tecnología dentro de la industria automotriz, se ha logrado mejorar de varias maneras, el confort, la seguridad, la autonomía, las emisiones y las fallas dentro de un vehículo, todo esto es gracias a la presencia de las ECUS y de los sensores en el vehículo, pero dada la presencia de dos o más ECUS se ha debido establecer una red de comunicación entre los distintos sistemas electrónicos y de control que posee el vehículo.
Figura 21. diagrama explicativo de la red de comunicación, para diagnosis e información de un vehículo (Caizatoa &
Mendez, 2014)
60 con el fin de detectar si existe un código o no comparando estos datos con patrones preestablecidos, y a la vez tiene la función de facilitar el acceso a los mismo a través de un dispositivo externo.
La comunicación tanto externa como interna que establece el vehículo sea entre las distintas ECUS o con un dispositivo de diagnóstico externo se ve garantizada gracias a los siguientes elementos, los mismos que intervienen en la misma.
Buses
Son elementos que permiten la comunicación tanto entre una ECU con otra, como la comunicación entre la ECU principal y el Scanner automotriz.
Dichas conexiones se rigen a ciertas normas establecidas según el fabricante del vehículo y modelo del mismo.
Los buses comúnmente más utilizados en la industria automotriz son los siguientes:
MOST Byteflight J1850 MI
Bus D2B SMARTwireX DSI
61 CAN
Intellibus OBD-II Bus SAEJ1708 BST
MML Flex-ray IDB-1394
62 Protocolos de comunicación
Son las reglas o las normativas que caracterizan el intercambio de información entre dos o más ECUS, entre ECUS esclavas y el procesador central, o entre el puerto OBDII y el exterior los protocolos principales son: ISO y SAE.
Redes de comunicación interna del vehículo.
La red de comunicaciones se ha visto afectada debido, al gran avance tecnológico, ya que esto conlleva que las ECUS, sus buses y sus protocolos están sometidos a exigencias mayores, relacionadas con velocidad, fiabilidad, estabilidad y prioridades que estas den.
Tabla 13. Estándares más utilizados en comunicación interna del vehículo, (Andrade F. , 2014)
ORGANIZACIÓN >125 kbps <125 kbps
ISO (Europa) CAN
ISO11898 CAN ISO 11519 ISO 11992 SAE (EEUU) Vehículos livianos CAN SAE J2284 J1850 SAE (EEUU) Camiones y buses
CAN SAE J1939
J1587/1708, J1922
63 Clasificación
Los fabricantes han realizado una clasificación, basados en la velocidad como parámetro, y se han dividido los buses internos en tres grandes grupos, los mismos que se refieren a velocidad alta, media y baja.
Figura 23. Clasificación de buses de comunicación interna en el vehículo, (MAzo, Espinoza, Baset, & Gardel, 2014)
3.2.8. ACCESOS DEL SISTEMA OBDII
3.2.8.1. Acceso a datos en vivo del sistema a bordo
Brinda la posibilidad de conocer valores relativos al funcionamiento del vehículo en el momento que se realiza la solicitud del mismo, tenemos gran variedad de valores para escoger como por ejemplo:
Las revoluciones por minuto del motor La velocidad del vehículo