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.

Quito, febrero de 2015

Derechos de autor

© Universidad Tecnológica Equinoccial. 2015

Reservados todos los derechos de reproducción

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

C.I. 040130849-9

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.

DIRECTOR DEL TRABAJO

C.I. 1718133448

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

“Lo importante es no dejar de hacerse preguntas.”

Albert Einstein

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

2.5.1. VISUALIZACIÓN EN ENTORNO DE WINDOWS 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

3.1.10. INICIACIÓN DEL BUS 44

VII

3.1.11. INTERPRETANDO LOS CÓDIGOS DE FALLA DEL VEHÍCULO 46

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

BLUETOOTH 75

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

BIBLIOGRAFÍA 129

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

Figura.16 Guía Para Detección Y Borrado De Códigos De Error 50

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

Figura.32 Lcd 20 X 4 Con I2c 74

XI

Figura.33 Diagrama Explicativo De Conexión 74

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

Figura.49 Prueba Datos A Bordo, Kia Sportage 90

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

Figura.58 Borrar DTC Ford Ecosport 97

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

62

Tabla.14 Distribución De Pines Mcp255174 72

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 Equinoccial

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á úti l 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.

Este scanner automotriz se realizó mediante la programación de una tarjeta

con microcontrolador, lo que permitió obtener directamente la falla en lugar de

código de diagnóstico correspondiente facilitando ampliamente la detección

de la falla y obviamente el proceso de reparación, es decir este scanner

automotriz aparte de que cumplió con la función de herramienta cumplió la

función de información, dos pilares que son valiosos y útiles en la carrera de

Ingeniería Automotriz.

XV

En el proceso del desarrollo, diseño y construcción del presente scanner se

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.

Con respecto al mantenimiento del presente se debe considerar el

mantenimiento de la batería del vehículo, y de la toma de 12v del interior del

vehículo. Aunque por otro lado cabe recalcar que es posible el uso de fuentes

externas tanto para el puerto USB como para el Jack de alimentación es decir

que podemos alimentar al mismo desde un tomacorriente, desde un puerto

USB o desde el vehículo.

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 .

In the process of development, design and construction of this scanner several

tests were performed with various faults generated intentionally shot several

XVII

vehicles achieving reliable results each and every test so it can be stated that

automotive scanner works in every variety of vehicles.

With respect to the maintenance of this you should consider keeping the

vehicle's battery , and the 12v socket inside the .but you can use external

alimentation for the Arduino device.

1. INTRODUCCIÓN

2

En la actualidad, los vehículos poseen un sin número de aplicaciones tales

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.

La industria automotriz se ha visto envuelta en un avance tecnológico sin

precedentes, por lo cual el diagnóstico empírico es obsoleto y hasta cierto

modo poco útil, de modo que se plantea la realización, estudio y desarrollo de

un scanner automotriz el mismo que será programado y visualizado vía

Android dada la facilidad de uso que posee este sistema operativo.

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.

Logrando tener acceso a datos a bordo, lectura de DTC, y posterior a la

reparación mecánica o electrónica del vehículo, es posible en borrado del

código de falla, cabe recalcar que el escáner automotriz posee una base de

datos de la mayoría de códigos de falla estándar.

2. MARCO TEÓRICO

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

El socket o conector tipo OBDII tiene 16 pines, pero es bueno recalcar que no

se usa la totalidad de los mismos, de hecho en rigor estricto solo se usa uno

o dos de los diez y seis pines con el fin de transferir datos es decir establecer

comunicación con el scanner.

6

Esto es tan evidente que si tomamos un conector OBDII y lo observamos

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.

Generalmente los pines 4 y 16 se utilizan para alimentar o proveer de energía

al scanner. De modo que cuando se procede a conectar un scanner al socket

OBDII, este se encienda, ya que este recibe alimentación eléctrica.

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

OBD II (On Board Diagnostics Second Generation) Diagnostico a Bordo,

segunda generación.

8

2.1.2.1. Tipos de códigos

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.

El uso de Arduino en proyectos no obliga el uso de ordenador para la ejecución

del mismo aunque el posible el monitoreo de Arduino con distintos software

como Flash, MATLAB, LabView,etc.

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:

Xoscillo: Es un osciloscopio el mismo que es de tecnología abierta y

podría ser de gran utilidad en el ámbito automotriz.

10

Equipo científico para diversas aplicaciones de carácter investigativo:

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

Los fabricantes es decir cada uno de ellos tiene su propio protocolo de

comunicación, cada marca ha escogido uno de ellos y todos los

vehículos de esa marca poseen el mismo protocolo de modo que es

difícil o complicado saber con qué protocolo se comunica nuestro auto.

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

El OBD-II estas siglas corresponden a un protocolo tanto de

diagnóstico en el que incluyen varios protocolos de comunicación

este protocolo fue exigido por el Gobierno de EEUU cuya función

primordial es diagnosticar con respecto a las emisiones. El programa

basado en OBD-II funciona con variedad de marcas de automóviles,

mientras el VAG-COM usa un protocolo el mismo que es propiedad

de Volkswagen; funciona con VW, Audi, SEAT y Skoda. A pesar de

que se puede usar un programa de diagnóstico de OBD-II en todos

los automóviles fabricados a partir de 1996 es decir que sean

compatibles con OBD-II, el programa de OBD-II sólo va a generar

comunicación con el motor y en parte con la transmisión automática,

mas no con los demás sistemas electrónicos que posee el vehículo.

Es decir se necesitan más protocolos de comunicación incluidos en

el scanner o la programación del mismo con el fin de obtener los

códigos en Volkswagen se usa el protocolo VAG-COM.

12

