UNIVERSIDAD POLITÉCNICA DE

CARTAGENA

Escuela Técnica Superior de Ingeniería

Industrial

Diseño e implementación de un
sistema de captura CAN/ODBII

TRABAJO FIN DE GRADO

GRADO EN INGENIERÍA ELECTRÓNICA INDUSTRIAL Y
AUTOMÁTICA

Autor: Eulogio Gómez Polo

Director: Joaquín Roca González

Cartagena 28/09/16
 Proyecto Fin de Grado
Ingeniería Electrónica Industrial Y Automática

Diseño e implementación de un sistema

de captura CAN/ODBII

Autor:
Eulogio Gómez Polo

Tutor:
Joaquín Francisco Roca González
Profesor titular

Departamento De Tecnología Electrónica

Escuela Técnica Superior de Ingeniería Industrial
Universidad Politécnica de Cartagena
Cartagena, 2016

i
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

AGRADECIMIENTOS:

Agradecer a mi familia y pareja por creer en mí y apoyarme en estos duros cuatro años.

“El fracaso es una oportunidad para empezar otra vez con más inteligencia.”
Henry Ford

ii
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

ÍNDICE
1. INTRODUCCIÓN .................................................................................................................... 1
2. OBJETIVOS............................................................................................................................. 1
3. REVISIÓN DEL ESTADO DEL ARTE ......................................................................................... 2
3.1 BUSES DE MONITORIZACIÓN .............................................................................................. 2
3.1.1 REQUISITOS DE UN BUS DE CAMPO............................................................................. 3
3.1.2 HISTORIA DEL USO DE LOS BUSES EN LOS VEHÍCULOS ................................................ 4
3.1.3 BUS CAN ....................................................................................................................... 4
3.1.4 CARACTERÍSTICAS TÉCNICAS BUS CAN......................................................................... 6
4. OBD ....................................................................................................................................... 8
4.1 HERRAMIENTAS ................................................................................................................... 9
5. INTERFACE ELM327............................................................................................................. 11
5.1 TIPOS DE COMUNICACIÓN INTERFACE-OBD ..................................................................... 11
5.1.1 COMUNICACIÓN INALÁMBRICA ................................................................................. 11
5.1.2 COMUNICACIÓN RS232 .............................................................................................. 11
6. COMUNICACIÓN SERIE ....................................................................................................... 13
6.1 SOFTWARES UTILIZADOS................................................................................................... 14
6.1.1 NULL MODEM EMULATOR ......................................................................................... 14
6.1.2 REALTERM .................................................................................................................. 15
6.1.3 VIRTUAL SERIAL PORT DRIVER ................................................................................... 16
7. PROGRAMA DE LECTURA DE PUERTO SERIE...................................................................... 18
8. PROGRAMA ESCRITURA PUERTO SERIE ............................................................................. 19
9. PROGRAMA ESCRITURA Y LECTURA .................................................................................. 21
10. PRIMERA PRUEBAS CON OBD II ..................................................................................... 22
10.1 MONITORIZACIÓN CON TORQUE .................................................................................... 27
11. COMANDOS AT ............................................................................................................... 30
11.1 PRUEBAS ELM 327 Y COMANDOS AT .............................................................................. 31
12. ELM 327 PIDs .................................................................................................................. 39
12.1 MEJORA EN EL PROGRAMA DE ESCRITURA Y LECTURA .................................................. 48
13. PRUEBAS DE FALLO ......................................................................................................... 50
14. BORRRRADO DE FALLOS ................................................................................................. 52
15. CREACIÓN DEL DRIVER ................................................................................................... 53
15.1 MEJORA DRIVER .............................................................................................................. 75
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

15.2 DRIVER BAJO NIVEL ......................................................................................................... 77

15.3 DRIVER DE BAJO NIVEL 2.0 .............................................................................................. 82
15.4 CREACIÓN DEL DRIVER FINAL. ......................................................................................... 84
16. PRUEBAS ESTÁTICAS ....................................................................................................... 86
17. GRÁFICAS LABVIEW ........................................................................................................ 88
17.1 PRUEBAS GRÁFICAS ......................................................................................................... 89
18. CONCLUSIONES Y FUTURAS APLICACIONES .................................................................. 93
19. ANEXOS ........................................................................................................................... 94
20. REFERENCIAS ................................................................................................................ 116
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

1. INTRODUCCIÓN
En este proyecto se va a desarrollar una driver para la monitorización de automóviles. Esta
función puede realizarse en prácticamente cualquier vehículo del mercado.

La viabilidad de este proyecto reside en la existencia de estándares para la comunicación con el

vehículo. Para llevar a cabo esta tarea se emplea una interfaz de ELM 327 bluetooth, la cual
sirve como enlace entre el vehículo y el ordenador del usuario, el cual se encargará de enviar
peticiones, recibir respuestas, traducir respuestas y almacenar los valores de dichas respuestas.

Describimos OBD (On Board Diagnostics) como un sistema capaz de monitorizar diversos
parámetros de los vehículos, utilizado mayormente para la diagnosis.

OBD nació en EEUU con el objetivo de controlar las emisiones de gases, este sistema fue
evolucionando de la mano con la electrónica en los vehículos, hasta OBD II capaz de recoger
muchísima más información.

2. OBJETIVOS
El proyecto objeto tiene por objetivo el desarrollo de un sistema que permita el registro de las
interacciones de usuario con el vehículo de cara a su integración en estudios de factores
humanos en conducción. Para ello, se tendrá que:

 Llevar a cabo una revisión del estado del arte en los sistemas de comunicación "On
Board Diagnostics".
 Identificar los requisitos del interface CAN/ODBII.
 Implementar un driver de adquisición para la captura de los parámetros de interacción.
 Programar una aplicación de ejemplo que permita el registro continuado.

1
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

3. REVISIÓN DEL ESTADO DEL ARTE

3.1 BUSES DE MONITORIZACIÓN

-Definición de bus:

Es una tecnología de comunicación y protocolos usados en automatización y control de

procesos industriales.

Su tarea es comunicar los distintos sensores y actuadores con sistemas inteligentes como puede
ser un PC o un PLC, así estos sistemas inteligentes pueden tener información del estado de todo
el proceso.

2
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En comparación, la interconexión de serie de componentes de planta mediante bus de campo

es una opción mucho más rentable:

Los mazos de cable se ven considerablemente reducidos o incluso eliminados. La interconexión

de equipos, se realiza mediante el mismo cable bus.

Los elementos pueden posicionarse en la ubicación que deseemos y conectarlos mediante el

cable de bus, proporcionando una estructura de comunicaciones ideal para aplicar los
conceptos de racionalización y competitividad actuales.

A la hora de identificar los componentes, se hace una tarea más sencilla, hablamos de
mangueras, hilos, borneros… Reducen las dimensiones ante la ausencia de tanto cableado.

Las tareas de autodiagnóstico también forman parte de este sistema, pudiendo mostrar al
operario, reduciendo el tiempo de búsqueda de fallos.

Los protocolos de transmisión tienen rutinas de detección y corrección de errores, aumentando

la fiabilidad y eficiencia de las comunicaciones.

La estandarización permite que un integrador pueda escoger dispositivos de múltiples

fabricantes.

3.1.1 REQUISITOS DE UN BUS DE CAMPO

Todo bus de campo debe contemplar una serie de puntos:

1. Integración de datos: Se deben poder conectar todo tipo de dispositivos,

conviven en la red de datos de clases diferentes. Los datos de entradas/salidas ocupan
poco espacio en las comunicaciones, se procesan de forma cíclica, mientras que los
datos de parametrización, son más voluminosos, se transmiten de forma acíclica.

2. Integración de dispositivos: Cualquier controlador debe poder conectarse al

bus, además tendremos la posibilidad de conectar ordenadores personales, hecho que
aprovecharemos para el desarrollo del proyecto.

3. Tiempo real: El ciclo de trabajo del bus debe estar siempre por debajo del ciclo
ode trabajo del controlador para mantener las especificaciones de tiempo real.

4. Eficiencia del protocolo: Estos deben transmitir y gestionar los datos que se
envían a los destinatarios de los mismos. Definimos eficiencia como la relación entre
datos transmitidos y útiles.

5. Determinismo: Por determinismo se entiende saber cuando algo va a ocurrir,

así se asegura un muestreo y control más fiable y preciso.

3
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

6. Seguridad: Con sistemas que trabajen a bajas velocidades se puede conseguir

mayor protección de datos, en comparación a los sistemas que trabajan a altas
velocidades de transmisión.

7. Expansión: La posibilidad de ampliación de un bus vendrá dado por unos puntos

como puede ser número máximo de nodos, tipo de soporte de señal…

8. Diagnóstico: Las funciones de diagnóstico deberían poder detectarse de forma

rápida y sencilla, así se obtiene una rápida respuesta del usuario e incluso parar la
máquina de forma rápida si la situación lo requiere.

9. Disponibilidad: Se deben poder proporcionar recambios que continúen con el

correcto funcionamiento de la maquinaria.

3.1.2 HISTORIA DEL USO DE LOS BUSES EN LOS VEHÍCULOS

Como es evidente cada vez la electrónica tiene más peso en los vehículos. Hace años los
dispositivos electrónicos que disponíamos en los vehículos eran mínimos, por lo que la
comunicación entre estos era mediante cables directos (punto a punto).

A medida que se iba introduciendo electrónica fue necesario plantearse la necesidad de definir
un protocolo de comunicaciones para la automoción. Entonces nació el CAN bus.

3.1.3 BUS CAN

Este es un bus de automatización que nació con la finalidad de satisfacer aplicaciones de la
industria automovilística. Su objetivo inicial fue abastecer a la industria del automóvil con un
bus de bajo coste que pudiera ser montado en un vehículo.

La cantidad de dispositivos que se disponían en los vehículos en la década de los 80 hizo pensar
que se necesitaba un tipo de comunicación que reduzca la cantidad de cable, problemas de
montaje, peso del vehículo, normalización de equipo y conexiones.

Entonces en Febrero de 1986 Robert Bosch presentó CAN (Controller Area Network) en la
Society of Automotive Engineergs (SAE). También se produjo la colaboración de empresas como
Intel, como fabricante, y Mercedes-Benz, como colaborador del desarrollo del bus.

Can fue implementado por primera vez en 1992 por Mercedes-Benz en sus vehículos de alta
gama para control de motor y electrónica variada.

Las características más destacadas de este bus eran:

 El sistema de gestión de bus carecía de un elemento central de control.

 El sistema de acceso no era destructivo que garantizaba el acceso al bus mediante un
sistema de prioridades que eliminaba los retrasos en la transmisión.
 El control de errores desconecta cualquier nodo defectuoso para mantener la
comunicación entre el resto de nodos operativos.

4
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

 Los mensajes no se identifican mediante direcciones si no mediante su contenido,

donde se encuentra también una prioridad asignada a los mensajes.

Las sucesivas revisiones del estándar, debidas a errores o lagunas de diseño, se han ido
especializando, dando lugar a normas tales como:

 ISO 11898-1 donde se describe la capa de enlace.

 ISO 11898-3 especifica la Capa Física CAN tolerante a fallos.
 ISO 11992 para camiones y remolques.
 ISO 11783 para maquinaria agrícola y forestal.

En 1992, usuarios y fabricantes fundan el grupo Can in Automation (CiA) con el fin de la mejora
técnica y comercial de este bus.

Una de sus primeras tareas fue establecer las especificaciones de la Capa de Aplicación para
CAN, usando como punto de partida las especificaciones ya desarrolladas.

