IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO

OBD-II SOBRE BUS CAN CON ARDUINO

IMPLEMENTATION OF AN OBD-II DIAGNOSTICS TOOL OVER CAN

BUS WITH ARDUINO
Armando Rodríguez Rodríguez1, José Raúl Vento Álvarez2

1 Universidad de Pinar del Río, Cuba, arrodriguez@upr.edu.cu, Km1 ½ Carretera a Ovas, Coop. Pedro Téllez, Pinar del
Río
2 Universidad de Pinar del Río, Cuba, vento@upr.edu.cu

RESUMEN: El presente proyecto implementa un sistema de diagnóstico abordo basado en el protocolo de diag-
nosis OBD-II sobre CAN-BUS que permitirá, tanto visualizar variables en tiempo real, como realizar un diagnóstico
del estado del automóvil que muestre los códigos de funcionamiento, falla y rendimient o energético. Los sistemas
de diagnóstico de a bordo nos permiten no solo conocer los códigos de fallos almacenados, también nos permiten
conocer en tiempo real un gran número de variables de especial relevancia como la velocidad, el nivel de combu s-
tible, el nivel de emisión de CO2, etc. El trabajo desarrollado se centra en un sistema de diagnóstico específico
basado en el protocolo OBD-II sobre CAN-BUS, como una de las posibles aplicaciones que posee dicho bus de
comunicación. En el proyecto se implementó un sistema de diagnosis OBD-II centrándose en el extremo del BUS
que corresponde al escáner o unidad de diagnóstico. El sistema propuesto consiste en el desarrollo de un equipo
capaz de recuperar los datos relacionados al estado del vehículo bajo prueba. Estos equipos revisten gran utilidad
a la hora de detectar o, al menos, conducir al personal de mantenimiento automotor, a la solución de averías en
los automóviles. En el sistema se desarrolló el estándar OBD-II en una placa Arduino Mega 2560, conectada un
módulo compuesto transceiver-controller CAN. El scanner posee una conexión USB la cual permite la visualiza-
ción de los datos recuperados de forma versátil en una PC a través de una interfaz gráfica creada en LabVIEW™.
Palabras Clave: OBD-II, CAN, Arduino, ECU

ABSTRACT: This Project implements an on-board diagnostics system based on OBD-II diagnostic protocol over
CAN-BUS, which allows displaying both real time variables and mak e a diagnostic of vehicle status that show ru n-
ning, failure and energy efficiency codes. The on-board diagnostics systems allow us to recover stored failure
codes, also check ing, in real time, a lot of high relevance variables as vehicle speed, fuel level, CO2 emission,
etc. This article is focused in a specific on-board diagnostics system based on OBD-II over CAN-BUS, as one of
the applications of this communication bus. Is implemented in this project an OBD-II diagnostics system related to
the scanner or diagnostic unit. The proposed system consists in developing a capable device of retrieving data of
vehicle under test. These devices are useful in the moment of detecting or, at least, guiding maintenance person-
nel to fix automobile faults. The system was developed over an Arduino Mega 2560 board which is connected to a
transceiver-controller CAN module. The scanner has an USB plug which allows retrieved data displaying in a PC
via graphic interface created in LabVIEW™.

Keywords: OBD-II, CAN, Arduino, ECU

