Simulador Diagnosis CAN OBDII

SIMULADOR Diagnosis CAN OBDII
Diseño, construcción y programación.
Autor: Joaquin Berrocal Piris
ARDUINO MEGA, EAGLE, TORQUE PRO
30-5-2023

Simulador Diagnosis CAN OBDII ISO 11898-2 por Joaquín Berrocal Piris

Contenido
pág
RESUMEN .................................................................... 8
1 INTRODUCCIÓN Y OBJETIVOS ................................................. 8
1.1 OBJETIVOS:..................................................................................................................... 8
2 PROTOCOLOS DE COMUNICACIÓN OBD2 ........................................ 9
2.1 – ISO 9141-2 .................................................................................................................. 9
2.2 - ISO 14230-4 / KWP2000............................................................................................... 9
2.3 CAN ISO 15765 (acrónimo del inglés Controller Area Network)....................................... 9
2.4 – SAE J1850 VPW y PWM................................................................................................ 10
3 ARQUITECTURA DEL BUS CAN ................................................ 10
3.1 El bus CAN ................................................................................................................... 11
3.2 Arquitectura del bus..................................................................................................... 12
3.2.1 Línea de transmisión............................................. 12
3.2.2 Resistencias de terminación...................................... 12
3.2.3. Unidades de control............................................. 14
3.3 Niveles de tensión y modo diferencial........................................................................... 16
3.3.1 Bus CAN de alta velocidad........................................ 16
4 MODOS DE MEDICIÓN OBD2 .................................................. 17
4.1 Modo 01: Obtención de datos de actuales .................................................................... 18
4.2 MODO 03: Lectura Códigos de diagnóstico almacenados DTCs..................................... 23
4.2.1 El primer valor se identifica con una letra P / B / C / U........ 24
4.2.2 El segundo valor se representa con número:....................... 25
4.2.3 El tercer valor se muestra también con un número:................ 25
4.2.4 –Y los dos últimos también son números:.......................... 25
4.3 MODO 04 Borrado de códigos de falla (DTC) abreviatura en inglés de Diagnostic Trouble
Code .................................................................................................................................. 25
5 HARDWARE UTILIZADO EN EL PROYECTO, DESCRIPCIÓN: ......................... 26
5.1 ARDUINO MEGA............................................................................................................ 26
5.1.1 Características eléctricas:...................................... 26
5.2 LCD I2C de 20X04........................................................................................................ 29
5.2.1 Informaciones interesantes LCD I2C:.............................. 29
5.2.2 LCD2004 Características eléctricas:.............................. 29
5.2.3 Dimensiones LCD2004:............................................. 30
5.3 TRANSCEIVER BUS MCP2515......................................................................................... 30
5.3.1 INFORMACIÓN INTERESANTE SOBRE MCP2515............................ 31
5.3.2 Diagrama esquemático del módulo CAN MCP2515...................... 31
5.3.3 Características y especificaciones de MCP2515.................... 31
5.3.4 PINES SPI con el mcp2515-CAN BUS................................. 31
5.3.5 Ejemplo de conexión de pines SPI del módulo MCP2515 para la arduino
UNO.................................................................... 32

5.3.6 CONEXIÓN CAN DEL CONECTOR OBD2 con el mcp2515.................... 32
5.3.7 Funciones principales manejo del mcp2515......................... 34
5.4 Interfaz OBD2 ELM 327 ................................................................................................ 35
6 Portada, Diseño, Construcción y Programación ............................ 36
6.1 PRUEBAS PREVIAS REALIZADAS con “Arduino UNO R3” .................................................. 38
6.2 COMPONENTES en PCB y con los pads y vías................................................................. 39
6.3 CARA TOP Y BOTTOM............................................................................................. 40
6.4 DIMENSIONES ............................................................................................................... 41
6.4.1 Otras medidas.................................................... 42
6.5 CONSTRUCCIÓN Y MONTAJE......................................................................................... 43
6.5.1 Diseño en el PC terminado........................................ 44
6.5.2 LLegada de las placas diseñadas.................................. 45
6.5.3 Montaje sobre las Placas......................................... 46
6.5.4 Montando el conector OBD2 sobre la placa......................... 51
6.5.5 PRESENTACIÓN FINAL MONTAJE....................................... 52
7 DISPOSICIÓN POTENCIÓMETROS .............................................. 54
7.1 OBSERVACIÓN IMPORTANTE: ....................................................................................... 54
8 CONFIGURACIÓN DEL PROGRAMA DE DIAGNOSIS TORQUE PRO ...................... 55
8.1 SIMULACIÓN DE LECTURA DE PARÁMETROS DEL VEHÍCULO........................................... 56
8.2 SIMULACIÓN DE LECTURA DE AVERÍAS.......................................................................... 57
9 Sotfware desarrollado para el simulador: ................................ 58
9.1 Programa principal ....................................................................................................... 58
9.1.1Función Setup ().................................................. 59
9.1.2 Función loop ().................................................. 60
9.1.3 Función ReadMessage ()........................................... 62
9.1.4 Función RepyMode01()............................................. 62
9.1.5 Función ReplyMode03 ()........................................... 63
9.1.6 Otras funciones usadas........................................... 64
9.1.7 Librerías:....................................................... 65
Bibliografía .............................................................. 66
ANEXOS A Soportes para los potenciómetros y medidas ....................... 67
ANEXO B Programación hecha en Arduino ..................................... 69
ANEXO C; PIDs Completos del estándar OBD2 ................................. 81

Índice de Tablas:
pág
Tabla 1; MODOS OBD2........................................................... 17
Tabla 2: Formato de petición OBD-II en modo 01 ......................................... 19
Tabla 3:Formato de respuesta OBD-II en Modo 01 ........................................ 19
Tabla 4: Consulta - Respuesta CAN................................................... 20
Tabla 5: Principales PIDs OBD-II Modo 01 .............................................. 21
Tabla 6: Formato de petición OBD-II en Modo 03 ......................................... 23
Tabla 7: Formato de respuesta OBD-II en Modo 03 ........................................ 23
Tabla 8: Codificación de los DTCx.................................................... 24
Tabla 9: Formato de petición OBD2-II en Modo 04 ........................................ 26
Tabla 10: Formato de respuesta afirmativa en Modo 04..................................... 26
Tabla 11: Formato de respuesta negativa en Modo 04...................................... 26

Índice de ilustraciones:
Pág
Ilustración 1:bus can ............................................................ 10
Ilustración 2: Bus CAN -LIN ........................................................ 11
Ilustración 3: Gateway ........................................................... 12
Ilustración 4: Cable CAN.......................................................... 12
Ilustración 5: Resistencias CAN ..................................................... 13
Ilustración 6: Resistencia Bus ...................................................... 13
Ilustración 7: UCE .............................................................. 14
Ilustración 8: microcontrolador, transceptor BUS CAN ...................................... 15
Ilustración 9: Conector de diagnosis .................................................. 15
Ilustración 10:tensión inactivo ambas: H y L 2,5 V ......................................... 17
Ilustración 11: Al transmitir datos diferencia entre H y L 2,5 V................................. 17
Ilustración 12: tensión al transmitir datos H en 3,75V y L pasa a 1,25V .......................... 17
Ilustración 13: luz MIL (Malfunction Indicator Light) ....................................... 25
Ilustración 14: Arduino MEGA foto pinout .............................................. 27
Ilustración 15: Dimensiones Arduino UNO y MEGA ........................................ 27
Ilustración 16; Arduino MEGA pinout completo .......................................... 28
Ilustración 17: Valores en LCD ...................................................... 29
Ilustración 18:módulo Can-Bus MCP2515 .............................................. 30
Ilustración 19: Esquemático CAN MCP2513 ............................................. 31
Ilustración 20: Conector OBD2 pinout................................................. 32
Ilustración 21: conexionado Arduino-mcp2515-LCD-OBD2 ................................... 33
Ilustración 22: escanner ELM327 bluetooth ............................................. 35
Ilustración 23:Esquema Electrónico del simulador......................................... 37
Ilustración 24; componentes en PCB ................................................ 39
Ilustración 25: Medias sobre la PCB .................................................. 42
Ilustración 26: Diseño Circuito y PCB ................................................. 43
Ilustración 27: Diseño circuito y PCB.................................................. 44
Ilustración 28: PCB ampliada....................................................... 44
Ilustración 29: Recepción de las PCB diseñada las realizo en color azul y verde...................... 45
Ilustración 30: vista de las PCB ..................................................... 45
Ilustración 31:montaje pcb sobre soporte .............................................. 46
Ilustración 32: montaje 1 ......................................................... 46
Ilustración 39: montaje 8, PCB + MCP2515 ............................................. 50
Ilustración 40: Montaje 9, conector OBD2 .............................................. 51
Ilustración 41: Imágenes montado y funcionando ......................................... 52
Ilustración 42: vista LEDS MIL activos ................................................. 53
Ilustración 43: led verde del ELM327 conexión OK vía bluetooth ............................... 53
Ilustración 44: disposición potenciómetros ............................................. 54
Ilustración 45: imágenes torquePro.apk ............................................... 55
Ilustración 46: imágenes relojes con valores emitidos ...................................... 56
Ilustración 47: Averías detectadas DTCs ............................................... 57
Ilustración 48 diseño hecho para apoyos de los potenciómetros ............................... 67
Ilustración 49 medidas soportes .................................................... 68

Índice de los diagramas de flujo:
pág
Diagrama de flujo 1 Función SETUP ......................................... 60
Diagrama de flujo 2 Función loop .......................................... 61
Diagrama de flujo 3 función ReadMessage ................................... 62
Diagrama de flujo 4 Función ReplyMode01 ................................... 63
Diagrama de flujo 5 Función ReplyMode03 ................................... 64

RESUMEN
Como se sabe el sistema OBD2 de los vehículos nos permite conocer los códigos de fallos
almacenados, también nos permiten conocer en tiempo real un gran número de variables del vehículo,
como la velocidad, el nivel de combustible, la temperatura del refrigerante motor, etc.
En este proyecto se trata de desarrollar un equipo simulador de una ECU *Engine Control Unit o
Unidad de Control de Motor (ECU), con el que poder ver, tanto en un pc, o, como en nuestro caso
concreto, sobre una aplicación de un teléfono móvil; Torquepro.apk (o cualquier otra de su estilo) los
valores simulados de 6 sensores del vehículo utilizando potenciómetros que hacen sus veces en la placa
shield que construyamos. Así mismo, se podrán ver los valores OBD2 en el MODO 01 en tiempo real sobre
una LCD20X4 I2C. También se podrán simular 6 averías mediante el uso de 6 microinterruptores.
Vamos a utilizar una placa Arduino MEGA y, sobre ella, montaremos una shield, que será la que
desarrollemos en este proyecto mediante la ayuda del programa de esquemas electrónicos y pcb; EAGLE
9.6.2. A su vez, en la misma, montaremos un transceiver CAN-BUS MCP2515, que será el encargado de
convertir los valores CAN entre Arduino y el CAN-BUS del sistema de diagnosis del vehículo.
En este trabajo se darán unas explicaciones sobre el funcionamiento del sistema OBD2 que llevan
los vehículos para su autodiagnosis y borrado de averías DTCS. Nos centraremos principalmente en el
protocolo CAN ISO 11898-2 de alta velocidad (hasta 1Mbit/s) que es el que vamos a utilizar en nuestro
proyecto, aún así, hablaremos también de otros protocolos OBD2. Más adelante, con fotos, se verá el
proceso de construcción de la placa del simulador, luego exposición-explicación del programa del
controlador del simulador creado para Arduino MEGA. En la parte final se complementará con ANEXOS
de tablas y datos y webs interesantes.
1 INTRODUCCIÓN Y OBJETIVOS
El sistema propuesto se centra en el desarrollo de un equipo electrónico simulador de una ECU. El
presente proyecto implementa un sistema de diagnóstico de abordo basado en el protocolo de diagnosis
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.
1.1 OBJETIVOS:
Simulación lectura de variables en tiempo real, detección de códigos de falla y borrado de los mismos.
 Estudio de la comunicación CAN
 Comunicación bidireccional entre la ECU desarrollada y el escáner OBD-II.
 Visualización de variables en tiempo real: velocidad, RPM, etc.
 Estado del vehículo en tiempo real haciendo uso del indicador luminoso MIL.
 Detección y borrado de códigos de falla.