En 1993 un consorcio de empresas europeas, lideradas por Bosch, iniciaron el desarrollo de lo

que ha sido CANopen. Un perfil basado en CAL(Can Application Layer) específico para Células de
fabricación. Tras varias revisiones CANopen es adaptado a CiA para así tener a disposición
futuras mejoras quedando su perfil de comunicaciones totalmente definido en 1995.

En 1995 se desarrollan los identificadores de 29 bits (CAN2.0 B) y se publica el perfil de

comunicaciones DS-301 que define CANopen.

En el año 2000, un consorcio formado por varias compañías definió un protocolo para la
transmisión de mensajes CAN multiplexados en el tiempo, lo que hace posible la transmisión
periódica de mensajes y el control en lazo cerrado mediante CAN, sin alterarlo.

5
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El perfil DS-304 permite integrar componentes de nivel de seguridad 4 en este tipo de buses, las
aplicaciones de estos protocolos en el campo de seguridad en máquinas se llama CANopen-
Safety.

3.1.4 CARACTERÍSTICAS TÉCNICAS BUS CAN

De las comunicaciones: Aparecen dos perfiles DS 301 comunicaciones CiA y DS 4xx donde se
definen los Perfiles Estándar Especificados. Para este último tenemos:

 DSP 401 para módulos Entradas/Salidas.

 DSP 402 Variadores.
 DSP 404 Dispositivos de medida y control.
 DSP 406 encóders.

Cada dispositivo se modeliza mediante un perfil determinado, que define los datos mínimos que
debe tener. Esta información se estructura en un diccionario donde se encuentra toda la
información que se define. Los elementos no tienen limitación de tamaño. Para acceder a cada
elemento del diccionario se estructura una dirección consistente en un índice y subíndice en la
siguiente figura se muestra a modo de ejemplo un diccionario de un variador ATV.

Intercambio de datos: En el perfil DS301 se definen cuatro tipos de mensajes:

1. Mensajes de gestión de Red. Controla los mecanismos de bus, basado en la

relación Maestro-Esclavo.

2. SDO. Definen las tareas de baja prioridad, se trata de comunicaciones acíclicas,

activadas por un programa. También basado en la relación Maestro-Esclavo, se puede
dirigir un mensaje a un nodo concreto. Permite crear canales de comunicación entre
dispositivos.

6
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

3. PDO. Tareas de tipo cíclico, para intercambio de datos de proceso en

aplicaciones de tiempo real. Basado en la relación Productor-Consumidor, cada nodo
empite su PDO al bus y será recogido por el consumidor que lo requiera.

4. SFO. Donde se encuentran las tareas de sincronización.

ESTRUCTURA DE CAPAS

Como ya se ha definido anteriormente se crearon varias capas, los cuales van a ser definidas a
continuación.

Capa Física: Determina la concepción física del bus:

 Topología: Bus con terminaciones de línea y con derivaciones en paralelo.

 Soporte: Cable par trenzado, de 2 o 4 hilos.
 Dispositivos: 1 Maestro y 127 esclavos.
 Velocidad: 1Mb a 25m /10Kbps a 1000m pero dependerá del tipo de cable.
 Distancia: Máximo 1000m.

El número de nodos no está limitado por la especificación pero se limita a 32 o 64. Este es un
protocolo multimaestro, para evitar colisiones entre los mensajes se usa un servicio basado en
el principio de prioridad, encuentra el número de ceros que tiene el mensaje en su
identificador, a mayor número de ceros mayor prioridad. La especificación CAN define dos
estados para los bits que circulan por el bus siendo el dominante (“0”) y el recesivo (“1”).

Capa de Enlace: CAN es una red que hace servir el método de detección de portadora. Cualquier
nodo está en disposición de transmitir cuando la red está libre. El acceso al bus está basado en
el método CSMA/AMP siendo la particularidad de este método:

Un elemento realiza la acción de “autoescucha” para saber si el mensaje emitido es el correcto,

permite la detección de transmisiones simultáneas.

Si dos nodos intentan transmitir simultáneamente un algoritmo especial de arbitraje será el

encargado de decidir el que irá primero, sin perder datos. Decide que nodo accede al bus y el
resto esperará a que este quede libre.

7
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Se realizará una función AND para todos los bits que estén presentes en el bus, cada nodo lee
la información presente en el bus, si la información no coincide con lo que hay en el bus, se
aborta la transmisión. Los bits se van transmitiendo de izquierda a derecha.

Capas de Red y Transporte: Los nodos reciben datos, estos deben decidir si los datos son
coherentes. Cada trama CAN comienza con un identificador llamado COB-ID (Communication
Object Identifier). Por lo que conviene llamar a los nodos como identificadores.

Para establecer la conexión, el dispositivo generará una petición a la red en la cual pide la
reserva de un canal de comunicación, quedando así reservado para la transferencia de datos
entre identificadores.

El identificador de cada mensaje incorpora información sobre su prioridad. La detección de

error y retransmisión automática, junto con la gestión de mensajes prioritarios garantiza el
trabajo en tiempo real.

En la actualidad hay tantos dispositivos electrónicos, desde los elevalunas hasta sistemas airbag,
que es necesario utilizar varios sub-buses para las distintas electrónicas, como puede ser la de la
seguridad, climatización.

Un uso será para servicios de diagnosis y también es posible la toma de datos del vehículo. Los
coches tienen un conector OBD. En la siguiente figura se muestra el conector de la OBD del
vehículo donde se realizarán las pruebas.

Con él se accede al CAN y es posible monitorizar mediante un PC o sistema inteligente.

4. OBD
En la década de los 60, en el estado de California se pide que se establezca una medida para el
control de las emisiones en los vehículos, con el fin de intentar reducir los niveles de
contaminación, una vez se fijó esta idea, ésta fue ampliada hasta el punto de que todos los
vehículos deberían llevar este sistema OBD, no lo sabían pero cambiarían el futuro de la
reparación de los vehículos drásticamente.

El Congreso aprobó la primera Ley de Aire Limpio en 1970, que era la base de la Agencia de
Protección Ambiental (EPA). En las siguientes décadas la EPA comenzó a establecer la línea base
para el control de las emisiones. Por ejemplo en 1975 requiere que los vehículos que salgan

8
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

nuevos al mercado deben llevar catalizador, primer depurador de emisiones antes de la zona de
salida de gases, para reducir así el nivel de emisiones.

Los fabricantes comenzaron a utilizar sensorería para el registro de datos y así mejorar el
control de las emisiones. Tras unos años finalmente el diagnóstico a bordo se introdujo en 1985,
con el fin de revolucionar los sistemas de vigilancia que se habían estado utilizado
anteriormente. Society of Automotive Engineers (SAE) diseñó un conector estándar conocido
como conector de enlace de datos y conjunto de señales de prueba para ir junto con el sistema.
La EPA decide aplicar esta nueva tecnología con el fin de facilitar el mantenimiento de los
vehículos.

En 1996 el SAE presentó la segunda generación de las OBD conocido como OBD-II. El nuevo
objetivo era tener nuevos códigos de error conocidos como códigos de diagnóstico (DTC) los
cuales serían los mismos para todos los vehículos. El gobierno decide en 1996 que todos los
vehículos de nueva fabricación deben llevar este sistema de diagnóstico.

Esta herramienta ha recorrido un largo camino desde la idea principal hasta lo que es hoy en
día, desde un equipo para intentar reducir el nivel de contaminación a una herramienta
indispensable actualmente en los talleres mecánicos.

4.1 HERRAMIENTAS
Disponemos de dos tipos de herramientas para nuestro sistema de diagnóstico:

1. Escáner automotriz.

2. Lector de códigos.

Dado que este es un sistema altamente utilizado en el sector de la reparación de vehículos para
la detección de fallos mediante su conjunto de sensores, para actualizar datos acerca de fechas
de mantenimiento del vehículo…

Nuestro proyecto necesita extraer los códigos para transmitirlo a un ordenador personal, por
ello debemos utilizar un escáner lector de códigos.

Mientras que las privadas te venden el OBD-II con un software del propio fabricante para con el
fin de identificar los fallos.

4.1.1 ESCÁNER AUTOMOTRIZ

Son aparatos electrónicos de alto costo, frecuentemente utilizado por los técnicos con el fin de
monitorear el funcionamiento del automóvil. En la siguiente imagen se muestra un ejemplo de
un escáner automotriz.

9
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

A continuación se describen algunas de las características de este escáner automotriz:

 Lectura en tiempo real y de códigos de error.

 Lectura de códigos genéricos OBD, así como de códigos específicos de fabricantes (P0,
P2, P3, U0, U1), con interpretación del código de error.
 Tabla interna de códigos de error.
 Posibilidad de obtener la información como ve imagen fija.
 Borrar historial de errores.
 Lectura de registro de datos en tiempo real y restitución interna por pantalla.
 Información amplia de los sensores importantes en el control del motor.

4.1.2 LECTOR DE CÓDIGOS OBD.

El lector de códigos OBD es un hardware que permite la lectura de datos desde la unidad
central, para ser transmitidos hacia algún dispositivo de procesamiento a través de una interfaz,
puede ser por puerto serie USB o inalámbrico.

10
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Para nuestro proyecto se usará el lector ELM327 siendo sus principales características las
siguientes:

 Funciona igual que un escáner automotriz, siempre que dispongamos de un software

que decodifique los datos enviados.
 Soporta los 5 protocolos de comunicación de sistema OBD-II anteriormente descritos.
 Utiliza un circuito integrado ELM327 de la compañía ELM Electronics.
 Trabaja con los nueve modos de medición del sistema OBD-II.
 Velocidad de señal 38400 baudios .
 Voltaje de operación 12V (Voltaje batería).

5. INTERFACE ELM327
Los automóviles que son producidos hoy en día requieren, por ley, un sistema que proporcione
el diagnóstico del vehículo. Los datos son transmitidos a interfaces, los cuales utilizan
estándares, pero ninguno de ellos son directamente usables por el ordenador o dispositivos
inteligentes. ELM327 tiene como objeto actuar como puente entre los puertos de los sistemas
OBD y el PC o dispositivo inteligente.

El dispositivo es capaz de interpretar nueve protocolos OBD, las comunicaciones son de alta
velocidad y un sistema de baja energía cuando no se esté utilizando

5.1 TIPOS DE COMUNICACIÓN INTERFACE-OBD

5.1.1 COMUNICACIÓN INALÁMBRICA

La comunicación interface-PC puede ser de tipo inalámbrica, ya que elm327 dispone de
dispositivos bluetooth y wifi. En este proyecto se utilizará un dispositivo bluetooth.

5.1.2 COMUNICACIÓN RS232

La comunicación OBD-PC será por puerto serie RS-232, define la interconexión serie entre un
dispositivo transmisor de datos y receptor de datos. En un principio estaba orientado a
conexiones punto a punto pero se fue introduciendo en el entorno industrial para
comunicaciones entre captadores y sistemas de adquisición de datos.

11
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

La comunicación serie envía y recibe información hasta completar todos los bits de un dato, la
comunicación suele realizarse a través de tres líneas, dos de recepción y envío de datos y otra
de tierra.

Existen dos tipos de transmisión serial, síncrona y asíncrona, en la comunicación asíncrona es

posible recibir y transmitir simultáneamente y la duración de cada bit está dada por la velocidad
de transmisión. Normalmente cuando no se está transmitiendo información, la línea permanece
en estado alto y cuando se quiere iniciar la transferencia de datos se coloca en bajo por un
tiempo determinado, esto se conoce como bit de arranque. Después de transmitir cada uno de
los bits del menos significativo al más significativo se coloca la línea de nuevo en alto un tiempo
determinado antes de transmitir otro byte de información. Para realizar una comunicación
síncrona, existen otras líneas de intercambio de pulsos de sincronización, los cuales indican
cuando un byte es válido. Los parámetros más importantes en la comunicación serial son:

 Velocidad de transmisión (Baud rate): La velocidad de transmisión se define como el