2.4. COMUNICACIÓN BLUETOOTH

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

Siempre que los dispositivos estén próximos es decir dentro de

alcance los dispositivos que poseen este protocolo de comunicación

pueden comunicarse entre ellos. Las comunicaciones son

realizadas por medio de radiofrecuencia lo que posibilita que los

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.

Este módulo es identificado como USART (Universal Synchronous

Asynchronous Receiver Transmitter) y es de suma importancia para el

presente proyecto. El módulo USART posee compatibilidad con el protocolo

de comunicación RS232 el mismo que es muy utilizado en laptops.

14

Los modos de operación disponibles son los siguientes:

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.

Esta plataforma permite el desarrollo de aplicaciones por terceros (personas

ajenas a Google). Los desarrolladores deben escribir código gestionado en el

lenguaje de programación Java a través de la SDK que proporciona Google.

Una alternativa es el uso de la NDK (Native Development Kit) de Google para

hacer el desarrollo en el C en código nativo.

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)

La finalidad de uso de este sistema operativo es la realización de una

visualización completa la misma que se puede realizar tanto en Tablet como

16

Smarthphones, dado que los mismos poseen o cuentan con conexión

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

Los sensores de temperatura en el vehículo por lo general son del tipo

termistor, es decir son sensores resistivos los mismos que varían la resistencia

con respecto a la temperatura, a menor temperatura mayor es la resistencia

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

Estos sensores son del tipo piezoeléctrico, es decir que generan voltaje a

través de golpes o deformaciones que sufran estos sensores, son hechos de

cuarzo que es un material que posee las propiedades antes mencionadas, del

mismo modo las variaciones de voltaje que presenten o generen son enviadas

a la PCM y esta las interpreta y da respuesta a través de los actuadores.

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,

Los iones de oxígenos son recolectados por los electrodos y al trasportarse se

genera una variación de tensión la misma que va en márgenes de 0 voltios a

1 voltio

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

Figura 4. Conexión sonda lambda (Dany, 2014)

20

ONDA EN EL OSCILOSCOPIO

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

Es un sensor de tipo termistor es decir varían su voltaje y resistencia en

función de su temperatura. A medida que la temperatura va aumentando, la

resistencia y el voltaje en el sensor disminuyen.

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

Figura 6. Onda sonda lambda (Celis, 2013)

22

ONDA EN EL OSCILOSCOPIO

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.

La ECM identifica así la frecuencia recibida y gracias a esto le es posible

controlar el tiempo de la ignición como así también la cantidad de inyección

requerida reducir el golpeteo.

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

Figura 9. Conexión del KS (e-auto.com.mx, 2014)

24

ONDA EN EL OSCILOSCOPIO

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

Este sensor es un termistor esto quiere decir que puede ser NTC o PTC, el

99% de los vehículos poseen IAT NTC que conmutan negativo, este sensor

tiene que estar en contacto con el aire que ingresa a la admisión del vehículo

y lo que hace es dependiendo la temperatura del aire este varia su tensión y

resistencia, a mayor temperatura obtenemos menor tensión y menor

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

Figura 12. Onda del IAT (Mandy Concepcion, 2014)

26

2.7.3.5. Sensor de aceleración (TPS)

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

Figura 13. Conexión del TPS (e-auto.com.mx, 2014)

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

0,78 0

28

TABLA RESISTENCIA VS PORCENTAJE DE APERTURA

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

1,40 0

3. METODOLOGÍA

30

3.1. ADQUISICIÓN DE DATOS

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 utilizado

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.

Borrado 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

Figura 15. Diagrama de conexión (elmelectronics, 2014)

32

3.1.6. CARACTERÍSTICAS ELÉCTRICAS.

Tabla 4. Características eléctricas ELM327 (elmelectronics,

2014)

3.1.7. COMUNICACIÓN CON EL ELM327

El ELM327 tratará de comunicarse con la computadora a través de la

comunicación serial RS232, pero la computadoras modernas usualmente no

brindan una comunicación serial del tipo que se necesita, existen varias

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.

Para ver la lista completa de comandos refiérase al anexo 4

34

Tabla 5. Características eléctricas ELM327 (Caizatoa &

Mendez, 2014)

3.1.8.2. Comandos OBD

Si los bytes que se envían al ELM 327 no comienzan con las letras “A“ o “T“ ,

se asume que son comandos OBD para el vehículo, cada comando de bytes

ASCII serán comprobados con el fin de asegurar que solo dígitos

hexadecimales válidos se envíen , entonces se convertirán en bytes de datos

par asi ser transmitidos al vehículo.

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.

Dado que los resultados o las respuestas del ELM327 vienen en hexadecimal,

finalmente se debe manipular los resultados de alguna manera (la

combinación de bytes y dividiendo por 4 para obtener rpm, dividiendo por 2

para obtener grados de avance, la conversión de temperaturas, etc.). Existe

una tabla de PID que son los que se envían a la ECU, y cada uno de ellos

cuenta con su respectiva formula.

36

Tabla 6. Tabla de comandos OBDII (Caizatoa & Mendez,

2014)

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

Tabla 9. Tabla de comandos específicos para ISO (Caizatoa

& Mendez, 2014)