2 PROTOCOLOS DE COMUNICACIÓN OBD2
Los protocolos estandarizados por ISO (International Organization for Standardization) se dividen en tres:
ISO 9141-2, ISO 14230-4 (KWP2000, Keyword Protocol 2000). ISO 15765-4 (CAN,Controller Area
Network)
Los protocolos estandarizados por SAE (Society of Automotive Engineers) se dividen en dos: SAE J1939 y
SAE J1850 (PWM (Pulse Width Modulation) y VPW (Variable Pulse Modulation)
2.1 – ISO 9141-2
Utilizado en vehículos europeos, asiáticos y americanos (en este caso Chrysler con variantes)
intercambio de información serial asincrónico, es decir, intercambio de palabras clave mediante códigos
Utiliza la línea K el proceso de establecimiento de la comunicación con el tester se efectúa a una
velocidad extremadamente lenta (5 Bd). Acabada esta fase, la comunicación comienza a la velocidad
definitiva; las tasas binarias típicas son 9.600 y 10.400 baudios.
2.2 - ISO 14230-4 / KWP2000
Este estándar es un protocolo de comunicación muy similar al ISO 9141 basado en Bus
bidireccional sobre una única línea llamada K-Line, ocasionalmente puede haber una segunda línea
llamada L-Line para las señales presentes.
2.3 CAN ISO 15765 (acrónimo del inglés Controller Area Network).
¡ESTE ES EL PROTOCOLO Y LA CONEXIÓN USADA EN NUESTRO SIMULADOR CAN!
Este protocolo CAN tue desarrollado por Robert Bosch Gmbh que se extiende al campo del
control industrial y existen dos versiones básicas de este protocolo, que son las siguientes: CAN 1.0 y
CAN 2.0
El estandar CAN 1.0, es el método empleado para permitir una velocidad de transmisión de hasta 125
Kbit/s lo que permite con esta velocidad realizar funciones de control.
El CAN 2.0, es una versión del protocolo CAN compatible con el estándar CAN 1.0 cuya función es
aumentar la velocidad a 500 Kbit/s al estandarizase bajo SAE J2284-500 y a 1 Mbit/s bajo la ISO
11898 (Velocidad de transmisión alta).

2.4 – SAE J1850 VPW y PWM
Es un estándar para la velocidad de transmisión de datos a baja y media velocidad:
– VPW es la versión de comunicación más lenta alcanzando 10,4 Kbit/s y la transmisión a través de un solo
cable a masa.
– PWM, es la versión de comunicación más alta alcanzando los 41,6 Kbit/s y transmitiendo en modo
diferencial con dos cables.
3 ARQUITECTURA DEL BUS CAN
Un bus CAN presenta una topología de bus lineal, en el que uno o dos cables actúan como
elemento de conexión de todas las unidades en la red y éstas se conectan al bus mediante cables de
conexión que van desde la unidad al cable principal. De esta forma, las unidades se encuentran
conectadas entre sí en paralelo.
Algunas unidades de una red lineal pueden forman parte de otras redes o subredes,
estableciéndose de esta forma la interconexión entre las mismas (el caso de un bus LIN perteneciente a
un bus CAN).
Ilustración 1:bus can

3.1 El bus CAN
CAN (acrónimo del inglés Controller Area Network) es un protocolo de comunicaciones desarrollado
en 1983 por la firma alemana Robert Bosch GmbH para vehículos, basado en una topología de bus para
la transmisión de mensajes y la gestión de la comunicación entre múltiples unidades de control.
La comunicación de los distintos sistemas de un vehículo se realiza a través de distintas redes de
trabajo (buses) de acuerdo con las necesidades requeridas por cada sistema (frecuencia y la velocidad de
transmisión, volumen de datos que representa, fiabilidad y precisión en la transmisión). Por esta razón en
los vehículos no existe una única red para la interconexión de todas las unidades de control. Así, cada
fabricante define las distintas redes de trabajo existentes en un vehículo en función de los sistemas
equipados en el mismo y de sus criterios técnicos.
Existen redes CAN de baja y de alta velocidad según la velocidad de transmisión de datos sea
inferior o no a 250 kbps. Un bus CAN de baja velocidad también es denominado "bus tolerantes a fallos",
pues el diseño interno de sus unidades puede permitir su funcionamiento monoalámbrico o degradado,
esto es, la transmisión de datos a través del bus en determinados casos de avería del mismo. Sin embargo,
la tendencia de los fabricantes de vehículos en los últimos años es el empleo de redes CAN con velocidades
de transmisión de 250 ó 500 kbps (alta velocidad), quedando en desuso los buses CAN de baja velocidad
(de tasas inferiores a 250 kbps).
El conexionado eléctrico entre los distintos buses CAN que dispone un vehículo y entre sus
unidades de control sólo es posible cuando los buses a conectar funcionan con la misma velocidad de
transmisión de datos.
Así, para poder establecer una comunicación entre buses de distintos sistemas funcionales del
vehículo o buses CAN que emplean velocidades de transmisión distintas, se emplea un conversor (pasarela
o gateway) que permite la conexión lógica entre los buses sirviendo de “intérprete” para la transmisión
de mensajes de unos buses a otros. De esta forma, puesto que el conversor gateway puede comunicar
con todas las unidades de control del vehículo a través de los distintos buses en los que se encuentran,
éste también se emplea como elemento de conexión (interfaz o interface) con un equipo de diagnosis
externo.
Ilustración 2: Bus CAN -LIN

El conversor gateway, en función del fabricante y modelo del vehículo puede ir alojado en una unidad de
control o ser una unidad de control propia.
Ilustración 3: Gateway
3.2 Arquitectura del bus
Un bus CAN está constituido por los siguientes componentes.
3.2.1 Línea de transmisión
Como hemos mencionado, el bus CAN en el vehículo presenta una topología lineal. Esta topología
lineal se materializa mediante una pareja de cables trenzados (con paso de 20 mm) y sin apantallar
denominados CAN-H (high) y CAN-L (low), siendo la impedancia característica de estos cables de 120 Ω.
Los niveles de tensión empleados en cada cable o línea del bus (que veremos más adelante) junto
con el trenzado de los cables tienen como objetivo proporcionar una mayor protección frente a
interferencias electromagnéticas.
El color empleado en los cables del bus no se encuentra estandarizado. Algunas marcas suelen emplear
el color naranja con uno de los cables rallado para distinguir ambos cables.
Ilustración 4: Cable CAN
3.2.2 Resistencias de terminación
Para evitar interferencias provocadas por reflexiones de la onda que podrían perturbar la
comunicación, usualmente se emplean en el bus dos resistencias de terminación de 120 ohm que evitan
o limitan en el bus las reflexiones de las señales. Las resistencias pueden estar ubicadas en los extremos

del bus, pueden integrarse en las unidades de control o puede emplearse una única resistencia terminal
de 60 Ohm integrada en una de las unidades de control del bus.
Ilustración 6: Resistencia Bus
Como el par de cables trenzados empleados en el bus tienen una impedancia característica de 120
Ω, éste será el valor característico de las resistencias de terminación que se emplean en el bus para unir
ambas líneas.
Ilustración 5: Resistencias CAN

Si se emplea una única resistencia de terminación integrada en una unidad de control (próxima a
60 Ω por ser la resistencia equivalente a dos de 120 Ω agrupadas en paralelo), resultan reflexiones más
intensas que, sin embargo, no tienen efectos negativos a raíz de las reducidas longitudes de los buses de
datos en el automóvil. Por supuesto, deberemos considerar que las especificaciones de las longitudes
máximas posibles de los buses de datos que proporciona la norma CAN no podrán aplicarse en este caso
a consecuencia de las reflexiones.
3.2.3. Unidades de control
Por definición de red, en un bus CAN necesitamos como mínimo dos unidades de control para que
a través del bus pueda efectuarse la comunicación entre ellas.
Ilustración 7: UCE
Cada unidad de control se compone de los siguientes módulos.
3.2.3.1 Controlador
Se encarga de las reglas de comunicación del bus,
3.2.3.2 transmisor / Receptor
También llamado transceptor. Este módulo es el encargado de la codificación y decodificación de los
mensajes en el bus, sincronización, control de los niveles de la señal o del control de acceso al medio. Se
conecta directamente a las líneas del bus. Para el caso de un bus CAN de alta velocidad el integrado que
se emplea es el TJA1050 (es el que utilizamos en este proyecto en la shield mcp2515)
3.2.3.3 Microcontrolador
Se encarga de la realizar la comunicación con los sensores y actuadores conectados a la unidad de
control y procesa los datos mediante el software implementado. Este software lo constituyen las
instrucciones programadas y memorizadas en una memoria ROM (read only memory, memoria de sólo
lectura). (En nuestro proyecto usamos como microcontrolador una Arduino Mega)

Ilustración 8: microcontrolador, transceptor BUS CAN
3.2.3.4 Conector OBD2 de diagnósis
Los equipos de diagnosis actuales establecen la comunicación con las distintas redes del vehículo
a través del conector de diagnosis del mismo, normalmente a través de un bus CAN de diagnóstico de alta
velocidad.
Ilustración 9: Conector de diagnosis

3.3 Niveles de tensión y modo diferencial
La actual tendencia de los fabricantes de vehículos en el empleo de redes CAN de alta velocidad
con tasas de transmisión de 500 kbps (y el desuso los buses CAN de baja velocidad) tratemos los niveles
de tensión correspondientes al bus CAN de alta velocidad (según norma ISO 11898-2).
3.3.1 Bus CAN de alta velocidad
El estándar de bus CAN de alta velocidad permite velocidades de hasta 1 Mbps, equivalente a un
tiempo de bit de 1 µs. Sin embargo, en los vehículos se emplea como velocidad máxima de transferencia
la de 0,5 Mbps = 500 Kbps, equivalente a un tiempo de bit de 2 µs
Los niveles de tensión que se corresponden con el modo dominante y recesivo son de 3,5 V y 2,5 V
respectivamente para el cable CAN-H y de 1,5 V y 2,5 V para el cable CAN-L.
Con esta configuración el bus CAN de alta velocidad funcionará siempre que ambas señales del
bus mantengan su integridad. Por el contrario, en el caso de corte de una de las señales el bus dejará de
funcionar. Esto sólo sucede en los buses CAN de alta velocidad, en cuyas unidades no se encuentra
implementado el modo de funcionamiento monoalámbrico o degradado.

Ilustración 10:tensión inactivo ambas: H y L 2,5 V
Ilustración 11: Al transmitir datos diferencia entre H y L 2,5 V
Ilustración 12: tensión al transmitir datos H en 3,75V y L pasa a 1,25V
4 MODOS DE MEDICIÓN OBD2
El estándar OBD-2 SAE J1979 define diez modos de operación que permiten acceder a los distintas
partes de la ECU. Los modos de operación y su descripción se muestran en la siguiente tabla 1 (Wiki OBD-
II PID https://es.wikipedia.org/wiki/OBD-II_PID) En este proyecto se trabaja con los modos marcados en
negrita:
Modo 01: Obtención de datos de actuales
Modo 03: Códigos de diagnóstico almacenados
Modo 04: Borrado de códigos de falla (DTC) abreviatura en inglés de Diagnostic Trouble Code
Tabla 1; MODOS OBD2
Modo
(hex)
Descripción
01 Muestra los parámetros disponibles

02 Muestra los datos almacenados por evento
03 Muestra los códigos de fallas de diagnóstico (Diagnostic Trouble Codes, DTC)
04 Borra los datos almacenados, incluyendo los códigos de fallas (DTC)
05
Resultados de la prueba de monitoreo de sensores de oxígeno (solo aplica a vehículos sin
comunicación Controller Area Network, CAN)
06
Resultados de la prueba de monitoreo de components/sistema (resultados de la prueba de
monitoreo de sensores de oxígeno en vehículos con comunicación CAN)
07 Muestra los códigos de fallas (DTC) detectados durante el último ciclo de manejo o el actual
08 Operación de control de los componentes/sistema a bordo
09 Solicitud de información del vehículo
0A Códigos de fallas (DTC) permanentes (borrados)
Al acceder a cada modo, la información de respuesta será en hexadecimal. Para interpretar la
información se deberá hacer la conversión a decimal y luego aplicar fórmulas establecidas por el estándar
para obtener el valor deseado.
Estos datos se conocen como PID (Parameter Identificación). PID es un código de solicitud de
información que se envía a la ECU según el modo OBDII. Cada modo en OBDII tiene PID estandarizados.
Dependiendo del modo y del PID, la respuesta se interpreta de distinta forma. El proceso de obtención de
PID es:
 Introducir PID
 Envío de PID por el protocolo de comunicación
 La ECU reconoce el PID y obtiene la información
 Se envía información solicitada por el protocolo de comunicación
4.1 Modo 01: Obtención de datos de actuales

Este modo tiene información en tiempo real de todos los sensores con que el automóvil está
equipado. Al realizar la petición de información de algún PID, este devolverá un valor en hexadecimal.
Este valor se convierte a decimal y se aplica una fórmula según el PID para obtener el resultado
estandarizado para el PID. En la tabla 5 se muestran los PIDs para el modo 0x01 y la descripción de cada
uno
La información en este modo incluye un parámetro de identificación (PID o Parameter ID), este
parámetro indica al sistema de diagnóstico de a bordo la información específica requerida. Existe un
listado amplio de PIDs para este modo, no obstante no todos los PIDs son soportados por todos los
sistemas. Por este motivo el PID $00 incluye un código que indica para cada ECU qué PIDs soporta. El PID
$00 indica los PIDs soportados desde el PID $01 al $20, a su vez el PID $20 indica los PIDs soportados desde
el PID $21 hasta el $40, y así sucesivamente. Todas las ECUs deben soportar por defecto el PID $00.
En la Tabla 2 siguiente se muestra el formato que debe tener la trama OBD-II para realizar peticiones en
el Modo 01, sin tener en cuenta el byte cero que indica la longitud efectiva.
Tabla 2: Formato de petición OBD-II en modo 01
Como se puede observar, es posible solicitar hasta seis PIDs diferentes en una misma trama,
aunque no es lo más común. El formato de la respuesta en Modo 01 es el que se muestra en la Tabla 3,
en el caso de haberse requerido más de un PID habría que enviar una respuesta por cada PID solicitado.
Para indicar que estamos respondiendo a una solicitud de un modo en concreto el valor hexagesimal será
el valor del modo en cuestión, 1 en este caso, más 40 en hexagesimal.
Tabla 3:Formato de respuesta OBD-II en Modo 01

Donde Dato A, Dato B, Dato C y Dato D contienen los datos de diagnóstico referentes al PID
solicitado. No siempre tienen que usarse los cuatro bytes de datos, por ejemplo para responder al PID
$0D (velocidad del vehículo) solo se emplea el Dato A quedando el resto sin uso.
Tabla 4: Consulta - Respuesta CAN
Consulta Bytes
ID CAN
0x7DF
0 1 2 3 4 5 6 7
Núm de
Bytes de
datos;
1--4
Selección
Modos:
01 a 09
Código
PID
Ejem
05
Temp
Refrig
NO utilizado, ISO 15762-2 sugiere poner CCh
Bytes
Respuesta 0 1 2 3 (A) 4 (B) 5 (C) 6 (D) 7
byte4
ID CAN
0x7E8
Núm de
Bytes de
datos del
3 a 6
El 7 no
es
utilizado
puede
ser 00h ó
55h
Se suma
(+40 )
Respuesta
al modo
01:
41
Código
PID
Ejem
05
Temp
Refrig
Byte 0
Valor del
parámetro
especificado
Byte 1
opcional
Byte 2
opcional
Byte 3
opcional
Byte 4
NO
usado.
Puede
ser:
00h ó
55h
Los bytes de respuesta se representan con las letras A, B, C, D. A, es el byte más significativo. Los
bits de cada byte se representan del más significativo al menos, con los números del 7 al 0:
Donde A, B, C y D representan los bytes de datos Byte A, Byte B, Byte D y Byte C, el número de bytes de
información usados en cada PID viene representado en la columna Bytes de la Tabla 4 principales PIDs OBD2.
La Tabla 5 recoge los principales PIDs del estándar OBD-II según la definición de SAE J1979. Junto
con su descripción se da la respuesta esperada para cada PID, junto con información sobre cómo traducir
la respuesta en datos significativos. Además, establece que no puede haber PIDs personalizados definidos
por el fabricante que no están definidos en la norma OBD-II. (Nota; en los ANEXOS pondré todos los PIDs
del estándar)

Tabla 5: Principales PIDs OBD-II Modo 01

4.2 MODO 03: Lectura Códigos de diagnóstico almacenados DTCs
Este modo permite extraer de la memoria de la ECU todos los Códigos de Diagnóstico de Error o
DTCs (Data Trouble Code) almacenados. Los Códigos de Diagnósticos de Error (DTCs) consisten en códigos
de tres dígitos precedidos por un identificador alfanumérico. Cuando la ECU reconoce e identifica un
problema, se almacena en la memoria un DTC que corresponde a ese fallo. Estos códigos tienen por
objetivo ayudar al usuario a determinar la causa fundamental de un problema. En la siguiente figura se
ilustra el formato DTC recomendado por la normativa SAE.
existe una tabla con todos los códigos estandarizados, no impide que cada fabricante añada sus
propios códigos para el control de parámetros o errores que no están en los códigos estándares.
El procedimiento para acceder a dichos DTCs es el siguiente, primero se envía una petición
solicitando a la ECU todos los DTCs almacenados (Tabla 5). Acto seguido, esta responderá con un mensaje
por cada DTC almacenado (Tabla 6), o con ceros en caso de no existir ningún código de error.
Tabla 6: Formato de petición OBD-II en Modo 03
El valor del resto de bytes no tiene importancia, si bien es cierto que la norma recomienda rellenar
con todos los bytes a “$00” o “$55” en hexagesimal. (55h es 85D)
Tabla 7: Formato de respuesta OBD-II en Modo 03
Como se muestra en la tabla anterior los DTCs se encuentran codificados en dos bytes que
llamaremos HB (High Byte) y LB (Low Byte). En el byte HB se encuentran codificados los tres primeros
caracteres del DTC y en el byte LB los dos restantes, dicha codificación se ilustra en la tabla 7:

Tabla 8: Codificación de los DTCx
Por ejemplo, si el DTC es P0217, su codificación sería la siguiente:
 High Byte = “00000010”
o P = “00”
o 0 = “00”
o 2 = “0010”
 Low Byte = “00010111”
o 1 = “0001”
o 7 = “0111”
4.2.1 El primer valor se identifica con una letra P / B / C / U
P => (Tren Motriz).- Cuando el código de error empieza por esta letra se refiere a que dicha falla procede
del motor o las transmisiones.
B => (Carrocería).- Cuando empieza por esta letra significa que el fallo se encuentra en la carrocería de los
vehículos.

C => (Chasis).- Si el código de error tiene esta letra, se entiende que la falla está localizada en el chasis,
nos referimos a Airbag, frenos, etc.
U => (Red).- Si la falla empieza por esta letra se refiere a que la falla está en relación con la transmisión
de datos entre distintos módulos ubicados en el vehículo. (Mal funcionamiento de algún modulo).
4.2.2 El segundo valor se representa con número:
El segundo valor siempre es numérico, este valor que será de un número (1 cifra), nos determina
si es un código genérico (mismo código en cualquier vehículo).
El número “0” nos indica que es genérico, mientras que el 1, 2 y 3 indican que son
códigos elaborados por el fabricante, (siguen siendo OBDII).
4.2.3 El tercer valor se muestra también con un número:
Este tercer valor también es un numero de 1 cifra y nos indica de forma más precisa de donde proviene
dicha falla:
1/ Falla causada por el mal funcionamiento de un sensor ubicado en algún sistema que controla
la relación combustible – aire en el motor u otros factores que influyan en la falla de esta.
2/ Falla ubicada en el sistema de alimentación como puede ser en la Bomba de combustible, inyectores,
etc.
3/ Falla en el sistema de encendido como puede ser en la Bobina, sensores de detonación, etc.
4/ Falla en el sistema de anticontaminación (Catalizador, etc.)
5/ Falla en la velocidad o ralentí del vehículo.
6/ Falla en el (ECM) módulo de control del motor y salidas auxiliares (fallos en el procesador o memoria
como en sus circuitos electrónicos).
7 y 8/ Fallas en la parte de transmisiones automáticas o en control de tracción.
4.2.4 –Y los dos últimos también son números:
Identifican de una manera más exacta que sección del sistema está funcionando mal.
4.3 MODO 04 Borrado de códigos de falla (DTC) abreviatura en inglés de
Diagnostic Trouble Code
Con este modo se pueden borrar todos los códigos almacenados en la Unidad
de Control Electrónico, incluyendo los DTCs y el cuadro de datos congelados. Este
modo también apaga el indicador luminoso MIL, aunque si se borraron los códigos sin
haberse corregido el error, estos volverán a aparecer.
El funcionamiento en este modo se resume en una petición y una respuesta
confirmando que el borrado o reseteo se ha llevado a cabo con éxito. En las
Tablas 8 y 9 se ilustran estos mensajes de petición y respuesta en caso afirmativo.
Ilustración 13: luz MIL
(Malfunction Indicator Light)

Tabla 9: Formato de petición OBD2-II en Modo 04
Tabla 10: Formato de respuesta afirmativa en Modo 04
En el caso de que no haya sido posible el borrado de estos códigos el mensaje que devuelve la ECU es el siguiente:
Tabla 11: Formato de respuesta negativa en Modo 04
5 HARDWARE UTILIZADO EN EL PROYECTO, DESCRIPCIÓN:
Se utilizan: la Arduino MEGA / Pantalla LCDI2C 20X04 / TRANSCEIVER BUS MCP2515 / Conector OBD2/
Interfaz OBD2 ELM 327
5.1 ARDUINO MEGA
5.1.1 Características eléctricas:

Ilustración 14: Arduino MEGA foto pinout
Ilustración 15: Dimensiones Arduino UNO y MEGA

Ilustración 16; Arduino MEGA pinout completo

5.2 LCD I2C de 20X04
Utilizada en el proyecto para ver: posición del acelerador en %, Velocidad del vehículo en Kms/h , rpm
revoluciones por minuto del motor, Nivel del fuel en % , Temperatura aire de admisión de -40 a + 60ºC, Temperatura
refrigerante motor de –40 a 150ºC
Es una pantalla de Cristal Líquido de 20 columnas y 4 filas. Para reducir cableado se le añade un módulo
controlador I2C con el que con sólo dos cables conectados en la Arduino MEGA en los pines: SDA pin 20 y SCL pin
21 , permite ver sobre el display los valores OBD2 actuales (MODO 01) en tiempo real.
Ilustración 17: Valores en LCD
5.2.1 Informaciones interesantes LCD I2C:
https://www.makerguides.com/es/character-i2c-lcd-arduino-tutorial/
https://www.luisllamas.es/arduino-lcd-i2c/
Generador de caracteres especiales para LCD https://www.aladuino.com.mx/blog/generador-de-
caracteres-especiales-para-lcd-alfanumericas/
5.2.2 LCD2004 Características eléctricas:

5.2.3 Dimensiones LCD2004:
5.3 TRANSCEIVER BUS MCP2515
Ilustración 18:módulo Can-Bus MCP2515
Como Arduino no contiene ningún puerto CAN incorporado, se utiliza un módulo CAN llamado
MCP2515. Este módulo CAN está conectado con Arduino mediante el uso de la comunicación SPI (en
inglés Serial Peripherical Interface, Interfaz Serie Periférica); es un puerto de comunicación serie síncrona
cuya función es la de enviar información binaria mediante 4 cables de conexión).
Este módulo soporta CAN V2.0 B, con velocidad de comunicación de hasta 1 Mb/s, es alimentado
con 5 V (con corriente de trabajo de 5mA) y dispone de una resistencia terminal de 120 Ω que puede
emplearse mediante un puente entre los pines del conector J1.
El CAN-BUS MCP2515, será el encargado de convertir los valores CAN entre Arduino y el CAN-BUS
del sistema de diagnosis del vehículo
El módulo MCP2515 tiene un controlador CAN MCP2515 y un transceptor TJA1050 SP de alta
velocidad. La conexión entre MCP2515 y el PIC es a través de SPI. Por lo tanto, es fácil interactuar con
cualquier microcontrolador que tenga interfaz SPI, como en nuestro proyecto con la Arduino MEGA

5.3.1 INFORMACIÓN INTERESANTE SOBRE MCP2515
arduino-mcp2515
Tutorial modulo CAN MCP2515 arduino página interesante con mucha información sobre el módulo
CAN MCP2515
5.3.2 Diagrama esquemático del módulo CAN MCP2515
Este módulo va conectado con arduino mediante el uso de la comunicación SPI. Permite comunicar
Arduino con tu automóvil mediante el protocolo CAN. Esta placa CAN SPI es ideal para la automatización
industrial, domótica y otros proyectos.
Ilustración 19: Esquemático CAN MCP2513
5.3.3 Características y especificaciones de MCP2515
• Utiliza el transceptor CAN de alta velocidad TJA1050
• Dimensión: 40 × 28 mm
• Control SPI para ampliar la interfaz del bus CAN múltiple
• Oscilador de cristal 8MHZ
• Resistencia terminal 120Ω
• Admite la operación CAN de 1 Mb / s
• Operación en espera de baja corriente
• Se pueden conectar hasta 112 nodos
5.3.4 PINES SPI con el mcp2515-CAN BUS
MCP2515 MEGA (en la UNO serían)
INT 2 2
SCK 52 13
SI 51 11
SO 50 12
CS 53 10
GND GND GND
VCC +5V +5V
--------------------------------------------

5.3.5 Ejemplo de conexión de pines SPI del módulo MCP2515
para la arduino UNO.
Nota con la MEGA, que es la que usaremos en el proyecto, son otros pines SPI ver página anterior
NOTA: poner el puente al jumper J1 para conexión de su R 120 ohm. Sólo en los shieds extremos,
cuando hay sólo dos pues en cada uno de ellos hacerlo. Si hubiera 3, en el del medio no ponerlo.
Se pueden conectar hasta 112 nodos con el MCP2515
5.3.6 CONEXIÓN CAN DEL CONECTOR OBD2 con el mcp2515
Se hace a través de los pines 6 CAN H y el 14 CAN L, pines 4 y 5 masa vehículo y masa señal (poner
unidos a GND del PIC Arduino Mega) y pin 16, positivo de alimentación (en este proyecto le valen > 7 V a
14 VDC ) Lo alimento a 9 V DC así se garantiza un menor calentamiento del regulador de tensión de la
placa Arduino Mega.
Ilustración 20: Conector OBD2 pinout
5.3.6.1 Conexión de PIC a bus de diagnosis mediante EOBD
En el proyecto vamos a emplear el PIC Arduino Mega con el módulo MCP2515 y una pantalla
LDC20x4 con módulo I2C para conectar al bus CAN de diagnóstico de un vehículo a través del conector
EOBD (pin 6 para CAN-H y pin 14 para CAN-L) para obtener las tramas de datos del vehículo.

Tenemos que considerar que un vehículo transmite datos a través del terminal OBD “a petición”.
Por tanto, debemos realizar una petición a través del microcontrolador que conectemos al conector OBD.
Esta petición tiene un formato determinado, establecido por la SAE (en inglés Society of Automotive
Engineers) en función del modo de prueba de diagnóstico OBD. En el proyecto utilizaremos los modos 01
para lectura valores en tiempo real, modo 03 para lectura de DTCS y el modo 04 para borrado de DTCS
Un esquema del conexionado necesario puede verse en la siguiente imagen.
Ilustración 21: conexionado Arduino-mcp2515-LCD-OBD2
Los valores de los bytes del campo de datos de la trama de envío para los distintos PID según la norma
SAE puede consultarse en el siguiente enlace:
[PID SAE Wikipedia]
Como ejemplo de datos que pueden pedirse en la comunicación con el vehículo a través del conector
EOBD, el byte 3 puede tomar el valor de:
• 0x11 para la posición del acelerador
• 0x0D para velocidad del vehículo
• 0x0C para régimen del motor en revoluciones por minuto (r.p.m)
• 0x2F para nivel de combustible
• 0x46 para temperatura ambiente
• 0x05 para la temperatura del refrigerante
• 0x46 para temperatura ambiente
Para pedir los datos en el modo 01 se precisa el identificador ID 0x7DF
La trama de respuesta obtenida presenta el ID 0x7E8 y su campo de datos se decodifica de la siguiente
forma:
• Temperatura: byte(4) – 40 en decimal (ºC)
• Régimen del motor: (byte(4)*256 + byte(5) )/4 en decimal (rpm)
• Velocidad del vehículo: byte(4) en decimal (km/h)

• Posición del acelerador: byte(4) /2,55 en decimal (%)
La programación del microcontrolador mediante el IDE necesita tener instalado las librerías
correspondientes al módulo I2C (Wire), a la pantalla LCD (LiquidCrystal_I2C) y al bus CAN (SPI y
mcp_can.h).
MUY IMPORTANTE: La librería "mcp_can.h" correspondiente al bus CAN define los valores de velocidad
del bus en función a la frecuencia de reloj interno del microcontrolador. Usualmente dicha librería define
las velocidades del bus para una frecuencia de reloj interno de 8 Mhz. Sin embargo, el microcontrolador
Arduino MEGA y compatibles empleados usualmente tienen definida una frecuencia de reloj interno de
16 Mhz. Esto conlleva que, en el empleo de la librería, las velocidades del bus se corresponden a la mitad
de la elegida en el sketch. Por tanto, es necesario definir una velocidad doble de la que necesitemos en
el bus (por ejemplo, deberemos seleccionar una velocidad de 1.000 kbps en el sketch para que el
microcontrolador establezca una velocidad de 500 kbps en el bus)
5.3.7 Funciones principales manejo del mcp2515
canMsg1.can_id = 0x01;
Es importante que se defina el ID para determinar de donde llega el frame
canMsg1.can_dlc = 1;
Longitud de datos
canMsg1.data[0] = 0x00;
El mensaje o datos que se enviara, este dato se modificara dependiendo del estado de la
entrada.
mcp2515.sendMessage(&canMsg1);
Envía el mensaje, ID, LONGITUD y DATOS
mcp2515.setBitrate(CAN_500KBPS);
Define la velocidad de transmisión se puede configurar a
• CAN_5KBPS,
• CAN_10KBPS,
• CAN_20KBPS,
• CAN_31K25BPS,
• CAN_33KBPS,
• CAN_40KBPS,
• CAN_50KBPS,
• CAN_80KBPS,
• CAN_83K3BPS,

• CAN_95KBPS,
• CAN_100KBPS,
• CAN_125KBPS,
• CAN_200KBPS,
• CAN_250KBPS,
• CAN_500KBPS,
• CAN_1000KBPS
mcp2515.readMessage(&canMsg)
Lee el mensaje si hay datos disponibles y los almacena en la variable canMsg de tipo can_frame
5.4 Interfaz OBD2 ELM 327
El Dispositivo ELM327 Mini es un escáner automotriz de 16 pines y muy bajo precio, unos 3€,que
se conecta directamente a la interfaz OBD2 del vehículo. Puede leer todos los parámetros del vehículo, y
leer y borrar los códigos de averías DTCs.
(En nuestro proyecto lo conectaremos al conector OBD2 que se montará sobre la shield que
construyamos del simulador y nos dará vía bluetooth la lectura y borrado de los valores de los sensores y
DTCs que simulemos)
Admite prácticamente todos los protocolos OBD2 .(recomendable en la programación que
hagamos en Arduino poner la comunicación a 250 ó 500 Kbaud)
Ilustración 22: escanner ELM327 bluetooth

SIMULADOR Diagnosis CAN OBDII
6 Portada, Diseño, Construcción y Programación
Autor: Joaquin Berrocal Piris
ARDUINO MEGA, EAGLE, TORQUE PRO

Ilustración 23:Esquema Electrónico del simulador

6.1 PRUEBAS PREVIAS REALIZADAS con “Arduino UNO R3”
Antes de la construcción se verifica que funciona adecuadamente, Se hizo la prueba con una Arduino
UNO R3. Se adaptaron los PINES SPI y todo OK
-----PINES SPI con el mcp2515-CAN BUS ------
INT 2 2
SCK 52 13
SI 51 11
SO 50 12
CS 53 10
GND GND GND
VCC +5V +5V
--------------------------------------------

6.2 COMPONENTES en PCB y con los pads y vías
Ilustración 24; componentes en PCB

6.3 CARA TOP Y BOTTOM

6.4 DIMENSIONES
(medidas de la placa PCB. Contorno en amarillo 100x70 mm)

6.4.1 Otras medidas
Como se puede observar las medidas están tomadas desde el propio software de hacer el circuito y
placa pcb (EAGLE 9.6.2) Claramente no es un programa de dibujo
Ilustración 25: Medias sobre la PCB

6.5 CONSTRUCCIÓN Y MONTAJE
(Se montará la placa shield sobre la Arduino Mega 2560 R3)
Diseñando con el EAGLE 9.6.2 el circuito y la placa shield a montar sobre la placa
Arduino Mega 2560 R3
Ilustración 26: Diseño Circuito y PCB

6.5.1 Diseño en el PC terminado
Ilustración 27: Diseño circuito y PCB
Ilustración 28: PCB ampliada

6.5.2 LLegada de las placas diseñadas
Ilustración 29: Recepción de las PCB diseñada las realizo en color azul y verde
Ilustración 30: vista de las PCB
https://jlcpcb.com/ precio: 5 placas verdes 2$ + 5 placas azules 4$ . El transporte por DHL 25,66$ +
custodia aduanas 6,65$. Coste Total 38,27$ / 36,84€ (tardó 6 días en llegar)

6.5.3 Montaje sobre las Placas
Ilustración 31:montaje pcb sobre soporte
Ilustración 32: montaje 1

Montaje de MCP2515, comunidador CAN entre Arduino y el BUS OBD2
Conector OBD2: CAN HIGH Pin 6 / CAN LOW Pin 14)