número de bits por segundo que se envían. Por ejemplo una comunicación a 300
baudios significan 300 bits por segundo.

 Bits de datos: Este parámetro se refiere al número de bits que se enviaran por paquete.
El numero bits por paquete no siempre es de la longitud de un byte, pueden ser menos
o más bits. Los bits de todos los determina el tipo de información que se envía. Un
paquete se refiere a la transferencia de los bits de datos, bits de inicio/parada y paridad.

 Bits de parada: Se refiere al el bit que indica el fin de la comunicación de un paquete.

Debido a que cada equipo posee su propio reloj, es posible que no estén sincronizados.
Por lo que los bits de parada también proporcionan un margen de tolerancia.

 Paridad: El bit de paridad sirve para verificar si hay errores en la comunicación serial.
Existen tres tipos de paridad: par, impar y espaciada.

Existe la posibilidad de comunicar el dispositivo mediante USB con el ordenador, realizándose

como se muestra a continuación:

12
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

6. COMUNICACIÓN SERIE
En este apartado se trata de usar un software para poder ver que datos se están transmitiendo
por los puertos COM ya que la OBD estará conectada al PC mediante puerto serie para ello se
creará mediante un software un par de puertos virtuales y con otro software se enviará
información que será captada por el otro puerto de la pareja. Para tener una vista rápida de lo
que se quiere hacer se presenta el siguiente esquema:

13
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

6.1 SOFTWARES UTILIZADOS

6.1.1 NULL MODEM EMULATOR

Null Modem Emulator com0com es un controlador de puerto serie virtual, el cual está
disponible libremente, permite la creación de pares de puertos COM virtuales. La salida de un
puerto es la entrada del otro y viceversa.

A continuación se muestra el formato inicial del software instalado, en el cual se puede crear los
pares de puertos virtuales, elegir conexiones…

De esta forma se puede conectar virtualmente dos puertos que necesiten el intercambio de
datos vía puerto COM.

Los nuevos puertos virtuales a crear serán nombrados como COM30 y COM40.

14
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ahora se procede a ver si el programa funciona correctamente. Abriendo el administrador de

dispositivos del PC y se puede observar que se ha creado un nuevo puerto serie como describe
la siguiente imagen:

Para verificar que el envío de datos a través de estos puertos se realiza correctamente, se hará
uso de otro software llamado RealTerm.

6.1.2 REALTERM
Se define puerto serie virtual como un software que genera puertos seriales emulados en el PC,
lo que permite realizar comunicaciones entre ellos sin que existan físicamente. Esto permite
realizar las pruebas al software y la comunicación.

Es muy útil para depurar y hallar los fallos de comunicación sin tener que conectar todo
físicamente.

15
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Una vez instalado, el programa tendrá el siguiente aspecto:

6.1.3 VIRTUAL SERIAL PORT DRIVER

Sin embargo el programa RealTerm no reconocía estos puertos virtuales creados, por lo que se
cambió de software para la creación de los puertos virtuales. Este software es Virtual Serial Port
Driver desarrollado por Eltima.

Este software también es sencillo de utilizar, crea el par de puertos a los que llamados COM30 y
COM40.

16
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En el panel de control, seleccionando administrador de dispositivos y se observa si este puerto

ha sido creado correctamente.

Tras ello usando RealTerm, se selecciona la pestaña “Ports” hay que seleccionar los baudios
deseados.

Se define baudio como una unidad de medida utilizada en telecomunicaciones, que representa
el número de símbolos por segundo en un medio de transmisión digital.

En el desplegable donde están los puertos, se selecciona el puerto COM30 creado

anteriormente.

Se abre otra ventana de RealTerm y realizando la misma operación, pero ahora el puerto
COM40.

17
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ahora en la pestaña Send se puede enviar información de un puerto y que la recoja el otro de la
siguiente forma:

7. PROGRAMA DE LECTURA DE PUERTO SERIE

LabvView posee una librería, VISA, que ofrece la posibilidad de controlar puertos tales RS232,
COM…

Para este proyecto se ha usado NIVISAfull15.01

El objetivo de este apartado es familiarizarse con el programa Labview y su driver VISA, para ello
se creará un programa el cual lea lo que está ocurriendo en un puerto COM seleccionado.

El puerto COM es seleccionado en VISA resource name, se activa la comunicación serie y se

indican los baudios a los que se va a trabajar, estos baudios deben ir en concordancia con los de
la interface ELM327, en este caso se selecciona 9600 baudios. El programa trabajará durante 20
segundos, leerá únicamente los bytes detectados en el puerto seleccionado y los mostrará en el
panel frontal por medio de un indicador, por último sólo quedaría cerrar la comunicación.

18
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Creando un programa de LabView para que lea el puerto COM40 y muestre por pantalla, la
información será enviada desde RealTerm, en el cual se selecciona el puerto COM30 y se envía
la información al puerto COM40, datos que registrará LabView para posteriormente mostrarlo:

8. PROGRAMA ESCRITURA PUERTO SERIE

En la página de National Instruments, se encuentra disponible para su descarga el archivo
serial_write, el cual será usado para continuar con la realización de pruebas.

El funcionamiento de este programa de escritura describe el siguiente proceso, en primer lugar

se inicializa la comunicación serie indicando por qué puerto hay que escribir y la velocidad.
Mediante un bucle while se enviará lo que se haya escrito en el controlador “write buffer”
continuamente cada 500ms el puerto seleccionado, finalmente se cerrará la comunicación
serie.

Con el archivo serial_write, desde el puerto que deseemos, en este caso seleccionando el
puerto COM30 se podrá enviar información, esta debe recibirla el puerto COM40, por lo que
realizando una comprobación:

19
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

A través del Visa serial, seleccionando el puerto deseado, y los bauds que deben coincidir, tanto
en el programa de LabView como en RealTerm. En la zona de escritura, ahí se crea un bucle que
esté leyendo continuamente que hay escrito en el buffer para su envío.

20
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

9. PROGRAMA ESCRITURA Y LECTURA

Debido a que no solo es necesario leer la información que proviene de la OBD II sino que
también se hace necesario enviar información, PIDs, que se describirán en apartados
posteriores, se procede a realizar un programa en LabView para realizar pruebas de escritura y
lectura en los puertos.

El programa comienza inicializando la comunicación serie, para ello se habilitan dos puertos, ya
que se han creado un par de puertos virtuales para las pruebas, en ellos se seleccionará el
puerto que se quiere usar para la escritura y para la lectura, la velocidad de la comunicación
que en este caso hemos seleccionado para los dos 9600 baudios y 8 bites de datos a enviar

A continuación se muestra cómo quedaría el programa:

21
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

10. PRIMERA PRUEBAS CON OBD II

El hardware ELM327 es un dispositivo de diagnosis para coches multimarca capaz de conectar a
“todos los vehículos del mercado” gracias a que soporta todos los protocolos de conexión:

EOBD/OBD II (ISO-9141, ISO14230 (KWP2000) PWM, VPW y CAN)

Para realizar el primer ensayo, para ver si funciona correctamente nos descargamos desde “Play
Store” la aplicación Torque Lite, la cual ofrece un amplio abanico de operaciones.

Se puede utilizar el GPS para proporcionar los registros de seguimiento con el motor de registro
para que pueda ver lo que estaba haciendo en cualquier momento también puede mostrar y
restablecer un DTC / CEL / código de fallo como un scantool.

Herramienta de diagnóstico que utiliza un sistema OBD II adaptador Bluetooth para conectarse
a su motor de su gestión OBD2 / Diseño ECU propio tablero con los widgets / medidores que
selecciones.

Las emisiones de CO2 de lectura de cuadros de mando personalizables, masiva base de datos de
código de error para permitir la búsqueda de códigos de avería de muchos fabricantes

La interface se conecta en el vehículo como se muestra a continuación:

22
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Una vez instalado este software, en los ajustes del dispositivo móvil, se activa el Bluetooth y
comenzar una búsqueda de dispositivos Bluetooth.

Una vez se seleccione OBDII, pedirá la vinculación entre dispositivos. Esto se hace introduciendo
una contraseña, que por defecto será 1234.

Como primera prueba se procede seleccionar en la aplicación realizar un barrido de señales de

falla, a ver si todo está correcto en el vehículo:

23
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Vemos que el fallo P2620, según el software, es un fallo en una mariposa, realizando una
búsqueda en un catálogo virtual de códigos de fallas, a ver si coincide, con el fallo descrito.

Como se puede comprobar, el fallo coincide. Ahora se conectará mediante un software e

interface que proporciona BMW a los concesionarios, a ver si el resultado es el correcto.

En primer lugar se conecta la interface que es proporcionada con el software de diagnosis

oficial:

24
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Esta interface que utiliza rs232 como sistema de comunicación se conecta a un convertidor
rs232 a Ethernet.

Una vez iniciado el software, y activada la pestaña de prueba del vehículo, este muestras las
distintas unidades de control que hay en el coche:

25
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El fallo se encuentra la unidad de control “DDE”

26
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

10.1 MONITORIZACIÓN CON TORQUE

El software Torque permite también la monitorización en tiempo real del estado del vehículo,
algunos de los PID que permite monitorizar son los que se muestran a continuación:

27
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En esta prueba se hará uso de los siguientes PIDs

 Velocidad del vehículo, proporcionada por la posición GPS. Unidades Km/h.

 Velocidad del vehículo, proporcionada por la OBD II. Unidades :Km/h.
 Posición en el eje Z del pedal del acelerador. (La posición del pedal de aceleración toma
como referencia 0 la posición en la que se encuentre el teléfono móvil, dato que ofrece
el giroscopio del mismo). Unidades: Tanto por uno.
 Vueltas del motor. Unidades: RPM.

Para la selección de estos PIDs se despliega el menú, añade pantalla y se procede a elegir como
quiere que se muestre por pantalla, el PID, el tamaño y la posición a ocupar en la pantalla:

28
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El ejemplo tendrá el siguiente aspecto:

Ahora se realiza una prueba para las RPM, en la cual ponemos a aproximadamente el vehículo
parado a 1500 RPM.

29
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ahora se procede a realizar la prueba de velocidad:

11. COMANDOS AT
Los comandos AT o comandos Hayes, fueron desarrollados por la empresa Hayes
Microcomputer Products Inc. sobre el año 1978 para poder comunicarse con su módem con la
capacidad de controlar el modem a través de la línea de datos.

El modem desarrollado por Hayes era externo, lo que le permitía comunicarse con todos los
ordenadores de entonces por medio del puerto RS232. Casi todos los comandos comienzan con
la secuencia “AT”, que significa atención. Más adelante los comandos AT se convirtieron en un
estándar y la TIA/EIA (Telecommunications Industry Association/Electronic Industries Alliance)
lo público bajo el título “Data Transmission Systems and Equipment - Serial Asynchronous
Automatic Dialing and Control”, también conocido como TIA/EIA-602.

En el aparato de diagnóstico a utilizar, se pueden configurar algunos parámetros y así modificar