Tabla 10. Tabla de comandos específicos para ISO (Caizatoa

& 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:

1. Mostrar datos actuales.

2. Mostrar datos congelados.

3. Mostrar los códigos error.

4. Borrar códigos de error.

40

5. Resultados a la prueba de sensores de oxígeno.

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.

> AT SP 0

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.

Convertir el 7B hexadecimal a decimal, uno obtiene 7 x 16 + 11 = 123. Esto

representa la corriente la temperatura en grados centígrados, pero con el cero

compensado para permitir temperaturas bajo cero, para convertir a la

temperatura real del refrigerante, es necesario restar 40 a partir del valor que

nos responde el ELM327.

42

En este caso, entonces, el la temperatura del refrigerante es 123-40 o 83 ° C.

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.

Esto es posible ya que el ELM327 se encarga del formato de datos y la

traducción, a menos se vayan a realizar funciones más avanzadas, en realidad

no hay necesidad de saber con qué protocolo cuente el vehículo siempre y

cuando este se encuentre dentro de los 9 protocolos que soporta el ELM327.

Los ejemplos anteriores muestran sólo una sola línea de respuesta para cada

solicitud, pero las respuestas a menudo constar de varios mensajes

separados, ya sea desde múltiples ECUs respondiendo o de una ECU cuyos

mensajes necesitan ser combinados para formar una respuesta. De todos

modos para poder adaptarse a este número variable de respuestas, el ELM327

normalmente espera a ver si alguno más está llegando.

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.

Esto puede ahorrar una considerable cantidad de tiempo, ya que el tiempo

predeterminado para el temporizador AT ST es 200 ms. (El ELM327 todavía

establece el temporizador después el envío de la solicitud, pero eso es sólo

en caso de que la única respuesta solicitada no llegue.). (elmelectronics, 2014)

Algunos protocolos (como J1850 PWM) requiere el reconocimiento del

ELM327 para cada mensaje enviado. Si se proporciona un número para las

respuestas que es demasiado pequeño, el ELM327 responderá demasiado

pronto, esto puede causar congestión en el bus, mientras que la ECU intenta

el envío varias veces para volver a enviar los mensajes que no fueron

reconocidos.

44

Por esto razón, se debe saber cuántas respuestas esperar antes de utilizar

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

Las normas tanto la ISO 9141-2 e ISO 14230-4 (KWP2000) requieren que el

bus OBD del vehículo sea 'inicializado' antes de que cualquier comunicación

puede tener lugar. La norma ISO 9141 permite sólo un lento proceso de

iniciación (de 2 a 3 segundos), mientras que ISO 14230 permite tanto un

método lento y una alternativa más rápida.

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.

Por defecto, el ELM327 se asegura que estos "despertar" o mensajes

"ociosos" se envíen cada 3 segundos, pero esto se puede ajustar con el

comando AT SW.

46

El contenido del mensaje de activación también es programable por el usuario

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.

Por lo que cabe recalcar que, este byte cumple una doble función, con el bit

más significativo siendo utilizado para indicar que la luz indicadora de mal

funcionamiento (MIL, o "Check Engine Luz ') se ha encendido por uno de los

códigos de este módulo (si hay más de uno), mientras que el otro 7 bits de

este byte proporcionan el número real los códigos de problemas almacenados

pero no exactamente los actuales sino también los congelados. Con el fin de

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

Se debe tener en cuenta que la respuesta ha sido rellenado con de 00 como

es requerido por la norma SAE para este modo, los 0000 no representan

actuales códigos de falla.

48

Como cuando se solicita el número de códigos almacenados, los bits más

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)

Tomando el ejemplo de código de error (0201), el primer dígito (0) entonces

sería reemplazado por P0 y el 0201 se convertiría en P0201 (que es el código

para un 'falla en el circuito del inyector cilindro 1 ").

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

Las consecuencias del borrado de todos estos datos no es aplicable sólo al

ELM327 esto se produce cada vez que se utiliza cualquier herramienta de

análisis para restablecer los códigos. El mayor problema con la pérdida de

estos datos es que su vehículo puede funcionar mal por un corto tiempo,

mientras se lleva a cabo una re calibración.

50

Figura 16. Guía para detección y borrado de códigos de error

(Andrade F. , 2014)

Poner el vehiculo en "CONTACTO"

>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

PARA RESETEAR LOS CÓDIGOS

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.

Cuando se genera un error o un parámetro salga de los límites de

funcionamiento correcto o normal, la ECU es la encargada de almacenar dicha

falla, si la misma se repitiese el sistema OBDII informa al conductor a través

del check engine.

52

3.2.2. FUNCIONES DE DIAGNÓSTICO DEL OBDII EN VEHÍCULOS A

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.

Fallos en la combustión de los cilindros.

Calibración del comienzo de inyección.

Presión de la sobrealimentación.

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

Existe un modo de “funcionamiento en caso de emergencia” este se activa en

caso de avería, estos son los más importantes:

54

3.2.4.1. Sensor del pedal del acelerador

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

Todas las ECUS de las que se compone un sistema OBDII, son las

encargadas de monitorear y de diagnosticar los distintos sensores y

actuadores que compones los sistemas del vehículo debido a la disposición

de las mismas en el vehículo, resulta prácticamente imposible y absurdo el

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,

2014)

56

Encabezado: Como se muestra en la Figura 16 el encabezado utiliza 3 bytes

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.

Bytes de datos: Estos son los bytes que contienen la información solicitada y

están compuestos por 8 bytes de los cuales 7 contienen datos y uno de ellos

es utilizado para PCI.

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.

Figura 19. Ubicación de la luz indicadora (Check engine)

(Juliancho, 2014)

58

No existe un botón, pulsador, o manera alguna de restablecer o apagar la luz

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.

Figura 20. Ubicación del puerto OBDII (Alejandro, 2014)

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)

Con el fin de asegurar el diagnostico a bordo del vehículo es necesario y muy

importante la comunicación entre todos los sistemas electrónicos del vehículo,

es decir que las ECUS se comuniquen entre si y a la vez, respondan a un

60

procesador central el mismo que tendrá como función el análisis de los datos

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

IEBus

LIN

61

CAN