Ilustración 39: montaje 8, PCB + MCP2515

6.5.4 Montando el conector OBD2 sobre la placa
Ilustración 40: Montaje 9, conector OBD2

6.5.5 PRESENTACIÓN FINAL MONTAJE
Ilustración 41: Imágenes montado y funcionando

Ilustración 42: vista LEDS MIL activos
Ilustración 43: led verde del ELM327 conexión OK vía bluetooth

7 DISPOSICIÓN POTENCIÓMETROS
Luz verde activa, indica que hay entendimiento, vía bluetooth, entre el programa TORQUE
PRO del móvil con la interfaz OBDII ELM327 de la placa.
Tendremos la posibilidad de lectura de parámetros y lectura/borrado de averías,
rpm >>>>>>> Temp. Refrigerant
Velocidad kms/h Temp. Aire admis.
Posic acelerador Nivel combustible
7.1 OBSERVACIÓN IMPORTANTE:
los valores en la LCDI2C 20X4 no se ven reflejados hasta que no haya comunicación y petición
de valores entre el Torque Pro.apk y el ELM327. Por tanto, este añadido de la pantalla LCD es algo poco
interesante al poder directamente verlo sobre el teléfono móvil en la aplicación Torque Pro o cualquier
otra similar
Ilustración 44: disposición potenciómetros