el comportamiento. Muchos de estos parámetros son auto-configurables, puesto que verifica el
protocolo que soporta el módulo OBD II, ajusta la velocidad de transferencia y otros parámetros
de transmisión de datos. Algunas de las cosas que podemos cambiar es por ejemplo resetear o
reiniciar, ajuste de tiempos de espera habilitar el “echo”… Todo esto se consigue a través de los
comandos AT. A continuación se muestra una imagen el aspecto que tiene el envío de
comandos AT.

30
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

ELM327 reconoce los comandos que empiezan por “AT”, cuando lo ejecuta correctamente
devuelve un “OK” o el valor de lo que le hemos solicitado. Los valores numéricos tanto enviados
como recibidos se hacen en hexadecimal. A continuación se expone una tabla con la descripción
y el valor de algunos comandos a modo de ejemplo, estos comandos AT han sido extraídos del
datasheet de la interface.

Valor Descripción
AT Z Reinicia
AT @1 Descripción del dispositivo
AT @2 Identificador del dispositivo
AT DP Descripción del protocolo
AT I Nos muestra la versión ID

11.1 PRUEBAS ELM 327 Y COMANDOS AT

En primer lugar hay que vincular el ordenador con la interface.

31
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Para el envío de comandos AT se utilizará el driver serial_write, al cual será necesario realizar
unas modificaciones, ya que el envío de datos AT necesita de un envío específico tanto para el
cierre de línea como para que baje a la siguiente. Para ello se habilita en el VISA serial “Enable
termination Char” y definirá que será lo que lo active, en este caso 0xA.

Se creará un “Concatenate Strings”, donde en primer lugar se realizará en el envío de

información AT por defecto, ya que todos los comandos AT lo llevan delante, se ha habilitado
una variable de control para el envío deseado y para terminar el salto de línea.

32
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El programa tendrá el siguiente aspecto en su diagrama de bloques:

Mientras que el panel frontal se mostraría así:

Al realizar un envío de un comando AT recibiremos de vuelta lo que hemos solicitado como ya

se explicó anteriormente, por lo que se necesita volver a utilizar el programa lectura y escritura
que se describió en apartados anteriores, pero realizando estos cambios en la parte de
escritura.

33
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

La primera prueba que a realizar será con uno de los comandos AT que aparecían en el cuadro
de ejemplos, en concreto el comando AT I, el cual mostrará la versión del ID de la interface.

34
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Como se puede observar, al realizar el envío del comando AT, la interface devuelve su ID, en
este caso ELM327 v2.1.

Para la realización de las pruebas con los PIDs, en el datasheet del ELM 327 se encuentra los
pasos que debemos seguir si se ha estado utilizando la interface previamente.

En primer lugar se debe enviar el comando AT encargado de resetear, esto se hace con el
comando AT Z. Tras esto la interface debería responder encendiendo un led y pintando

“ELM 327 v2.1”.

El siguiente paso es elegir un protocolo, una manera sencilla de elegirlo es mediante el envío del
comando AT SP 0, el cual le dirá que seleccione automáticamente uno.

Se puede pedir a la interface que muestre el protocolo que está utilizando para realizar las
comunicaciones mediante el comando AT DP.

35
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El protocolo que está utilizando la interface es el ISO 1596-4 (CAN 11/500). Del conector
hembra se puede extraer información acerca de que protocolo utiliza el vehículo. El método
para identificar que pines disponibles hay que fijarse en que exista continuidad en dichos pines.

En la imagen se aprecia como los pines disponibles son 3, 4, 5, 6, 8, 9, 11, 12, 13, 14 y 16.

En la siguiente imagen se describe a que corresponde cada uno de los pines.

36
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Existen pines habilitados por el fabricante que no corresponden con los estandarizados, como
se puede observar en la imagen.

El protocolo ISO15765-4 CAN se corresponde con el pin 6, pin disponible en el vehículo, por lo
que será posible la comunicación con el vehículo Mediante el comando AT SPx, donde x será el
número del protocolo que deseemos. A continuación se muestran los protocolos soportados
por la ELM327:

Cabe destacar que se realizaron pruebas en diferentes coches para comprobar las
comunicaciones con diferentes vehículos, a continuación se muestra una lista de los coches
probados:

Marca Modelo Año

Mini One 2011
BMW Serie 1 2010
BMW 320d 2004
BMW 320d 2013
Chevrolet Matiz 2007
Citroën Berlingo 2005

Todos los vehículos fabricados a partir del 2008 deben llevar obligatoriamente el protocolo de
comunicación ISO15765-4 CAN.

37
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

38
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

12. ELM 327 PIDs

Se define OBD II PIDs como códigos de identificación de los distintos parámetros medibles en el
vehículo. El estándar OBD II define algunos parámetros, sin embargo el fabricante de los
vehículos, puede introducir sus propios códigos.

El estándar SAE J1979 de Society of Automotive Engineers define algunos OBD II PIDs para sus
distintos modos de operación. En el Modo 1 es donde se encuentran los datos actuales del
vehículo.

El sistema OBD-II utiliza distintos modo de medición, depende de cada uno de ellos permite el
acceso a ciertos datos de la ECU del automóvil.

Los datos de un automóviles son solicitados a través de códigos PID(Parameter Identification).

Cada código PID está relacionado con una medida específica de los modos 1 y 2 del sistema
OBD-II.

Modo 1- obtención de datos

En este modo se puede acceder a los datos en tiempo real producidas por los sensores del
motor de un automóvil. Para solicitar las medidas se necesita mandar una solicitud a la ECU, a
través del código PID, luego la ECU enviará una respuesta.

Algunos ejemplos de medidas que se encuentran en este modo serían: temperatura

refrigerante del motor, RPM del motor, velocidad del automóvil, temperatura del aire de
admisión, posición absoluta del acelerador.

39
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Modo 2- acceso a cuadro de datos congelados

Se accede a los valores que se encuentran en la memoria de la ECU, suele ser fallos que
quedaron guardados. De funcionamiento similar al modo 1 con la diferencia de que los valores
en este caso no son en tiempo real.

Modo3- obtención de los códigos de fallo

Con este modo se puede acceder a los códigos de falla DTC (Data Trouble Codes) que se
encuentran almacenados en la ECU. Destacamos que las fallas ocurren cuando en alguno de los
sensores ocurre una medida fuera a la del rango admisible.

Modo4- borrado de los códigos de fallo y valores almacenados

En este modo se pueden borrar los códigos de falla almacenados en la ECU, quedando su
memoria a cero.

Modo 5- resultado de las pruebas de los sensores de oxígeno

Aquí se tiene acceso a los resultados de las pruebas realizadas a los sensores de oxígeno, así se
determina la eficiencia del catalizador. No es válido para CAN.

Modo 6-Resultados de las pruebas de otros sensores

No todos los sistemas o componentes precisan de una constante vigilancia, en este modo
tenemos acceso a ellos. Sólo para CAN.

Modo 7-Muestra de códigos de fallo pendientes

Se puede leer la memoria de la ECU donde se encuentran los DTCs pendientes que no han sido
reparados o borrados.

Modo 8-Control de funcionamiento de componentes

En este modo se pueden realizar pruebas a los actuadores como válvulas con el fin de activar o
desactivar los mismos, este modo no debe ser usado por personas que no tengan la adecuada
formación.

Modo 9-Información del automóvil

En este modo se puede solicitar el número de identificación del automóvil, llamado VIN, consta
de 17 caracteres alfanuméricos sin incluir ni la I, O ni Q. Con lo que podemos identificar el
automóvil esté donde esté.

En la siguiente imagen se muestra un ejemplo de un VIN.

40
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

A continuación se muestra una tabla donde se exponen a modo de ejemplo algunos de los OBD
II PIDs:

PID TAMAÑO DESCRIPCIÓN MÍNIMO UNIDADES FÓRMULA

00 4 PIDs soportados
0C 2 Engine RPM 0 RPM ((A*256)+B)/4
0D 1 Vehicle speed 0 Km/h A

Donde PID es el identificador del código, el tamaño es el número de bytes del código, mínimo
refiere al valor más pequeño que nos dará, mientras que la fórmula viene dada para convertir el
dato recibido en lo que se desea transformar, para su correcta interpretación, mientras que la
letra A representa el primer byte, la letra B el segundo y así sucesivamente.

Como se explicó, existen diferentes modos de funcionamiento, ahora lo que se busca es enviar
un PID para que nos devuelva que PIDs disponibles, para ello es necesario acceder al modo 01
de funcionamiento, en el cual podemos visualizar los datos. Para realizar el envío del PID
debemos seleccionar primero el modo, en este caso será 01 y posteriormente el PID que
deseamos. Debemos de recibir un número hexadecimal, el cual pasándolo a binario dará los PID
soportados de la siguiente forma.

Si recibimos por ejemplo “BE1FA813” su número binario será:

”10111110000111111010100000010011”

Lo cual se traduce que leyendo de izquierda a derecha, cada posición del número binario se
corresponderá con PID, el 0 indicará que ese PID no está disponible, mientras que el 1 indicará
que está disponible de esta forma estarán disponibles para este ejemplo los PIDs:

01, 03, 04, 05, 06, 07, 0C, 0D, 0E, 0F, 10, 11, 13, 15, 1C, 1F y 20

41
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ahora se realizará el envío del PID 00 en el modo 01 siendo este el resultado:

El número hexadecimal es “41 00 98 3B A0 13”.

Según el datasheet de la interface el 41 significa 01+40, siendo el 01 el modo en el que nos

encontramos, mientras que después nos repite el PID enviado 00, los siguientes números
representan el número hexadecimal que pasado a binario nos dará los PIDs soportados.

Por lo que el número “98 3B A0 13” pasado a binario sería:

“10011000001110111010000000010011”

Bin 1 0 0 1 1 0 0 0 0 0 1 1 1 0 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1
So S N S S S N N N N N S S S N S S S N S N N N N N N N N S N N S S
PID 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2
1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F 0

Por lo que los PIDs que soporta son los siguientes:

 01: Supervisar el estado.

 04: Carga del motor.
 05: Temperatura del refrigerante del motor.
 0B: Presión del colector de admisión.
 0C: Revoluciones por minuto del motor.
 0D: Velocidad del vehículo.
 0F: Temperatura del aire de admisión.
 10: Caudal de aire a través del MAF (Mass air flow).
 11: Posición del acelerador.

42
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

 13: Sensores de oxígeno presentes.

 1C: OBD estándares del vehículo.
 1F: Tiempo que lleva encendido el motor.
 20: PIDs soportados del 21 al 40.

Cabe destacar que todos estos PIDs seguirían dentro de modo 01 de funcionamiento.

Ahora se procede a ver que PIDs están disponibles en todo el modo 01 de funcionamiento para
ello se sigue con el PID 20.

El número hexadecimal es “B0 19 A0 11”.

En binario “10110000000110011010000000010001”

Por lo que los PIDs disponibles serán:

 21: Distancia recorrida con la lámpara indicadora de mal funcionamiento.

 23: Sensor de oxígeno 4 relación de combustible-aire.
 24: Sensor de oxígeno 6 relación de combustible-aire.
 2C: Sensor de oxígeno 7 relación de combustible-aire.
 2D: EGR error.
 30: Calentamientos desde que se borraron los códigos.
 31: Distancia recorrida desde que los códigos se borrados.
 33: Presión absoluta barométrica.
 3C: Temperatura del catalizador (banco 1 sensor 1).
 40: PIDs soportados del 41 al 60.

43
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Se puede realizar otra prueba de similares características con el PID 40 en el modo 01 que
mostrara los PID disponibles desde el 41 al 60.

Número hexadecimal que devolvió “CC D0 00 00” en binario corresponde al número

“11001100110100000000000000000000”.