Intellibus

OBD-II Bus

SAEJ1708

BST

MML

Flex-ray

IDB-1394

Figura 22. Diagrama explicativo de función de buses en la

red de comunicaciones un vehículo (megatecpower, 2014)

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

ASIA CAN *********

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

Temperatura del refrigerante

64

Porcentaje de apertura de la mariposa

Posición de la mariposa

Temperatura del aire de ingreso

Presión de combustible

Tiempo de avance

Estos entre infinidad de valores más que se pueden monitorear en tiempo

real, para conocer estos valores es necesario enviar una solicitud a la ECU

en esta solicitud debe constar un PID el mismo que permite especificar qué

valor es el que se desea monitorear.

Las ECU son las encargadas de responder a esta solicitud con el último valor

que se haya sensado.

Figura 24. Solicitud y respuesta para acceso de datos a

bordo (Huertas & Véliz, 2006)

65

3.2.9. ACCESO A DATOS CONGELADOS

Esta función nos brinda la posibilidad de acceder, a los códigos de falla que la

ECU a almacenado en el momento de ocurrir la falla incluso si la falla luego

pareciera desapareces, es decir se tratase de una falla intermitente, la utilidad

de esta función es que se puede determinar bajo qué circunstancias ocurrió

dicha falla.

Tanto el mensaje que contiene la solicitud como el mensaje que posee la

respuesta es exactamente idéntico al anterior.

3.2.10. ACCESO A CÓDIGOS DE FALLA

Esta función permite acceder a los códigos de falla arrojados por las distintas

ECUS, el procedimiento para la obtención de los códigos de falla del vehículo

se resume en dos pasos, el primer paso es:

Enviar una solicitud con un PID

Esta solicitud lo que permite es conocer el número exactos de códigos de falla

que posee el vehículo en ese momento.

Entrar al modo 03 (realizar petición de códigos de falla)

El sistema OBDII nos proveerá los códigos de falla que posee el vehículo con

un máximo de 4 códigos, dado que en caso de la existencia de más códigos

el funcionamiento del vehículo sería prácticamente imposible o paupérrimo.

66

Figura. 25 Solicitud y respuesta para acceso a Códigos de

falla (Huertas & Véliz, 2006)

4. DISEÑO E IMPLEMENTACIÓN DEL PROTOTIPO

68

4.1. DISEÑO DEL PROTOTIPO

4.1.1. ARDUINO DUE

El Arduino Due es una placa electrónica basada en el Atmel SAM3X8E ARM

Cortex-M3 de la CPU. Es la primera placa Arduino basado en un

microcontrolador núcleo ARM de 32 bits. Cuenta con 54 pines digitales de

entrada / salida (de los cuales 12 pueden utilizarse para salidas PWM), 12

entradas analógicas, 4 UARTs (puertas seriales), un reloj de 84 MHz, una

conexión USB OTG capaz, 2 DAC (de digital a analógico), 2 TWI, un conector

de alimentación, una cabecera de SPI, un encabezado JTAG, un botón de

reinicio y un botón de borrado. Véase anexo 1 (Arduino, 2013).

Figura 26. Arduino DUE (Arduino, 2013)

4.1.2. SPARK FUN OBDII- UART

Esta tarjeta electrónica es la que nos brinda la posibilidad de interactuar con

el sistema OBDII del vehículo, nos brinda una interfaz en serial y permite el

acceso a la ECU mediante comandos, el ELM327, soporta los principales

69

protocolo OBDII, esta placa será conectada en uno de los extremos al conector

OBDII y en el otro al Arduino, accesando y procesando la información.

Figura. 27 SparkFun OBDII - UART (sparkfun, 2014)

4.1.2.1. ELM327

El ELM 327 es un microcontrolador de tipo PIC, cuya programación tiene la

función de interpretar los códigos mas no la evaluación de mensajes, su

principal función es la capacidad de crear una comunicación directa con la

ECU, mediante el puesto OBDII.

Cabe recalcar que para establecer comunicación con la computadora a bordo

se utiliza lenguaje ASCII.

70

Figura 28. Esquema de aplicación tradicional del ELM327

(elmelectronics, 2014)

71

4.1.2.2. MCP2551

La tarjeta Sparkfun contiene un integrado conocido como MCP2551 el mismo

que posee la capacidad de transmitir y receptar a alta velocidad en protocolo

CAN, su función principal es interpretar y convertir las señales lógicas en el

nivel de tensión o voltaje adecuado (TTL/CMOS), lo que significa que 0=0V y

1=1,5V, estas señales provienes desde el controlador CAN y por el BUS

Figura 29. MCP2551 (elmelectronics, 2014)

CARACTERÍSTICAS PRINCIPALES

a) Opera a un megabit por segundo.

b) Provee resistencia a daños por cortocircuito (negativo o positivo).

c) Alta exención al ruido.

d) Funcionalidad en temperaturas entre (-40 y 125) grados centígrados.

e) Función automática de apagado térmico.

72

DISTRIBUCIÓN DE LOS PINES DEL MCP2551

Figura 30. Distribución de pines MCP2551

(datasheetcatalog, 2014)

Tabla 14. Distribución de pines MCP2551 (Caizatoa &

Mendez, 2014)

73

4.1.3. CABLE OBDII- RS232

Para lograr establecer comunicación entre la placa SparkFun y el conector

OBDII es necesario el uso de un cable especial, esta normativa sobre los cable

o el conector es regida por la SAE (Sociedad de Ingenieros de América),

estableciendo así la necesidad del uso de un conector J1962. En este cable

conmutan la mayoría de los protocolos de conexión OBDII

. Figura 31. Cable OBDII-RS232 (Caizatoa & Mendez, 2014)