8 CONFIGURACIÓN DEL PROGRAMA DE DIAGNOSIS TORQUE PRO
V1.8.19
La conexión con la interfaz ELM 327 se hace vía bluetooth.
Ilustración 45: imágenes torquePro.apk

Estos relojes pueden ser cambiados por otros diseños escogiéndolos en el TorquePro
Rpm x 1000 Temp. refrigerante (--40 a 150ºC)
Velocidad Kms/h Temp. aire admisión (--40 a 60ºC)
Posición acelerador (%) Nivel combustible (%)
8.1 SIMULACIÓN DE LECTURA DE PARÁMETROS DEL VEHÍCULO
mediante Torque Pro.apk
(La información procede de los 6 potenciómetros que simulan sensores del vehículo)
Ilustración 46: imágenes relojes con valores emitidos

6 microinterruptores provocan estas averías que tengo configuradas:
DTC1: P0120- Tren motriz Posición pedal acelerador
DTC2: P0500- Tren Motriz Velocidad del vehículo
DTC3: P0654- Tren Motriz Rpm del motor
DTC4: P0460- Tren Motriz Nivel de combustible
DTC5: P0110- Tren motriz Temp.aire admisión
DTC6: P0217- Tren motriz Temperatura refrig. motor excesiva
Ilustración 47: Averías detectadas DTCs
8.2 SIMULACIÓN DE LECTURA DE AVERÍAS
Provocadas a través de los 6 microinterruptores (DTC1 – DTC6)
LEVE: LED Ámbar
GRAVE: LED Rojo (DTC3 rpm y DTC6 temp refrigerante)