PIDs disponibles:

 41: Supervisar el estado del ciclo de conducción actual.

 42: Control del módulo de voltaje.
 45: Posición relativa del acelerador.
 46: Temperatura del aire del ambiente.
 49 Posición del acelerador D.
 4A:Posición del acelerador E
 4C: Mando de accionamiento del acelerador.

Como se puede observar el PID 60 no está disponible, que es el que dice los PIDs disponibles
desde el 61 al 80. Realizando una prueba, nuestra interface debería de devolver, según el
datasheet, “NO DATA”.

44
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Realizando la misma operación para el PID 80.

Este PID tampoco es soportado, por lo que para saber si se puede trabajar del PID 61 al A0, se
debería de hacer manualmente.

En el modo de funcionamiento 02 se trabaja igual que lo expuesto anteriormente, idénticos

PIDs la diferencia radica en que estos datos recibidos no son en tiempo real, proporciona los
datos congelados.

El modo de funcionamiento 03, como ya se expuso anteriormente, dice cuántos códigos de fallo
tiene el vehículo, no tiene PIDs disponibles, simplemente muestra el mensaje con su cabecera y
tras el 43 fruto de 40+03 proporciona los dos números hexadecimales finales proporciona el
número de fallos.

45
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El vehículo muestra cero fallos, cuando se realizaron las fotos del taller se borraron todas las
fallas, de ahí que ya no muestre ninguno.

En esta ocasión se trabajará con el modo de funcionamiento 09.

El número hexadecimal obtenido es el siguiente“54 62 00 00”.

Pasado a binario se obtiene “1010100011000100000000000000000”.

 01: VIN Contador de mensajes

46
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

 03: Calibración número de mensajes ID.

 05: Calibración números de verificación mensaje de recuento.
 09: ECU número de mensajes nombre para el PID 0A
 0A: Nombre del ECU.

Mientras que los PID del 12 al 255 están reservados para el modelo IDO/SAE.

Ahora se procede a obtener el VIN del vehículo.

El número hexadecimal obtenido es “01 57 42 41 33 44 39 31 30 32 30 46 34 30 36 34 39 30”

en este caso el hexadecimal hay que pasarlo a ASCII para obtener el valor del VIN que está
reflejado en el vehículo. Su equivalente en ASCII es “WBA3D91020F406490”. Bajo el capó del
vehículo se encuentra reflejado su VIN y coincide con el valor que nos ha devuelto la interface.

Antes de empezar a crear programas para la monitorización se procede a comprobar el

funcionamiento de uno de los PIDs, como por ejemplo el de la velocidad del vehículo 0D.

47
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En esta primera fotografía se muestra el valor que devuelve estando el vehículo parado, si se
observa se obtiene los valores de cabecera 41 0D por lo explicado anteriormente y luego los
valores de la velocidad en hexadecimal, las unidades del valor devuelto al ser en hexadecimal,
para obtener los km/h será necesario realizar la conversión hexadecimal-decimal. En este caso
la velocidad sería de 0km/h.

Para las dos imágenes anteriores, se observa que devuelve un valor de 8km/h y de 0B
correspondiente a 11km/h respectivamente.

12.1 MEJORA EN EL PROGRAMA DE ESCRITURA Y LECTURA

Con el fin de no estar enviando continuamente comandos a la interface se ha creado un nuevo
programa bajo Labview, en el cual introduciendo case, botones y recogeremos los datos leídos
en el buffer en un archivo .txt

48
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Mientras no se pulse el botón WRITE estará dentro de false, por lo que no se enviará nada,
mientras que la lectura, cuando tenga más de un byte en el puerto se realizará la lectura.

Por el contrario si se pulsa WRITE se entrará en true donde se enviará el dato escrito en
COMMAND, cuando el número de bytes sea cero el case entrará en false y no se estará leyendo
nada.

En cuanto a la recolección de datos en un .txt se ha puesto que sea un archivo solo de escritura.
El panel frontal tendrá el siguiente aspecto después de los cambios.

49
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

13. PRUEBAS DE FALLO

En este apartado se va a provocar un fallo quitando sensores, en este caso será el sensor de
presión del turbo.

Una vez quitado el sensor, se procede a arrancar el vehículo el vehículo y se encenderá una luz
en el cuadro, indicando incidencia. Mediante este modo 03 se puede visualizar el fallo.

50
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El tratamiento de esta respuesta es el siguiente, el primer byte en este caso 02, al pasarlo a
binario “10” nos da el primer carácter del DTC como se refleja en la siguiente tabla:

Por lo que el primer carácter será B.

El segundo byte nos da el valor de la segunda del DTC haciendo uso de la siguiente tabla:

El segundo carácter será 1.

Los restantes caracteres se obtienen con la siguiente tabla:

51
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

14. BORRRRADO DE FALLOS

Con el modo 04 se borran los fallos, para ello se ejecuta y comprueba mediante el modo 03 de
nuevo.

Como se observa ahora tenemos 0 fallas. Haciendo uso del modo 07 con el que obtenemos los
códigos de fallo pendiente nos cercioramos de que los códigos han sido borrados.

52
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

15. CREACIÓN DEL DRIVER

Antes de la creación total del driver, se procede a crear un programa en el cual la respuesta sea
escrita manualmente y a partir de su respuesta compuesta por una cabecera, modo de
funcionamiento, PID repetido y hexadecimal solicitado se creará un programa para cada PID
que interprete esta respuesta.

El funcionamiento es mediante case, estos cases son seleccionados a través del PID que se han
enviado, ya que en la respuesta repite el PID justo antes del hexadecimal deseado, el PID
repetido ocupa la posición diez en la cadena de caracteres, cabe destacar que aunque sea un
número hexadecimal, estos están escritos en modo texto, por lo que los espacios también
ocuparán posición.

Sea un ejemplo con la respuesta al PID 00 “7E8 03 41 00 98 3B A0 13” como ya se vio con
anterioridad. Procediendo a fraccionar esta respuesta mediante “String Subset”. Las diez
primeras posiciones son ocupadas por la cabecera, incluyendo el 41 como cabecera, las dos
siguientes serán el PID mientras que la respuesta será iniciada en la posición trece hasta el final,
traducido al lenguaje de Labview se haría lo siguiente:

Cabe destacar que el último String Subset al no tener declarada cuantas posiciones le
perteneces por defecto irá hasta la última posición.

Como se ha nombrado el PID determinará el case en el que se encuentre, siendo para este PID
el case 0, los números hexadecimales del PID devuelto son pasados a decimal mediante un
“Hexadecimal String To”.

53
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

La respuesta es analizada dentro del case.

Como se ha hecho al principio, volviendo a recorrer la respuesta eliminando los espacios, la

respuesta en este caso es “98 3B A0 13” por lo que se recorre de dos en dos, una vez hecho hay
que convertir este hexadecimal a binario para lo que se utiliza “Hexadecimal String To” siendo el
cero conectado al default lo que indica que se convierta a binario. Ahora el siguiente paso será
juntar estos cuatro números binarios, para ello utilizanzo “join numbers”. Este binario ya unido
es enviado a un hi.lo para mostrarlo en el panel frontal.

Como se pretende crear un driver que permita seleccionar un PID y sea guardado en un array, lo
que se hace es mandar el binario a un “Replace Array Subset”, la posición del array se le dará
mediante el PID repetido, en este caso ocupará la posición cero del array. Este array debe ser
inicializado.

Siendo los valores asignados el inicio y final del array, el valor final del array se ajustará cuando
sepamos el número total de PIDs con los que se trabajará finalmente. A través del “Replace
Array Subset” enviamos el dato a New Array donde se mostrará en el panel frontal.

54
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El panel frontal tendrá el siguiente aspecto:

Donde en Respuesta debemos escribir la respuesta de la interface, el recuadro de cabecera nos

mostrará la misma cabecera más el modo de funcionamiento PID repetirá el PID que a pedir,
PIDn es el case en el que nos encontramos, la respuesta mostrará el número a tratar, hi.lo el
resultado final al igual que el New Array, pero este ocupando la posición que ha sido asignada.

Ahora se procede a realizar la prueba, el valor en binario que debería de dar para “98 3B A0 13”
es “10011000001110111010000000010011”. Escribiendo manualmente la respuesta que daría
la interface al PID 00 ejecutando y obteniendo:

El PID 04 se corresponde con la carga del motor. Devuelve una pareja de bits, estos bits han de
ser tratados en decimal y bajo la fórmula:
𝐴
2.55
Donde A es la pareja de bits en decimal, el valor es interpretado como un porcentaje con valor
mínimo 0 y máximo 100 de la carga del motor.

55
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Para este caso el valor devuelto es 3B, en decimal es 59, haciendo uso de la fórmula se obtiene
un 23,13%

56
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 05 devuelve el valor de la temperatura del agua de refrigeración, para tratar esta
respuesta hay que pasar el número a decimal y restarle cuarenta, lo cual otorgará la
temperatura en grados centígrados en el rango de -40 a 215˚C.

En esta prueba se ha obtenido una respuesta “6F”, realizando el cambio se obtiene una
temperatura de 71˚C.

57
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 0B proporciona presión del colector de admisión el único tratamiento que necesita es
pasar a decimal los bytes. Obteniendo el resultado en KPa y trabajando bajo el rango [0, 255]
KPa.

Según esta respuesta tenemos una presión del colector de admisión de 95KPa.

58
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 0C el cual da las revoluciones por minuto del vehículo nos devuelve dos bytes y se trata
cambiando su valor a decimal y mediante la siguiente fórmula:
256𝐴 + 𝐵
4
Donde se tiene el resultado en revoluciones por minuto dentro del rango [0, 16383.75] RPM.

A=0C B=FA

256 · 12 + 250
𝑅𝑃𝑀 = = 830,5
4
Traduciendo esta ecuación a lenguaje de Labview se obtiene:

59
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 0D que devuelve la velocidad del vehículo este PID se trata igual que el OB, únicamente
pasar el byte a decimal.

El PID 0F que devuelve temperatura del aire de admisión del vehículo este PID se trata igual que
el 05, únicamente pasar el byte a decimal y restarle cuarenta, obteniendo un resultado en
grados centígrados y con rango [-40, 215] ˚C.

El PID 10 da el caudal de aire a través del MAF (Mass Air Flow). Devuelve 2 bytes y se tratará
cumpliendo la siguiente fórmula:
256 · 𝐴 + 𝐵
100
Obteniendo un resultado bajo el rango [0, 655.35] expresado en gramos/segundo.

60
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

256 · 2 + 4
= 5.16 𝑔/𝑠
100
Aprovechando el código escrito para el PID OC únicamente cambiando el denominador por
100.

El PID 11 que da la posición del acelerador devuelve un byte, el cual se trata usando la siguiente
fórmula en decimal:
100
𝐴
255
Obtenemos un porcentaje en el rango [0, 100] %

61
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

100
· 216 = 84,70%
255

El PID 1C devuelve un solo byte de datos que describe qué normas OBD ECU cumple.

Se puede observar que devuelve un valor de 6 por lo que según el datasheet la norma seis se
corresponde con EOBD europea.

62
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 1F devuelve dos bytes, los cuales nos dice el tiempo en segundos que lleva el motor
encendido en segundos dentro del rango [0, 65535]. Para su traducción se utiliza la siguiente
fórmula:

256·A+B

Tiempo=256·1+113=369 segundos.

Traduciendo la ecuación anterior a lenguaje Labview se obtiene:

63
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 21 devuelve 2 bytes que proporcionan la distancia que se ha recorrido con alguna
lámpara de mal funcionamiento encendida, usando la ecuación que para el PID 1F se obtiene la
distancia expresada en kilómetros en el rango [0, 65535] km.