4.1.4. LCD 20 X 4 CON I2C

La LCD es una pantalla de cristal líquido la misma que es plana y delgada, se

encuentra formada por pixeles monocromos los mismos que están colocados

delate de la luz de fondo, se utilizará con el Arduino dada la compatibilidad y

la facilidad que brinda en cuanto a conexión se refiere y la baja cantidad de

energía que requiere para un correcto funcionamiento.

74

. Figura 32. LCD 20x4 con I2C (Andrade F. , 2014)

4.1.5. DIAGRAMA EXPLICATIVO DE CONEXIÓN

Figura 33. Diagrama explicativo de conexión (Andrade F. ,

2014)

OBDII

(Vehículo) •Envía y recive información

SparkFun

•Premite visualización de datos

Arduino •Comunicación serial

SeedBTslave y Bluetooth

Dispositivo

Android

75

4.1.6. DIAGRAMA DE CONEXIÓN DE HARDWARE Y COMUNICACIÓN

BLUETOOTH

Figura 34. Diagrama de conexión de hardware y

comunicación Bluetooth (Andrade F. , 2014)

4.1.7. APP INVENTOR

App inventor es una plataforma virtual la misma que es propiedad de Google

y trabajan en conjunto con el MIT (instituto de tecnología de Massachusetts).

Esta plataforma permite la creación y desarrollo de aplicaciones en formato

.apk, es decir aplicaciones ejecutables en sistema operativo Android, la misma

que se realizar a través del enlace de bloques.

Es decir las aplicaciones se las realizan mediante programación didáctica e

intuitiva, aunque las aplicaciones desarrolladas en esta plataforma son

simples, satisfacen las necesidades del usurario con respecto a su dispositivo

móvil.

76

Figura 35. App inventor (puravidaapps, 2015)

4.2. IMPLEMENTACIÓN DEL PROTOTIPO

Para realizar la implementación del prototipo, se tomó en cuenta dos factores

muy importantes la optimización de espacio y la funcionalidad del mismo de

modo que se realizó el montaje del mismo es una caja de proyectos

electrónicos tipo H, la misma que se modificó, retirando la cubierta superior de

color negro, y colocando un vidrio color bronce en lugar de la cubierta original,

todo esto se lo realizó con el fin de obtener visibilidad del interior de la misma,

dando acceso así a los leds de la placa SparkFun los que indican el envío y

recepción de datos, como la apertura y cierre del módulo Bluetooth, mismo

con el que se pareara el dispositivo móvil Android, mediante una aplicación

móvil (.apk) diseñada mediante app inventor.

77

Figura 36. Caja de proyectos tipo H modificada (Andrade F. ,

2014)

Posteriormente se procedió al anclaje de las placas que se usó para obtención

y petición de datos, tanto la placa Arduino DUE como la placa SparkFun fueron

ancladas a la cubierta inferior de la caja de proyectos mediante el uso de

postes para placas electrónicas.

Figura 37. Postes de anclaje para placas electrónicas

(mercadolibre, 2014)

A continuación se montó el Shield Bluetooth en el Arduino y se realizó las

conexiones necesarias mediante el uso de cable Arduino.

Del mismo modo se conectó el cable serial y el cable USB que hará la función

de fuente.

78

Figura 38. Placas montadas y conexiones en las mismas

(Andrade F. , 2014)

Una vez conectados todos los dispositivos necesarios para alimentación,

solicitud y recepción de datos se procedió a conectar la LCD la misma que

proporcionará información visual, como por ejemplo de los datos a bordo o nos

informará en que momento debemos revisar el dispositivo móvil.

Figura 39. Prototipo final (Andrade F. , 2014)

79

4.3. MANUAL DE PROCEDIMIENTOS

4.3.1. INSTALACIÓN DE LA APLICACIÓN EN ANDROID

En primer lugar lo que se debe hacer, es la instalación de la aplicación provista

en el CD, esta aplicación es las que nos permitirá la conexión con el scanner

por medio del Bluetooth del Dispositivo Android.

Figura 40. Aplicación provista en el CD (Andrade F. , 2014)

La aplicación debe ser trasferida desde el CD al Dispositivo Android por medio

del cable de datos o por Bluetooth, para que sea factible la instalación de la

aplicación primero seguimos este procedimiento:

80

Ajustes>>Seguridad>>Fuentes desconocidas.

Luego de activar dicha casilla la pantalla del dispositivo Android se vera como

muestra la Figura 41:

Figura 41. Ajustes Android (Andrade F. , 2014)

81

Una vez que tengamos la aplicación en el teléfono procedemos a buscarla con

el gestor de archivos propio del teléfono u cualquier otro gestor de archivos

descargado desde la Play Store, y nos encontraremos con un icono igual al

que se muestra en la Figura 42:

Figura 42. Aplicación en gestor de archivos Android

(Andrade F. , 2014)

82

Se procede a darle “click” al archivo “EscanerAutomotriz”.

El teléfono automáticamente desplegara una pantalla como la que se muestra

en la Figura 43:

Las opciones con respecto a los instaladores de aplicaciones varían según el

fabricante y las aplicaciones instaladas por el usuario.

Figura 43. Instalación de la aplicación (Andrade F. , 2014)

83

Se procede a escoger cualquier opción y se realizará automáticamente la

instalación de la aplicación, y la ejecutamos normalmente como cualquier

aplicación, al abrir la aplicación obtendremos una pantalla idéntica a la que

muestra la Figura 44; de preferencia se debe tener activado el bluetooth del

dispositivo movil.

Figura 44. Pantalla inicial de la aplicación (Andrade F. ,

2014)

84