9 Sotfware desarrollado para el simulador:
El programa de simulación que he creado en Arduino, lo que hace es emular una ECU real de un vehículo
sobre la placa de un arduino MEGA (se podría también haber hecho en la UNO)
Dicho programa, se encarga de atender a las peticiones OBD-II que le llegan a través del bus CAN, para
lo cual, al no disponer la arduino mega del mismo, necesita de un transceiver o conversor de dicho bus.
Usamos el “mcp2515” del fabricante Seedstudio,, que lo hemos acoplado sobre la shield que hemos creado
y que a su vez va montada sobre la placa de arduino
El citado conversor lo que permite es la comunicación entre la Arduino y el OBD2 al cual estará montado
el escáner de diagnóstico ELM327, que usaremos por su bajo precio, unos 3€ y haberse convertido en todo
un referente a nivel mundial, o cualquier otro de características similares Dichas peticiones se realizan
desde la apk Torquepro o cualquier otra similar, desde la cual, se podrán pedir, en el Modo 01,valores en
tiempo real, los cuales lo proporcionarán los potenciómetros de la shield que hemos construido y que
simulan sensores del vehículo. En el Modo 03, se pide conocer si existen averías almacenadas y en el Modo
04 se permite realizar el borrado de dichas averías, siendo necesario, como sucede en los vehículos reales,
que, previamente, se hayan reparado antes de borrarla, en caso contrario volverían a aparecer.
En concreto, la generación de las averías las creamos mediante los microinterruptores DTC1 a DTC6
ubicados en la shield que hemos construidos y que están próximos a los leds.
Interruptor cerrado, queda puesto a masa, avería creada, abierto reparada.
La existencia de averías queda reflejada con la activación de los dos leds MIL. El ámbar, para avería
importante y, el led MIL, rojo, para avería muy grave
A continuación, indico lo que cada microinterruptor provoca, marcando en “negrita” aquellos que
activan el led MIL, rojo, de avería grave que son; el DTC3 y el DTC6”.
DTC3: P0654- Tren Motriz Rpm del motor “activa led MIL rojo”
DTC6: P0217- Tren motriz Temperatura refrig. motor excesiva “activa MIL rojo”
Para que la información OBD-II llegue a Arduino MEGA es necesario el uso de dos librerías: la primera;
“SPI.h” posibilita la comunicación serie (SPI) entre Arduino MEGA y el módulo CAN-BUS, la segunda;
“mcp_can.h” permite a Arduino MEGA enviar, recibir y configurar tramas CAN a través de la placa CAN-
BUS Shield mcp2515.
9.1 Programa principal
El programa que he desarrollado en este proyecto, también conocido como programa de simulación
es el que se encarga de que la placa Arduino MEGA simule una ECU, procesando los mensajes de petición
OBD-II y realizando las operaciones necesarias para contestar a dichas peticiones.
El propio programa lo tengo bien documentado con comentarios en las instrucciones para mayor
claridad en su cometido.
Este programa, al igual que cualquier programa Arduino, basa su funcionamiento en el uso de dos
funciones, que a su vez llaman a otras. Estas funciones son, setup y loop. Estas funciones hacen uso de
llamadas a otras funciones, consiguiendo así un programa ordenado y bien estructurado.
El uso de todas estas funciones en conjunto, dotan al programa principal de las siguientes
funcionalidades:
 Leer e interpretar mensajes OBD-II, siendo capaz de detectar peticiones en los Modos 01, 03 y 04.

 Contestar a las peticiones OBD-II en Modo 01, leyendo las entradas digitales y analógicas de la
placa de que simula señales reales de un vehículo, generando la respuesta OBD-II con los datos
obtenidos en tiempo real y enviando dicha respuesta vía CAN.
 Testeo continuo del vehículo simulado, almacenando DTCs en caso de error y encendiendo el
indicador luminoso MIL. El led ambar para avería menos grave y el led rojo para avería grave
Serán graves la DTC3 rpm del motor y la DTC6 temperatura del motor
 Contestar a las peticiones OBD-II en Modo 03, comprobando el estado del vehículo simulado y
respondiendo con el DTC correspondiente en caso de error.
 Borrar códigos de error cuando sea solicitado mediante el Modo 04 de OBD-II.
Para comprender mejor el funcionamiento del programa principal se estudiará a continuación la
funcionalidad de cada una de sus funciones.
9.1.1Función Setup ()
La función setup es la primera función en ser ejecutada dentro del programa y se ejecuta una única
vez.
En este caso se usa la función setup para:
a) Crear delay 2 sgs para estabilizar tensiones al conectar la fuente de alimentación
b) Inicializar la comunicación serie entre la placa Arduino y el PC
c) Inicializar la comunicación serie con la LCDI2C 2004
d) Escribir el mensaje de presentación sobre la LCD
e) Definir los pines de E/S y su puesta inicial a nivel 0
f) Inicializar la comunicación CAN

El bus CAN se ha iniciado
Salimos del SETUP()
e iniciamos el LOOP ()
Diagrama de flujo 1 Función SETUP
SETUP ()
a) Delay 2 sgs estabiliza tensiones al conectar
b) Inicializa comunicación serie con PC y LCD
c) Escribe mensaje presentación sobre la LCD
d) Define los pines de E/S y puesta inicial a nivel 0
9.1.2 Función loop ()
Es la función principal del programa, contiene el código que se ejecutará continuamente mientras
la placa siga alimentada.
En esta función se envían a los distintos modos las peticiones que son realizadas por el scanner de
diagnóstico OBD-II (ELM 327), esto provoca la respuesta de las funciones encargadas del funcionamiento
de los modos. Tenemos configurados tres modos el 01 el 03 y el 04
El programa desarrollado se encarga de interpretar los mensajes recibidos a través del scanner de
diagnóstico OBD-II (ELM 327) y llamar a la función encargada de responder dependiendo del modo OBD-II
en el que se ha recibido la petición. Está configurado para trabajar en tres modos:
Modo 01: Lectura de tiempo real de los valores proporcionados por los 6 potenciómetros que
simulan seis sensores del vehículo
Modo 03: Lectura de posibles averías o DTCs. Si avería grave led MIL, rojo, activo para la DTC 3 de
rpm y la DTC6 de temperatura motor excesiva.
Modo 04: para el borrado de las averías y apagado del/os leds MIL
Inicia CAN
¿Buen
inicio
del bus
CAN?
No, “goto”
volver a
intentar
NO
SÍ