El PID 23 devuelve 4 bytes que da la presión manométrica en la vía del combustible, usando la
ecuación 10(256·A+B) se obtiene dicha presión en KPa, en el rango [0, 655350] KPa.

10(256·11+193)= 30090KPa

64
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 24 muestra los resultados del sensor de oxígeno 1, este PID devuelve 4 bytes, si usamos
los dos primeros con la fórmula:
2
(256𝐴 + 𝐵)
65536
Obtenemos el ratio de equivalencia fuel-aire en un rango [0, 2]. En el caso de utilizar los dos
últimos bytes se obtendrá el voltaje dado al sensor siguiendo la fórmula:
2
(256𝐶 + 𝐷)
65536

Para el ejemplo se procede a traducir el ratio, en la prueba previa realizada se ha obtenido la

siguiente respuesta.

65
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

2
(256 · 255 + 255) = 1.999
65536

El PID 2C devuelve el valor del mandado de la EGR (Exhaust Gas Recirculation) mediante un byte
que ha de ser tratado como el PID 11. Proporcionará el valor en porcentaje con un rango de 0 a
100%

El PID 2D el EGR error mediante un byte, que traduciéndose con la ecuación:

100
𝐴 − 100
128
Esta ecuación devuelve el valor en porciento con un rango [-100, 99.2]%

66
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

100
128 − 100 = 0%
128

El PID 30 nos da el número de calentamientos desde que los códigos de fallo se borraran,
proporciona este dato mediante un byte, el cual pasado a decimal otorgará el número de
calentamientos, trabaja en el rango [0, 255] cuentas.

67
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Según la respuesta esto habría ocurrido 198 veces.

El PID 31 devuelve dos bytes que traducidos mediante la ecuación 256A+B da la distancia
recorrida desde que se borraron códigos en el rango [0, 65535] expresado en kilómetros.

256·40+112=10352 km

Reutilizando el código del PID 1F obtendremos los resultados esperados.

El PID 33 da presión absoluta barométrica mediante un byte que cuando se traduce a decimal
se obtiene los KPa en el rango [0, 255] KPa.

68
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Deduce una presión absoluta barométrica de 94KPa.

El PID 3C da temperatura del catalizador (banco 1 sensor 1) mediante dos bytes que son
traducidos mediante la siguiente expresión:
256𝐴 + 𝐵
− 40
10
Obteniendo el resultado en grados centígrados en el rango [-40, 6513,5] ˚C

256 · 2 + 244
𝑡ª𝑐𝑎𝑡𝑎𝑙𝑖𝑧𝑎𝑑𝑜𝑟 = − 40 = 35.6˚𝐶
10

69
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 42 devuelve dos bytes, se traducen mediante la ecuación:

256 · 𝐴 + 𝐵
1000
Con esto se tiene el valor en voltios del control del módulo de voltaje, con un valor entre [0,
65535] V.

256 · 48 + 92
𝑉𝑜𝑙𝑡𝑎𝑗𝑒 = = 12.38 𝑉.
1000

70
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El PID 45 da la posición relativa del acelerador, la forma de tratar este byte devuelto es idéntica
a la del PID 11 o 2C.

71
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Con el vehículo en marcha se obtiene.

100
𝑃𝑜𝑠 𝑅𝑒𝑙 𝐴𝑐 = · 12 = 4.706%
255

El PID 46 da la temperatura del aire del ambiente mediante un byte tratado como el PID 05,
restándole 40 al número devuelto.

72
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Tª ambiente=65-40=25˚C

El PID 49 da la posición del acelerador D tratando el byte devuelto como el PID 45.

73
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

100
𝑝𝑜𝑠 𝑟𝑒𝑙 𝐷 = · 37 = 14.5%
255

El PID4A da la posición del acelerador E, al cual se realizará el mismo proceso para la obtención
de los datos.

El PID 4C mando de accionamiento del acelerador, con el mismo tratamiento que los dos PIDs
anteriores.

74
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

15.1 MEJORA DRIVER

Para la creación del driver lo primero es realizar una mejora en el programa que decodifica los
PIDs, puesto que el programa anterior cuando leía un nuevo valor y lo decodificaba, al mostrarlo
borraba los valores acumulados en las demás casillas.

La mejora se va a realizar utilizando el “Shift Register”, registro de desplazamiento del bucle

while.

75
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Se añade un case para realizar el reseteo de forma manual.

76
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Finalmente se habilitarán los pines para trabajar con este decodificador de códigos como una
subrutina VI.

15.2 DRIVER BAJO NIVEL

El driver final, hará uso de otro driver a crear de bajo nivel que tendrá el comportamiento de
una máquina de estados, el comportamiento será el siguiente.

INIT:

En primer lugar se inicializa la comunicación serie y crea una subrutina VI con el programa
anterior que decodifica las respuestas de los PID, a la cual se pondrá en reset, para habilitar el
estado inicial de la máquina.

77
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

QUERY:

Una vez ejecutado este estado se irá a Query, estado en el cual se realizará la petición, en este
driver de bajo nivel todavía no se implementará el envío automático de PIDs, si no que habrá
que escribirlos manualmente.

Para avanzar al siguiente estado existen dos caminos, ir a STOP o a PAUSE QUERY, para elegir el
camino se hace uso de un selector si el botón de STOP ha sido presionado el selector llamará a
la función que se encuentra en TRUE por lo que irá a STOP, mientras que en el caso contrario irá
a PAUSE QUERY. Ir a los estados se consigue gracias al registro de desplazamiento al cual se le
ha puesto un indicador de estado para ver en el panel frontal el estado en el que se encuentra
la máquina de estados, para mandar el nuevo estado al CASE se hace uso de otro selector en el
cual si reset está en true irá al estado INIT, mientras que si no se presiona RESET irá al estado
recibido por el registro de desplazamiento.

PAUSE QUERY:

El estado PAUSE QUERY es un estado de espera, con el fin de no saturar la ECU a la hora de
enviar automáticamente los PIDs se le da un tiempo de espera que será introducido
manualmente en el panel frontal.

78
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

También se abren dos caminos, a STOP o PARSE con el mismo funcionamiento que el anterior.

STOP:

El funcionamiento del estado STOP cierra la comunicación serie, hasta que no se presione reset
no se puede volver a trabajar con el programa.

PARSE:

El estado PARSE lo que hace es leer lo que devuelve la interface, el funcionamiento es el mismo
que en el programa de escritura y lectura.

79
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Si no se detectan bytes no se hace se activa el case false que no realiza ningún envío y se
enviará al registro de desplazamiento el estado PAUSE PARSE, en el caso que se detecte algún
byte en el puerto activa el caso TRUE en el cual se lee la respuesta y se envía a la subrutina que
decodifica esta respuesta, luego irá al estado QUERY, mientras que se pondrá en TRUE el data
ready, indicando que se ha recibido dato.

80
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

PAUSE PARSE

El estado PAUSE PARSE se comporta igual que el estado PAUSE QUERY con la diferencia de que
el estado siguiente sería QUERY.

Se le dará el siguiente aspecto al driver:

En cuanto a los pines habilitados:

81
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

15.3 DRIVER DE BAJO NIVEL 2.0

En esta ocasión se va a realizar un driver, el cual será otra máquina de estados similar a la
anterior, por lo que se usará como base. La diferencia radica en que se ha quitado la pausa tras
la petición.

INIT

Se tiene un estado inicial, el cual inicializará la comunicación serie y activará la subrutina de

decodificación de códigos, la cual pondrá a cero todos los valores de la ejecución anterior y
empezará con el envío del PID 00, para ello se sitúa una constante de valor 0 y se envía
dirección al registro de desplazamiento.

QUERY

A través de los registros de desplazamiento indicamos que el siguiente estado es el query,

donde se vuelve a realizar la petición. Cuando se pulse “Reset” vuelve al estado por defecto.

82
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En el caso de que se haya arrancado la máquina el registro de desplazamiento mandará un 0, el

cual se convierte a hexadecimal de tamaño 2 para darle el formato “00” y se le añade un 01
delante por lo que el PID a enviar será el 0100, esto se mostrará en el indicador “COMMAND
Out”. Para que una vez haya terminado de ejecutar todos los PIDs se realiza una comparación
del tamaño del array, al cual le restamos uno, ya que empieza en el cero y se comprueba con el
PID enviado, si es más pequeño que el tamaño del array-1 entonces se incrementa la posición
del array y se envía al registro de desplazamiento, en caso contrario, enviamos un 0 para que
vuelva a empezar el ciclo de peticiones.

PARSE

El siguiente estado es PARSE donde se lee la respuesta de la interface, este estado es igual que
el estado PARSE del driver de bajo nivel, que manda dicha lectura a la subrutina de
decodificación de respuesta, una vez se ha leído y decodificado se muestra en el indicador
OBD_PIDs, si no hay datos que leer se irá al estado PAUSE PARSE, realizará la pausa e irá al
estado QUERY de nuevo. Como en el driver de bajo nivel, en este también se puede pulsar STOP
en cualquier momento y parar el programa.

Para hacer uso de este driver en el programa final, habilitaremos los pines de la siguiente forma:

83
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

15.4 CREACIÓN DEL DRIVER FINAL.

Para la creación del driver final hacemos uso de una estructura “Stacked Sequence Structure”,
esta estructura empieza en cero, donde se inicializa nuestro driver de alto nivel, indicando que
puerto utilizaremos y poniendo el reset a true, para ir al estado inicial de la máquina de estados.

El estado 1 tendrá el siguiente aspecto.

Lo que aquí se hace es crear un fichero de escritura, con formato TXT, el cual cada vez que se
ejecute el programa pedirá crear uno nuevo, luego en una estructura while donde aparece el
driver de alto nivel, al cual le envía un array de los PIDs disponibles que habrán sido escritos a
mano en el panel frontal. A continuación se muestra un trozo de dicho array:

84
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Estos PIDs están escritos en decimal, ya que dentro del driver de alto nivel se pasaban a
hexadecimal de dos cifras.

Se habilita un STOP, el cual se conectará con el stop del bucle while y también se indicará el
tiempo de espera en el estado PAUSE PARSE de la máquina de estados.

En el estado CASE, el cual se pondrá en true cuando data ready, salida del driver, indique que
hay datos, en dicho caso del driver se envían los PIDs ya traducidos del pin del driver, los cuales
se podrán visualizar mediante un indicador y envía a un “Array To Spreadsheet String”, el cual
convierte una matriz de cualquier dimensión a una tabla en forma de cadena, que contiene
pestañas que separan los elementos de columna, un carácter EOL dependiente de la plataforma
que separa las filas, y, para las matrices de tres o más dimensiones, los encabezados separan
páginas. Tendrá el formato de float con tres decimales.

La salida de la tabla se envía a un “Write to Text File”. Por último solo quedaría cerrar el fichero
una vez finalice el programa.

En el caso de que data ready ponga el case en FALSE, el programa no realizará ninguna acción.

Se habilita un botón de Reset para enviar un Reset al driver.

85
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

16. PRUEBAS ESTÁTICAS

Antes de realizar ningún tipo de prueba con el vehículo en marcha nos hay que cerciorarse que
el programa funciona correctamente, esto se hace con el vehículo parado y variando por
ejemplo las revoluciones del motor y la velocidad.

En primer lugar pedirá crear el archivo de escritura.

Tras eso, estando el vehículo en ralentí obtenemos:

Recordando que los PIDs de las RPM y la velocidad son 0C, 0D respectivamente, por lo que
ocuparán la posición en la tabla 13 y 14.