Procedemos a darle “click “a ingresar y se nos desplegará la pantalla principal

de la aplicación con la que se puede realizar las funciones del prototipo antes

descritas. Véase Figura 45.

Figura 45. Pantalla principal de la aplicación (Andrade F. ,

2014)

4.3.2. USO DE LA APLICACIÓN Y EL PROTOTIPO.

Se procede a alimentar el prototipo mediante un cable USB y a conectar el

mismo con el puerto OBDII del vehículo y poner el vehículo en “contacto” es

decir con la llave del vehículo en posición ON.

Activamos el Bluetooth del dispositivo Android y se lo vincula con el prototipo,

el mismo que se llamará SeeedBTSlave.

85

En la pantalla principal de la aplicación presionamos “conectar” y se

desplegara una pantalla como la siguiente. Véase Figura 46.

Figura 46. Dispositivos Bluetooth (Andrade F. , 2014)

De modo que se presiona en “SeeedBTSlave” y la aplicación automáticamente

volverá a la pantalla principal.

Monitoreo.

Al presionar monitoreo la aplicación enviará la orden al prototipo, y los datos

a bordo (Velocidad, RPM, Temperatura), se mostraran automáticamente en la

LCD.

86

Lectura de errores.

Cabe recalcar que debido al extenso número de protocolos de comunicación

utilizados, este prototipo posee dos opciones (Scanner A y Scanner B),

logrando así abarcar más protocolos y por lo tanto más vehículos.

De modo que el botón “vector” que se encuentra en la pantalla principal sirve

para tener conocimiento si debemos ejecutar Scanner A o Scanner B.

Al presionar “vector” tenemos dos opciones si nos responde una serie de

caracteres similar a esta:

43 02 02 02 02 04

En la que en el cuarto carácter nos muestra el número de errores y luego

obviamente el error “0202” y “0204”.

Presionamos Scanner A.

Si al presionar “vector”, nos responde una serie de caracteres similar a esta:

43 01 07 01 22 00 00

En la que nos muestra 2 errores “0107” y”0122”, más en la 4ta posición no nos

muestra el número de errores.

Presionamos Scanner B.

Se procede a reparar el vehículo.

Borrado de códigos de Falla.

Una vez reparado el vehículo, en la pantalla principal de la aplicación se

encuentra el botón “Borrar DTC”.

Al presionar este botón borraremos los códigos de falla que posea el vehículo.

5. ANALISIS DE RESULTADOS

88

5.1. CHEVROLET AVEO 2009

Figura 47. Prueba datos a bordo, Chevrolet Aveo (Andrade

F. , 2014)

Como se puede observar en la imagen se ha realizado pruebas en un

Chevrolet Aveo del año 2009, en la misma que se logró acceder a los datos

de la PCM del vehículo.

En este caso a través de la aplicación del dispositivo móvil se logró acceder a

los datos a bordo del vehículo, y esta información es desplegada en la pantalla

de cristal líquido.

Lo que indica que el prototipo, es completamente compatible con este

vehículo, y se puede llevar a cabo todas las pruebas descritas anteriormente,

en este vehículo, desde nuestro dispositivo móvil

89

Figura 48. Solicitud de vector y numero de códigos de falla

en Chevrolet Aveo (Andrade F. , 2014)

Se solicitó a la PCM los códigos de falla del vehículo y como se puede ver en

la imagen el vehículo no presentaba códigos de diagnóstico.

90

5.2. KIA SPORTAGE 2011

Figura 49. Prueba datos a bordo, Kia Sportage (Andrade F. ,

2014)

Como se puede observar en la imagen se ha realizado pruebas en un Kia

Sportage del año 2011, en la misma que se logró acceder a los datos de la

PCM del vehículo.

91

Figura 50. Forzado de error, Kia Sportage

(Andrade F. , 2014)

Dado que después de realizar una solicitud, a la PCM del vehículo, esta nos

informó que el vehículo se encontraba en perfecto estado, forzar un error en

el vehículo seria lo óptimo.

Para realizar pruebas del prototipo en lo que a detección de códigos de falla y

borrado de códigos de diagnóstico concernía, se desconectó un sensor en el

vehículo, se lo apago y encendió tres ocasiones con un minuto de separación

entre cada una de ellas, con el fin de que se cumpla el ciclo de manejo y la

PCM del vehículo compruebe cada actuador y sensor de vehículo.

Se volvió a enviar una solicitud a la PCM y en esta ocasión nos respondió la

presencia de un código de falla.

En la siguiente figura se puede apreciar, la respuesta de la solicitud antes y

después de forzar el error en el vehículo.

Cabe recalcar que como se menciona en el manual de procedimientos se debe

tener en cuenta el vector respuesta, antes de seleccionar Scanner A o Scanner

B.

92

Figura 51. Solicitud vector y numero de errores, Kia Sportage

(Andrade F. , 2014)

Dado el vector respuesta de la PCM, se debe presionar scanner A, así

conoceremos exactamente donde se encuentra la falla en el vehículo.

Figura 52. Solicitud Scanner A, Kia Sportage (Andrade F. ,

2014)

93

Se procede a la reparación del fallo generado en el vehículo, (en este caso

desconexión de sensor de aceleración TPS).

Se enciende y apaga 3 veces el vehículo con una separación de un minuto, y

presionamos borrar DTC.

Se realiza un nuevo escaneo y el código habrá sido borrado.

Como se muestra en la siguiente figura.

Figura 53. Borrar DTC, Kia Sportage (Andrade F. , 2014)

94

5.3. FORD ECOSPORT 2007

Figura 54. Prueba datos a bordo, Ford Ecosport (Andrade F.

, 2014)

Como se puede observar en la imagen se ha realizado pruebas en un Ford