loop ()
Fin loop ()
Diagrama de flujo 2 Función loop
Trama
CAN
recibida
ReadMessage()
switch (MODO)
Llama a
ReplyMode01()
Llama a
ReplyMode03()
Baja banderas
posibles averías:
(flagDTC1 a 6
y el numDTCs = 0)
Modo01
Modo03
Modo04
Borra mensaje
BuildMessage="";
SÍ
Comprueba_DTC()
Sí ON (está/n a 0)
DTC1-2-4-5
Activa: LedMILAmbar
Sí OFF (está/n a 1)
DTC1-2-4-5
OFF: LedMILAmbar
Sí ON (está/n a 0)
DTC3 o DTC6
Activa: LedMILRojo
Sí OFF (está/n a 1)
DTC3 o DTC6
OFF: LedMILRojo
NO

Lee mensaje. Llamada
funciones:
ReadMessage()
getCanId()
Diagrama de flujo 3 función ReadMessage
9.1.3 Función ReadMessage ()
Con esta función se consigue leer y almacenar en un bufer (buf) de datos todos los mensajes
relevantes que envía el dispositivo OBD-II (ELM 327), devolviendo dicho mensaje y almacenando el modo.
Se guarda también el PID en caso de estar en modo uno. Para realizar dicha tarea hace uso de las funciones
readMsgBuf y getCanId de la librería mcp_can.h, librería que facilita el fabricante Seed para dar
conectividad CAN a la placa Arduino a través del módulo CAN-mcp2515 (este módulo va sobre la shield que
se ha construido en el nuestro proyecto)
9.1.4 Función RepyMode01()
La función ReplyMode01 es la función encargada en exclusiva de responder a las peticiones
realizadas del modo 01, mediante un mensaje de respuesta OBD-II, las peticiones en este modo van
acompañadas con un identificador (PID), para que la ECU identifique con qué parámetro está relacionado
la petición, ejemplo; 05 para la temperatura motor, 0C para las rpm, 0D para la velocidad del vehículo,etc.
El funcionamiento de esta función está basado en una estructura switch-case, en la cual se formará
la respuesta OBD-II dependiendo del PID que se haya requerido.
Primero se define un mensaje OBD-II de respuesta por defecto vacío, este mensaje se rellena
utilizando los cálculos pertinentes que se encuentran en la tabla de los PIDs del estándar OBD2 según la
definición J1979 (ver tabla en Anexo) dependiendo del valor de la variable que indica el PID y por último se
envía la trama CAN haciendo uso de la función sendMsgBuf. de la librería mcp_can.h.
Imprime vía serie el
modo OBD2 y el PID
¿Tamaño msg
distinto de
cero?
SÍ
¿Modo 01?
NO SÍ Almacena PID
Almacena Modo
NO
Devuelve el
mensaje

Mensaje OBD2 por
defecto
Salimos de la
función
Diagrama de flujo 4 Función ReplyMode01



9.1.5 Función ReplyMode03 ()
La función ReplyMode03 es la equivalente a ReplyMode01 para el Modo 03 OBD-II. Esta función es
la encargada de enviar los códigos de error almacenados en la ECU en caso de existir alguno. De lo contrario
enviará el mensaje definido por la norma OBD-II para indicar que no hay error.
El funcionamiento básico de ReplyMode03 se basa en suponer que no hay error, por lo que se define
un mensaje OBD-II por defecto para indicar que no existen DTCs almacenados. Acto seguido se
comprueban las banderas de error (flagDTC1 a flagDTC6 por haber organizado en el simulador 6 averías),
en caso de existir alguna activa se crea el mensaje OBD-II que informe al programa de diagnóstico del DTC
almacenado, de lo contrario se envía el mensaje por defecto.
Los 6 códigos de averías DTCs que hemos creado con la ayuda de los 6 microinterruptores ubicados
en la placa shield que se ha construido son:
Switch (PID)
Prepara el mensaje OBD2,
llamando a funciones de
lectura o cálculo si es
necesario.
Envío de la
respuesta OBD2
sendMsgBuf()
necesario.
necesario.
Envío de la
respuesta OBD2
sendMsgBuf()
Envío de la
respuesta OBD2
sendMsgBuf()
PID 01
PID 02
PID xx

Define el mensaje OBD2
sin errores por defecto:
unsigned char OBDIImsg[8] = {6,
67, 0, 0, 0, 0, 0, 0};
Enviamos la respuesta
OBD2 de no haber DTCs
Salimos de la función
Diagrama de flujo 5 Función ReplyMode03
// Mensaje OBD-II predefinido para responder en el modo 1
// {len datos, 03+40hex, num DTCs, DTC1H, DTC1L, DTC2H, DTC2L}
unsigned char OBDIImsg[8] = {6, 67, 0, 0, 0, 0, 0, 0}; // Inicializamos a 0 no hay DTCs
9.1.6 Otras funciones usadas
El resto de funciones son utilizadas para adquirir los datos necesarios de la placa de simulación con
el fin de responder a los mensajes OBD-II en Modo 01. Para responder a las peticiones en dicho modo se
leen las 6 primeras entradas analógicas a las cuales están independientemente conectadas los 6
potenciómetros con los que simulamos sensores del vehículo y se realizan todos los cálculos necesarios.
Dentro de este grupo de funciones se encuentran las siguientes:
ReadThrottle: Función para calcular la posición en % del acelerador según la posición del
potenciómetro 1 de la placa de simulación.
ReadSpeed: Función para calcular la velocidad en Kms/h actual según la posición del
ReadRPM: Función para calcular el número de revoluciones por minuto según la posición del
ReadNivelFuel: Función para leer las Nivel de fuel en % según la posición del potenciómetro 3
ReadTempAireAmbiente: Función para leer la temp del aire aspirado según la posición del
potenciómetro 4
ReadTempRefrigMotor: Función para leer la Temp Refrig Motor según la posición del
potenciómetro 5
¿Bandera
de DTC
activada?
Preparamos mensaje OBD2 para
notificar avería DTC
ej: P0654 mal functo sensor
velocidad
SÍ
NO

(Esta otra función ya no está conectada a las entradas analógicas, está unida a entradas digitales)
comprueba_DTCS(): comprueba cuántos y cuáles microinterruptores DTCs están cerrados, como
son 6, máximo de averías provocadas serán 6. Estos microcinterrupotores DTC1 a DTC6 están conectados
independientemente a las entradas digitales: 3 a 6, de la Arduino MEGA.
9.1.7 Librerías:
En el proyecto se usan las siguiente librerías:
A) Librerías para el manejo de la pantalla LCDI2C
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
B) Librerías para dotar de comunicación CAN a la placa arduino
#include <SPI.h>
#include "mcp_can.h" // para el módulo mcp2515
//----------------------------------
9.1.7.1 librería genérica SPI.h
SPI (Serial Peripheral Interface), esta librería de sotfware libre pertenece a Arduino, es un bus de
comunicación a nivel de circuitos integrados. La transmisión de datos se realiza en serie, es decir, un bit
después de otro.
El bus SPI se define mediante 4 pines:
 SCLK o SCK: (Pin 52) Señal de reloj del bus. Esta señal rige la velocidad a la que se transmite cada
bit.
 MISO (Master Input Slave Output): (Pin 50) Es la señal de entrada a nuestro dispositivo, por aquí
se reciben los datos desde el otro circuito integrado
 MOSI (Master Output Slave Input): (Pin 51) Transmisión de datos hacia el otro circuito integrado.
 SS o CS (Chip Select o Slave Select): (Pin 53) habilita el circuito integrado hacia el que se envían
los datos. Esta señal es opcional y en algunos casos no se usa.
INT 2 2
SCK 52 13
SI 51 11
SO 50 12
CS 53 10
GND GND GND
VCC +5V +5V
--------------------------------------------
9.1.7.2 Librería mcp_can.h:
La librería mcp_can desarrollada por el fabricante Seed Technology facilita el uso del módulo CAN-
BUS Shield mcp2515. Esta librería es software libre,
La librería mcp_can.h permite el uso de las siguientes funciones para dotar a la placa Arduino de
conectividad CAN. En el programa Arduino creado viene también indicado su finalidad. Marco en negrita
las usadas en el programa.

 mcp_can: establece el pin CS para la comunicación serie. En la MEGA es el pin 53
 begin: inicia el bus CAN a la velocidad que se le especifica como parámetro de entrada.
 init_Mask: establece una máscara para los identificadores CAN (ID).
 init_Filt: establece filtros para los identificadores CAN (ID).
 sendMsgBuf: envía un mensaje a través del bus CAN, pasando como parámetros de entrada el
identificador, el RTR, la longitud de los datos y los datos.
 readMsgBuf: lee un mensaje CAN recibido.
 readMsgBufID: lee un mensaje CAN recibido de una dirección ID específica.
 checkReceive: comprueba si se ha recibido algún mensaje CAN.
 checkError: comprueba si ha ocurrido algún error.
 getCanId: toma la dirección ID, cuando se ha detectado un mensaje recibido.
 isRemoteRequest: activa una bandera si se ha recibido una trama de petición remota (remote
request).
 isExtendedFrame: activa una bandera si se ha recibido una trama CAN Extended.
Bibliografía
Aladuino. (s.f.). Generador de caracteres especiales para LCD alfanuméricas.
Obtenido de aladuino: https://www.aladuino.com.mx/blog/generador-de-
caracteres-especiales-para-lcd-alfanumericas/
LLamas, L. (s.f.). Conectar un display LCD Hitachi a Arduino por bus I2C.
Obtenido de arduino lcd i2c: https://www.luisllamas.es/arduino-lcd-i2c/
Makerquides. (s.f.). Makerquides. Obtenido de Cómo controlar un carácter I2C
LCD con Arduino.
Osés, A. G. (s.f.). Universidad de Navarra. Obtenido de Diseño de una red CAN
bus con Arduino: https://academica-
e.unavarra.es/bitstream/handle/2454/19115/TFG%20Dise%C3%B1o%20de%20una%2
0Red%20Can%20bus%20-
%20Alejandro%20Garc%C3%ADa%20Os%C3%A9s.pdf?sequence=1&isAllowed=y
WIKIPEDIA. (s.f.). Obtenido de OBD-II PID: https://es.wikipedia.org/wiki/OBD-
II_PID
Zambrano, J. B. (2015). Desarrollo de un simulador electrónico de una ECU y su
diagnóstico sobre CAN y OBD-II. Obtenido de
https://biblus.us.es/bibing/proyectos/abreproy/90361/fichero/TFG_JOSE_BE
LTRAN_ZAMBRANO.pdf

ANEXOS A Soportes para los potenciómetros y medidas
Estos apoyos tienen la misión de evitar que se puedan romper las patillas de los potenciómetros al
hacer uso de los mismos. Los he diseñado en SolidWorks 2022. Las medidas en la siguiente hoja. La altura
35,60 mm y la profundidad interior de rosca a base es de 0,7 mm
Ilustración 48 diseño hecho para apoyos de los potenciómetros

Ilustración 49 medidas soportes