86
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

En la flecha negra se indican las revoluciones por minuto, mientras que en la roja la velocidad,
en ralentí 829.5 RPM, la velocidad es cero en ambos casos, acelerando y obteniendo la imagen
en cualquier instante de la aceleración se obtiene una velocidad 1508 RPM.

Observando la posición 18, correspondiente con el PID 11 se obtiene la posición de la válvula en

un rango de 0 a 100 se obtiene que la válvula en esos momentos había recorrido el 84.7%

A continuación se muestra un fragmento de los datos que se han recogido en esta prueba,
guardados en el TXT son los siguientes:

87
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Las pruebas dinámicas se realizarán en el apartado donde se integra el programa con gráficas,
con el fin de que sea más fácil visualizar los cambios en los parámetros gracias a dichas gráficas.

17. GRÁFICAS LABVIEW

Para elegir qué graficar, se realizará una selección de PIDs que tengan una relación directa en el
estado del conductor, es decir, se graficará las revoluciones por minuto, la posición de la válvula
de admisión, ya que esto indicará el tipo de aceleración que realiza el conductor y la velocidad
del vehículo. Se graficará también a modo ejemplo la temperatura del refrigerante.

Dado que el programa utiliza un array en el que cada PID ocupa una posición en concreto se
utilizará un “array index” en el cual se indicará la posición de dicho array a graficar.

Para la válvula, la velocidad y las revoluciones por minuto se hará uso de “graph chart”. Para
que empiece desde cero la siguiente vez que se ejecute el programa hay que irse a property
node, seleccionar history data y colocarlo en el case 0 que se ejecuta por defecto cuando se
inicia el programa y se le manda un cero.

88
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

17.1 PRUEBAS GRÁFICAS

En primer lugar se procede a realizar pruebas estáticas, para ello se visualizará en LabView el
estado en ralentí del vehículo:

89
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Realizando una aceleración se podrá observar si el funcionamiento es el correcto, se realiza

dicha aceleración hasta 2500 rpm.

Una vez comprobado el funcionamiento del programa, se procede a realizar las pruebas con el
vehículo en marcha. En primer lugar se muestra una imagen de un momento de aceleración.

90
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ahora se procede a realizar la misma prueba pero frenando, otorgando la siguientes gráficas.

91
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

El vehículo al no disponer de velocidad crucero, se intentó mantener una velocidad constante

de 50km/h de forma manual, con el fin de obtener una gráfica constante en velocidad.

Una vez se ha comprobado el correcto funcionamiento de las gráficas se procede a

personalizar quedando finalmente con el siguiente aspecto:

92
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

18. CONCLUSIONES Y FUTURAS APLICACIONES

Tras concluir el proyecto puedo comentar que no hay mucha información disponible acerca de
cómo conectarse al vehículo, dado que los fabricantes venden sus propios softwares. Como se
puede observar a lo largo de la memoria, los objetivos marcados al principio de la misma
quedan cumplidos.

El software utilizado es 100% válido para los vehículos que sean el mismo modelo al usado
para la creación del ejemplo, ya que como se detalló en la memoria, ha sido necesario ir
viendo que PIDs estaban disponibles en el vehículo. Dichos PIDs no es necesario que estén
disponibles en otro vehículo de marca diferente, incluso no tienen porque estarlo en coches de
la misma marca pero diferente modelo.

Como futuras aplicaciones, se puede estudiar gracias al almacenamiento de datos qué tipo de
conducción realiza el usuario, si es un conductor agresivo, realizando muchos acelerones, si es
un conductor que circula a límites de velocidad superiores a los permitidos…

Por otro lado también se puede realizar un estudio de cómo está interactuando el conductor
con el vehículo, cabe destacar que la conducción de un usuario cansado no es la misma que la
de un usuario que se encuentra despejado. Por lo que esto más un estudio de actividad
cerebral (encefalograma), ritmo cardiaco, posición del cuerpo... podría dar como resultado la
fatiga del conductor, realizando un aviso al usuario, evitando así que conductores pongan sus
manos en el volante si se encuentran en un estado físico no óptimo.

Otra futura aplicación y más clara todavía es, gracias al almacenamiento de datos, la creación
de una “caja negra” para el vehículo.

93
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

19. ANEXOS
Listado de comandos AT:

94
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

95
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

96
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Lista de PIDs disponibles:

MODO 1 Y 2

Data
PID
bytes Description Min value Max value Units
(hex)
returned

00 4 PIDs supported [01 - 20]

Monitor status since DTCs

01 4
cleared. (Includes
malfunction indicator lamp

97
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

(MIL) status and number of

DTCs.)

02 2 Freeze DTC

03 2 Fuel system status

04 1 Calculated engine load 0 100 %

05 1 Engine coolant temperature -40 215 °C

06 1 Short term fuel trim—Bank 1

07 1 Long term fuel trim—Bank 1 -100

99.2 (Add
(Reduce
Fuel: Too %
Fuel: Too
Lean)
08 1 Short term fuel trim—Bank 2 Rich)

09 1 Long term fuel trim—Bank 2

Fuel pressure (gauge

0A 1 0 765 kPa
pressure)

Intake manifold absolute

0B 1 0 255 kPa
pressure

0C 2 Engine RPM 0 16,383.75 rpm

98
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

0D 1 Vehicle speed 0 255 km/h

°
0E 1 Timing advance -64 63.5
before TDC

0F 1 Intake air temperature -40 215 °C

10 2 MAF air flow rate 0 655.35 grams/sec

11 1 Throttle position 0 100 %

Commanded secondary air

12 1
status

Oxygen sensors present (in

13 1
2 banks)

Oxygen Sensor 1
14 2 A: Voltage
B: Short term fuel trim

Oxygen Sensor 2 0 1.275 Volts

15 2 A: Voltage -100 99.2
B: Short term fuel trim %

Oxygen Sensor 3
16 2 A: Voltage
B: Short term fuel trim

99
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Oxygen Sensor 4
17 2 A: Voltage
B: Short term fuel trim

Oxygen Sensor 5
18 2 A: Voltage
B: Short term fuel trim

Oxygen Sensor 6
19 2 A: Voltage
B: Short term fuel trim

Oxygen Sensor 7
1A 2 A: Voltage
B: Short term fuel trim

Oxygen Sensor 8
1B 2 A: Voltage
B: Short term fuel trim

OBD standards this vehicle

1C 1
conforms to

Oxygen sensors present (in

1D 1
4 banks)

1E 1 Auxiliary input status

1F 2 Run time since engine start 0 65,535 seconds

20 4 PIDs supported [21 - 40]

Distance traveled with

21 2 malfunction indicator lamp 0 65,535 km
(MIL) on

Fuel Rail Pressure (relative

22 2 0 5177.265 kPa
to manifold vacuum)

100
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Fuel Rail Gauge Pressure

23 2 (diesel, or gasoline direct 0 655,350 kPa
injection)

Oxygen Sensor 1
AB: Fuel–Air Equivalence
24 4
Ratio
CD: Voltage

Oxygen Sensor 2
AB: Fuel–Air Equivalence
25 4
Ratio
CD: Voltage

Oxygen Sensor 3
AB: Fuel–Air Equivalence
26 4
Ratio
CD: Voltage

Oxygen Sensor 4
AB: Fuel–Air Equivalence 0 <2 ratio
27 4
Ratio 0 <8 V
CD: Voltage

Oxygen Sensor 5
AB: Fuel–Air Equivalence
28 4
Ratio
CD: Voltage

Oxygen Sensor 6
AB: Fuel–Air Equivalence
29 4
Ratio
CD: Voltage

Oxygen Sensor 7
AB: Fuel–Air Equivalence
2A 4
Ratio
CD: Voltage

101
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Oxygen Sensor 8
AB: Fuel–Air Equivalence
2B 4
Ratio
CD: Voltage

2C 1 Commanded EGR 0 100 %

2D 1 EGR Error -100 99.2 %

Commanded evaporative
2E 1 0 100 %
purge

2F 1 Fuel Tank Level Input 0 100 %

Warm-ups since codes

30 1 0 255 count
cleared

Distance traveled since

31 2 0 65,535 km
codes cleared

Evap. System Vapor

32 2 -8,192 8191.75 Pa
Pressure

Absolute Barometric
33 1 0 255 kPa
Pressure

Oxygen Sensor 1
AB: Fuel–Air Equivalence
34 4
Ratio
CD: Current

Oxygen Sensor 2 0 <2 ratio

AB: Fuel–Air Equivalence -128 <128 mA
35 4
Ratio
CD: Current

36 4 Oxygen Sensor 3
AB: Fuel–Air Equivalence

102
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Ratio
CD: Current

Oxygen Sensor 4
AB: Fuel–Air Equivalence
37 4
Ratio
CD: Current

Oxygen Sensor 5
AB: Fuel–Air Equivalence
38 4
Ratio
CD: Current

Oxygen Sensor 6
AB: Fuel–Air Equivalence
39 4
Ratio
CD: Current

Oxygen Sensor 7
AB: Fuel–Air Equivalence
3A 4
Ratio
CD: Current

Oxygen Sensor 8
AB: Fuel–Air Equivalence
3B 4
Ratio
CD: Current

Catalyst Temperature: Bank

3C 2
1, Sensor 1

Catalyst Temperature: Bank

3D 2 -40 6,513.5 °C
2, Sensor 1

Catalyst Temperature: Bank

3E 2
1, Sensor 2

103
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Catalyst Temperature: Bank

3F 2
2, Sensor 2

40 4 PIDs supported [41 - 60]

Monitor status this drive

41 4
cycle

42 2 Control module voltage 0 65.535 V

43 2 Absolute load value 0 25,700 %

Fuel–Air commanded
44 2 0 <2 ratio
equivalence ratio

45 1 Relative throttle position 0 100 %

46 1 Ambient air temperature -40 215 °C

47 1 Absolute throttle position B

48 1 Absolute throttle position C

49 1 Accelerator pedal position D

0 100 %
4A 1 Accelerator pedal position E

4B 1 Accelerator pedal position F

Commanded throttle
4C 1
actuator

4D 2 Time run with MIL on

0 65,535 minutes
Time since trouble codes
4E 2
cleared

Maximum value for Fuel–Air 255, 255, ratio, V,

4F 4 equivalence ratio, oxygen 0, 0, 0, 0
255, 2550 mA, kPa
sensor voltage, oxygen

104
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

sensor current, and intake

manifold absolute pressure

Maximum value for air flow

50 4 rate from mass air flow 0 2550 g/s
sensor

51 1 Fuel Type

52 1 Ethanol fuel % 0 100 %

Absolute Evap system

53 2 0 327.675 kPa
Vapor Pressure

54 2 Evap system vapor pressure -32,767 32,768 Pa

Short term secondary

55 2 oxygen sensor trim, A: bank
1, B: bank 3

Long term secondary

56 2 oxygen sensor trim, A: bank
1, B: bank 3
-100 99.2 %
Short term secondary
57 2 oxygen sensor trim, A: bank
2, B: bank 4

Long term secondary

58 2 oxygen sensor trim, A: bank
2, B: bank 4

59 2 Fuel rail absolute pressure 0 655,350 kPa

Relative accelerator pedal

5A 1 0 100 %
position

105
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Hybrid battery pack

5B 1 0 100 %
remaining life

5C 1 Engine oil temperature -40 210 °C

5D 2 Fuel injection timing -210.00 301.992 °

5E 2 Engine fuel rate 0 3276.75 L/h

Emission requirements to
5F 1
which vehicle is designed

60 4 PIDs supported [61 - 80]

