C. EDGAR EDUARDO GONZALEZ LIZARRAGA
54
TESINA OPTIMIZACION DE FUNCIONES Y ALGORITMOS DE PROGRAMACION PARA EL PROTOCOLO DE COMUNICACIÓN CAN ENTRE MCU DE 16 BITS Y UNIDAD DE CONTROL DE MOTOR QUE PRESENTA C. EDGAR EDUARDO GONZALEZ LIZARRAGA EN CUMPLIMIENTO PARCIAL DE LA ESTADÍA PRÁCTICA DE INGENIERÍA MECATRÓNICA ASESOR ACADÉMICO M.C. ALEJANDRO LIZARRAGA LIZARRAGA ORGANISMO RECEPTOR PYANSA S.A. DE C.V. Mazatlán, Sin. 9 de Diciembre de 2016
Transcript of C. EDGAR EDUARDO GONZALEZ LIZARRAGA
TESINA
OPTIMIZACION DE FUNCIONES Y ALGORITMOS DE
PROGRAMACION PARA EL PROTOCOLO DE COMUNICACIÓN
CAN ENTRE MCU DE 16 BITS Y UNIDAD DE CONTROL DE MOTOR
QUE PRESENTA
C. EDGAR EDUARDO GONZALEZ LIZARRAGA
EN CUMPLIMIENTO PARCIAL DE LA
ESTADÍA PRÁCTICA DE
INGENIERÍA MECATRÓNICA
ASESOR ACADÉMICO
M.C. ALEJANDRO LIZARRAGA LIZARRAGA
ORGANISMO RECEPTOR
PYANSA S.A. DE C.V.
Mazatlán, Sin. 9 de Diciembre de 2016
iv
RESUMEN
“OPTIMIZACION DE FUNCIONES Y ALGORITMOS DE PROGRAMACION
PARA EL PROTOCOLO DE COMUNICACIÓN CAN ENTRE MCU DE 16 BITS Y
UNIDAD DE CONTROL DE MOTOR”
Edgar Eduardo González Lizárraga
Unidad Académica de Ingeniería Mecatrónica
Universidad Politécnica de Sinaloa
Mazatlán, Sinaloa, Diciembre 2016
Asesor: M.C Alejandro Lizárraga Lizárraga
La estadía fue realizada en PYANSA S.A. de C.V. en el departamento de innovación
investigación y desarrollo (i+I+D), en el proyecto “optimización de funciones y
algoritmos de programación para el protocolo de comunicación CAN entre MCU de 16
bits y unidad de control de motor”, donde por medio de investigación, pruebas de
laboratorio y campo, se detectó problemas y puntos de programación que impiden un
correcto funcionamiento del microcontrolador al momento de realizar una
comunicación mediante protocolo CAN con la unidad de control de motor de un
vehículo. El motivo de la realización del proyecto fue la detección de errores de
programación, así como la mejora y optimización del código de programa y lograr una
comunicación y lectura de información exitosa para su implementación en vehículos
reales fuera del laboratorio, así como la corroboración de los parámetros obtenido por
el programa en comparación con otros medios de obtención de datos.
v
INDICE
I. INTRODUCCIÓN ______________________________________________________ 10
1.1. Antecedentes de la empresa ____________________________________________ 11
1.2. Departamento de i+I+D _______________________________________________ 11
II. MARCO TEORICO _____________________________________________________ 13
2.1. CAN Bus __________________________________________________________ 13
2.1.1. Historia del CAN Bus _____________________________________________ 13
2.1.2. Niveles de tensión del bus _________________________________________ 14
2.1.3. Tasa de transferencia _____________________________________________ 15
2.1.4. Tipo de tramas __________________________________________________ 16
2.1.5. Trama de datos __________________________________________________ 17
2.1.6. Formato extendido _______________________________________________ 19
2.1.7. Bit de relleno ___________________________________________________ 20
2.2. Unidad de control de motor ____________________________________________ 21
2.3. Códigos de fallas ____________________________________________________ 22
III. DESARROLLO DE PROYECTO ________________________________________ 25
3.1. Objetivos del proyecto ________________________________________________ 26
3.2. Comunicación usuario-MCU ___________________________________________ 27
3.3. Simulador de ECU ___________________________________________________ 31
3.3.1. Fuente de voltaje _________________________________________________ 32
3.4. Problemas del prototipo _______________________________________________ 34
3.5. Modificaciones ______________________________________________________ 35
3.5.1. Implementación de banderas en ciclos while ___________________________ 35
3.5.2. Modificación de función DTC ______________________________________ 38
3.5.3. Configuración de Timer para DTC ___________________________________ 39
3.6. Pruebas de campo ___________________________________________________ 42
3.6.1. Códigos de fallas ________________________________________________ 42
3.6.2. Interpretación de DTC ____________________________________________ 43
3.6.3. Kilometraje _____________________________________________________ 46
3.6.4. Tiempo de encendido del motor _____________________________________ 47
vi
3.7. Resultados y observaciones ____________________________________________ 49
IV. BIBLIOGRAFÍA _____________________________________________________ 50
vii
INDICE DE FIGURAS
Figura 2.1. Niveles de tensión del bus CAN. ___________________________________ 14
Figura 2.2. Conexión de nodos en el bus CAN. ________________________________ 15
Figura 2.3. Trama CAN en formato estándar. __________________________________ 17
Figura 2.4. Trama CAN antes y después de la adición de bit de relleno. ___________ 21
Figura 2.5. Unidad de control de motor. ______________________________________ 22
Figura 2.6. Código de falla.__________________________________________________ 25
Figura 3.1. Módulos de un sistema embebido. _________________________________ 26
Figura 3.2. Convertidor USB-Serial y modulo bluetooth respectivamente. _________ 27
Figura 3.3. Interfaz de Docklight. ____________________________________________ 28
Figura 3.4. Ejemplo de trama. _______________________________________________ 28
Figura 3.5. Sistema de comunicación usuario-ECU _____________________________ 30
Figura 3.6. Simulador ECU. _________________________________________________ 31
Figura 3.7. Configuración del LM317. ________________________________________ 32
Figura 3.9. Fuente de voltaje a 12V. __________________________________________ 33
Figura 3.8. LM317 a 12V. ___________________________________________________ 33
Figura 3.10. Visualización del bus CAN. ______________________________________ 34
Figura 3.11. Lógica de un ciclo while. _________________________________________ 35
Figura 3.12. Lógica de programación. ________________________________________ 36
Figura 3.13. Lógica de programación con "timeout". ____________________________ 37
Figura 3.14. Implementación de "timeout". ____________________________________ 38
Figura 3.15. Antes y después de la lógica de programación. _____________________ 39
Figura 3.16. Registros de configuración de timer. ______________________________ 40
Figura 3.17. Habilitación de interrupción por timer. ____________________________ 41
Figura 3.18. Interrupción por timer 5. _________________________________________ 42
viii
Figura 3.20. Conector OBD II de la camioneta. _________________________________ 43
Figura 3.19. Códigos de fallas por scanner. ____________________________________ 43
Figura 3.21. DTC's. _________________________________________________________ 44
Figura 3.22. Conversión de hexadecimal a binario. _____________________________ 44
Figura 3.23. Trama del kilometraje, parámetros resaltados en amarillo. ___________ 46
Figura 3.24. Indicador de kilometraje del vehículo. _____________________________ 47
Figura 3.25. Parámetros del tiempo de encendido del motor. ____________________ 48
Figura 3.26. Captura de tiempo con cronometro. _______________________________ 48
ix
INDICE DE TABLAS
Tabla 2.1. Relación longitud-tasa de transferencia. _____________________________ 15
Tabla 2.2. Formato de trama estándar. ________________________________________ 18
Tabla 2.3. Formato de trama extendido. _______________________________________ 19
Tabla 2.3. Formato de trama extendido (continuación). _________________________ 20
Tabla 2.4. Sistema donde se encuentra el DTC. _________________________________ 23
Tabla 2.5. Tipo de código. ___________________________________________________ 24
Tabla 2.6. Subsistemas. _____________________________________________________ 24
Tabla 3.1. Estructura de la trama. ____________________________________________ 29
Tabla 3.2. Primer Carácter. __________________________________________________ 45
Tabla 3.3. Segundo carácter. _________________________________________________ 45
Tabla 3.4. Tercer, cuarto y quinto carácter. ____________________________________ 45
Tabla 3.5. Conversión de DTC de trama CAN. _________________________________ 46
Tabla 3.6. Resultados de pruebas. ____________________________________________ 49
10
I. INTRODUCCIÓN
PYANSA S.A. de C.V. es una empresa que forma parte del Grupo Alerta, el cual
cuenta con más de 60 años de experiencia sirviendo al sector energético en la
distribución del Gas Licuado de Petróleo (LP), con empresas como Gaspasa y Diesgas,
que tienen presencia en los estados de Sinaloa, Baja California, Sonora, Querétaro,
Guanajuato y Jalisco. El objetivo principal de PYANSA es proveer los servicios
profesionales administrativos, científicos y técnicos a todas las empresas del grupo,
generando proyectos innovadores que permitan brindar soluciones efectivas, a través
de la aplicación de tecnología de vanguardia y las habilidades necesarias que faciliten
la resolución de problemas en las diferentes áreas de negocios de las empresas del
grupo, quienes demandan soluciones tecnológicas, agiles y flexibles, que les generen
una ventaja competitiva, expandan sus mercados, faciliten la productividad y aseguren
la continuidad del negocio. Aunque los principales desarrollos de PYANSA están
dirigidos a cubrir las necesidades de las empresas distribuidoras de gas, también se ha
incursionado en otros sectores como el agroindustrial y las telecomunicaciones, con
proyectos como Basculas Agrícolas y Antenas Selectivas.
Gracias a la estrategia organizacional del grupo, basada en la innovación
tecnológica continua con un enfoque de satisfacción a los clientes y en la generación de
lealtad y confianza, se ha logrado ubicar a la empresa distribuidoras gas entre las 20
empresas más importantes del país y son líderes en la región Noroeste.
11
1.1. Antecedentes de la empresa
El Grupo Alerta tuvo sus inicios en la ciudad de Culiacán con el establecimiento de
Gas del Pacifico en julio de 1953, gracias a la visión y espíritu emprendedor de su
fundador don Rodolfo Rodríguez Amold, quien se aventuró al reto de introducir el uso
de gas licuado de petróleo (LP) en una sociedad que solo conocía los métodos
tradicionales para cocinar y generar calor, la leña y el petróleo, combustibles que
ahumaban las casas, impregnaban los alimentos y que eran lentas para cocer y calentar
los alimentos, además de ser un riesgo para la salud de los habitantes del hogar y
generar daño al medio ambiente. La empresa de gas fue la precursora de todo lo que
ahora es el Grupo Alerta, que actualmente está conformado por ocho giros, siendo el
más grande de ellos la distribución de gas LP. Con el crecimiento de la demanda de
usuario de gas LP y la entrada de competidores en la zona fue necesario el
establecimiento de mejores estrategias para seguir siendo un negocio rentable y ofrecer
un buen servicio a los clientes. En 1984 se constituye PYANSA, una empresa cuyo
objetivo era la concentración de los servicios tecnológicos, incluyendo la
automatización del área contable y la generación de tecnologías propias que permitan
la comercialización del gas LP, midiendo contabilidad, informática e investigación y
desarrollo, esta diversidad ha sido la base del éxito en el desarrollo de proyectos, que
contemplan cada vez más la integración entre diferentes disciplinas.
1.2. Departamento de i+I+D
El desarrollo de la tecnología es un ámbito en el que las empresas del Grupo Alerta
han invertido importantes esfuerzos, con la convicción de que es uno de los caminos
más sólidos para mantenerse en un nivel óptimo de competitividad y ofrecer mejores
productos a sus clientes. Como estrategia empresarial, muchas empresas optan por
ofrecer descuentos, pero la organización ha elegido no hacerlo, porque a largo plazo
12
esto significa el deterioro del equipo y de transporte, y la adaptación de los sueldos del
personal, por lo que se ha optado por trabajar hacia adentro: en los valores, en la
tecnología, y en reforzar la idea entre los clientes de que los productos que se venden
tienen un valor agregado.
El personal dedicado a investigación y desarrollo de la tecnología de Grupo Alerta
se concentra en PYANSA que es una parte fundamental para estar a la vanguardia y
desarrollar sus propias herramientas y recursos. El departamento de i+i+D de PYANSA
está conformado por un grupo de ingenieros de diversas especialidades, con mayor
enfoque en el diseño electrónico, mecatrónica e informática. Los proyectos
desarrollados por el departamento de i+i+D, incluyen el planteamiento de
requerimientos, determinación de las especificaciones técnicas de diseño, planeación
de las pruebas a realizar, desarrollo de Firmware y Software, diseño electrónico y
mecánico, fabricación de prototipos, pruebas de laboratorio y pruebas de campo, así
como toda la documentación necesaria (certificaciones y manuales) para sacar los
nuevos productos del mercado.
13
II. MARCO TEORICO
2.1. CAN Bus
CAN Bus es un protocolo de comunicación en serie desarrollado por Bosch en los
años 80 para el intercambio de información entre unidades de control electrónicas del
automóvil, aunque actualmente ya ha despertado el interés de otros sectores como el
área de control y automatización industrial. Se utiliza además como base para
arquitecturas de bus industrial en aplicaciones de tiempo real distribuidas, sistemas de
supervisión continua y control en el ámbito de producción.
CAN significa Controller Area Network (Red de área de control) y Bus, en
informática, se entiende como un elemento que permite transportar información.
La robustez del bus CAN se basa en su arquitectura multimaestro. Este sistema
permite compartir una gran cantidad de información entre los diferentes módulos de
control conectados a la red, lo que provoca una reducción importante tanto del número
de sensores utilizados como de la cantidad de cables que componen la instalación
eléctrica, de esta forma aumenta considerablemente las funciones actuales en los
sistemas del automóvil donde se emplea el CAN Bus sin aumentar los costos, además
de que estas funciones pueden estar repartidas entre dichos módulos.
2.1.1. Historia del CAN Bus
El desarrollo del protocolo CAN comenzó en 1983 en la empresa Robert Bosch
GmbH (comúnmente conocida como Bosch). El protocolo fue oficialmente lanzado en
1986 en el congreso de la Sociedad de Ingenieros Automotrices (SAE) en Detroit. Desde
entonces, CAN se ha convertido en uno de los protocolos líderes en la utilización del
bus serie.
14
A comienzos de los 80, los ingenieros de Bosch evaluaron el posible uso de los
sistemas de bus serie existentes en los coches de pasajeros, pero ninguno de los
protocolos de red disponibles satisfacía los requisitos de estos.
Este protocolo de bus serie de ideo principalmente para aportar mayor
funcionalidad, seguridad y fiabilidad, junto a una mayor eficiencia en el gasto del
combustible, ya que la reducción del peso y la complejidad de los automóviles a través
de la reducción del cableado iban a favorecer este hecho. (Soriano)
2.1.2. Niveles de tensión del bus
La transmisión de señales en un bus CAN se lleva a cabo a través de dos cables
trenzados. Las señales de estos cables se denominan CAN_H (CAN high) y CAN_L
(CAN low) respectivamente. El bus tiene dos estados definidos: estado dominante y
estado recesivo. En estado recesivo, los dos cables del bus se encuentran al mismo nivel
de tensión, mientras que en estado dominante hay una diferencia de tensión entre
CAN_H y CAN_L de al menos 1.5 V como se puede apreciar en la Figura 2.1, la
transmisión de señales en forma de tensión diferencial, en comparación con la
Figura 2.1. Niveles de tensión del bus CAN.
15
transmisión en forma de tensiones absolutas, proporciona protección frente a
interferencias electromagnéticas.
2.1.3. Tasa de transferencia
Los distintos nodos de un bus CAN deben estar interconectados mediante un par
de cables trenzados con una impedancia características de 120 Ω (Figura 2.2), y puede
ser cable apantallado o sin apantallar. El cable trenzado proporciona protección frente
a interferencias electromagnéticas externas.
Las propiedades de la línea de transmisión limitan el ancho de banda de los datos.
Orientativamente, se aceptan los valores de la Tabla 2.1 como límite de longitud del
bus en función de la tasa de transferencia.
Tabla 2.1. Relación longitud-tasa de transferencia.
Tasa de transferencia
(Kbit/s)
Longitud del bus (m) Tiempo de bit (µs)
1000 30 1
800 50 1.25
500 100 2
250 250 4
125 500 8
62.5 1000 20
20 2500 50
10 5000 100
Figura 2.2. Conexión de nodos en el bus CAN.
16
2.1.4. Tipo de tramas
El protocolo CAN está basado en mensajes, no en direcciones. El nodo emisor
transmite el mensaje a todos los nodos de la red sin especificar un destino y todos
ellos escuchan el mensaje para luego filtrarlo según le interese o no.
Existen distintos tipos de tramas predefinidas por CAN para la gestión de la
transferencia de mensajes:
Trama de datos.
Trama de información remota.
Trama de error.
Trama de sobrecarga.
En un bus CAN los nodos transmiten la información espontáneamente con tramas
de datos, bien sea por un proceso cíclico o activado ante eventos en el nodo. (Arroyo,
2005)
17
2.1.5. Trama de datos
CAN tiene dos formatos diferentes para transmitir datos: el formato de trama
estándar (Figura 2.3), según la especificación CAN 2.0A y, el formato de trama
extendida según la especificación CAN2.0B. la principal diferencia entre ambos es la
longitud del identificador del mensaje (ID), que en el caso de la trama estándar es de
11 bits y en el caso de la extendida es de 29 bits.
El estándar dice que un controlador CAN debe aceptar tramas en formato base, y
puede o no aceptar tramas en formato extendido. Pero en cualquier caso debe tolerar
tramas en formato extendido. Es decir, que si un controlador está configurado para que
solo acepte tramas en formato base no debe lanzar un error cuando reciba una trama
en formato extendido, sino que simplemente no transmitirá el mensaje al procesador
central, en la Tabla 2.2 se observa la estructura que componen a la trama estándar.
Figura 2.3. Trama CAN en formato estándar.
18
Tabla 2.2. Formato de trama estándar.
Nombre del campo Longitud
(bits)
Finalidad
Inicio de trama 1 Demarca el comienzo de una transmisión
Identificador - ID 11 Un identificador (único) que también representa la
prioridad de la trama
Petición de
transmisión remota -
RTR
1 Dominante (0) para tramas de datos y recesivo (1) para
tramas de peticiones remotas.
Bit de extensión de
identificador – IDE
1 Dominante (0) para el formato base (identificador de 11
bits)
Bit reservado (r0) 1 Bit reservado. Deber ser dominante (0), pero aceptado
tanto dominante como recesivo.
Código de longitud
de datos - DLC
4 Numero de bytes de datos en el mensaje, entre 0 y 8. Si
este campo es mayor que 8 el mensaje será de 8 byte
como máximo de cualquier modo.
Campo de datos 0-64 (0-8
bytes)
Datos de la trama
CRC 15 Verificación por redundancia cíclica.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de
recibido – ACK
1 El transmisor emite recesivo (1) y cualquier receptor
emite dominante (0).
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama EOF 7 Debe ser recesivo (1).
19
2.1.6. Formato extendido
En el formato extendido los dos campos de identificador se combinan para formar
el identificador de 29 bits. El formato de la trama se puede apreciar en la Tabla 2.3.
Tabla 2.3. Formato de trama extendido.
Nombre del campo Longitud
(bits)
Finalidad
Inicio de trama 1 Demarca el comienzo de una transmisión
Identificador A – ID_A 11 Primera parte del identificador (único) que
también representa la prioridad de la trama.
Sustituto de transmisión
remota – SRR
1 Debe ser recesivo (1).
Bit de extensión de
identificador – IDE
1 Recesivo (1) para el formato extendido
(identificador de 29 bits).
Identificador B – ID_B 18 Segunda parte del identificador (único) que
también representa la prioridad de la trama.
Petición de transmisión
remota – RTR
1 Dominante (0) para tramas de datos y
recesivo (1) para tramas de peticiones
remotas.
Bits reservados (r1, r0) 2 Bit reservado. Debe ser dominante (0), pero
aceptado tanto dominante como recesivo.
20
Tabla 2.3. Formato de trama extendido (continuación).
Código de longitud de
datos – DLC
4 Numero de bytes de datos en el mensaje,
entre 0 y 8. Si este campo es mayor que 8 el
mensaje será de 8 bytes como máximo de
cualquier modo.
Campo de datos 0-64 (0-
8 bytes)
Datos de la trama.
CRC 15 Verificación por redundancia cíclica.
Delimitador CRC 1 Debe ser recesivo (1).
Hueco de acuse de
recibido – ACK
1 El transmisor emite recesivo (1) y cualquier
receptor emite dominante (0).
Delimitador ACK 1 Debe ser recesivo (1).
Fin de trama – EOF 7 Debe ser recesivo (1).
2.1.7. Bit de relleno
Para asegurar que hay suficientes transiciones recesivo-dominante y garantizar
así la sincronización, un bit de polaridad opuesta es insertado después de cinco bits
consecutivos de la misma polaridad. Esta práctica es necesaria debido a la
codificación sin vuelta a cero del protocolo CAN. Los bits insertados son eliminados
21
por el receptor. La regla de los bits de relleno implica que una trama puede ser más
larga de lo esperado si se suman los bits teóricos de cada campo de la trama, esto se
puede observar en la Figura 2.4.
2.2. Unidad de control de motor
La unidad de control de motor o ECU (sigla en inglés de Engine Control Unit) es una
unidad de control electrónico que administra varios aspectos de la operación de
combustión interna del motor. Las unidades de control de motor más simples sólo
controlan la cantidad de combustible que es inyectado en cada cilindro en cada ciclo
de motor. Las más avanzadas controlan el punto de ignición, el tiempo de
apertura/cierre de las válvulas, el nivel de impulso mantenido por el turbocompresor,
y control de otros periféricos.
Se puede definir una ECU como la unidad de control electrónico que regula al
motor. Esto se traduce de una manera sencilla definiéndolo como el corazón de un
complejo sistema electrónico compuesto por sensores y actuadores (Figura 2.5), en la
Figura 2.4. Trama CAN antes y después de la adición de bit de relleno.
22
que los sensores informan a la unidad central y ésta envía la orden necesaria a los
actuadores para transformar dicha información inicial. (Panadero, 2012)
La función de los sensores sería la de registrar diversos parámetros sobre el
funcionamiento del vehículo (tales, por ejemplo, como las revoluciones del motor,
temperatura de los sistemas, señal de la posición del acelerador, etc.) Estos sensores
actúan como puente hasta el sistema central o ECU y transforman dichas magnitudes
físicas en electrónicas.
2.3.Códigos de fallas
Los códigos de fallas automotriz o DTC (Diagnostic Trouble Code) son un sistema que
fue creado para que los scanner puedan dar un diagnóstico de los problemas de los
autos en ese momento. Esto hace que las detecciones de los problemas de un auto se
reconozcan más rápido.
Figura 2.5. Unidad de control de motor.
23
En la actualidad hay códigos diferentes para cada marca y otros que se han
convertido en genéricos y que han colaborado para que el sistema de lenguaje sea más
fácil de seguir. Algunos otros si son exclusivos y van cambiando dependiendo hasta el
modelo de la unidad. (Cise Electronics, 2010)
Una vez que el código de falla o código de diagnóstico (DTC) es creado existe una
anatomía para este código, esto esta descripto por la norma SAE, Los códigos de falla
OBD II son del tipo alfanumérico, y cada uno de los dígitos presentan una ruta
especifica del diagnóstico. Lo primero que se tiene es una letra, esta puede tener varias
posibilidades de acuerdo al lugar del vehículo en el cual se desarrolle el código, las
posibles letras se aprecian en la Tabla 2.4.
Tabla 2.4. Sistema donde se encuentra el DTC.
Letra Significado
P Powertrain: Comprende los códigos relacionados con el motor y la transmisión
automática.
B Body: comprende los sistemas que conforman la parte de carrocería y confort, también
algunos sistemas relacionados con el inmovilizador.
C Chasis: Comprende los sistemas relacionados con el chasis como puede ser algunos
sistemas ABS-AIRBAG y sistemas de diferencial que no estén relacionados con la
gestión de la transmisión automática.
U Network: Comprende los problemas relacionados con la transmisión de datos de un
módulo a otro, las redes de comunicación se pueden averiar y dejar sistemas completos
por fuera del sistema. En este caso cualesquiera de los módulos restantes pueden
generar un código relacionado con ese sistema.
24
Luego el segundo valor es un numero el cual indica si el código es completamente
genérico, o está dentro del OBD II (Tabla 2.5), pero es algo particular que el fabricante
ha dispuesto para ese problema, aunque se generan también al mismo tiempo códigos
completamente universales.
Tabla 2.5. Tipo de código.
Numero Significado
0 Código completamente universal denominado SAE.
1, 2 o 3 Código del fabricante, aunque sigue siendo OBD II o CAN.
El tercer digito indica el subsistema sobre el cual está montada la falla es así como
tendremos la ubicación precisa del problema analizando este digito. La Tabla 2.6
muestra algunos de los subsistemas para un problema en el motor.
Tabla 2.6. Subsistemas.
Digito Significado
1 Problema ocasionado por un problema con un sensor que afecte la relación Aire-
Combustible o cualquier problema que afecte el buen funcionamiento de esta.
2 Problemas relacionados con el sistema de alimentación (bomba de combustible,
inyectores, relé de bomba, sensores de presión del riel).
3 Problemas relacionados con el encendido, este puede estar compuesto por elementos
como bobinas, CKP, CMP, sensores de detonación.
4 Problemas relacionados con el desempeño del sistema de anticontaminación.
5 Relacionado con algún problema de la marcha mínima.
6 Problemas referentes a los circuitos de procesamientos como memoria y procesador o
referente a masas y positivos fuera de especificación.
7 u 8 Relacionados con la transmisión automática os sistemas controladores de tracción en
las 4 ruedas.
25
En la Figura 2.6 se muestra un ejemplo de código de falla genérico, en este caso se
trata de un problema con el circuito de la válvula actuadora del árbol de levas.
III. DESARROLLO DE PROYECTO
Un sistema embebido es un sistema de computación diseñado para cubrir
necesidades específicas, a diferencia de un PC, el sistema embebido se dota con los
módulos estrictamente necesarios para su función (Figura 3.1), de ahí su coste óptimo.
PYANSA S.A. de C.V. es una empresa que está constantemente en la búsqueda de
innovación y el diseño de sistemas embebidos, es una gran herramienta que le ha
aportado soluciones eficientes, entre todos estos esta un prototipo de comunicación
CAN, el cual tiene como objetivo extraer mostrar el kilometraje, el tiempo de encendido
del motor y los códigos de fallas de un vehículo.
Figura 2.6. Código de falla.
26
3.1. Objetivos del proyecto
Establecer una comunicación MCU-ECU por protocolo CAN.
Optimizar el código de programación.
Obtener el valor del kilometraje de la ECU.
Obtener códigos de fallas de la ECU.
Obtener tiempo de encendido del motor de la ECU.
Figura 3.1. Módulos de un sistema embebido.
27
3.2. Comunicación usuario-MCU
En laboratorio, la comunicación es realizada por una computadora, un convertidor
USB-Serial desarrollado por la empresa y un módulo bluetooth (Figura 3.2), para la
comunicación con el dispositivo, y la aplicación es sustituida por Docklight (Figura
3.3), este es un programa para el desarrollo de protocolos de comunicación serial, los
comandos o tramas son cargados en el programa y facilita la modificación de estos para
los desarrolladores.
En la figura 3.6 la ventana izquierda (azul) se encuentran las posibles tramas
disponibles que se pueden enviar, en la ventana de la derecha (color blanco) se puede
ver la comunicación, de color azul las tramas enviadas, y de color rojo las tramas
recibidas. El software proporciona la posibilidad de representar los bytes de las tramas
en formato hexadecimal, decimal y ASCII para una mejor interpretación.
Figura 3.2. Convertidor USB-Serial y
modulo bluetooth respectivamente.
28
La estructura de la trama consta de un conjunto de bits, los cuales se interpretan de
acuerdo a su posición y cada uno representa cierta información, la Figura 3.4 muestra
un ejemplo simple de la estructura convencional de una trama y la Tabla 3.2 indica
describe los campos que usualmente estas llevan.
Figura 3.3. Interfaz de Docklight.
Figura 3.4. Ejemplo de trama.
29
Tabla 3.1. Estructura de la trama.
Campo Información
Campo de
delimitación
Localizados en ambos extremos de la trama, los receptores estarán
continuamente intentando detectar secuencia de delimitación para
sincronizarse con el comienzo de la trama.
Campo de
dirección
Identifica a la estación secundaria que ha trasmitido o que va
recibir la trama. El campo de dirección tiene normalmente 8 bits,
este tipo de direccionamiento se utiliza cuando la estación
primaria quiere enviar una trama a todas las secundarias, este
campo sirve para informar a una o más estaciones secundarias si
deben leer el mensaje o ignorarlo.
Campo de
control
El campo de control define la longitud exacta del campo de datos
de la trama, este campo se utiliza como parte de la secuencia de
verificación de la trama con el objetivo de asegurar que se haya
recibido el mensaje de manera adecuada.
Campo de
información
Este campo contiene la información que la estación primaria desea
transmitir a las estaciones secundarias.
Comprobación
de trama
Es un código para la detección de errores en la transmisión de la
trama. Normalmente se utiliza una comprobación de redundancia
cíclica (CRC). El receptor recibe la trama y genera una CRC para
buscar errores. Si ambos CRC, tanto del emisor como el receptor
coinciden, la trama fue recibida correctamente.
30
El usuario envía cierta instrucción al sistema embebido, el MCU interpreta la orden
de la trama y ejecuta la tarea asignada, en este caso es la comunicación con la ECU del
vehículo, lee cierta información, envía una trama CAN por el bus, captura la trama que
es regresada por la ECU y arma una nueva trama con la información recolectada y es
enviada al usuario, la imagen 3.5 muestra un diagrama de bloques que ejemplifica la
comunicación usuario-ECU.
Computadora
(Docklight)
Modulo
Bluetooth
Modulo
Bluetooth
MCU
Sistema Embebido
ECU
Modulo
USB-Serial
Figura 3.5. Sistema de comunicación usuario-ECU
31
3.3. Simulador de ECU
Para probar la lectura por CAN del prototipo en laboratorio sin necesidad de un
vehículo real, se hace uso de un simulador ECU (Figura 3.6), en un MCU programado
con tramas predeterminadas para responder como lo haría un ECU, de esta manera se
puede comprobar que las tramas son enviadas y recibidas correctamente por el bus
CAN. Este dispositivo fue creado por los desarrolladores de PYANSA.
la alimentación usada para la electrónica es de 12 V, ya que se alimenta
directamente de la batería de los vehículos, para las pruebas en laboratorio, debido a
la falta de pilas de este voltaje, es necesario adaptar una fuente de voltaje de un
cargador de 24 V con un integrado LM317.
Figura 3.6. Simulador ECU.
32
3.3.1. Fuente de voltaje
Para la fuente de voltaje se cuenta con un cargador de 24V DC, y un LM317, para
su empleo solo requiere dos resistores exteriores para conseguir el valor de salida., la
configuración se puede ver en la Figura 3.7.
La tensión entre la patilla ajuste y salida es siempre de 1.25 voltios (tensión
establecida internamente por el regulador), y en consecuencia la corriente que circula
por el resistor 𝑅1 es:
𝐼𝑅1 = 𝑉𝑅1
⁄ = 1.25𝑅1
⁄ 3.1
Esta misma corriente es la que circula por 𝑅2, siendo entonces la tensión en 𝑅2
𝑉𝑅2 = 𝐼𝑅1 ∗ 𝑅2 3.2
Sustituyendo 𝐼𝑅1 en esta fórmula obtenemos la siguiente ecuación:
𝑉𝑅2 = 1.25 ∗𝑅2
𝑅1⁄ 3.3
Figura 3.7. Configuración del LM317.
33
Como la tensión de salida es 𝑉𝑂𝑈𝑇 = 𝑉𝑅1 + 𝑉𝑅2 , entonces 𝑉𝑂𝑈𝑇 = 1.25 +
(1.25 ∗𝑅2
𝑅1⁄ ) y simplificando por factor común:
𝑉𝑂𝑈𝑇 = 1.25 ∗ (1 +𝑅2
𝑅1⁄ ) 3.4
De esta última formula si consideramos que el voltaje de salida deseado es de 12 V,
y 𝑅2 es de 3.3 KΩ, despejando 𝑅1 tenemos:
𝑅1 ≅ 390Ω
Con esta configuración se obtiene los 12V de voltaje de salida que requiere la
electrónica para las pruebas, en la Figura 3.8 se puede ver el diagrama del circuito, y
en la Figura 3.9, el circuito físico montado sobre una tablilla perforada.
Figura 3.8. LM317 a 12V. Figura 3.9. Fuente de voltaje a 12V.
34
3.4. Problemas del prototipo
Existe una falta de comunicación entre el MCU y el simulador ECU, esto se puede
notar durante las pruebas de laboratorio, donde, al pedir cualquier tipo de información
al simulador ECU, el MCU (kilometraje, tiempo de encendido del motor o códigos de
fallas) responde al usuario con un “NC” (en formato ASCII) esta trama es la que le
indica al usuario la falta de conexión física entre el MCU y el bus CAN del vehículo,
para descartar algún falso en las pistas del prototipo se realizaron pruebas de
continuidad en el layout, a lo cual no se encontraron problemas, otra posible causa del
problema es que el MCU no este enviando información por el bus, a lo cual el simulador
ECU nunca le responde y por eso el MCU actúa como si no existiera una conexión, para
verificar esto se conectó el osciloscopio al bus CAN y se observó si el MCU realmente
envía información por el bus al simulador ECU, la Figura 3.10 es una captura de
pantalla del osciloscopio conectado al CAN_H (amarillo) y CAN_LOW (verde) cuando
se solicita la información del kilometraje, se puede apreciar que los tensiones de voltaje
son correctos y la señal no se encuentra distorsionada, por lo que la transferencia de
información por el bus se encuentra en perfecto estado.
Figura 3.10. Visualización del bus CAN.
35
Otro problema que se encuentra es el hecho que el programa se congela en
ocasiones cuando se solicitan los códigos de fallas, el ingeniero asesor en la empresa
comenta que esto se puede deber a ciclos while utilizados en la programación que se
quedan ciclados y no permiten al MCU seguir ejecutando el programa.
3.5. Modificaciones
3.5.1. Implementación de banderas en ciclos while
Los ingenieros de la empresa comentaron que posiblemente la razón por la cual el
MCU se queda congelado y no procesa otras instrucciones es porque posiblemente el
programa se queda ciclado en algunos puntos del programa, más específicamente los
ciclos while.
La estructura del ciclo while la conforman una condicional y un bloque de
programación, la lógica dice que si la condición del ciclo es verdadera (true o “1”
booleano) el bloque de programación se ejecutara indefinidamente hasta que la
condición sea falsa, la lógica se puede apreciar en la Figura 3.11.
Figura 3.11. Lógica de un ciclo while.
36
El uso de esta estructura es muy frecuente en la programación usada en el MCU
para verificar la correcta ejecución del código y lecturas sin errores de datos, si la
lectura no tiene éxito o es errónea la condición del ciclo se vuelve falsa.
El problema de esta lógica es en la lectura de tramas, cuando el MCU recibe una
trama guarda su información en un arreglo, pero no verifica que la información sea
correcta, cuando el programa realiza una lectura de esta información para su
interpretación usa una estructura como la Figura 3.12, el programa queda ciclado
leyendo la información hasta que esta no presente errores, pero en este punto el
programa no recibe información nueva solamente lee una información almacenada, si
la información está mal y no puede ser interpretada, el programa se queda atorado en
este punto, y el reset manual es obligatorio.
Para solucionar esta problemática en la estructura se implementa una bandera por
interrupción, la bandera cumple con el papel de la condición en los ciclos while, y la
interrupción la activación de esta, la bandera tiene dos formas de activarse, en el mismo
ciclo while del programa una vez que no se detectan errores, si existe error en la lectura
Figura 3.12. Lógica de programación.
37
el while queda ciclado y aquí es cuando la interrupción entra para activar la bandera y
finalizar el ciclo while, en la Figura 13 se ejemplifica mediante un diagrama de flujo la
lógica de la programación, la variable “timeout” hace referencia a la bandera y la
interrupción es activada por un timer. Una interrupción es una función especial con
una serie de instrucciones, la diferencia con este tipo de funciones es que pueden ser
llamadas y el MCU deja de ejecutar el código del programa y ejecuta el de la
interrupción, una vez finalizada las instrucciones de la interrupción regresa al
programa principal y reanuda la ejecución donde se quedó.
Figura 3.13. Lógica de programación con "timeout".
38
La bandera “timeout” debe ser limpiada una vez salga del ciclo, si se deja activada
no se ejecutarían los demás ciclos while en la programación. La interrupción es
generada por un timer con una configuración de desborde de 0.05 segundos, en la
Figura 14 se puede ver la implementación de la bandera en un ciclo while y la activación
en la interrupción respectivamente.
3.5.2. Modificación de función DTC
Otra modificación fue en una función llamada DTC, que es la encargada de pedir
los códigos de fallas, la comparación de lógica de forma simplificada en la función
original y la modificación se puede apreciar en los diagramas de flujo de la Figura 3.15.
La función original una vez que lee los DTC verifica que no exista un error al
momento de recibirlos, si existe un error el programa se queda ciclado esperando que
el error desaparezca pero este jamás lo hará ya que la información es almacenada en
Figura 3.14. Implementación de "timeout".
39
un arreglo de datos, y si la información no se recibió bien, aun así la información será
escrita en este arreglo, y la función siempre leerá la información y la tomara como
errónea, es aquí donde se produce el bucle, para solucionarlo, se habilita un nuevo
Timer, ya que el Timer 3 ya está en uso y puede crear conflicto, cuando el Timer 5 se
desborde, la interrupción levantara una bandera que pone en falso las condiciones de
los ciclos while en la función, el programa sale de estos ciclos y manda una trama de
error al usuario, ya que la información de los DTC’s no se leyó de forma correcta.
3.5.3. Configuración de Timer para DTC
Un Timer es un módulo temporizador/contador de un 8 u 16 bits, dependiendo el
MCU, que cuenta con un preescalador programable, puede funcionar como
temporizador o como contador. En modo temporizado el valor del registro TMR se
incrementa con cada ciclo de instrucción (o cada X ciclos dependiendo del
preescalador). Al desbordarse el registro TMR, la bandera de la interrupción del Timer
se pone a 1, una interrupción es una serie de instrucciones que se ejecuta
inmediatamente cuando esta es provocada, en este caso es provocada por el
Figura 3.15. Antes y después de la lógica de programación.
40
desbordamiento de un Timer, no importa que instrucciones se encuentre haciendo el
MCU, cuando es llamada la interrupción inmediatamente se deja de ejecutar el código
del programa y pasa a ejecutar el de la interrupción, cuando finaliza el código de
interrupción retoma el código del programa.
La inicialización del Timer 5 se puede ver en la figura 3.16, todos los registros
pueden ser consultados en el datasheet del MCU.
Cada Timer es de 16 bits, pero es posible usar dos Timers para formar uno solo de
32 bits, el preloader (PRx) es el registro de valor de desborde, cuando el Timer sea
activado el registro TMRx empezara a incrementar, cuando llegue al mismo valor que
PRx el Timer se desborda y se activa la interrupción, para saber el valor de desborde
para el preloader en un tiempo determinado se tiene la siguiente formula:
𝑃𝑟𝑒𝑙𝑜𝑎𝑑𝑒𝑟 = 𝑡𝑖𝑒𝑚𝑝𝑜 𝑒𝑛 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠
𝑝𝑟𝑒𝑠𝑐𝑎𝑙𝑒𝑟∗ 𝑡𝑐𝑦 3.5
Figura 3.16. Registros de configuración de timer.
41
Donde el 𝑡𝑐𝑦 es igual al inverso del MIPS (mega instrucciones por segundo), en este
caso el MCU está configurado a 40 MIPS, el Timer tiene un preescaler de 1, y queremos
un desborde de 1 segundo, por lo que:
𝑃𝑟𝑒𝑙𝑜𝑎𝑑𝑒𝑟 = 1
1∗ 1 40000000⁄ 3.6
𝑝𝑟𝑒𝑙𝑜𝑎𝑑𝑒𝑟 = 40000000
Si se convierte esta cantidad a hexadecimal obtenemos el número 2625A00, cuando
se está usando el modo de 32 bits, es necesario dividir el preloader en dos de 16 bits, los
bits menos significativos se escriben en el preloader del Timer 4 y los más significativos
en el preloader del Timer 5 como se puede observar en la Figura 3.16.
Una vez configurado el tiempo de desborde del Timer se puede configurar la
interrupción del mismo, lo primero es habilitar la interrupción del Timer mediante el
registro que se puede apreciar en la Figura 3.17.
Dentro de la interrupción de Timer 5 lo primero es limpiar la bandera del Timer,
esto es necesario para la correcta ejecución del código, después se resetea los valores
del Timer, para que empiece a incrementar desde cero una vez que se active de nuevo,
y finalmente se activa la variable que se usara en la función de los DTC, como se puede
apreciar en la Figura 3.18.
Figura 3.17. Habilitación de interrupción por timer.
42
3.6. Pruebas de campo
3.6.1. Códigos de fallas
Las pruebas de campo se realizaron en una camioneta Ford F150 modelo 2014, antes
de realizar las pruebas, se usó un scanner comercial, con la intención de tener un punto
de comparación respecto a los DTC una vez que el sistema embebido los muestre. El
scanner que se uso fue el AUTO ENGINUITY versión 10.03.
Durante el análisis con el scanner comercial se detectaron 5 códigos de fallas como
se puede ver en la captura de pantalla de la Figura 3.19, los códigos fueron: P0030,
P0053, P219b, P0161 y P0171, esto marca un punto de referencia para los códigos
capturados por el sistema embebido.
Por medio del conector OBD II conectaremos el prototipo al bus CAN igual que
con el scanner, esta entrada suele estar ubicada en la parte inferior del tablero (Figura
3.20), una vez conectados se piden los DTC y se guardan la información recibida para
su análisis.
Figura 3.18. Interrupción por timer 5.
43
3.6.2. Interpretación de DTC
Normalmente los códigos de fallas están representados por una numeración
alfanumérica de 5 dígitos como se puede apreciar el Figura 3.19, pero los códigos de
Figura 3.19. Códigos de fallas por scanner.
Figura 3.20. Conector OBD II de la camioneta.
44
falla arrojados por la ECU están en formato hexadecimal y por eso es necesario
interpretarlos para determinar el tipo de código de falla. A continuación, se describen
una serie de pasos para pasar los códigos de fallas de formato hexadecimal al estándar
alfanumérico.
Primero se identifican los DTC en la trama, los cuales son todos los resaltados en
color amarillo de la Figura 3.21. Los DTC’s están resaltados en pares, esto es porque
cada DTC ocupa una longitud de 2 bytes, entonces en la imagen se observa un total de
5 DTC diferentes.
A manera de ejemplificar el proceso se toma el valor arrojado de “00 30” para la
interpretación, tomar en cuenta que los valores de la trama están en hexadecimal, ahora
se convierte el valor del DTC en binario, el resultado es un numero de 16 bits en binario,
se asigna un nombre a cada bit como se ve en la Figura 3.22, de izquierda a derecha
empezando por A7 hasta llegar a B0, con ayuda de la Tabla 3.2, 3.3 y 3.4 se forman los
5 caracteres del DTC.
Figura 3.21. DTC's.
00 30
0000 0000 0011 0000
A7 A6 A5 A4 A3 A2 A1 A0 B7 B6 B5 B4 B3 B2 B1 B0
Figura 3.22. Conversión de hexadecimal a binario.
45
Tabla 3.2. Primer Carácter.
A7 – A6 Primer carácter del DTC
00 P – Powertrain
01 C – Chasis
10 B – Body
11 U - Network
Tabla 3.3. Segundo carácter.
A5 – A4 Segundo carácter del DTC
00 0
01 1
10 2
11 3
Tabla 3.4. Tercer, cuarto y quinto carácter.
A3 – A0, B7 – B4, B3 – B0 Tercer, cuarto y quinto carácter
0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 9
1010 A
1011 B
1100 C
1101 D
1110 E
1111 F
46
Para el DTC “00 30” se obtiene con ayuda de las tablas en su forma alfanumérica el
DTC P0030, si se obtienen el resto de DTC de la trama de la misma manera se puede
ver que los obtenidos con el prototipo en la Tabla 3.5 coinciden con los del scanner
comercial (Figura 3.19)
Tabla 3.5. Conversión de DTC de trama CAN.
DTC (hexadecimal) DTC (formato de 5 caracteres)
01 71 P0171
00 53 P0053
00 30 P0030
21 98 P219b
01 61 P0161
3.6.3. Kilometraje
El segundo parámetro que sea desea conocer es el kilometraje del vehículo, la trama
sigue, para esta ocasión los parámetros del kilometraje abarcan 3 bytes, estos bytes se
pueden ver en la Figura 3.23, tomar en cuenta que los bits más significativos a los
menos significativos van de izquierda a derecha.
Solo es necesario una conversión hexadecimal a decimal para conocer el kilometraje
del vehículo: 0A91B2 = 692658. El ultimo digito del kilometraje es decimal, pero no es
posible expresar décimas en hexadecimal, por lo que la ECU arroja el valor en número
entero, es necesario por parte de los desarrolladores una vez obtenido el valor, dividirlo
en base 10, para pasar el ultimo digito a decimal: 69265.8 Km.
Figura 3.23. Trama del kilometraje, parámetros resaltados en amarillo.
47
Para verificar este valor solo se compara con el kilometraje que indica el propio
vehículo y de esta manera se comprueba que es un valor correcto, en la Figura 3.24
aparece una fotografía del indicador del kilometraje de la camioneta el día de las
pruebas, se puede observar que concuerda con el obtenido mediante el sistema
embebido.
3.6.4. Tiempo de encendido del motor
El tercer y último parámetro que se le pide a la ECU es el tiempo de encendido del
motor, la trama sigue la misma estructura que la trama del kilometraje, la diferencia
radica en la longitud de los bytes de información, el kilometraje consta de un largo de
3 bytes mientras que el tiempo de encendido de motor consta de una longitud de 2
bytes, el orden de los bits se mantiene, los más significativos del lado izquierdo y los
menos significativos del lado derecho. En la Figura 3.25 se puede apreciar los valores
Figura 3.24. Indicador de kilometraje del vehículo.
48
de los parámetros resaltados en amarillo, nótese que la visualización de la trama en
Docklight está en formato en decimal para una mejor visualización de la informacion.
Como la trama se encuentra en formato decimal no es necesario una conversión es
totalmente legible el parámetro, en la Figura 3.30 se puede apreciar 000062 que
equivalen a los segundos que tiene prendido el motor o más simplificado solo 62
segundos. Para verificar este valor durante las pruebas se tomó un cronometro
empezando a contar en el momento de encender el motor, y se le solicitaba la
información del tiempo al sistema cada cierto tiempo para verificar que si era el valor
correcto. En la figura 3.26 se puede ver una foto del cronometro cuando contesto la
trama de la Figura 3.25, como se puede observar, los tiempos coinciden.
Figura 3.25. Parámetros del tiempo de encendido del motor.
Figura 3.26. Captura de tiempo con cronometro.
49
3.7. Resultados y observaciones
Después de las pruebas con campo con las modificaciones los resultados obtenidos
fueron positivos, pero aún se cuenta con ciertas fallas que se tienen que pulir, uno de
ellos es la respuesta del prototipo, ya que manda algunos parámetros erróneos
aleatoriamente lo que dificulta su interpretación, por otra parte, el congelamiento del
programa ya no es problema con las modificaciones realizadas, pero se observó que
tarda un tiempo considerable en responder cuando se le piden los DTC, en la tabla 3.6
se pueden observar los resultados de las pruebas y las observaciones realizadas. Se
pretende que el programa siga en constante mejora para pulir esos pequeños detalles
con los que aun cuenta y de esta manera pueda ser utilizado por la empresa.
Tabla 3.6. Resultados de pruebas.
Problema Resultados Observaciones
Excelente Bueno Malo
Comunicación entre
MCU y ECU
x
Lectura de DTC x La trama arrojada en ocasiones
contiene elementos basuras
ilegibles.
Lectura de
kilometraje
x En ocasiones el dispositivo
responde una trama errónea.
Lectura de tiempo
de encendido del
motor
x En ocasiones el dispositivo
responde una trama errónea.
Congelamiento del
sistema
x
50
IV. BIBLIOGRAFÍA
Arévalo, O. (29 de Mayo de 2014). starMedia México. Obtenido de
http://autos.starmedia.com/taller-mecanico/que-son-codigos-fallas-
automotriz.html
Arroyo, A. E. (Noviembre de 2005). Obtenido de Universidad Autonoma del Estado
de Hidalgo Web Site:
https://www.uaeh.edu.mx/docencia/Tesis/icbi/licenciatura/documentos/Red%2
0controladora%20de%20area%20CAN.pdf
Chulca, M. C., & Flores, X. M. (s.f.). Obtenido de
http://repositorio.espe.edu.ec/bitstream/21000/8209/1/AC-EAC-ESPE-
047842.pdf
Circuitos electrónicos. (s.f.). Circuitos electrónicos. Obtenido de
ttp://www.circuitoselectronicos.org/2011/04/el-temporizador-timer-0-en-
los.html
Cise Electronics. (24 de Octubre de 2010). CISE electronica. Obtenido de
http://www.cise.com/portal/notas-tecnicas/item/228-acerca-de-los-
c%C3%B3digos-de-falla-o-dtc.html
Deitel. (2004). Cómo programar en C/C++ y Java. México: PEARSON EDUCACIÓN.
Floy, T. L. (2006). Fundamentos de Sistemas Digitales. Madrid: PEARSON EDUCACIÓN
S.A.
Fresno, J. A. (Septiembre de 2004). Obtenido de
http://deeea.urv.cat/public/PROPOSTES/pub/pdf/561pub.pdf
Galeano, G. (2009). Programación de sistemas embebidos en C. México: ALFAOMEGA
GRUPO EDITOR.
Huete, A. J. (Febrero de 2011). Obtenido de http://e-
archivo.uc3m.es/bitstream/handle/10016/11854/PFC_Alberto_Lopez_Esteban.p
df?sequence=2
Learning about Electronics. (s.f.). Learning about Electronics. Obtenido de
http://www.learningaboutelectronics.com/Articles/MCP2551-CAN-
transceiver-circuit.php
51
Medina, M. C. (Marzo de 2008). Escuela Politécnica Nacional Web Site. Obtenido de
http://bibdigital.epn.edu.ec/bitstream/15000/4194/1/CD-1398.pdf
Panadero, J. (3 de Julio de 2012). Diariomotor Tecmovia. Obtenido de
http://www.diariomotor.com/tecmovia/2012/07/03/ecu-que-es-y-el-porque-de-
su-existencia/
Wikipedia. (23 de Octubre de 2004). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/Bus_CAN
Wikipedia. (6 de Febrero de 2006). Wikipedia. Obtenido de
https://en.wikipedia.org/wiki/OBD-II_PIDs
Wikipedia. (25 de Mayo de 2009). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/LM317
Wikipedia. (3 de Septiembre de 2014). Wikipedia. Obtenido de
https://es.wikipedia.org/wiki/OBD
0