Ecosport del año 2007, en el mismo que se logró acceder a los datos de la

PCM del vehículo.

95

Figura 55. Forzado de error, Ford Ecosport

(Andrade F. , 2014)

Dado que después de realizar una solicitud, a la PCM del vehículo, esta nos

informó que el vehículo se encontraba en perfecto estado, forzar un error en

el vehículo seria lo óptimo.

Para realizar pruebas del prototipo en lo que a detección de códigos de falla y

borrado de códigos de diagnóstico concernía, se desconectó un sensor en el

vehículo, se lo apago y encendió tres ocasiones con un minuto de separación

entre cada una de ellas, con el fin de que se cumpla el ciclo de manejo y la

PCM del vehículo compruebe cada actuador y sensor de vehículo.

Se volvió a enviar una solicitud a la PCM y en esta ocasión nos respondió la

presencia de un código de falla.

En la siguiente figura se puede apreciar, la respuesta de la solicitud antes y

después de forzar el error en el vehículo.

Cabe recalcar que como se menciona en el manual de procedimientos se debe

tener en cuenta el vector respuesta, antes de seleccionar Scanner A o Scanner

B.

96

Figura 56. Solicitud vector y numero de errores, Ford

Ecosport (Andrade F. , 2014)

Dado el vector respuesta de la PCM, se debe presionar scanner A, así

conoceremos exactamente donde se encuentra la falla en el vehículo.

Figura 57. Solicitud Scanner A, Ford Ecosport (Andrade F. ,

2014)

97

Se procede a la reparación del fallo generado en el vehículo, (en este caso

desconexión de inyector del cilindro numero 4).

Se enciende y apaga 3 veces el vehículo con una separación de un minuto, y

presionamos borrar DTC.

Se realiza un nuevo escaneo y el código habrá sido borrado.

Como se muestra en la siguiente figura.

Figura 58. Borrar DTC, Ford Ecosport (Andrade F. , 2014)

6. CONCLUSIONES Y RECOMENDACIONES

99

6.1. CONCLUSIONES

Es viable la creación de tecnología automotriz, y tecnología afín,

mediante la utilización de dispositivos existentes en el mercado, y un

plan de investigación definido, logrando así demostrar que el desarrollo

automotriz dentro del país y de la Universidad Tecnológica Equinoccial

es factible.

Se construyó el prototipo de un scanner automotriz, bajo parámetros

técnicos y ergonómicos, teniendo en cuenta la optimización del volumen

que ocuparía, la visibilidad, la comodidad en pruebas de ruta y la

facilidad de lectura de códigos.

Cada generación de ECU posee su propio protocolo de comunicación

lo que hace sumamente difícil la compatibilidad de cualquier scanner

automotriz con absolutamente todo el parque automotor existente, pero

no obstante se ha logrado compatibilidad con aproximadamente el 90%

del parque automotor, refiriéndonos a vehículos a gasolina fabricados a

partir del 2005, y un 50% con vehículos fabricados anteriormente o que

posean protocolos obsoletos, mismos que no son capaces de brindar

todas las facilidades y todos los datos que los protocolos actuales

proveen.

Dada la alta tasa de renovación vehicular que existe actualmente en el

país, se concluye que es un proyecto viable y utilitario en la misión de

diagnosticar fallas de manera técnica en los vehículos.

La tecnología inalámbrica está en auge en nuestro tiempo dada la

comodidad que provee, por lo cual la lectura de los códigos de falla y el

borrado de los mismos se los podrá realizar inalámbricamente mediante

el uso de la aplicación provista con el presente proyecto mismo que es

ejecutable o compatible con sistema operativo Android.

100

6.2. RECOMENDACIONES

El voltaje para la alimentación externa de esta placa debe estar

comprendido entre los 6V como mínimo y los 12V como máximo,

viniendo a ser este el voltaje de alimentación recomendado pero de

ninguna manera el límite, dado que el límite inferior está establecido en

5V y el límite superior en 16V

El uso del scanner automotriz a pesar de ser completamente intuitivo,

es recomendable se lo realice, después de haber leído y comprendido

el manual de operación que se provee en el presente trabajo de

titulación.

En caso de apertura de la caja de proyectos y de tener acceso a la placa

Arduino, se recomienda que bajo ninguna circunstancia se presione el

pulsador “erase”, esto podría generar pérdidas en la base de datos del

Arduino, o fallas en la programación.

Para un correcto funcionamiento se recomienda, conectarse via

Bluetooth con el prototipo antes de empezar a trabajar.

Se recomienda el incentivo en prácticas y desarrollo de proyectos de

este tipo, con el fin de promover el uso y desarrollo de tecnología para

el diagnóstico automotriz.

101

GLOSARIO DE TÉRMINOS

OBDII Sistema de diagnóstico a bordo.

ECT Sensor de temperatura de refrigerante del motor.

KS Sensor de golpeteo del motor.

IAT Sensor de temperatura del aire de admisión.

TPS Sensor de posición de la aleta de aceleración.

ECU Unidad de control del motor.

ECM Módulo de control del motor.

PCM Módulo de control del ten de potencia.

LCD Pantalla de cristal líquido.

RPM Revoluciones por minuto.

I2C Bus de comunicaciones en serie.

UART Transmisor-Receptor Asíncrono Universal.

ELM327 Microcontrolador programado para acceder a la PCM.

SAE Sociedad de Ingenieros Automotrices.

ANEXOS

ANEXO 1

104

105

106

107

108

ANEXO 2

110

111

112

ANEXO 3

114

115

ANEXO 4

117

118

119

120

ANEXO 5

122

123

124

125

126

ANEXO 6