/*****************************
* Simulador_CAN_OBD2_por_Joaquin_Berrocal_Piris_LCDI2C_ELM327.io
Simula una ECU del motor respondiendo con mensajes OBD-II sobre CAN.
permite lectura valores actuales,6 Averías y Borrado
Le tengo dispuesto tres modos de funcionamiento:
Modo 1: Flujo de Datos en Vivo,
Modo 3: Leer Códigos de Falla DTC y
Modo 4: Borrar Fallos.
Autor: Joaquín Berrocal Piris, Fecha: 30/05/23
Librerías necesarias comunicación CAN-BUS:
SPI.h: permite la comunicación entre Arduino y CAN-BUS Shield.
mcp_can.h: librería para la comunicación CAN con arduino
******MATERIALES y PINES UTILIZADOS********
Arduino MEGA 2560R3
MCP2515 >> para la comunicación CAN
ELM327 >> para transmitir al móvil los valores CAN
TorquePro >> APK para lectura en el móvil vía bluetooth
LCDI2C 20X4 >> Opción de ver valores tbién en pantalla LCD
(ralentiza algo los tiempos de lectura)
6 interruptores que provocan averías:
6 potenciómetros simulan 6 sensores del vehículo:"
* POT0 conectado a A0 posición del acelerador en %
* POT1 conectado a A1 Speed o velocidad del vehículo hasta 255kms máximo
* POT2 conectado a A2 rpm revoluciones por minuto del motor
* POT3 conectado a A3 Nivel Fuel, en %
* POT4 conectado a A4 Temperatura aire de admisión de --40 a +60ºC
* POT5 conectado a A5 Temperatura refrigerante motor --40 a 150ºC
LedMILAmb >> pin 9 indicador MIL Ambar, avería
LedMILRoj >> pin 10 Indicador MIL Rojo, avería Grave;DTC3 rpm Motor y DTC6 Temp.
Refrig.
Transformador 220VAC/9VDC >> para poder usarlo a la red eléctrica 220VAC
nota; se puede alimentar con >= 8VDC a 13
INT 2 2
SCK 52 13
SI 51 11
SO 50 12
CS 53 10
GND GND GND
VCC +5V +5V
--------------------------------------------
*/
// --- PROGRAMA ------
//---- Librerías para I2C-----
ANEXO B Programación hecha en Arduino

#include <Wire.h>
#include <LiquidCrystal_I2C.h>
//-----librerías para CAN-BUS--------
#include <SPI.h>
#include "mcp_can.h" // para el mcp2515
//----------------------------------
// Constantes
const int SPI_CS_PIN = 53; // Pin CS, en la UNO sería el 10
const char ThrottlePin = A0; //Analógica Posición acelerador(potenciómetro 0)
const char SpeedPin = A1; //Analógica Velocidad (potenciómetro 1)
const char RpmPin = A2; //Analógica rpm (potenciómetro 2)
const char NivelFuelPin = A3; // Analógica de nivel Aforador (potenciómetro 3)
const char TempAireAmbientePin = A4; // Analógica de Temp aire colect motor
(potenciómetro 4)
const char TempRefrigMotorPin = A5; // Analógica de Temp refrig motor (potenciómetro
5)
// para LCD20X4 I2C pines SDA 20 Y SCL 21. En la UNO serían el A4 y el A5
const char SDAPin = 20;
const char SCLPin = 21;
//-----------------------------------------------------------------------
const int DTC1 = 3;
const int DTC2 = 4;
const int DTC3 = 5;
const int DTC4 = 6;
const int DTC5 = 7;
const int DTC6 = 8;
const int LedMILAmb = 9; // Led ambar indicador MIL avería
const int LedMILRoj = 10; //Led rojo indicador MIL "avería Grave"
// Variables
////INT32U canId = 0x000; // Identificador CAN "NO LO COMPILA"
unsigned int canId = 0x000; // Identificador CAN
unsigned char len = 0; // Longitud de los datos recibidos
unsigned char buf[8]; // Buffer de almacenamiento del mensaje OBD-II
String BuildMessage=""; // Cadena para imprimir el mensaje recibido
int MODE = 0; // Modo de funcionamiento OBD-II
int PID = 0; // Parameters IDs del Modo 1
int flagDTC1 = 0; // Flags hasta 6 averías
int flagDTC2 = 0;
int flagDTC3 = 0;
int flagDTC4 = 0;
int flagDTC5 = 0;
int flagDTC6 = 0;
int numDTCS = 0;
//Crear el objeto lcd dirección 0x27 y 20 columnas x 4 filas
LiquidCrystal_I2C lcd(0x27,20,4); //
// Definimos el pin CS para la comunicación entre Arduino-MEGA y CAN-BUS Shield
MCP_CAN CAN(SPI_CS_PIN); //es el pin 53 en la MEGA y el 10 en la UNO
//++++++++++++++++++++++++++++
// FUNCIONES
//++++++++++++++++++++++++++++
// int ReadThrottle()
// Entradas: ninguna /*/ Salidas: TPosition