Driver's demand engine -

61 1 -125 125 %
percent torque

Actual engine - percent

62 1 -125 125 %
torque

63 2 Engine reference torque 0 65,535 Nm

64 5 Engine percent torque data -125 125 %

Auxiliary input / output

65 2
supported

66 5 Mass air flow sensor

67 3 Engine coolant temperature

Intake air temperature

68 7
sensor

Commanded EGR and EGR

69 7
Error

106
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Commanded Diesel intake

6A 5 air flow control and relative
intake air flow position

Exhaust gas recirculation

6B 5
temperature

Commanded throttle
6C 5 actuator control and relative
throttle position

6D 6 Fuel pressure control system

Injection pressure control

6E 5
system

Turbocharger compressor
6F 3
inlet pressure

70 9 Boost pressure control

Variable Geometry turbo

71 5
(VGT) control

72 5 Wastegate control

73 5 Exhaust pressure

74 5 Turbocharger RPM

75 7 Turbocharger temperature

76 7 Turbocharger temperature

Charge air cooler

77 5
temperature (CACT)

Exhaust Gas temperature

78 9
(EGT) Bank 1

107
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Exhaust Gas temperature

79 9
(EGT) Bank 2

7A 7 Diesel particulate filter (DPF)

7B 7 Diesel particulate filter (DPF)

Diesel Particulate filter

7C 9
(DPF) temperature

7D 1 NOx NTE control area status

7E 1 PM NTE control area status

7F 13 Engine run time

80 4 PIDs supported [81 - A0]

Engine run time for Auxiliary

81 21 Emissions Control
Device(AECD)

Engine run time for Auxiliary

82 21 Emissions Control
Device(AECD)

83 5 NOx sensor

Manifold surface
84
temperature

85 NOx reagent system

Particulate matter (PM)

86
sensor

Intake manifold absolute

87
pressure

108
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

A0 4 PIDs supported [A1 - C0]

C0 4 PIDs supported [C1 - E0]

MODO 05

PID Data bytes Min Max

Description Units Formula[a]
(hex) returned value value

OBD Monitor IDs

0100 supported ($01 –
$20)

0.005 Rich to lean

O2 Sensor Monitor
0101 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 1
voltage

0.005 Rich to lean

O2 Sensor Monitor
0102 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 2
voltage

0.005 Rich to lean

O2 Sensor Monitor
0103 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 3
voltage

0.005 Rich to lean

O2 Sensor Monitor
0104 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 4
voltage

109
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

0.005 Rich to lean

O2 Sensor Monitor
0105 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 1
voltage

0.005 Rich to lean

O2 Sensor Monitor
0106 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 2
voltage

0.005 Rich to lean

O2 Sensor Monitor
0107 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 3
voltage

0.005 Rich to lean

O2 Sensor Monitor
0108 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 4
voltage

0.005 Rich to lean

O2 Sensor Monitor
0109 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 1
voltage

0.005 Rich to lean

O2 Sensor Monitor
010A 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 2
voltage

0.005 Rich to lean

O2 Sensor Monitor
010B 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 3
voltage

110
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

0.005 Rich to lean

O2 Sensor Monitor
010C 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 4
voltage

0.005 Rich to lean

O2 Sensor Monitor
010D 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 1
voltage

0.005 Rich to lean

O2 Sensor Monitor
010E 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 2
voltage

0.005 Rich to lean

O2 Sensor Monitor
010F 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 3
voltage

0.005 Rich to lean

O2 Sensor Monitor
0110 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 4
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0201 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 1
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0202 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 2
voltage

111
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

0.005 Lean to Rich

O2 Sensor Monitor
0203 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 3
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0204 0.00 1.275 Volts sensor threshold
Bank 1 Sensor 4
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0205 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 1
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0206 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 2
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0207 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 3
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0208 0.00 1.275 Volts sensor threshold
Bank 2 Sensor 4
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0209 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 1
voltage

112
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

0.005 Lean to Rich

O2 Sensor Monitor
020A 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 2
voltage

0.005 Lean to Rich

O2 Sensor Monitor
020B 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 3
voltage

0.005 Lean to Rich

O2 Sensor Monitor
020C 0.00 1.275 Volts sensor threshold
Bank 3 Sensor 4
voltage

0.005 Lean to Rich

O2 Sensor Monitor
020D 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 1
voltage

0.005 Lean to Rich

O2 Sensor Monitor
020E 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 2
voltage

0.005 Lean to Rich

O2 Sensor Monitor
020F 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 3
voltage

0.005 Lean to Rich

O2 Sensor Monitor
0210 0.00 1.275 Volts sensor threshold
Bank 4 Sensor 4
voltage

113
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

MODO 09

Data
PID Min Max
bytes Description Units Formula[a]
(hex) value value
returned

Bit encoded. [A7..D0] =

Mode 9 supported
00 4 [PID $01..PID $20] See
PIDs (01 to 20)
below

VIN Message Count

in PID 02. Only for
01 1 ISO 9141-2, ISO Usually value will be 5.
14230-4 and SAE
J1850.

17-char VIN, ASCII-

Vehicle
encoded and left-
02 17-20 Identification
padded with null chars
Number (VIN)
(0x00) if needed to.

Calibration ID
message count for
It will be a multiple of 4
PID 04. Only for
03 1 (4 messages are
ISO 9141-2, ISO
needed for each ID).
14230-4 and SAE
J1850.

Up to 16 ASCII chars.
Data bytes not used
04 16 Calibration ID
will be reported as null
bytes (0x00).

114
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

Calibration
verification numbers
(CVN) message
05 1 count for PID 06.
Only for ISO 9141-
2, ISO 14230-4 and
SAE J1850.

Raw data left-padded

Calibration with null characters
06 4 Verification (0x00). Usually
Numbers (CVN) displayed as hex
string.

8 if sixteen (16) values

are required to be
reported, 9 if eighteen
In-use performance
(18) values are
tracking message
required to be
count for
reported, and 10 if
07 1 PID 08 and 0B. 8 10
twenty (20) values are
Only for ISO 9141-
required to be reported
2, ISO 14230-4 and
(one message reports
SAE J1850.
two values, each one
consisting in two
bytes).

4 or 5 messages, each
In-use performance
one containing 4 bytes
08 4 tracking for spark
(two values). See
ignition vehicles
below

115
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

ECU name
09 1 message count for
PID 0A

ASCII-coded. Right-
0A 20 ECU name padded with null chars
(0x00).

In-use performance
5 messages, each one
tracking for
0B 4 containing 4 bytes (two
compression
values). See below
ignition vehicles

20. REFERENCIAS

>https://sourceforge.net/projects/com0com/

> http://com0com.sourceforge.net/

> http://elmelectronics.com/ELM327/AT_Commands.pdf

> https://en.wikipedia.org/wiki/OBD-II_PIDs

> http://www.obdtester.com/elm-usb-commands

> https://www.clusterfsck.io/blog/arduino-elm327-library/

116
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

> http://blog-j.marcano.net.ve/?s=realterm&x=0&y=0

> http://realterm.sourceforge.net/

> https://sourceforge.net/p/com0com/support-requests/16/

> https://learn.sparkfun.com/tutorials/terminal-basics/real-term-windows

> http://www.virtual-serial-
port.org/products/vspdxp/?gclid=CjwKEAiAmNW2BRDL4KqS3vmqgUESJABiiwDTmr3nvPfjWlO
5GEXzM9Y4VQi6JkGrcyH7I9XejMxnzRoCuQjw_wcB

> http://embeddedtweaks.com/tutorial-virtual-serial-port-using-vspe/

> https://es.wikipedia.org/wiki/Baudio

> http://www.ni.com/white-paper/7907/es/

> http://www.ni.com/download/ni-visa-15.0.1/5693/en/

> https://www.youtube.com/watch?v=VpxBTtvCklo#t=51.365499

> http://forums.ni.com/t5/Discusiones-sobre-Productos-NI/VI-para-enviar-y-recibir-comandos-
AT-a-traves-del-RS232/td-p/2346806

> http://www.wut.de/e-38011-ww-daes-000.php

> http://www.zonabot.com/9-comandos-at.html

117
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

> http://carsandtechnolgy.blogspot.com.es/2013/11/las-mejores-apps-para-diagnosis-
con_6005.html

> https://play.google.com/store/apps/details?id=org.prowl.torquefree&hl=es

> https://www.youtube.com/watch?v=WR8znKYQRR4

> http://obdii.pro/es/code/P2620

> http://sensoresyactuadoresverano2013.blogspot.com.es/2013/06/sensores-del-
telefono.html

>https://en.wikibooks.org/wiki/Serial_Programming/Modems_and_AT_Commands/Special_C
ommands_and_Character_Sequences

> https://www.youtube.com/watch?v=1Fmp8bH0jPw

> https://support.microsoft.com/en-us/kb/124890

> http://www.obdsol.com/knowledgebase/obd-software-development/reading-real-time-
data/

> http://www.ni.com/academic/students/learnlabview/esa/generate.htm

> http://www.motor66.com/noticias-motor/mecanica/466-mecanica-el-caudalimetro-
medidor-de-masas-de-aire

> https://zone.ni.com/reference/en-XX/help/371361H-01/glang/array_to_spreadsheet_str/

> https://es.wikipedia.org/wiki/OBD

118
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

> https://es.wikipedia.org/wiki/Diagrama_de_Gantt

> http://www.ni.com/data-acquisition/what-is/esa/

> http://www.instrumentacionycontrol.net/cursos-libres/automatizacion/curso-supervision-
procesos-por-computadora/item/271-los-buses-de-campo-directo-al-grano.html

https://sites.google.com/site/sistemasdemultiplexado/protocolos-de-comunicacin/4-2-historia

> http://www.motorpasionfuturo.com/industria/can-bus-como-gestionar-toda-la-electronica-
del-automovil

> http://www.cetitec.com/products/automotive-bus-converter.html

> SISTEMAS SCADA 2ª edición. Autor "Aquilino Rodríguez Pelín".

> http://www.nicoclub.com/archives/the-history-of-on-board-diagnostics.html

> http://www.obdexperts.co.uk/faq.html

> http://www.aficionadosalamecanica.com/obd2.htm

> http://www.pce-iberica.es/medidor-detalles-tecnicos/instrumento-de-automocion/equipo-
automocion-t69.htm

> http://www.ocio.net/motor/descifrando-el-numero-de-serie-de-un-automovil-vin/

> https://theksmith.com/software/hack-vehicle-bus-cheap-easy-part-1/

> http://openxcplatform.com/

119
 PROYECTO FIN DE GRADO

Diseño e implementación de un sistema de captura

CAN/ODBII
Eulogio Gómez Polo

> http://www.obdtester.com/

> http://hackaday.com/2013/10/22/can-hacking-the-in-vehicle-network/

> http://autoayuda-motivacional.com/frases-de-auto-ayuda-henry-ford/

PROYECTOS

-JUAN MANUEL DIMATÉ CÁCERES y PEDRO MAURICIO GONZÁLEZ CASTILLO UNIVERSIDAD

PONTIFICIA BOLIVARIANA

FACULTAD DE INGENIERÍA ELECTRÓNICA

ESCUELA DE INGENIERIAS Y ADMINISTRACIÓN

BUCARAMANGA

2010

-REYES GODÍNEZ JUAN CARLOS

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO.

-SEMINARIO WEB MONITORES OBD II ING. ANTONIO VILLEGAS CASAS

-FRANCISCO MÉNDEZ FLORES

Diseño e implementación de un sistema de captura CAN/ODBII sobre plataformas hardware

abiertas

120