128

BIBLIOGRAFÍA

130

Alejandro. (26 de 10 de 2014). http://www.teseomotor.com/ubicacion-conector-obd/. Obtenido de http://www.teseomotor.com/ubicacion-conector-obd/: http://www.teseomotor.com

Andrade, F. (2011). Sensores. Andrade, F. (17 de Octubre de 2014). Arduino. (28 de 10 de 2014). Recuperado el 22 de Octubre de 2013, de

Arduino: http://www.Arduino.cc/es/ Arduino. (s.f.). Amazon.com. Recuperado el 22 de Octubre de 2013, de

http://www.amazon.com/Arduino-A000062-Due/dp/B00A6C3JN2/ref=sr_1_2?ie=UTF8&qid=1382412054&sr=8-2&keywords=arduino+due

Bosch, R. (2005). Manual de la Tecnica del automovil. Leonberg: Bauer & Partner.

Boxall, J. (2013). Arduino Workshop. San Francisco, USA: Library of congress cataloging.

Caizatoa, M., & Mendez, X. (24 de 10 de 2014). repositorio.espe.edu.ec. Obtenido de repositorio.espe.edu.ec

Castellanos, L. (26 de 02 de 2014). Tecnologia al dia. Recuperado el 22 de Octubre de 2013, de http://tecnologiaaldia.wordpress.com/2009/09/14/que-es-android/

Celis, E. (14 de 9 de 2013). automecanico.com. Recuperado el 21 de Octubre de 2013, de http://automecanico.com/auto2003/obdll.html

Dany. (29 de 07 de 2014). aficionadosalamecanica.com. datasheetcatalog. (29 de 10 de 2014). datasheetcatalog.com. Obtenido de

datasheetcatalog.com: datasheetcatalog.com e-auto.com.mx. (29 de 07 de 2014). http://e-auto.com.mx/. elmelectronics. (21 de 09 de 2014). elmelectronics.com. Obtenido de Elm

Electronics. González Melis, P. (30 de 10 de 2014). http://tec.upc.es/eau/OBDII.pdf. Hernandez, H. H. (s.f.). www.prezi.com. Recuperado el 22 de Octubre de

2013, de http://prezi.com/a4q17ejexk6j/diagnostico-scanner-automotriz/

hetpro. (25 de 02 de 2014). http://hetpro-store.com/index.php?option=com_content&view=article&id=%2023&Itemid=&lang=en. Obtenido de http://hetpro-store.com/index.php?option=com_content&view=article&id=%2023&Itemid=&lang=en: http://hetpro-store.com/index.php?option=com_content&view=article&id=%2023&Itemid=&lang=en

Huertas, E., & Véliz, F. (2006). Sistema Monitor Remoto Interactivo de Vehiculos.

131

Juliancho. (26 de 10 de 2014). http://www.stcolombia.com/portal/proyectos-foristas-street-tuning/37161-jetta-1-8-rojo-tornado-2.html. Obtenido de http://www.stcolombia.com/portal/proyectos-foristas-street-tuning/37161-jetta-1-8-rojo-tornado-2.html: http://www.stcolombia.com

Mandy Concepcion, A. D. (29 de 07 de 2014). diycardoctor.com. Margolis, M. (2011). Arduino Cookbook. Sebastopol: O'reilly. MAzo, M., Espinoza, F., Baset, A., & Gardel, A. (27 de 10 de 2014).

https://espacioseguro.com/fundacionfitsa0/admin/_fitsa/archivos/publicaciones/0000034/Libro%20diagnosis%20electronica.pdf. Obtenido de https://espacioseguro.com/fundacionfitsa0/admin/_fitsa/archivos/publicaciones/0000034/Libro%20diagnosis%20electronica.pdf: https://espacioseguro.com

megatecpower. (27 de 10 de 2014). http://www.tecnomovil.com/Cursos-formacion/Garantia%20mecanica/Mecanica%20avanzada%20II/Mecanica%20avanzada%20II_archivos/image018.jpg. Obtenido de http://www.tecnomovil.com/Cursos-formacion/Garantia%20mecanica/Mecanica%20avanzada%20II/Mecanica%20avanzada%20II_archivos/image018.jpg: http://www.tecnomovil.com

mercadolibre. (26 de 12 de 2014). mercadolibre.com. Obtenido de mercadolibre.com: http://articulo.mercadolibre.com.mx/MLM-476491395-6-postes-o-patitas-para-tarjeta-electronica-pcb-arduino-pic-_JM

Robot. (s.f.). amazon.com. Recuperado el 22 de Octubre de 2013, de http://www.amazon.com/Robot-Non-contact-Liquid-Level-Switch/dp/B00C0Q6Q1E/ref=sr_1_3?ie=UTF8&qid=1382412376&sr=8-3&keywords=obd+ii+arduino

Rodríguez, I. C. (27 de 07 de 2014). slideshare.com. Rodriguez, L. (24 de 10 de 2014).

http://issuu.com/diegoquemero/docs/auto_elec_ok. Obtenido de http://issuu.com/diegoquemero/docs/auto_elec_ok: http://issuu.com

seeed. (s.f.). Amazon.com. Recuperado el 22 de Octubre de 2013, de http://www.amazon.com/Bluetooth-Shield-for-Arduino/dp/B007BYI172/ref=dp_return_2?ie=UTF8&n=541966&s=pc

sparkfun. (28 de 10 de 2014). https://www.sparkfun.com/products/9555. Obtenido de https://www.sparkfun.com/products/9555: https://www.sparkfun.com

Tarnok, F. (s.f.). http://www.multiscanners.cl. Obtenido de http://www.multiscanners.cl/atecnicos/conector2.htm.