// Función para leer la posición del acelerador según la posición del potenciómetro 0
int ReadThrottle(){
// Lee la entrada analogica del PIN A0
int sensorValue = analogRead(ThrottlePin);
//Del Case 17 (11h) FÓRMULA OBD2: (A * 100/255)."LO CALCULA EL PROPIO RELOJ DEL
ELM327"
//Para que lea desde 0 a 100%, el valor tope en la lectura analógica será 255
// Convierte el valor leído entre 0-1023 en un valor entre 0-255
int Throttle = sensorValue * (255.0 / 1023.0);
// --Ver en LCDI2C 20x4 primera posición(columna:5) de la línea(fila:1)
lcd.setCursor(5, 1);
lcd.print(" "); //limpiamos 4 posiciones de los valores ejm 100%
// Escribimos el Mensaje en el LCD.
int PosicAceler = (Throttle*100/255);
lcd.print(PosicAceler);// Posición acelerador
lcd.print("%");
//---------------------------------------------------------------
return Throttle;
}
//----------------------------------------------------
// Función
// int ReadSpeed()
// Entradas: ninguna /*/ Salidas: Speed
// Función para leer la velocidad según la posición del potenciómetro 1
//----------------------------------------------------
int ReadSpeed(){
// Lee la entrada analógica del PIN A1
int sensorValue = analogRead(SpeedPin);
//Del Case 13 (0D) FÓRMULA OBD2: (A)"LO CALCULA EL PROPIO RELOJ DEL ELM327"
//Para que lea desde 0 a 255KMs, el valor tope en la lectura analógica será 255
int Speed = sensorValue * (255.0 / 1023.0);
lcd.print(" "); //limpiamos 4 posiciones de los valores
lcd.print(Speed);// velocidad en kms
//--------------------------------------------------
return Speed;
}
// ------------------------------------------------
// Función int ReadRPM()
// Entradas: ninguna /*/ Salidas: RPM
// Función para leer las rpm según la posición del potenciómetro 2
//------------------------------------------------
int ReadRPM(){
int sensorValue = analogRead(RpmPin);
//Del Case 12 (0C) FÓRMULA OBD2: ((A+256)+B)/4 "SE HACEN CÁLCULOS EN EL Case 12 ya
que se compone
//de 2 Bytes para poder pasárselo al ELM327 y éste haga sus cálculos

//Para que lea según OBD2 desde 0 a 16383 rpm.
//El valor tope en la lectura analógica que pongo será 6000 rpm
int RPM = sensorValue * (6000.0 / 1023.0);
lcd.print(RPM);//
//---------------------------------------------------------------
return RPM;
}
//-----------------------------------------------------
// Función: int ReadNivelFuel()
// Entradas: ninguna /*/ Salidas: NivelFuel
// Función para leer las Nivel de fuel según la posición del potenciómetro 3
//---------------------------------------------------
int ReadNivelFuel(){
int sensorValue = analogRead(NivelFuelPin);
//Del Case 47 (2Fh) FÓRMULA OBD2: (A * 100/255)."LO CALCULA EL PROPIO RELOJ DEL
ELM327"
//Para que lea desde 0 a 100%, el valor tope en la lectura analógica será 255
int NivelFuel = sensorValue * (255.0 / 1023.0);
lcd.setCursor(15,1);
int NivelComb = (NivelFuel*100/255);
lcd.print(NivelComb);// Posición acelerador
lcd.print("%");
//---------------------------------------------------------------
return NivelFuel;
}
//----------------------------------------------------------
// Función: int ReadTempAireAmbiente()
// Entradas: ninguna /*/ Salidas: Temp Aire colector admisión
// Función para leer la temp del aire aspirado según la posición del potenciómetro 4
//---------------------------------------------------------
int ReadTempAireAmbiente(){
int sensorValue = analogRead(TempAireAmbientePin);
// Convierte el valor leído entre 0-1023 en un valor TOPE de 0 a 255
// FÓRMULA OBD2 en el Case 70 (46h): A-40 Valor lectura -40 a 215ºC "LO CALCULA EL
PROPIO RELOJ DEL ELM327"
// Convierte el valor leído entre 0-1023 en un valor entre 0-100.Valor lectura en
reloj sería de -40 a 60ºC
int TempAireAmbiente = sensorValue * (100.0 / 1023.0);

lcd.print(TempAireAmbiente-40);// Temperatura Aire ambiente
lcd.print("C");
//---------------------------------------------------------------
return TempAireAmbiente;
}
//--------------------------------------------------------
// Función: int TempRefrigMotor()
// Entradas: ninguna Salidas: Temp refrig Motor
// Función para leer la Temp Refrig Motor según la posición del potenciómetro 5
//--------------------------------------------------------
int ReadTempRefrigMotor(){
int sensorValue = analogRead(TempRefrigMotorPin);
// Puede Convertir el valor leído entre 0-1023 en un valor TOPE de 0 a 255
// FÓRMULA OBD2 en el Case 05 (05h): A-40 Valor lectura en reloj -40 a 215ºC "LO
CALCULA EL PROPIO RELOJ DEL ELM327"
// En este caso convierto el valor leído entre 0-1023 en un valor entre 0-190.
Valor lectura en reloj sería de -40 a 150ºC
int TempRefrigMotor = sensorValue * (190.0 / 1023.0);
lcd.print(TempRefrigMotor-40);// Temperatura Refrig motor
lcd.print("C");
//---------------------------------------------------------------
return TempRefrigMotor;
}
// ------------------------------------------------------------
// Función: String ReadMessage()
// Entradas: ninguna /*/ Salidas: Message
// Función para leer los datos OBD-II dentro de la trama CAN, devuelve la cadena
leída
// Además si el mensaje es una petición valida guarda el Modo y el PID requerido
//------------------------------------------------------------
String ReadMessage(){
String Message="";
CAN.readMsgBuf(&len, buf); // Almacenamos el mensaje OBD-II en buf y su longitud en
len
// Imprime la dirección Id
canId = CAN.getCanId(); // Identificador del mensaje
Serial.print("<");Serial.print(canId);Serial.print(",");
// Construye el mensaje y lo imprime
for(int i = 0; i<len; i++)
{
if( i == len-1 ){
Message = Message + buf[i];
}
else {
Message = Message + buf[i] + ",";

}
}
Serial.println(Message);
// Guardamos el modo y el PID requerido
if ( buf[0] != 0 ){ // Comprobamos que el mensaje no está vacío
MODE = buf[1];
Serial.print("Modo: ");Serial.println(MODE);
// Si trabaja en modo uno guardamos el PID
if (MODE == 1){
PID = buf[2];
Serial.print("PID: ");Serial.println(PID);
}
}
return Message;
}
//-----------------------------------------------------
// Función: void ReplyMode01()
// Entradas: ninguna /*/ Salidas: ninguna
// Función para responder a una petición OBD-II en Modo 1
//-----------------------------------------------------
void ReplyMode01()
{
// {len datos, 01+40hex, PID, DatoA, DatoB, DatoC, DatoD}
unsigned char OBDIImsg[8] = {4, 65, PID, 0, 0, 0, 0, 0}; // Inicializamos len a 4
// Datos = 85 o 0 en el caso de que no se usen
int A=0; // Variables para cálculos
int B=0; // Variables para cálculos
switch (PID){
case 0: // PID 00 hex
// La longitud util en este caso es 6
OBDIImsg[0] = 6;
// PIDs soportados del 01-20 hex
OBDIImsg[3] = 0x88;
OBDIImsg[4] = 0x18;
OBDIImsg[5] = 0x80;
OBDIImsg[6] = 0x13;
CAN.sendMsgBuf(0x7E8, 0, 8, OBDIImsg); // Respuesta
break;
// MIL encendido si DTCflag = 1
if (numDTCS >= 1){
OBDIImsg[3] = 129; // PID 7F hex Luz MIL ON y Número de fallos detectados
}
// MIL apagado, 0 DTCs almacenados, ningun test posible
//DatoA,DatoB,DatoC,DatoD = 0;
CAN.sendMsgBuf(0x7E8, 0, 8, OBDIImsg); // Respuesta
break;
case 5: // PID 05 hex de -40 a 215 ºC FÓRMULA OBD2 A-40
A = ReadTempRefrigMotor();
OBDIImsg[3] = A; //El Rejoj del torquepro hace el calculo respectivo (A-40)
// Construimos la respuesta
CAN.sendMsgBuf(0x7E8, 0, 8, OBDIImsg);
break;
case 12:
// PID 0C hex de 0 a 6000 rpm "2 BYTES" FÓRMULA OBD2 ((A*256)+B)/4 se podrían
leer de 0 a 16383 rpm
// Cálculo de las RPM ((A*256)+B)/4
//información de cómo calcula el byte [3] y el byte[4] del bus de datos.

A = ReadRPM();
OBDIImsg[3] = A*4/256;
OBDIImsg[4] = A - (A*4/256);
break;
case 13: // PID 0D hex de 0 a 255 KMS FÓRMULA OBD2 (A)
// Cálculo de la velocidad
A = ReadSpeed();
OBDIImsg[3] = A;
break;
/*
NO ENCUENTRO RELOJ DE TEMP AIRE ENTRADA MOTOR
//voy a poner el case 70 (46h)de temp aire ambiente que sí tengo reloj
case 15: // PID 0F hex de -40 a 215 ºC FÓRMULA OBD2 A-40
// Temperatura del aire de entrada
A = ReadTempAireAmbiente();
OBDIImsg[3] = A; //EL CÁLCULO LO HACE EL ELM327
break;
*/
case 17: // PID 11 hex Posición Acelerador Throttle 0 a 100% FÓRMULA OBD2 (A+100/255)
// Cálculo de la posición del pedal del acelerador
A = ReadThrottle();
OBDIImsg[3] = A; //El Rejoj del torquepro hace el calculo respectivo (A+100/255)
break;
case 28: // PID 1C hex
// Estandar OBD-II utilizado
OBDIImsg[3] = 3; // El valor 3 indica compatible con OBD y OBD-II
break;
// La longitud útil en este caso es 6
OBDIImsg[0] = 6;
OBDIImsg[3] = 0x80;
OBDIImsg[4] = 0x02;
OBDIImsg[5] = 0x00;
OBDIImsg[6] = 0x01;
break;
case 47: // PID 2F hex
// Nivel de combustible FÓRMULA OBD2 (A+100/255)
A=ReadNivelFuel();
OBDIImsg[3] = A ; //El Rejoj del torquepro hace el calculo respectivo (A+100/255)
break;

// La longitud util en este caso es 6
OBDIImsg[0] = 6;
OBDIImsg[3] = 0x04;
OBDIImsg[4] = 0x08;
OBDIImsg[5] = 0x80;
OBDIImsg[6] = 0x00;
break;
case 70: // PID 0F hex de -40 a 215 ºC FÓRMULA OBD2 A-40
// Temperatura del aire de entrada.
A = ReadTempAireAmbiente();
OBDIImsg[3] = A; //El Rejoj del torquepro hace el cálculo respectivo (A-40)
break;
} // fin sel Switch
} // Fin ReplyMode01
//----------------------------------------------------------
// Función: ReplyMode03
// Entradas: ninguna // Salidas: ninguna
// Función para responder a una petición OBD-II en Modo 3
// ---------------------------------------------------------
void ReplyMode03(){
// {len datos, 03+40hex, num DTCs, DTC1H, DTC1L, DTC2H, DTC2L}
unsigned char OBDIImsg[8] = {6, 67, 0, 0, 0, 0, 0, 0}; // Inicializamos a 0 no hay
DTCs
//P0120: Mal fucnto posición acelerador/pedal/interruptor A.
if(flagDTC1 == 1){
OBDIImsg[2] = 1;//numDTCS; //1; // Número de DTCs = 1
OBDIImsg[3] = 1; // P0120
OBDIImsg[4] = 32;// P0120 32 es el dec de 20hex
}
//P0500: Una falla Mal funcionamiento del sensor de velocidad del vehículo
if(flagDTC2 == 1){
OBDIImsg[2] = 1;//numDTCS; //1; Número de DTCs = 1
OBDIImsg[3] = 5; //
OBDIImsg[4] = 0;//
}
//P0654: Una falla salida de RPM del motor
if(flagDTC3 == 1){
OBDIImsg[3] = 6; //
OBDIImsg[4] = 84;// P0654 84d es el dec de 54hx
}
//P0460: Una falla circuito sensor nivel de combustible
if(flagDTC4 == 1){
OBDIImsg[3] = 4; //
OBDIImsg[4] = 96;//P0460 96 es el dec de 60Hx
}

//P0110: Una falla sensor temperatura aire admisión.
if(flagDTC5 == 1){
OBDIImsg[3] = 1; //
OBDIImsg[4] = 16;// P0110 el 16 es el dec de 10Hx
}
if(flagDTC6 == 1){
OBDIImsg[3] = 2; // P0217 Sobrecalentamiento del motor HIGH
OBDIImsg[4] = 23; // P0217 Sobrecalentamiento del motor LOW el 23D es el dec de
17Hx
}
// Si no hay errores se envía el mensaje inicial
}// Fin del ReplyMode03();
//----------------------------------------------------------
// funcion comprueba_DTCS()comprueba cuántos interruptores están cerrados
// máximo de averías a ver 6 numDTCS = 6
//---------------------------------------------------------
void comprueba_DTCS(){
numDTCS = 0; //para que no siga subiendo solo cuente los que hay
if (digitalRead(DTC1) == 0){
flagDTC1 = 1; //activo su flag
numDTCS = numDTCS+1;
delay(100); // evita el debounce
}
}
}
}
}
}
Serial.print ("numDTCS: "); // SE PUEDE BORRAR
Serial.println (numDTCS);
delay(100); // evita debounce
} // fin void comprueba DTC()
//+++++++ FIN FUNCIONES. Ahora el setup y el loop +++++++++
void setup(){
delay (2000); // para estabilizar tensiones en el encendido

Serial.begin(115200); // Inicio de la comunicación serie
//----- inicio el LCDI2C 20x4---------
lcd.init();
//Encender la luz de fondo.
lcd.backlight();
// Ubicamos el cursor en la primera posición(columna:3) de la línea(fila:0)
lcd.print("SIMULADOR EOBDII");// caracteres 16
lcd.print("CAN ISO: 11898-2");
lcd.print("JOAQUIN");// caracteres 7
lcd.print("BERROCAL PIRIS");// caracteres 14
delay(3000); //tiempo visualizar
lcd.clear();
//---- acto seguido ponemos valores sensores en pantalla---------
lcd.print("MODO 01 actuales");// caracteres 16
lcd.print("Acel");
lcd.print("Velo");
lcd.print("rpm:");
lcd.print("Fuel");
// --- LOS DE TEMP AIRE Y REFRIGERANTE---
lcd.print("Aire");
lcd.print("Refr");
//-------------------------------------------------------
// Definición de los pines
pinMode(LedMILAmb, OUTPUT); // Pin 9 LedMILAmb configurado como salida
digitalWrite(LedMILAmb,LOW); //lo iniciamos apagado
pinMode(LedMILRoj, OUTPUT); // Pin 10 LedMILRoj configurado como salida

digitalWrite(LedMILRoj,LOW); //lo iniciamos apagado
pinMode(DTC1, INPUT); //pines 3 al 8 como entrada SWichts averías
pinMode(DTC2, INPUT);
// Iniciamos el bus CAN a 500 Kbps
START_INIT:
// Si se inicia correctamente continuamos
if(CAN_OK == CAN.begin(CAN_500KBPS))
{
Serial.println("El BUS CAN se ha iniciado correctamente");
}
// De lo contrario reintentamos el inicio del bus
else
{
Serial.println("Error en el inicio del BUS CAN");
Serial.println("Iniciando el BUS CAN de nuevo");
delay(100);
goto START_INIT;
}
}
void loop()
{
// Si recibe alguna trama CAN
if(CAN_MSGAVAIL == CAN.checkReceive())
{
MODE = 0;
PID = 0;
// Lee el mensaje
BuildMessage = ReadMessage();
// En qué modo estamos trabajando
switch (MODE){
case 1: // Si estamos trabajando en el modo 01 -> datos actuales
ReplyMode01(); // Llamamos a la función encargada de responder
break;
case 3: // Si estamos trabajando en el modo 03 -> DTCs
ReplyMode03(); // Llamamos a la función encargada de responder
break;
case 4: // Si estamos trabajando en el modo 04 -> limpiar DTCs
//bajamos la bandera de las posibles averías
flagDTC1 = 0;
flagDTC2 = 0;
flagDTC3 = 0;
flagDTC4 = 0;
flagDTC5 = 0;
flagDTC6 = 0;
numDTCS = 0;
break;
}
BuildMessage="";
}

//--- Chequeo de los DTCS indicadores de averías ---
// Cerrado indica nivel 0 y activa LedMILAmb/Roj y flag avería; flagDTC1 ... flagDTC6
// El LedMILRoj se activa con avería grave provocada por el DTC3 rpm y el DT6 temp
Refrig
comprueba_DTCS();
//-------------------------------------------------------
// Comprobamos el estado del indicador MIL
if ((flagDTC1 == 1)||(flagDTC2 == 1)||(flagDTC4 == 1)||(flagDTC5 == 1)) {
digitalWrite(LedMILAmb, HIGH);
}
else{
digitalWrite(LedMILAmb, LOW);
}
//---AVERÍAS GRAVES DTC3 RPM Y DTC6 TEMP REFRIG---
if((flagDTC3 == 1)||(flagDTC6 == 1)){
digitalWrite(LedMILRoj, HIGH);
}
else{
digitalWrite(LedMILRoj, LOW);
}
//--------------------------------------------------
} // Fin loop()
//--------FIN DEL PROGRAMA----------------

ANEXO C; PIDs Completos del estándar OBD2
En el presente anexo A se muestran todos los PIDs que contempla el estándar OBD 2 bajo SAE J2284

Simulador Diagnosis CAN OBDII

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Simulador Diagnosis CAN OBDII

Similar a Simulador Diagnosis CAN OBDII (20)

Más de joaquinin1

Más de joaquinin1 (20)

Último

Último (6)

Simulador Diagnosis CAN OBDII