“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales ”
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
1. INTRODUCCIÓN
En el escenario cubano actual, se nos presenta un
acelerado desarrollo del transporte automotor aso-
ciado al crecimiento del turismo y del manejo de
cargas por carretera. En la mayoría de los casos, el
parque disponible de vehículos en estas dos esferas
es de avanzada tecnología, que incluye sistemas
inteligentes abordo y sistemas de diagnóstico de
fallas y análisis de funcionamiento que incluyen efi-
ciencia energética y los efectos medioambientales.
Estos avances han permitido simplificar la reparación
del automóvil, detectando fallos potenciales que pu-
dieran dañarlo aún más, además de simplificar y
centralizar la visualización de variables en tiempo
real, que ahora pueden ser leídas directamente des-
de el ordenador central o ECU (Electronic Control
Unit).
En la actualidad son varios los ejemplos de sistemas
que se comercializan los cuales brindan la posibili-
dad de realizar diagnósticos del estado del automóvil.
[1]
En la última década se han desarrollado varios es-
fuerzos en la investigación de aplicaciones relaciona-
das con OBD-II implementadas sobre bus CAN in-
corporado a los sistemas de diagnosis de a bordo en
vehículos automotrices. [2][3]
El presente proyecto implementa un sistema de
diagnóstico abordo basado en el protocolo de diag-
nosis OBD-II sobre CAN-BUS que permitirá, tanto
visualizar variables en tiempo real, como realizar un
diagnóstico del estado del automóvil que muestre los
códigos de falla almacenados y permita borrarlos una
vez reparados. La gestión de este proceso se realiza
a través de una interfaz gráfica creada empleando el
software LabVIEW™.
2. SISTEMAS OBD-II
El sistema OBD-II se comenzó a utilizar de forma
obligatoria por los nuevos automóviles en los Estados
Unidos desde 1996, teniendo como objetivo monito-
rear los componentes que afecten el sistema de
control de emisiones de gases contaminantes y me-
dir parámetros en tiempo real como: temperaturas,
presiones, velocidades entre otros. Cuando el siste-
ma OBD-II detecta algún problema a través de los
transductores, se enciende una luz de advertencia en
el tablero alertando al conductor de la falla existente.
Además, se guarda la información sobre las fallas
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
detectadas en la memoria de la computadora del
automóvil, facilitando al técnico automotriz encontrar
los problemas para corregirlos posteriormente. [4]
Los componentes del sistema OBD-II son: la ECU
(Engine Control Unit) conocida como la computadora
del automóvil, los transductores encargados de enviar
los datos hacia la ECU, la luz indicadora de fallas
(MIL, Malfunction Indicator Light) ubicado en el table-
ro, y el conector de diagnóstico (DLC, Data Link
Connector) que sirve de interfaz entre la ECU y los
dispositivos de diagnóstico automotriz.
2.1 Computadora del automóvil
La ECU es la computadora del automóvil y su función
principal es obtener y manejar los datos provenientes
de todos los transductores del motor del automóvil.
Es un dispositivo que se encuentra generalmente
debajo del tablero en la parte del conductor [5].
2.2 Transductores del automóvil
Los transductores son dispositivos encargados de
monitorear de forma continua el funcionamiento y
operación del motor del automóvil [6. Entre las medi-
das que pueden obtener los transductores del motor
están: revoluciones por minuto del motor, temperatu-
ra del líquido refrigerante del motor, presión absoluta
del colector de admisión, presión barométrica, tem-
peratura de aire de admisión, posición del acelerador,
velocidad del automóvil, entre otras.
En la Tabla 1 se presentan algunos transductores del
motor del automóvil que permiten obtener las medi-
das antes mencionadas y que hacen que la ECU
pueda determinar la cantidad de combustible, el pun-
to de ignición y otros parámetros necesarios que
permiten evaluar las condiciones del automóvil. [7]
Tabla I: Transductores del motor del automóvil
Sensor Medida
Sensor CKP (Crankshat Revoluciones por minuto
Position)
Sensor ECT (Engine Temperatura del refrige-
Coolant Temperature) rante del motor
Sensor MAP (Mainfold Presión absoluta del
Ab solute Pressure) colector de admisión
Sensor de presión baro- Presión barométrica
métrica
Sensor IAT (Intake Air Temperatura del aire de
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”

Temperature) admisión datos de la ECU del automóvil. Para solicitar datos

Sensor TPS (Throttle Posi- Posición del acelerador de un automóvil es necesaria la utilización de códi-
tion Sensor) gos PID (Parameter Identification). Cada código PID
está relacionado con una medida específica de los
Sensor VSS (Vehicle Velocidad del automóvil
Speed Sensor) modos 1 y 2 del sistema OBD-II. Por ejemplo, si se
desea solicitar el dato en tiempo real de la velocidad
del automóvil, se debe ingresar al modo 1 y utilizar el
2.3 Luz indicadora de fallas PID 0D.

La luz MIL es utilizada por el sistema OBD-II y se

enciende cuando los transductores del motor detec-
tan un problema en el automóvil; su propósito es
alertar al conductor de la necesidad de realizar un
mantenimiento del mismo.
2.4 Conector DLC
El conector DLC (Data Link Connector) es una inter-
faz con forma trapezoidal de 16 pines basado en el
estándar SAE J1962, que se ubica bajo el tablero,
generalmente en el lado del conductor. El conector
DLC sirve como interfaz de acceso y recuperación de
datos desde la ECU hacia un equipo de diagnóstico
(escáner automotriz). [8]
En la Tabla 2 se muestra la descripción de los 16
pines del conector DLC.
Tabla II: Descripción delos pines del conector DLC
Pin Características
1 Uso del fabricante
2 Bus (+) J1850 VPM y PWM
3 Uso del Fabricante
4 Tierra (chasis)
5 Señal de Tierra
6 Bus de datos CAN alto (J-2284)
7 Línea K ISO 9141-2
2.6 Comunicación de la ECU con dispositi-
vos externos
En el sistema OBD-II, los protocolos de comunica-
ción permiten establecer la comunicación e inter-
cambio de mensaje de forma bi-direccional, entre una
herramienta de diagnóstico (escáner automotriz) y la
ECU del automóvil.
Los protocolos de comunicación soportados por el
sistema OBD-II incluyen el SAE J1850 PWM (Modu-
lación por ancho de pulso a 41.6 Kbps), el SAE
J1850 VPW (Ancho de pulso variable a 10.4 - 41.6
Kbps), el ISO 9141-2 (Comunicación serial asincró-
nica a 10.4 Kbaud), el ISO 14230 KWP (Comunica-
ción serial asincrónica hasta 10.4 Kbaud), y el ISO
15765 CAN (250 - 500 Kbps).
Tabla III: Modos de medición soportados por el Sis-
tema OBD-II
Modo Características
01 Obtención de datos actualizados. - Per-
mite el acceso en tiempo real a los valo-
res de salidas y entradas de la ECU.
02 Acceso a cuadro de datos congelados.-
La ECU toma una muestra de los
valores relacionaos con las emisiones
en el momento exacto de ocurrir un
fallo.

8 Uso del fabricante 03 Obtención de los códigos de falla.-

Permite extraer de la memoria de la
9 Uso del fabricante ECU todos los códigos de fallo (DTC,
10 Bus (-) J1850 Data Troub le Code) almacenados.
11 Uso del fabricante 04 Borrado de códigos de falla y valores
12 Uso del fabricante almacenados.- Se pueden borrar to-
dos los códigos almacenados en la
13 Uso del fabricante ECU, incluyendo los DTCs y el cuadro
14 Bus de datos CAN bajo (J-2284) de datos grabado.
15 Línea L ISO 9141-2 05 Resultado de las pruebas de los
16 Voltaje de batería transductores de oxígeno.- Permite el
acceso a los resultados de las pruebas
realizadas a los transductores de oxí-
2.5 Modos de medición geno.
06 Resultados de las pruebas de otros
El sistema OBD-II utiliza 9 modos de medición, don-
Transductores . Resultado del diagnósti-
de cada uno de los modos permite el acceso a los

“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
co en componentes que no están suje-
tos a vigilancia constante.
07 Muestra de códigos de falla pendientes. -
Permite leer de la memoria de la ECU
todos los DTCs pendientes.
08 Control de funcionamiento de compo-
nentes. -Se pueden realizar pruebas en
los actuadores.
09 Información del automóvil.- Permite soli-
citar el número de identificación del
automóvil (VIN, Vehicle Identification
Numb er).
3. PROPUESTA DE ARQUITECTURA DE LA
SOLUCION IMPLEMENTADA
Las herramientas de diagnóstico OBD-II son las en-
cargadas de gestionar el proceso de chequeo de
desperfectos técnicos en los automóviles. Forman
parte de la evolución del sistema electrónico del
vehículo con la incorporación de sistemas destinados
a la mejora del rendimiento, comodidad y seguridad
de los usuarios.
En esta investigación se plantea la implementación
de un scanner OBD-II sobre bus CAN, en una plata-
forma Arduino y monitoreo en PC (Personal Compu-
ter) a través de LabVIEW™. La interfaz eléctrica
encargada de manipular el bus CAN está definida por
el shield (placa de expansión) CAN para Arduino,
perteneciente a la factoría de Seeed Studio. En la
gráfica siguiente se describe el sistema desarrollado.
Figura. 1: Esquema general del sistema
El diagrama general del sistema diseñado y se apre-
cia que está dividido en dos etapas, la de adquisición
de datos (scanner) y la interfaz gráfica para la visua-
lización y monitoreo de parámetros.
De forma adicional, se cuenta con una herramienta
portátil profesional de lectura de códigos OBD-II,
como vía de comprobación de los resultados de la
puesta en práctica del sistema. Además, se ha si-
mulado en otra plataforma Arduino un módulo equiva-
lente a la computadora del auto, el cual provee un
comportamiento aproximado a la realidad.
3.1 Entornos de desarrollo
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
En el proceso de diseño del sistema se hace uso de
varios entornos de desarrollo diferentes: uno de alto
nivel, en el cual se implementa la interfaz gráfica y al
mismo tiempo la parte de procesamiento de los da-
tos adquiridos a través del scanner OBD-II. El otro
entorno está destinado a la programación de los
elementos de hardware en este caso la plataforma
Arduino, la cual actúa como adaptador USB-CAN.
La aplicación en alto nivel se desarrolló empleando el
software LabVIEW™ 2011. Para la programación del
hardware se empleó el entorno de desarrollo integra-
do o IDE de Arduino en versión 1.8.2.
3.1.1 LabVIEW™ 2011
Su nombre representa el acrónimo de Banco de
pruebas de Laboratorio para Ingeniería de Instrumen-
tación Virtual (Laboratory Virtual Instrumentation
Engineering Work bench). Es una plataforma y en-
torno de desarrollo para diseñar sistemas, con un
lenguaje de programación visual gráfico. Recomen-
dado para sistemas hardware y software de pruebas,
control y diseño, simulado o real y embebido, pues
acelera la productividad. El lenguaje que usa se lla-
ma lenguaje G, donde la G simboliza que es lenguaje
Gráfico. [9]
3.1.2 IDE de Arduino v1.8.2
Arduino [10] necesita de un programa externo ejecu-
tado en otro ordenador para poder escribir programas
para la placa. Este software es lo que llamamos
Arduino IDE (Integrated Development Environment) o
Entorno de Desarrollo Integrado en español. Arduino
IDE es muy sencillo y basado en Processing. Para
usarlo el procedimiento es el siguiente: se escribe un
programa en el IDE, se carga en Arduino, y el pro-
grama se ejecutará automáticamente en la placa.
Processing es un lenguaje de programación y en-
torno de desarrollo integrado de código abierto basa-
do en Java, que sirve como medio para la enseñanza
y producción de proyectos multimedia e interactivos
de diseño digital.
La estructura básica del lenguaje de programación de
Arduino es bastante simple y se compone de al me-
nos dos partes. Estas dos partes necesarias, o fun-
ciones, encierran bloques que contienen declaracio-
nes, estamentos o instrucciones.
 Función setup: es la parte encargada de re-
coger la configuración, es la primera función
en ser ejecutada dentro del programa y se
ejecuta una única vez. Esta función se utiliza
principalmente para inicializar los modos de
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
trabajo de los pines E/S y para configurarla
comunicación serie, aunque tiene muchas
utilidades adicionales.
 Función loop: también conocida como fun-
ción bucle contiene el código que se ejecuta-
rá continuamente (lectura de entradas, acti-
vación de salidas, etc.). Esta función forma
el núcleo de todos los programas de Arduino
y la que realiza la mayor parte del trabajo.
3.1.3 Placa Arduino UNO R3
Arduino UNO es una placa electrónica basada en el
ATmega328P. Cuenta con 14 pines digitales de en-
trada/salida (de los cuales 6 se pueden utilizar como
salidas PWM), 6 entradas analógicas, un cristal de
cuarzo de 16 MHz, una conexión USB, un conector
de alimentación, una cabecera ICSP y un botón de
reinicio (véase la Figura 2). El nombre “UNO” fue
elegido para conmemorar el lanzamiento del entorno
de programación integrado Arduino (IDE) 1.0. UNO
es el primero de una serie de placas Arduino USB y
el modelo de referencia para la plataforma Arduino.
Figura. 2: Placa Arduino UNO R3
La elección de esta placa está dada por la razón de
que la interfaz eléctrica empleada para controlar el
bus CAN (descrita posteriormente) está diseñada
para una total compatibilidad con Arduino UNO. O
sea, posee las mismas dimensiones de la placa, así
como el pinout del controlador CAN para la comuni-
cación vía SPI con la misma, descrita en la librería
que la acompaña.
3.1.4 Seeed CAN BUS Shield para Arduino
CAN es uno de los protocolos de comunicación bus
más usados debido a su largo alcance, su velocidad
de comunicación y su alta fiabilidad. Se encuentra
comúnmente en máquinas de control y en el bus de
diagnóstico automotriz. La placa CAN-BUS Shield
dota de conectividad CAN a la placa Arduino, para
ello la misma cuenta con el controlador CAN
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
MCP2515 con interfaz SPI, encargado del pre-
procesamiento de los mensajes CAN y con un trans-
ceiver CAN MCP2551, el cual maneja la interfaz
eléctrica del bus. Las características principales son
las siguientes:
 Implementa CAN 2.0B a velocidades de has-
ta 1 Mbps.
 Interfaz SPI de hasta 10 MHz.
 Soporta tramas estándar (11 bits), extendi-
das (29 bits) y tramas remotas.
 Dos buffers de recepción para el almacena-
miento de mensajes con prioridad.
 Conector industrial estándar de 9 pines sub-
D.
 Dos indicadores LED.
 Voltaje de operación: 5V.
 Dimensiones: 68x53 mm.
 Peso: 50 g.
Figura. 3: CAN BUS Shield
Existen otras alternativas de implementación de bus
CAN como es el caso de la placa de expansión CAN
de Spark fun. Pero este caso no es totalmente com-
patible con Arduino UNO. Es necesario modificar las
librerías para establecer la comunicación entre am-
bas placas. Otro ejemplo es la placa desarrollada por
Microchip, OLIMEX PIC32-EMZ64, la cual implemen-
ta bus CAN; no obstante, los precios de adquisición
de la misma son diversos y elevados.
3.1.5 Simulador de computadora del
vehículo
Es representación a la cual se le han acoplado sen-
sores y circuitos eléctricos que emulan parámetros
como la velocidad, la aceleración y otros de tipo
térmico tales como la temperatura ambiente y del
refrigerante del motor. La Figura 4 describe de forma
general este subsistema.
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
Este simulador soporta varios modos de operación
de los contemplados en el estándar OBD-II como
son:
 Flujo de datos en tiempo real. (Modo 01)
Se pueden apreciar parámetros como la velocidad, la
aceleración, la posición del pedal del acelerador,
varios valores de temperatura, el estado del indicador
MIL, el nivel de combustible, estadísticas relaciona-
das a la presencia de fallos en el motor, entre otros.
 Leer códigos de fallas (DTC). (Modo 03)
Se han programado dos códigos de error siguiendo
los requisitos de la estructura del mensaje OBD para
la respuesta a una petición en modo 03. De forma
adicional, se incorporó un LED para simular el indi-
cador MIL de la pizarra del auto y se activa al detec-
tar la presencia de fallos, cuya causa se genera al
presionar un botón, también implementado y conec-
tado a la interrupción 1 de la placa Arduino UNO.
Los códigos de fallas programados son los siguien-
tes:
 P0217: Exceso de temperatura en el motor.
 P0143: Bajo voltaje en circuito de sensor de
oxígeno (Banco 1 Sensor 3).
Figura. 4: Simulador de ECU

 Borrar códigos de fallas. (Modo 04)
Borra los códigos de error y genera un mensaje de
respuesta positivo para el modo de operación 04, si
fue exitoso el proceso de borrado y al mismo tiempo
apaga el indicador de fallos luminoso.
Se le adicionó un shield para dotarlo de conectividad
CAN y así posibilitar el diagnóstico OBD.
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
3.2 Herramienta de diagnóstico
El sistema aquí desarrollado consta de una placa
Arduino Mega 2560 y la tarjeta de expansión que la
dota de conectividad CAN, de ahí que sea posible la
interconexión con una red de este tipo. Se ha pro-
gramado de tal forma para dar cumplimiento a los
objetivos iniciales sobre el diagnóstico OBD-II, tales
como lectura de parámetros en tiempo real y de có-
digos de error relacionados con fallas y borrar los
registros de estos en la computadora una vez solu-
cionados a nivel de mantenimiento mecánico del
automóvil.
Figura. 5: Arduino Mega 2560 R3
3.2.1 Software desarrollado para el scan-
ner
El programa presente en esta placa se ha concebido
con el objetivo de emular una interfaz de diagnóstico
OBD-II sobre una placa Arduino. Este se software se
encarga de realizar peticiones a través de bus CAN
mediante a la placa de expansión para Arduino que
maneja este bus de datos.
El programa principal implementa las siguientes fun-
cionalidades:
 Leer e interpretar los comandos recibidos
desde la PC relacionados a las peticiones de
diagnóstico.
 Elaborar tramas CAN de acuerdo a los co-
mandos anteriores y relacionados con los
modos de operación 01, 03, 04 del estándar
OBD-II.
 Recibir mensajes de respuesta a través del
bus CAN y elaborar una trama que contenga
las variables encuestadas por el software en
PC.
El bus de datos CAN dentro del vehículo contiene
múltiples módulos interconectados y cada uno de
ellos se representa por una dirección o ID. Inmedia-
tamente después de conectar el scanner y empezar
a recibir los datos, se percibe que llegan muchos
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
mensajes con identificadores diferentes a los que
esperamos. En el caso del diagnóstico, se deben
enviar con el ID predefinido para la encuesta 0x7DF y
se espera recibir respuestas identificadas por 0x7E8
o 0x7E9, que se corresponden a los módulos más
importantes dentro del sistema. [11]
Por lo tanto, se decide aplicar dentro de esta función
el filtrado y enmascaramiento de mensajes para así
asegurar la recepción de los mensajes de diagnósti-
co solamente. Las funciones que permiten implemen-
tar esto son init_Mask () y init_Filt ().
Tabla IV: Filtrado y enmascaramiento de mensa-
jes CAN
El segmento de código ejecutado en la función loop
permite recibir los comandos desde la interfaz gráfica
en PC y efectuar las peticiones de diagnóstico hacia
la ECU del automóvil. Una vez recibidos los mensa-
jes, los procesa y los devuelve a la PC para ser vi-
sualizados en pantalla.
Las peticiones se hacen atendiendo a los datos reci-
bidos. Por ejemplo, si el comando recibido contiene
el ID de la ventana principal en la interfaz gráfica,
entonces se construye un mensaje OBD-II para en-
cuestar los parámetros relacionados a los indicado-
res que están en esa ventana. A excepción
Figura. 6: Flujo de la función setup
de las peticiones de borrado de DTC’s las cuales
tienes un comando diferente debido a que solo se
realizan bajo voluntad del usuario.
Las peticiones se conforman de acuerdo al formato
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
de la trama OBD-II para peticiones de diagnóstico,
rellenando el resto de los octetos del campo Datos
con el valor 0x55 (01010101 en binario) para no per-
der la sincronía de bits.
Figura. 7: Estructura de petición OBD-II en modo 01
Figura. 8: Scanner implementado
1. Interfaz CAN para diagnosticar el simulador
de ECU.
2. Interfaz CAN para conectar al vehículo.
3. Placa Arduino Mega 2560 y CAN bus shield
como unidad de procesamiento.
4. Conector OBD-II (DLC).
3.3 Interfaz gráfica de usuario
Como se ha mencionado previamente, la interfaz
gráfica se desarrolló empleando el software Lab-
VIEW™. La PC actúa como etapa final en el proce-
samiento de los datos obtenidos y son mostrados en
un ambiente cómodo y agradable a la vez, facilitando
la interacción con el sistema. Desde aquí es posible
monitorear diferentes parámetros presentes en el
automóvil distribuidos en varios menús.
La aplicación es capaz de leer a través de puerto
USB de la PC los datos provenientes de la placa
Arduino, entramados de tal forma y con la informa-
ción relativa a los parámetros que se quieran visuali-
zar. En la parte superior se observa varias pestañas
que facilitan el acceso a los menús habilitados para
ejecutar las pruebas y acciones sobre el automóvil.
Al iniciar la ejecución de la aplicación, LabVIEW™
ejecuta cada elemento en el diagrama de bloques
según la jerarquía descrita en el esquema de flujo y
una sola vez, posteriormente se detiene. Por lo tanto,
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
se encapsula todo el diagrama dentro de un ciclo
While, asegurando así la continuidad del mismo has-
ta tanto no ocurra error alguno o se pulse el botón
“Desconectar” desde el panel frontal. Ambas condi-
ciones determinan la ejecución del programa. Cada
ciclo de ejecución demora alrededor de 100ms en
completarse, por lo que podemos afirmar una correc-
ta lectura de los datos desde el automóvil y una
aproximación cercana al tiempo real.
Figura. 9: Ventana principal de la aplicación
Figura. 10: Flujo del programa en LabVIEW.
4. RESULTADOS OBTENIDOS
El proceso de validación del diseño que se ha desa-
rrollado está constituido por tres pasos.
 Comprobación con scanner profesional, del
simulador de la ECU, valorando la precisión
de su funcionamiento.
 Comprobación con scanner desarrollado del
simulador de la ECU, esperando la semejan-
za en resultados al caso anterior.
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
 Chequeo de parámetros en automóvil con
scanner desarrollado, previa comprobación
con scanner profesional.
Es importante definir que el scanner implementado
no realiza muestreo alguno a los transductores del
automóvil. Solamente realiza peticiones a la ECU,
que si incorpora datos y resultados de los muestreos
realizados a los sensores
4.1 Simulador de ECU encuestado por
scanner profesional
El simulador de ECU ha sido desarrollado para la
demostración del sistema implementado en ambien-
tes interiores como un aula. Además, reviste utilidad
como material didáctico en el trabajo con redes de
telecomunicaciones basadas en bus CAN y la impor-
tancia de estas para la automatización de procesos.
El sistema utilizado para la validación de los resulta-
dos obtenidos es el lector de códigos Innova 3100e
[12], una herramienta portátil para el diagnóstico
rápido del vehículo. Esta herramienta contempla los
cuatro protocolos del estándar y es capaz de efec-
tuar comunicación con cualquier ECU que se imple-
mente bajo alguno de ellos. Por lo tanto, reviste cier-
ta utilidad el auxilio de esta para comprobar los resul-
tados obtenidos.
Figura. 11: Lectura de DTC en simulador de ECU
Se puede comprobar que el indicador MIL permanece
encendido mientras existen fallos detectados y los
códigos de error recuperados coinciden plenamente
con los que fueron programados intencionalmente
dentro del simulador, así como los monitores de
diagnóstico presentes. Nótese que en la imagen de
la izquierda estos son menos que en la otra imagen,
esto significa que los que son comunes a ambas son
monitores cuyos ciclos de prueba ha concluido satis-
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”

factoriamente y el resto aún están por culminar. En obtenidos.

la realidad se perciben de forma intermitente en la
pantalla.

La herramienta de diagnóstico empleada acá posee

una desventaja y esta consiste en que no muestra
datos de parámetros físicos del vehículo en tiempo
real. Por lo que se hace necesario otros escenarios
de prueba para culminar la puesta a punto del siste-
ma implementado.

4.2 Simulador de ECU encuestado por

scanner implementado
Al principio de las mediciones el indicador de fallos
está encendido por lo que uno de las metas de esta
prueba es leer dichos códigos de error y comparar
los resultados con las lecturas tomadas con el scan-
ner profesional en el apartado anterior.
Figura. 13: Lectura de DTC’s

4.3 Scanner implementado encuestando

automóvil real
En este punto se pueden notar potencialidades ex-
tras en el sistema desarrollado respecto al lector
empleado en la primera prueba. El monitoreo en
tiempo real de parámetros técnicos del vehículo jue-
ga un papel fundamental en el mantenimiento que se
realice. Por esta razón se considera de suma impor-
tancia llevar a cabo esta última acción de cara a
validar la fiabilidad del sistema desarrollado.

Las pruebas realizadas están validadas en dos au-

tomóviles. El primero corresponde a un Hyundai Tuc-
Figura. 12: Simulador de ECU encuestado por
son de 2011 y el segundo de ellos a un Geelly GT
scanner implementado
2014.
Se aprecia el monitoreo de los parámetros en tiempo
real a través de los submenús dentro de la interfaz
gráfica. Los valores de la velocidad del auto, la acele-
ración del motor, el flujo de aire en el colector de
admisión y la posición del pedal del acelerador se
ven afectados al manipular el potenciómetro en la
placa de sensores del simulador habilitado para tal
función. Los valores de temperatura fueron simula-
dos mediante funciones aleatorias para poder apre-
ciar las variaciones en el tiempo y la frecuencia de
refrescamiento en la interfaz gráfica de usuario, la
que coincide con un ciclo de ejecución del programa
en LabVIEW.
Figura. 13: Valores obtenidos en la aplicación
Al pulsar el botón “LEER” se recuperan los códigos y
gracias a una pequeña base de datos que se En la izquierda se aprecian los indicadores del
incorporó a la aplicación es posible conocer una automóvil mostrando la RPM del motor (indicador
breve descripción del fallo o los fallos presentes izquierdo), mientras que en la derecha la interfaz
en el sistema. Al comparar con el ensayo gráfica de la aplicación mostrando una
anterior se aprecia la coincidencia en los resultados representación de los del auto y el valor de RPM

“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
 Rodríguez, Armando | “IMPLEMENTACIÓN DE UNA HERRAMIENTA PARA DIAGNÓSTICO OBD-II SOBRE BUS CAN CON ARDUINO”
leído en el indicador derecho. En ambos escenarios
los resultados son totalmente acorde a lo esperado.
4.4 Valoración económica
En este proyecto se valoran los gastos por concepto
de equipamiento.
Tabla V: Gastos en equipamiento
El mayor gasto del sistema es por concepto de la
computadora, lo cual indica que las principales
acciones en trabajos futuros deben estar
encaminadas en sustituir la etapa de interfaz gráfica
y procesamiento final de datos.
Por otra parte, si se excluye la PC, el costo de
realización del scanner en este proyecto es de 52
CUC, si se incluye una pantalla LCD para la
visualización de los resultados. En comparación con
el lector de códigos profesional empleado en las
pruebas, el cual se valora en 115 CUC, posee
ventajas notables a la hora de monitorear parámetros
en tiempo real y añade las mismas funcionalidades
que este último. Por lo tanto, la solución propuesta a
la herramienta de diagnóstico es viable en su
realización.
5. CONCLUSIONES
Con la realización de este trabajo se logró dar cum-
plimiento al objetivo principal de desarrollar un siste-
ma de diagnóstico abordo basado en el protocolo de
diagnosis OBD-II sobre CAN-BUS. Se desarrolló una
herramienta para el diagnóstico en automóviles, el
monitoreo de parámetros técnicos y su visualización
mediante una interfaz gráfica de usuario en tiempo
real. Esta funcionalidad no está disponible en la ma-
yoría de los sistemas profesionales que se distribu-
yen. Se implementó un simulador de una computado-
ra de a bordo de un vehículo y su diagnóstico sobre
CAN-BUS.
6. REFERENCIAS BIBLIOGRÁFICAS
1. www.x-tool.org
2. Simbaña, W., Caiza, J., Chávez, D. y Ló-
pez, G.: “Diseño e Implementación de un Sistema de
Monitoreo Remoto del Motor de un Vehículo basado
en OBD-II y la plataforma Arduino”, Revista Politécni-
“VI Simposio Internacional de Electrónica: Diseño, Aplicaciones, Técnicas Avanzadas y Retos Actuales”
ca, Vol. 37, No. 1, Quito, 2016
3. Rayo M., O., Diseño y realización de un sis-
tema on board diagnostics (OBD-II), Trabajo Final de
Curso, Universidad Politécnica de Cataluña, Catalu-
ña, 2009.
4. Meseguer Anastasio, J. E.: Caracterización
de los estilos de conducción mediante smartphones,
dispositivos OBD-II y redes neuronales. 2013.
5. Cervantes Alonso, O. y Espinosa Solís, S.:
Escáner Automotriz de Pantalla Táctil (Doctoral dis-
sertation), 2010.
6. García Oses, A.: Diseño de una red CAN bus
con Arduino., Trabajo Final de Grado, Universidad
Politécnica de Navarra, Pamplona, España, 2015.
7. Zabler, E.: Los sensores en el automóvil. Re-
verte. 2002.
8. McCord, K.: Automotive Diagnostic Systems.
CarTech Inc. 2011.
9. https://www.wikipedia.org/es/labview
10. http://www.arduino.org/
11. ISO 15765-4: Road vehicles. Diagnostics on
Controller Area Network (CAN). Part 4: Requirements
for emission-related systems, pp. 12
12.https://www.innova.com/en-
US/Product/Detail/3100e
7. SÍNTESIS CURRICULARES DE LOS AU-
TORES
1
Ing. Armando Rodríguez Rodríguez nacido en Pinar del Río,
Cuba, el 19 de junio de 1993. Graduado de Ingeniero en
Telecomunicaciones y Electrónica en la Universidad de Pinar del
Río “Hermanos Saiz Montes de Oca” de la ciudad de Pinar del
Río en 2017. Profesor del Departamento de Telecomunicaciones
y Electrónica de la Facultad de Ciencias Técnicas de la
Universidad de Pinar del Río desde 2017 hasta la actualidad. Ha
impartido asignaturas relacionadas con la Electrónica Analógica
y Fuentes de Alimentación. Investiga en las temáticas de la
automatización de procesos y los sistemas de control demótico.
2
Dr. José Raúl Vento Álvarez nacido en Pinar del Rio, Cuba, el
25 de noviembre de 1958. Graduado de Ingeniero en
Telecomunicaciones en el Instituto Superior Politécnico “José
Antonio Echeverría” (CUJAE) de la Ciudad de la Habana en
1982. Graduado de Máster en Redes de Telecomunicaciones en
la Universidad Politécnica de Madrid en 1996. Obtuvo el grado
de Doctor Ingeniero de Telecomunicación en la Universidad
Politécnica de Madrid, España, en 1998. Profesor del
Departamento de Telecomunicaciones y Electrónica de la
Facultad de Ciencias Técnicas de la Universidad de Pinar del
Rio desde 1990 hasta la actualidad. Ha impartido las
asignaturas relacionadas con Redes de Telecomunicaciones,
Telemática y Comunicaciones Ópticas, siendo tutor de varios
proyectos de culminación de estudios de ingeniería y maestría
en Telecomunicaciones. Investiga en las temáticas de sensores
de fibras ópticas y sistemas de control inmótico.