club158

Vista previa del material en texto

Sumario
11sumario
Capítulo 1: CaraCterístiCas del sistema CaN 
eN uNa iNterfase oBd CoN elm 327
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
El Protocolo CAN, Características del Sistema . . . . . . .3
Los Mensajes CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Más Sobre Formatos en Mensajes CAN . . . . . . . . . . . . .7
Alteración de los Mensajes de Control de Flujo . . . . . . .8
Capítulo 2: moNtaje de uNa iNterfase oBd ii 
CoN elm 327
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Sobre la Electrónica del Automóvil . . . . . . . . . . . . . . .12
OBD y OBD II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Conector OBD II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Funcionamiento y Construcción de la Interfase . . . . . .17
Instalación de la Interfase . . . . . . . . . . . . . . . . . . . . . . .21
Definición de OBD II . . . . . . . . . . . . . . . . . . . . . . . . . .22
OBD II en la Actualidad . . . . . . . . . . . . . . . . . . . . . . . .23
Componentes de un Sistema OBD II . . . . . . . . . . . . . .26
Qué es el CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Monitores de Emisiones OBD II . . . . . . . . . . . . . . . . . .29
Conector para Diagnóstico . . . . . . . . . . . . . . . . . . . . . .32
Acceso a la Información del Sistema OBD II . . . . . . . .33
Estructura del Código de Falla (DTC) . . . . . . . . . . . . .33
PID OBD II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Capítulo 3: uso del esCáNer CoN
programas de diagNóstiCo
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Recordemos Qué es OBD II . . . . . . . . . . . . . . . . . . . . .38
Cómo se Escanea un Vehículo . . . . . . . . . . . . . . . . . . . .39
Qué vehículos tienen OBD II . . . . . . . . . . . . . . . . . . . .45
Manejo e Interpretación del 
Programa ScanMaster . . . . . . . . . . . . . . . . . . . . . . . . . .45
Información del Vehículo . . . . . . . . . . . . . . . . . . . . . . .48
Estado del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Códigos de Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Freeze Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Sensores de Oxígeno . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Resultados de Monitoreo . . . . . . . . . . . . . . . . . . . . . . . .51
Planilla de Datos en Tiempo Real . . . . . . . . . . . . . . . . .52
Configuración PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Informe del Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . .53
Capítulo 4: Computadora de a Bordo
seCuNdaria para CoNfort
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
La Computadora de A Bordo . . . . . . . . . . . . . . . . . . . . .56
La Placa Madre de la Computadora de A Bordo . . . . .57
Los Controles Computarizados del Motor . . . . . . . . . .58
El Sistema Computarizado Básico 
de Control de Motor . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Las Funciones de la Computadora de A Bordo . . . . . . .60
La Computadora Propuesta . . . . . . . . . . . . . . . . . . . . . .60
Algunos Conceptos Sobre PICAXE . . . . . . . . . . . . . . .61
Primeras Experiencias . . . . . . . . . . . . . . . . . . . . . . . . . .62
Ideas de Programación . . . . . . . . . . . . . . . . . . . . . . . . . .68
Circuito Básico de la Computadora de A Bordo . . . . . .70
Programación de la Computadora de A Bordo . . . . . . .72
El Programa Inteligente . . . . . . . . . . . . . . . . . . . . . . . . .73
La Etapa de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
La Etapa de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
EscánErs E IntErfasEs OBD II:
sumarIO
psumario.qxd:Editorial Ingles 19/1/16 12:46 p.m. Página 1
Electrónica del Automóvil
22 Editorial
Di­rec­tor­
Ing. Ho ra cio D. Va lle jo
Pro­duc­ción
Jo sé Ma ría Nie ves
Autor­de­este­Tomo­de­Colección:
Ing. Horacio D. Vallejo
Selección­y­Coordinación:
Ing. Luis Horacio Rodríguez
Edi­to­rial­QUarK­S.r.l.
Pro­pie­ta­ria­de­los­de­re­chos­en­cas­te­lla­no­de­la­pu­bli­ca­ción­men­-
sual­Sa­bEr­ElEc­tró­ni­ca -­He­rre­ra­761­(1295)­-­Ca­pi­tal
Fe­de­ral­-­Buenos­Aires­-­Argentina­-­­T.E.­4301-8804
Ad­mi­nis­tra­ción­y­Ne­go­cios
Te re sa C. Ja ra
Patricia Rivero Rivero
Margarita Rivero Rivero
Staff
Liliana Teresa Vallejo
Mariela Vallejo
Diego Vallejo
Fabian Nieves
Luis Alberto Castro Regalado
José Luis Paredes Flores
Sis te mas: Pau la Ma ria na Vi dal
Red y Com pu ta do ras: Raúl Ro me ro
Video y Animaciones: Fernando Fernández
Le ga les: Fer nan do Flo res
Con ta du ría: Fer nan do Du cach
Técnica y Desarrollo de Prototipos: 
Alfredo Armando Flores
Aten­ción­al­Clien­te
Ale jan dro Va lle jo 
ate clien @we be lec tro ni ca .co m.ar
In­ter­net:­www­.we­be­lec­tro­ni­ca­.co­m.ar
Publicidad:
Rafael Morales
rafamorales@webelectronica.com.ar
Club­SE:
Grupo­Quark­SRL
luisleguizamon @we be lec tro ni ca .co m.ar
Edi­to­rial­Quark­SRL
He rre ra 761 (1295) - Ca pi tal Fe de ral
www .we be lec tro ni ca .co m.mx
La Edi to rial no se res pon sa bi li za por el con te ni do de las no -
tas fir ma das. To dos los pro duc tos o mar cas que se men cio -
nan son a los efec tos de pres tar un ser vi cio al lec tor, y no en -
tra ñan res pon sa bi li dad de nues tra par te. Es tá pro hi bi da la
re pro duc ción to tal o par cial del ma te rial con te ni do en es ta
re vis ta, así co mo la in dus tria li za ción y/o co mer cia li za ción
de los apa ra tos o ideas que apa re cen en los men cio na dos tex -
tos, ba jo pe na de san cio nes le ga les, sal vo me dian te au to ri za -
ción por es cri to de la Edi to rial. Marzo 2011.
Impresión: Talleres Babieca - México
Este es el tercer volumen de la colección Club Saber
Electrónica orientado a la electrónica automotriz, más específica-
mente, a explicar el funcionamiento y el empleo de una interfase
para OBD II contraída con el circuito integrado ELM 327.
Debemos aclarar que en el mercado existen un montón de dis-
positivos (en su mayoría de origen asiático) que “dicen ser” inter-
fases OBD II con ELM327 pero, en realidad, son clones que no fun-
cionan con la mayoría de los programas preparados para trabajar
con computadoras tipo PC a efectos de poder comunicar la compu-
tadora de un auto mediante un protocolo compatible con OBD II.
En este libro explicamos qué es OBD II, cuáles son los proto-
colos que soporta, qué es una computadora de a bordo, cuáles son
las computadoras secundarias, qué se puede hacer con un escáner
o una interfase para OBD II y qué programas podemos emplear
para obtener el máximo provecho de nuestro circuito.
Como es casi imposible colocar en un libro todo el material dis-
ponible sobre la materia, le brindamos al lector la posibilidad de des-
cargar un CD que contiene abundante información, detalles de arma-
do y de uso de la interfase propuesta, el proyecto completo de una
computadora de a bordo, videos sobre reparación, un curso comple-
to de mecánica automotriz y más de 15 programas para detectar y
borrrar códigos de error, realizar test de prueba, ajustes, etc.
En suma, creemos que es más importante el contenido del CD
que el propio texto que Ud. está leyendo, sin embargo, también
estamos seguros que esta obra representa un material importante
de lectura y que sirve como guía de capacitación para todo mecá-
nico y/o electrónico que desee profundizar sus conocimientos
sobre OBD II. 
¡Hasta entonces! 
Sobre el CD y Su DeSCarga
Ud, podrá descargar de nuestra web el segundo CD sobre
“Escáners y Computadoras de A Bordo”, que posee textos, cursos,
enciclopedias, videos, guías de reparación, programas, manuales de
servicio, etc. Para realizar la descarga deberá ingresara nuestra web:
www.webelectronica.com.mx, tendrá que hacer clic en el ícono
password e ingresar la clave “obD23”. Tenga este texto cerca suyo
ya que se le hará una pregunta aleatoria sobre el contenido para que
pueda iniciar la descarga.
Editorial
Del Editor al Lector
pEditorial:Sumario Inglés 19/1/16 1:00 p.m. Página 2
 
INTRODUCCIÓN
CAN (Controller Area Network) es un proto-
colo de comunicaciones desarrollado por la
firma alemana Robert Bosch GmbH, basado
en una topología bus para la transmisión de
mensajes en ambientes distribuidos, que ofre-
ce una solución a la gestión de la comunica-
ción entre múltiples CPUs (unidades centrales
de proceso) y que se utiliza en automóviles
para transmitir códigos de error hacia un intér-
prete (escáner y/o computadora). 
El protocolo de comunicaciones CAN pro-
porciona los siguientes beneficios:
* Es un protocolo de comunicaciones nor-
malizado, con lo que se simplifica y economiza
la tarea de comunicar subsistemas de diferen-
tes fabricantes sobre una red común o bus.
* El procesador anfitrión (host) delega la
carga de comunicaciones a un periférico inteli-
gente, por lo tanto el procesador anfitrión dis-
pone de mayor tiempo para ejecutar sus pro-
pias tareas.
* Al ser una red multiplexada, reduce
considerablemente el cableado y elimina
las conexiones punto a punto, excepto
en los enganches.
EL PROTOCOLO CAN, 
CARACTERÍSTICAS DEL SISTEMA
CAN se basa en el modelo produc-
tor/consumidor, que gestiona una rela-
ción entre un productor y uno o más con-
sumidores. CAN es un protocolo orienta-
do a mensajes, es decir, la información
que se va a intercambiar se descompo-
ne en mensajes, a los cuales se les asigna un
identificador y se encapsulan en tramas para
su transmisión. Cada mensaje tiene un identi-
ficador único dentro de la red, con el cual los
nodos deciden aceptar o no dicho mensaje.
Dentro de sus principales características se
encuentran:
Prioridad de mensajes.
Garantía de tiempos de latencia.
Flexibilidad en la configuración.
Recepción por multidifusión (multicast) con
sincronización de tiempos.
Sistema robusto en cuanto a consistencia
de datos.
Sistema multimaestro.
Detección y señalización de errores.
Retransmisión automática de tramas erró-
neas
Distinción entre errores temporales y fallas
permanentes de los nodos de la red, y desco-
nexión autónoma de nodos defectuosos.
Este sistema fue desarrollado para aplica-
ciones en los automóviles y por lo tanto la pla-
ESTRUCTURA CAN Y PROTOCOLO SAE
33Capítulo 1
Capítulo 1
CARACTERÍSTICAS DEL SISTEMA CAN 
EN UNA INTERFASE OBD II CON ELM 327
 
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 3
 
taforma del protocolo es el resultado de las
necesidades existentes en el área de la auto-
moción. La Organización Internacional para la
Estandarización (ISO, International
Organization for Standarization) define dos
tipos de redes CAN: una red de alta velocidad
(hasta 1Mbps), bajo el estándar ISO 11898-2,
destinada para controlar el motor e interconec-
tar la unidades de control electrónico (ECU); y
una red de baja velocidad tolerante a fallos
(menor o igual a 125kbps), bajo el estándar
ISO 11519-2/ISO 11898-3, dedicada a la
comunicación de los dispositivos electrónicos
internos de un automóvil como son control de
puertas, techo corredizo, luces y asientos.
El sistema CAN se basa en un protocolo de
comunicaciones serie que soporta control dis-
tribuido en tiempo real con un alto nivel de
seguridad y multiplexación.
El establecimiento de una red CAN para
interconectar los dispositivos electrónicos
internos de un vehículo tiene la finalidad de
sustituir o eliminar el cableado. En una red
CAN las unidades de procesamiento, los sen-
sores, los sistemas antideslizantes, etc. se
conectan a velocidades de transferencia de
datos de hasta 1Mbps.
La arquitectura de protocolos CAN, de
acuerdo al modelo de referencia OSI (Open
Systems Interconnection: Modelo de interco-
nexión de sistemas abiertos), incluye tres
capas: física, de enlace de datos y aplicación,
además de una capa especial para gestión y
control del nodo llamada capa de supervisor.
Capa física: En esta parte de la arquitectu-
ra se definen las características que deberá
reunir el hardware, es decir, los aspectos del
medio físico para la transmisión de datos entre
nodos de una red CAN, los más importantes
son niveles de señal, representación, sincroni-
zación y tiempos en los que los bits se trans-
fieren al bus. La especificación del protocolo
CAN no define una capa física, sin embargo,
los estándares ISO 11898 establecen las
características que deben cumplir las aplica-
ciones para la transferencia en alta y baja velo-
cidad.
Capa de enlace de datos: define las tare-
as independientes del método de acceso al
medio, además debido a que una red CAN
brinda soporte para procesamiento en tiempo
real a todos los sistemas que la integran, el
intercambio de mensajes que demanda dicho
procesamiento requiere de un sistema de
transmisión a frecuencias altas y retrasos míni-
mos. En redes multimaestro, la técnica de
acceso al medio es muy importante ya que
todo nodo activo tiene los derechos para con-
trolar la red y acaparar los recursos. Por lo
tanto la capa de enlace de datos define el
método de acceso al medio así como los tipos
de tramas para el envío de mensajes
Cuando un nodo necesita enviar informa-
ción a través de una red CAN, puede ocurrir
que varios nodos intenten transmitir simultáne-
amente. CAN resuelve lo anterior al asignar
prioridades mediante el identificador de cada
mensaje, donde dicha asignación se realiza
durante el diseño del sistema en forma de
números binarios y no puede modificarse diná-
micamente. El identificador con el menor
número binario es el que tiene mayor priori-
dad.
El método de acceso al medio utilizado es
el de Acceso Múltiple por Detección de
Portadora, con Detección de Colisiones y
Arbitraje por Prioridad de Mensaje
(CSMA/CD+AMP, Carrier Sense Multiple
Access with Collision Detection and Arbitration
Message Priority). De acuerdo con este méto-
do, los nodos en la red que necesitan transmi-
tir información deben esperar a que el bus esté
libre (detección de portadora); cuando se cum-
ple esta condición, dichos nodos transmiten un
bit de inicio (acceso múltiple). Cada nodo lee el
bus bit a bit durante la transmisión de la trama
y comparan el valor transmitido con el valor
recibido; mientras los valores sean idénticos,
el nodo continúa con la transmisión; si se
detecta una diferencia en los valores de los
bits, se lleva a cabo el mecanismo de arbitra-
je.
El protocolo CAN establece dos formatos
de tramas de datos (data frame) que difieren
en la longitud del campo del identificador, las
tramas estándares (standard frame) con un
Electrónica del Automóvil
44 Escáners e Interfases OBD II
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 4
 
identificador de 11 bits definidas en la especifi-
cación CAN 2.0A, y las tramas extendidas con
un identificador de 29 bits definidas en la espe-
cificación CAN 2.0B.
Para la transmisión y control de mensajes
CAN, se definen cuatro tipos de tramas: de
datos, remota (remote frame), de error (error
frame) y de sobrecarga (overload frame). Las
tramas remotas también se establecen en
ambos formatos, estándar y extendido, y tanto
las tramas de datos como las remotas se
separan de tramas precedentes mediante
espacios entre tramas (interframe space).
Un controlador CAN debe contar con la
capacidad de detectar y manejar los errores
que surjan en una red. Todo error detectado
por un nodo, se notifica inmediatamente al
resto de los nodos.
Capa de supervisor: La sustitución del
cableado convencional por un sistema de bus
serie presenta el problema de que un nodo
defectuoso puede bloquear el funcionamiento
del sistema completo. Cada nodo activo trans-
mite una bandera de error cuando detecta
algún tipo de error y puede ocasionar que un
nodo defectuoso pueda acaparar el medio físi-
co. Para eliminar este riesgo el protocolo CAN
define un mecanismoautónomo para detectar
y desconectar un nodo defectuoso del bus,
dicho mecanismo se conoce como aislamiento
de fallos.
Capa de aplicación: Existen diferentes
estándares que definen la capa de aplica-
ción; algunos son muy específicos y están
relacionados con sus campos de aplica-
ción. Entre las capas de aplicación más
utilizadas cabe mencionar CAL, CANopen,
DeviceNet, SDS (Smart Distributed
System), OSEK, CANKingdom.
Habiendo definido las características
de un sistema CAN estamos en condicio-
nes de analizar el formato de los mensajes
en este sistema.
LOS MENSAJES CAN
Para entender mejor cómo funcionan las
redes CAN (figura 1), es necesario compren-
der la estructura que componen los mensajes
que se envían a través del bus. Aprovechando
el trabajo de Raúl Milla Pérez (www.arcan.es)
ilustraremos con la mayor claridad posible la
estructura de un mensaje CAN.
Existen dos tipos de mensajes CAN que se
distinguen únicamente por la longitud del
Identificador “Identifier”. En el caso del
Formato Estandar “Standard Message Format”
son 11 bits, mientras que para el Formato
Extendido (Extended Message Format) son 29
bits. 
En las redes CAN no se asigna a los dispo-
sitivos una dirección y tampoco ningún meca-
nismo que los difiera entre ellos, es una capa
superior software, la capa “Selección”, la que
se encarga de saber si el mensaje le concier-
ne o no, y lo sabe gracias al Identificador. Esto
es una característica tan curiosa como poten-
te desde mi punto de vista, y es que en una red
CAN un mismo mensaje puede ser recibido
por varios. 
En la figura 2 podemos observar los distin-
tos campos de un mensaje CAN.
Vamos a describir los distintos campos que
componen el mensaje:
“Start of Frame” este bit se encarga de
avisar a los demás dispositivos que se va a ini-
ciar un mensaje, y de esta forma se sincroni-
zan. El inicio de mensaje se marca por un bit
dominante “0”.
ESTRUCTURA CAN Y PROTOCOLO SAE
55Capítulo 1
Figura 1
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 5
 
“Arbitration Field” consta del identificador
del mensaje, 11 bits, y un bit de control adicio-
nal (RTR). Cuanto más bajo sea el valor del
Identificador más prioridad tendrá el mensaje. 
Durante la transmisión de este campo, el
emisor comprueba en cada bit si todavía está
autorizado para emitir o si está emitiendo otro
dispositivo con un mensaje de mayor priori-
dad. El bit RTR indica si el mensaje contiene
datos (RTR=0) o si se trata de una trama
remota sin datos (RTR=1). Una trama de datos
siempre tiene una prioridad más alta que una
trama remota. La trama remota se emplea
para solicitar datos a otras unidades o bien
porque se necesita para realizar un chequeo.
“Control Field” Este campo informa sobre
las características del “Data Field”, se compo-
ne por un primer bit “IDE”, que indica qué tipo
de mensaje es, “0” para una trama estándar y
“1” para una trama extendida. Después un bit
reservado y los cuatro últimos contienen la lon-
gitud en Bytes del campo de datos “Data
Field”.
“Data Field” en este campo se encuentra
la información que puede variar entre 0 y 8
Bytes. Un mensaje de longitud 0 puede emple-
arse para la sincronización de procesos distri-
buidos.
Electrónica del Automóvil
66 Escáners e Interfases OBD II
Figura 2
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 6
 
“CRC Field” Es un código de 15 bits para
verificar posibles errores de transmisión, está
basado en una codificación Hamming con dis-
tancia 6, el último bit es siempre un “1” y deli-
mita el campo CRC.
“Ack Field” El campo ACK está compues-
to por dos bit que son siempre trasmitidos
como recesivos “1”. Todos los dispositivos que
verifican el CRC modifican el primer bit del
campo ACK por uno dominante “0”, de forma
que el periférico que está todavía transmitien-
do reconoce que al menos algún dispositivo ha
recibido el mensaje correctamente. De no ser
así, el emisor interpreta que su mensaje pre-
senta algún error.
“End of Frame” Este campo indica el final
del mensaje con una cadena de 7 bits recesi-
vos “1”. Puede ocurrir que en determinados
mensajes se produzcan largas cadenas de
ceros o unos, y que esto provoque una pérdi-
da de sincronización entre los dispositivos.
CAN resuelve esta situación insertando un bit
de diferente polaridad cada cinco bits iguales:
cada cinco “0” se inserta un “1” y viceversa. El
dispositivo que utiliza el mensaje, descarta un
bit posterior a cinco bits iguales. Estos bits
reciben el nombre de bit stuffing.
Como podemos ver, el mensaje en Formato
Estándar se compone de 130 bit, y es necesa-
rio un mecanismo para evitar el envío de men-
sajes erróneos, para este fin se encuentra el
campo CRC, pero existe otro mecanismo que
me ha parecido muy curioso, el propio emisor
recibe también el mensaje a la vez que lo
envía, y lo va comparando; si por alguna cir-
cunstancia no coincide, activa un flag de error
y detiene la transmisión durante 12 bits. 
En este tiempo todos los demás dispositi-
vos activan también el flag de error, el objetivo
de esta ventana temporal es permitir la sincro-
nización de todos los elementos. Una vez
transcurridos los 12 bits, el emisor vuelve a
enviar el mensaje. 
¿Qué pasa si el error en la recepción del
mensaje es permanente? 
La respuesta “sería” que el sistema se blo-
quearía, pero no es así, CAN ha pensado en
esto, y está dotado de un mecanismo capaz de
distinguir entre anomalías ocasionales y ano-
malías permanentes mediante una evaluación
estadística de las situaciones de error.
MÁS SOBRE FORMATOS EN MENSAJES CAN
La norma ISO 15765-4 (CAN) define varios
tipos de mensajes que se usan en sistemas de
diagnóstico. Corrientemente, hay 4 principales
que pueden usarse:
SF: Single Frame (Cuadro Único).
FF: First Frame (Primer Cuadro) (de un
mensaje multicuadro).
CF: Consecutive Frame (Cuadro
Consecutivo de un mensaje multicuadro).
FC: Flow Control frame (Cuadro de Control
de Flujo).
El mensaje SF almacena hasta 7 bytes de
datos y un byte PC I (Protocol Control
Information, o Información de Control de
Protocolo). El byte PC I siempre es el primero
de todos, y dice cuántos bytes de datos
siguen. Si está activada la opción CAF1 (CAN
Auto Formatting), entonces el ELM327 creará
este byte cuando transmita y lo eliminará
cuando reciba (si los encabezamientos están
habilitados, siempre lo verá).
Si desactiva la opción (CAF0), se espera
que provea todos los bytes de datos a enviar.
En sistemas de diagnóstico, esto significa el
byte PCI y los bytes de datos. El ELM327 no
modificará sus datos de ninguna manera,
excepto agregar bytes extra de relleno para
asegurar que siempre mande tantos bytes de
datos como se requieran (8 para ISO 15765).
No necesita poner la opción Allow Long (AT
AL) para enviar 8 bytes, ya que el CI lo hace
para Ud .
Se usa un mensaje FF para decir que está
por enviarse un mensaje multicuadro, y le dice
al receptor cuántos bytes de datos esperar. 
ESTRUCTURA CAN Y PROTOCOLO SAE
77Capítulo 1
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 7
 
El descriptor de longitud se limita a 12 bits,
de modo que se pueden recibir un máximo de
4095 bytes enseguida usando este método.
Los mensajes CF se envían después del men-
saje FF para proveer el resto de los datos.
Cada mensaje CF incluye un solo dígito hexa-
decimal (“número de secuencia”) que se usa
para determinar el orden cuando se reagrupan
los datos. Se espera que si un mensaje estu-
viera corrupto, podría estar desarreglado en
unos pocos paquetes, pero no más de 16, de
modo que un solo dígito normalmente es más
que adecuado. Como vimos antes, el número
de serie de un vehículo es una respuesta mul-
ticuadro:
>0902
014
0: 49 02 01 31 44 34
1: 47 50 30 30 52 35 35
2: 42 31 32 33 34 35 36
En este ejemplo, la línea que comienza con
0: es el mensaje FF. La longitud (014) fue
extraída del mensaje por el ELM327 e impresa
en la primera línea como se muestra. A conti-
nuación de la línea FF vienen dos CFs (que
comienzan con 1: y 2:). Para aprender más
detalles del formateo exacto, puede querer
enviarun pedido como el anterior, luego repe-
tir el mismo pedido con los encabezamientos
habilitados (AT H1). Esto mostrará los bytes
PCI que se usan realmente para enviar estos
componentes del mensaje total.
El cuadro FC es uno con el cual Ud. nor-
malmente no tiene que tratar. Cuando se envía
un mensaje FF como parte de una respuesta,
el ELM327 debe decirle al transmisor algunas
cosas técnicas (tales como cuánto demorar
entre cuadros consecutivos (CF), etc.) y lo
hace respondiendo inmediatamente con un
mensaje FC. Estos se predefinen mediante la
norma ISO 15765-4, de modo que se puedan
insertar automáticamente. También se pueden
“generar mensajes FC a medida”, tema que
veremos más adelante.
Si se detecta un cuadro FC mientras se
monitorea, se mostrará la línea con “FC:”
antes de los datos, para ayudarle a decodificar
la información. Hay un tipo final de mensaje
que se informa ocasionalmente, pero no es
soportado por la norma de diagnóstico. La
norma CAN permite la transmisión de un pedi-
do de datos sin enviar ningún dato en el men-
saje pedido. Para asegurar que el mensaje se
vea como tal, el transmisor también pone una
bandera especial en el mensaje (el bit RTR),
que se ve en cada receptor. El ELM327 siem-
pre busca esta bandera, o bytes de datos cero,
y puede informarle que fue detectado un RTR
mientras monitorea. Esto se muestra mediante
los caracteres RTR donde normalmente apa-
recerían los datos, pero sólo si está desactiva-
do el Autoformateo CAN, o están habilitados
los encabezamientos. A menudo, cuando se
monitorea un sistema CAN con una velocidad
de transferencia incorrecta, se pueden ver
RTRs. Note que el sistema CAN es bastante
robusto con varios métodos de detección de
errores en acción, de modo que durante la
transmisión normal de datos raramente verá
algún error. Sin embargo, cuando se monitore-
an los buses, puede ver errores (especialmen-
te si el ELM 327 está puesto en una velocidad
de transferencia incorrecta). Como ayuda para
el diagnóstico, cuando ocurren errores, el CI
imprimirá todos los bytes (sin importar a qué
CAF esté puesto), seguido del mensaje “<RX
ERROR”.
ALTERACIÓN DE LOS
MENSAJES DE CONTROL DE FLUJO
La norma ISO 15765-4 (CAN) proporciona
sólo 8 bytes de datos por cuadro de datos. Por
supuesto, hay muchos casos en los que los
datos que hay que enviar son más largos que
8 bytes, y CAN ha previsto esto permitiendo
que los datos se separen en segmentos y
luego se recombinan en el receptor.
Para enviar uno de estos mensajes multilí-
nea, el transmisor en un sistema CAN enviará
un mensaje FF, y luego esperará una respues-
ta del receptor. Esta respuesta, llamada men-
saje FC contiene información relacionada con
la temporización aceptable del mensaje, etc.,
y se requiere que se envíe antes de que el
transmisor envíe más datos. Para la ISO
15765-4, el tipo de respuesta está bien defini-
Electrónica del Automóvil
88 Escáners e Interfases OBD II
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 8
 
do, y nunca cambia. El ELM327 enviará auto-
máticamente esta respuesta FC mientras esté
habilitada la opción CAN FC (CFC 1), que es
por defecto.
Varios usuarios han pedido que demos más
flexibilidad sobre los datos enviados en el
mensaje FC, y con la v 1.1 hemos proporcio-
nado un medio para hacerlo. A fin de cambiar
cómo responde el ELM 327 cuando se necesi-
ta enviar un mensaje FC, Ud. necesita cambiar
los “modos” del Control de Flujo (FC). El
número 0 es el modo de FC por defecto. En
cualquier momento mientras Ud. está experi-
mentando, si Ud. desea restaurar las respues-
tas del Control de Flujo automático (para ISO
15765-4), simplemente ponga el modo en 0:
> AT FC SM 0
OK
Esto restaurará inmediatamente las res-
puestas a sus valores por defecto. 
Se ha suministrado el Modo 1 para los que
necesitan un control completo de sus mensa-
jes de Control de Flujo. Para usarlo, simple-
mente defina el CAN ID (encabezamiento) y
los bytes de datos que Ud. pide que se envíen
en respuesta a un mensaje FF. Si Ud. trata de
poner el modo antes de definir esos valores,
obtendrá un error:
> AT FC SM 1
?
Primero debe establecer los encabeza-
mientos y los datos:
> AT FC SH 7E8
OK
> AT FC SD 00 11 22
OK
Luego puede establecer el modo:
> AT FC SM 1
OK
De aquí en más, cada mensaje FF recibido
se responderá con el mensaje a medida que
Ud. ha definido (7E8 00 11 22 en este ejem-
plo). El modo final corrientemente soportado
permite al usuario establecer los bytes de
datos que se han de enviar, pero no los bits ID.
Los bits ID (bytes de encabezamiento) en el
modo 2 son los mismos que los que fueron
recibidos en el mensaje FF, o sea, sin cambio.
Para usar este modo, primero defina sus bytes
de datos, luego active el modo:
> AT FC SD 00 11 22
OK
> AT FC SM 2
OK
Para la mayoría de la gente, habrá poca
necesidad de manipular estos mensajes FC,
dado que las posiciones por defecto están
diseñadas para trabajar con las normas CAN
OBD. Si desea experimentar, estos comandos
especiales AT ofrecen ese control para Ud. La
tabla 1 resumen los modos corrientemente
soportados:
–––––––––––––––––––––––––––––––––
Modo El ELM327 El usuario
FC provee provee
0 Bits ID Sin Valores
Bytes de Datos
1 Sin Valores Bits ID
Bytes de Datos
2 Bits ID Bytes de Datos
Tabla 1. Números de Modo de Control de Flujo
–––––––––––––––––––––––––––––––––
Recuerde entonces que CAN es un proto-
colo serie que usa el método de transmisión
broadcast, es decir, un elemento envía un
mensaje a través del bus a todos los compo-
nentes, y estos se encargan de saber si la
información del mensaje le es útil o no. Si el
mensaje fuese de interés para algún nodo,
este lo almacena y procesa, si no, simplemen-
te la deshecha. 
Si vuelve a mirar la figura 1 podrá observar
que la “Unidad de control 2”, envía el mensaje
que tenía almacenado en memoria al bus, y
ESTRUCTURA CAN Y PROTOCOLO SAE
99Capítulo 1
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 9
 
todas las demás unidades ven ese mensaje a
sus entradas. Sin embargo la “Unidad de con-
trol 3” deshecha este mensaje en la etapa de
“Selección”, mientras que las restantes deci-
den qué es apropiado y lo almacenan.
CAN está orientado a mensajes, es decir la
información que se va a intercambiar, se des-
compone en mensajes, a los cuales se les
asigna un identificador y se encapsulan en tra-
mas para su transmisión, este ID o identifica-
dor es el que consigue que el nodo pueda
saber si el mensaje le será útil.
Es muy interesante saber que la
Organización Internacional para la
Estandarización (ISO, International
Organization for Standarization) define dos
tipos de redes CAN: red de alta velocidad,
bajo el estándar ISO 11898-2, y red de baja
velocidad, bajo el estándar ISO 11519-2/ISO
11898-3. 
Para finalizar, en la figura 3 se grafica la
estructura de un BUS 2003 a 2011 para la
marca Audi. ☺
 
Electrónica del Automóvil
1010 Escáners e Interfases OBD II
Figura 3
 Cap 1 CAN y SAE 2/7/11 4:59 PM Página 10
 
 
Hace casi 2 años que en Saber Electrónica
publicamos artículos sobre electrónica auto-
motor en la sección que denominamos “Auto
Eléctrico”. Así, mes a mes, hemos explicado
que el circuito integrado ELM 327, de la
empresa ELM Electronics constituye una ver-
dadera interfase multiprotocolo con el cual es
posible montar un escáner OBD II cuando se
conecta dicho integrado (o una interfase arma-
da con él) a una computadora tipo PC y se eje-
cutan los programas apropiados como el Scan
Master o el Scan Tool. A través de las diferen-
tes ediciones y de dos tomos del Club SE
publicados sobre el tema (Tomos de colección
Nº 58 y Nº 65) ha llegado la hora de “por fin”
armar su propia interfase para poder realizar el
diagnóstico a bordo de un automóvil.
Aclaramos que los datos vertidos en este artí-
culo son en base a los circuitos integrados
fabricados por ELM Electronics y que al haber
probado varios clones, NO NOS HACEMOS
RESPONSABLES si
emplea circuitos no origi-
nales. Alrespecto debe-
mos aclarar que a la fecha
de publicación de este
artículo NO EXISTE la ver-
sión v1.5 de este integra-
do y que trabajaremos en
base a la versión v1.4b.
Proponemos el armado
de un circuito que permita
conectar a la computadora
de a bordo de un vehículo
compatible con OBD II con
una computadora tipo PC
a la que le instalaremos un
programa que permita
decodificar los datos reci-
bos desde el vehículo. La
norma SAE J1962 dice que todos los vehícu-
los compatibles con OBD deben proveer un
conector normalizado cerca del asiento del
conductor y a dicho conector colocaremos
nuestro circuito. El circuito descrito aquí se
puede usar para aplicar a un conector OBD II
bajo norma J1962 sin modificación a su vehí-
culo.
INTRODUCCIÓN
Dado que en la revista Saber Electrónica
publicamos diferentes artículos relacionados
con el sistema de diagnóstico a bordo, dare-
mos a continuación algunos conceptos sintéti-
cos para luego poder abordar los conceptos
que nos permitan construir nuestra interfase.
El circuito descrito aquí se puede usar para
aplicar a un conector OBD II bajo norma J1962
1111Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
Capítulo 2
MONTAJE DE UNA INTERFASE OBD II
CON ELM 327
 
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 11
 
sin modificación a su vehículo y que podrá rea-
lizar las siguientes funciones:
§ Leer Códigos de Error 
§ Borrar Códigos de Error 
§ Leer Datos Freeze Frame 
§ Obtener Información en Tiempo Real
(Tanto Números como Gráficos) 
§ Obtener los resultados del monitoreo de
los Sensores de Oxígeno 
§ Obtener el resultado para Test de
Preparación
SOBRE LA ELECTRÓNICA EN EL AUTOMÓVIL
En 1989 se comenzó a trabajar en sistemas
de control electrónico que regulen la contami-
nación de los vehículos.
En 1994 se establecieron los primeros pro-
tocolos de comunicación entre los equipos ins-
talados en el auto y los equipos de escaneo
externo.
En 1996 nace el primer sistema de
Diagnóstico A Bordo normalizado (OBD).
Desde 2005 TODOS los vehículos deben
contar con un sistema de cómputo a bordo que
posea un puerto de comunicaciones
normalizado con OBD II.
La comunicación entre computado-
ra de a bordo y periféricos dentro del
vehículo se realiza en función del pro-
tocolo elegido por el fabricante.
OBD Y OBD II
La primera norma implantada fue la
OBD I en 1988, donde se monitoriza-
ban los parámetros de algunas partes
del sistema como:
La sonda lambda (sensor de oxíge-
no).
El sistema EGR (Exhaust gas recir-
culation).
ECM (Módulo de control). 
Se precisaba una lámpara indicado-
ra de mal funcionamiento (MIL), denominada
Check Engine o Service Engine Soon, para
que se iluminara y alertara al conductor del
mal funcionamiento y de la necesidad de un
servicio de los sistemas de control de emisio-
nes.
OBD-II: “On-Board Diagnostics II
Generation” o “Segunda Generación de
Diagnósticos a Bordo”, es un sistema basado
en la informática que se incorpora en todos los
vehículos menores y camiones del año 96 en
adelante en USA. 
EL OBD-II monitorea algunos de los com-
ponentes más importantes de los motores,
incluyendo controles de emisión individuales.
El sistema alerta tempranamente al conductor
con una luz en el tablero, conocida como
“Check Engine” o también “MIL” (Malfunction
Indicator Light). 
Este sistema protege al medio ambiente así
como al usuario y/o dueño del vehículo, avi-
sando desde que la falla es leve, y los costos
de reparación serán más bajos. 
EOBD: “European On-Board Diagnostic
EOBD” es un estándar definido por la
Comunidad Europea. El beneficio de este
estándar es dar a las autoridades una herra-
Electrónica del Automóvil
1212 Escáners e Interfases OBD II
Figura 1
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 12
 
mienta para controlar las emisiones de gases
de los vehículos.
El estándar EOBD ha sido implementado
en los vehículos con motores a gasolina en la
Comunidad Europea desde enero de 2001
(EU directive 98/96/EC). 
Para vehículos Diesel y a Gas Natural, la
aplicación de estas normas se programó para
antes del 2005. 
El Estándar EOBD incluye 5 protocolos de
comunicación diferentes, estos son: ISO 9141-
2, ISO 14230¬4 (KWP2000), SAE J1850 VPW,
SAE J1850 PWM e ISO 15765-4 CAN. Para
saber si el vehículo está dotado de un sistema
de diagnóstico a bordo, cuando da arranque o
contacto a su vehículo, en el tablero la luz
"Service Engine Soon" o "Check Engine"
debería encenderse brevemente. Esto indica
que el sistema está listo para revisar que su
vehículo esté funcionando bien. Al estar la luz
apagada, y mientras usted conduce el vehícu-
lo sin ninguna señal de parte de ésta, significa
que el vehículo está funcionando bien. En el
caso de que el vehículo presentara alguna
falla, éste acusa la situación mediante esta luz.
El sistema OBD le puede ayudar a ahorrar
tiempo, dinero y combustible, además de pro-
teger el medio ambiente. 
¿Quiénes tienen OBD II?
Todos los vehículos y camionetas construi-
dos para ser vendidos en EEUU a partir del
año 1996 deben ser compatibles con OBD-II. 
La Comunidad Europea adoptó los mismos
términos a partir del año 2000 para los vehícu-
los con motor a gasolina (nafta), y a partir del
año 2003 para los vehículos con motores
Diesel. 
Un vehículo compatible con OBD-II puede
usar cualquiera de los siguientes protocolos
entre computadora y sus periféricos: 
J1850 PWM 
J1850 VPW
ISO9141
ISO14230 (también conocido como
Protocolo Clave 2000).
CAN (ISO15765/SAE J2480). 
Los fabricantes de automóviles no fueron
autorizados para utilizar el protocolo CAN
hasta los modelos del año 2003. 
El protocolo de diagnóstico para OBD-II es
SAE J1979, pero no es el único. Incluso exis-
ten protocolos cautivos como el VAG-COM
(VW, Audi, SEAT y Skoda ). 
Esto significa que un escáner o una interfa-
se “debe” manejar el protocolo SAE J1979,
pero también puede aceptar otros. Si sólo
maneja este protocolo se comunicará con la
computadora mas NO con los microcontrola-
dores periféricos.
Si el escáner es multiprotocolo, puede
obtener los datos del vehículo enviados a la
ECU con dichos protocolos. Si se trata de una
interfase a conectar en la computadora, es el
programa que corre en la computadora el que
debe realizar el diagnóstico.
Hay programas de uso libre y otros con
licencia.
CONECTOR OBD II
En la figura 1 podemos observar un conec-
tor OBD II y sus conexiones. Note que dicho
conector muestra los pines empleados para
todos los protocolos mencionados, por lo que
debe tener en cuenta que cada computadora
de a bordo tendrá las conexiones de acuerdo
con el protocolo que utilice mientras que un
escáner multiprotocolo deberá tener todas las
conexiones mencionadas en la figura.
En la figura 2 tenemos tablas que nos indi-
can cuáles serán las conexiones presentes en
los pines del conector OBD II de acuerdo con
el protocolo empleado.
Como dato complementario, para las
comunicaciones ISO, el pin 15 (L-line) no
siempre debe estar presente. El Pin 15 se usó
antes en autos con ISO/KWP2000 para activar
1313Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 13
 
o despertar la ECU antes de la comunicación
puede comenzar en el pin 7 (K-Line). Más
tarde los vehículos tendían a utilizar solamen-
te el Pin 7 (K-Line) para comunicarse. 
En la figura 3 podemos ver un mapa de la
ubicación de conector (DLC) donde se divide
el tablero del vehículo en áreas enumeradas
para su mejor entendimiento. Cada área enu-
merada representa
un lugar específico
donde los distintos
fabricantes instalan
el Conector de
Datos. Las ubica-
ciones 1, 2 y 3 se
caracterizan por ser
las áreas preferidas
para la instalación
del DLC, mientras
que las restantes 4,
5, 6, 7 y 8 se
encuentran en otras
ubicaciones de
acuerdo a los
requerimientos de
la EPA. Cuando el
conector se
encuentra en las
ubicaciones 4 hasta
8 los fabricantes deben indicar con una etique-
ta en las ubicaciones 1, 2 o 3 que el conector
se encuentra en otro lado. 
Ubicación#1: En esta posición, el conec-
tor de datos se encuentra justo debajo de la
columna de dirección (o aproximadamente
150mm a la derecha o a la izquierda de ésta).
Dividiendo la parte inferior del tablero del vehí-
Electrónica del Automóvil
1414 Escáners e Interfases OBD II
Figura 3
Figura 2
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 14
 
culo en tres partes, este se encuentra en la
parte del centro. 
Ubicación #2: Esta posición es la que se
encuentra bajo el tablero del vehículo, entre la
puerta del conductor y la columna de direc-
ción. Dividiendo la parte inferior del tablero del
vehículo en tres partes, éste se encuentra en
la parte del lado izquierdo. 
Ubicación #3: Esta ubicación es la que se
encuentra bajo el tablero del vehículo, entre la
columna de dirección y la consola central.
Dividiendo la parte inferior del tablero del vehí-
culo en tres partes, éste se encuentra en la
parte del lado derecho. 
Ubicación #4: La posición del conector de
datos en esta ubicación está en la parte supe-
rior del tablero del vehículo, entre la columna
de dirección y la consola central. 
Ubicación #5: La posición del conector de
datos en esta ubicación está en la parte supe-
rior del tablero del vehículo, entre la columna
de dirección y la puerta del conductor. 
Ubicación #6: Esta ubicación presenta el
conector de datos en el lado Izquierdo de la
consola central del vehículo. 
Ubicación #7: Esta ubicación presenta el
conector de datos del vehículo 300mm a la
derecha de la línea central del vehículo, en la
consola central del mismo, hacia el lado acom-
pañante. 
Ubicación #8: Acá se puede encontrar el
conector de datos del vehículo en la parte infe-
rior de la consola central del vehículo, esto
puede ser en el lado derecho o izquierdo sin
especificarse. Esto no incluye la parte de la
consola central que se extiende hacia la parte
trasera del Vehículo. (Ver Ubicación #9). 
Ubicación #9: Esta ubicación no se mues-
tra en el diagrama, y representa cualquier otra
posición que se pueda dar en un vehículo, la
cual es menos frecuente pero sin embargo
algún fabricante la puede utilizar. Por ejemplo,
el conector se puede encontrar también en el
área de pasajeros de la parte trasera del vehí-
culo, o en el descansa brazos del conductor. 
El protocolo de diagnóstico para OBD-II es
SAE J1979. Un mensaje o requerimiento de
diagnóstico tiene un máximo de 7 Bytes de
datos. El primer Byte a continuación del
Encabezado o Header es el Modo de Test.
Este también es llamado el identificador de
servicio (SID o PID). Los siguientes Bytes varí-
an dependiendo del modo de Test Específico. 
Como mencionamos en otro artículo de
esta edición, hay varios Modos de Test de
Diagnóstico, de los cuales destacamos los
siguientes: 
Modo $01 - Solicitar Diagnóstico de Datos
del Tren de Poder - Este modo da acceso a la
emisión de datos actuales, incluyendo entra-
das y salidas tanto análogas como digitales,
así como información del estado del sistema. 
Modo $02 - Solicitar Diagnóstico de Datos
FreezeFrame del Tren de Poder - Este modo
da acceso a información de la emisión de
datos actuales en FreezeFrame. Un
FreezeFrame consiste en la entrega de datos
colectados en un evento específico como por
ejemplo alguna falla en el motor. 
Modo $03 - Solicitar Diagnóstico de
Códigos de Error - El propósito de este servi-
cio es de habilitar un accesorio externo para
obtener las emisiones de códigos de error con-
firmados. 
Modo $04 - Limpiar-Eliminar Información
sobre los Códigos de Error - El propósito de
este servicio es proveer los medios para un
equipo externo de análisis para poder eliminar
la información relacionada con los Códigos de
Error de la ECU del Vehículo. 
Modo $05 - Solicitar los Resultados del
Monitoreo de los Sensores de Oxígeno - Este
servicio permite acceder a los resultados del
monitoreo de los Sensores de Oxígeno. 
Modo $06 - Solicitar Resultados de
Monitoreo a bordo para los Sistemas de
Diagnóstico No Continuos - Este servicio da
acceso a los resultados para los Monitoreos a
bordo de Componentes o Sistemas que no son
monitoreados constantemente. Por ejemplo, el
1515Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 15
 
Electrónica del Automóvil
1616 Escáners e Interfases OBD II
Figura 4
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 16
 
monitoreo del Catalizador o el sistema de
Emanación de Gases. 
Modo $07 - Solicitar Resultados de
Monitoreo A Bordo para los Sistemas de
Diagnóstico Continuos - A través de este servi-
cio, el equipo de diagnóstico externo, puede
obtener los resultados para los Componentes
o Sistemas del Tren de Poder que son cons-
tantemente monitoreados durante la conduc-
ción en condiciones normales. 
Modo $08 - Solicitar el control del Sistema
A Bordo, Testeo o Componentes - Este servi-
cio habilita a un equipo externo de testeo para
controlar la operación del Sistema A Bordo,
Testeo o Componentes. 
Modo $09 - Solicitar Información del
Vehículo - Este servicio da acceso a informa-
ción específica del Vehículo como el Número
de Identificación del Vehículo e ID de
Calibración. 
FUNCIONAMIENTO Y
CONSTRUCCIÓN DE LA INTERFASE
El circuito de la figura 4 muestra cómo se
podría usar típicamente el ELM 327 para la
construcción de una interfase lectora de códi-
gos DTC o códigos de error. La alimentación
del circuito se obtiene del vehículo a través de
las patas 16 y 5 y después de un diodo pro-
tector y algún filtrado capacitivo, se presenta a
un regulador de 5V (Note que pocos vehículos
han sido informados que no poseen la pata 5;
en ese caso, use la pata 4 en vez de la 5). El
regulador alimenta varios puntos del circuito
así como un LED (para la confirmación visual
de que está presente la potencia). Hemos
mostrado un regulador 78L05 que limita la
corriente disponible a 100mA, lo cual es un
valor seguro para experimentar. La interfaz
CAN es un circuito de baja impedancia, y si se
hacen transmisiones constantes en CAN este
tipo de regulador puede ocasionar LV Resets o
posiblemente se apague por la sobre-tempera-
tura. Si sufre esos problemas, podría usar un
regulador 7805 de 1A.
La esquina izquierda superior del circuito
de la figura 4 muestra el circuito de interfaz
CAN. No aconsejamos hacer su propia interfaz
usando componentes discretos. 
Los buses CAN pueden tener un montón de
información crítica en ellos y Ud. puede hacer
más daño que bien si falla. Recomendamos
que use un chip transceptor como se muestra
en la figura. El chip MCP 2551 se usa en nues-
tro circuito, pero la mayoría de los grandes
fabricantes producen CIs de transceptores
CAN específicos. 
Mencionemos unos pocos: NXP 82C 251,
Texas Intruments SNE5LBC 031, y Linear
Technology LT 1796. Preste atención a los
límites de tensión; según la aplicación, puede
tener que tolerar 24V y sólo 12V.
1717Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
Lista de Materiales de la Interfase con ELM 327
(figura 4)
Resistores
R32, R33= 100Ω
R5 = 240Ω
R1, R2, R3, R4, R27, R28, R29, R30 = 470Ω
R17, R19 = 510Ω 1/2W
R16, R18 = 2.2kΩ
R6, R7, R14, R15, R23, R26, R31 = 4.7kΩ
R8, R9, R11, R13, R22, R24, R25, R35 = 10kΩ
R10, R21, R36 = 22kΩ
R20, R34 = 47kΩ
R12 = 100kΩ
Semiconductores
D1 = 1N4001
D2, D3, D4, D5 = 1N4148
L1, L2, L3, L4 = LED amarillo
L5 = LED verde
Q1, Q3, Q5, Q6, Q7, Q9 = 2N3904 (NPN)
Q2, Q4, Q8 = 2N3906 (PNP)
U1 = ELM327
U2 = MCP2551
U3 = 78L05 (5V, 100mA, regulator)
U4 = 317L (adj. 100mA, regulator)
Capacitores
C1, C2, C5, C6, C7 = 0.1µF x 16V
C3, C4 = 27pF
C8, C9 = 560pF
Varios
X1 = 4.000MHz - cristal
RS232, Conector = DB9F
IC Base = 28pin 0.3” (or 2 x 14pin)
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 17
 
Posee las conexiones para los protocolos
ISO 9141 e ISO 14250. Provee dos líneas de
salida como lo requieren las normas, pero
dependiendo de su vehículo, puede que no
necesite usar la salida ISO-L (muchos vehícu-
los no requieren esta señal para la iniciación,
pero algunossí, de modo que se muestra
aquí). 
Si su vehículo no requiere la línea L, sim-
plemente deje la pata 22 sin usar. El ELM 327
controla ambas salidas ISO a través de los
transistores NPN Q6 y Q7 como se muestra.
Estos transistores tienen resistores pull-up de
510 ohm conectados a sus colectores, como
lo requiere la norma. A menudo nos preguntan
por sustitutos de estos resistores. Si necesita
sustituirlos, puede subir hasta 560 ohm o
hacer los 510 ohm a partir de 2 resistores en
serie de 240 ohm (1/4W), pero no recomenda-
mos un valor menor porque estresa a cada dis-
positivo del bus. Se deben usar resistores de
1/2W dado que un corto a 13,8V produce una
disipación de 0,4W. Los datos se reciben de la
línea K del bus OBD y se conectan a la pata 12
después de ser reducidos por el divisor de ten-
sión R20/R21 mostrado. Debido al Schmitt trig-
ger a la entrada de la pata 12, estos resistores
darán niveles umbrales típicos de 9,1V (subi-
da) y 4,7V (caída), proporcionando una gran
cantidad de inmunidad contra el ruido mientras
se protege al CI.
La interfaz OBD final mostrada también
contempla las 2 normas J1850. La norma
VPW J1850 necesita una fuente de alimenta-
ción positiva de hasta 8V mientras que la PWM
J1850 necesita 5V, de modo que hemos mos-
Electrónica del Automóvil
1818 Escáners e Interfases OBD II
Figura 5
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 18
 
trado una fuente de alimentación de 2 niveles
que puede entregar ambos. Esta doble fuente
de alimentación usa un regulador ajustable
317L como se muestra, controlada por la pata
3 de salida. Con los valores dados de resis-
tencia, las tensiones seleccionadas serán de
7,5V y 5V, que funcionan bien para la mayoría
de los vehículos. Las dos salidas J1850 están
excitadas por la combinación Q1 - Q2 para el
Bus + , y Q3 para el Bus -.
La entrada VPW J1850 usa un divisor como
en la entrada ISO. Las tensiones umbrales típi-
cas con los resistores mostrados serán de
4,2V (subida) y 2,2V
(caída). La entrada PWM
J1850 es un poco diferen-
te en el sentido que debe
convertir una entrada dife-
rencial a una de termina-
ción única para el uso del
ELM327. En funciona-
miento, Q4 en realidad se
usa como amplificador
diferencial. El circuito serie
Q4 - D3 establece una ten-
sión de 1V (para la inmuni-
dad contra el ruido) mien-
tras que R11 limita el flujo
de corriente, y R12 man-
tiene cortado a Q4 cuando
la entrada se deja abierta.
Se ha agregado el
resistor R36 al circuito de
la figura 4 para ayudar a
cortar al transistor Q4 rápi-
damente en ciertas cir-
cunstancias. No es
imprescindible, pero es útil
si está conectado a una
capacidad muy alta como
la del modo PWM J1850 y
sufre algunos falsos BUS
ERRORs. Mostramos el
resistor como una opción y
le dejamos la elección de
su colocación.
El circuito de monitoreo
de tensión para el coman-
do AT RV se muestra en
este circuital conectado a la pata 2 del ELM
327. Los dos resistores simplemente dividen la
tensión de batería a un nivel seguro para el
ELM 327, y el capacitor filtra el ruido. Cuando
se lo envía, el ELM 327 espera un divisor
resistivo como el que se muestra, y establece
constantes nominales de calibración suponien-
do eso. 
Si su aplicación necesita un rango diferen-
te de valores, elija los valores resistivos para
mantener la entrada dentro del límite especifi-
cado de 0-5 V, y luego realice un AT CV para
calibrar el ELM 327 para su nueva relación del
1919Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
Figura 6
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 19
 
divisor resistivo. La máxima tensión que puede
mostrar el CI es de 99,9V.
Se muestra una interfaz RS 232 muy bási-
ca conectada a las patas 17 y 18 del ELM 327.
El circuito “toma” la tensión de alimentación de
la computadora de abordo para proveer una
variación de las tensiones RS 232 sin la nece-
sidad de una fuente de alimentación negativa.
Las conexiones mostradas de las patas de la
interfaz RS 232 son para un conector normali-
zado de 9 patas. Si usa una de 25 patas, nece-
sitará compensar las diferencias. La polaridad
de las patas RS 232 del ELM 327 es tal que
son compatibles con los CIs de interfaces nor-
malizadas (MAX 232, etc.), de modo que si
prefiere una de ellas, Ud. puede sacar todos
los componentes discretos mostrados y usar
aquélla. Los 4 leds mostrados (en las patas 25
a 28) han sido suministrados como medio
visual de confirmación de la actividad circuital.
No son esenciales, pero es lindo ver la reali-
mentación visual cuando se experimenta.
Finalmente, el cristal mostrado conectado
entre las patas 9 y 10 es un cristal normal de
4MHz. Los capacitores de carga del cristal
(27pF) son típicos y se pueden seleccionar
otros valores según lo que esté especificado
para el cristal que obtenga. La frecuencia del
cristal es crítica para la operación del circuito y
no debe alterarse. A menudo recibimos pedi-
dos de listas de partes que acompañen a
nuestros circuitos de Aplicaciones de ejemplo.
Dado que este circuito es más complejo que la
mayoría, hemos numerado y nombrado todos
los componentes y provisto un resumen de la
lista de partes. Son sólo sugerencias, ya que si
prefiere otro color de Led o tiene otro transis-
tor de propósito general a mano, etc., haga el
cambio. 
Un consejo rápido para aquellos que ten-
gan problemas para encontrar un zócalo
amplio de 0,3” para el ELM 327: muchos zóca-
los de 14 patas se pueden poner extremo con
extremo para formar un zócalo de 28 patas de
0,3” de ancho.
¿Qué pasa si sólo quiere usar uno de los
protocolos y una interfaz USB? 
Estas son preguntas comunes que recibi-
mos y las respuestas de ambas están grafica-
das en la figura 5.
Hay unos pocos CIs en el mercado que le
permiten conectar un sistema RS 232 directa-
mente a USB. Hemos mostrado el CP 2102 de
Silicon Laboratories (www.silabs.com) en la
figura 5, pero también hay otros; por ejemplo,
Future Technology Devices (www.ftdichip.com)
produce varios. Estos CIs proveen una forma
muy simple y relativamente barata de “puente-
ar” entre RS 232 y USB, y como puede ver,
requieren muy pocos componentes para
soportarlos. Si se usa el CP 2102, le adverti-
mos que es muy pequeño y difícil de soldar a
mano, así que esté preparado para eso.
También, si provee protección en las líneas de
datos con supresores de tensión transitoria
(TVS's), tenga cuidado de cuáles elige, dado
que algunos exhiben una capacidad muy alta y
afectarán la transmisión de los datos USB. El
circuito funcionará a la velocidad de 38400 bits
por seg..
Si quiere aprovechar totalmente la ventaja
de la velocidad de la interfaz USB, necesitará
cambiar PP 0C.
Considerando las partes protocolares OBD
de los circuitos de las figura 4 y 5, las diferen-
cias deben ser muy claras. Los protocolos que
no se usan en la figura 5 tienen sus salidas
ignoradas, o sea, en circuito abierto, y sus
entradas conectadas a un nivel lógico conve-
niente (las entradas CMOS nunca deben ser
dejadas flotando).
El circuito mantiene los LEDs de estado y el
circuito del Bus J 1850, pero la mayoría del
resto se ha eliminado. El circuito de conmuta-
ción de tensión ha sido reducido a un solo
regulador de 8V, dado que no hay ninguna
necesidad de conmutar a 5V. Note que la pata
3 intencionalmente ha sido dejada abierta ya
que no es requerida por el regulador de ten-
sión.
La primera vez que se usa este circuito,
probablemente se ponga en el protocolo 0, el
modo de “búsqueda automática” por defecto
(tal como se envía de fábrica). Cuando lo
conecta a un vehículo VPW J 1850, automáti-
camente detectará el protocolo, y si la memo-
Electrónica del Automóvil
2020 Escáners e Interfases OBD II
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 20
 
ria está habilitada (como se muestra), J 1850
VPW se convertirá en el nuevo protocolo por
defecto, sin que se requiera una entrada de su
parte. Esto funcionará bien para la mayoría de
las aplicaciones, pero si el circuito se usa en
un vehículo con la llave desconectada, por
ejemplo, entonces volverá a buscar unnuevo
protocolo. En general, Ud. no quiere que esto
suceda cada vez. Sólo puede ser un inconve-
niente menor tener que esperar mientras el
ELM 327 determina que es incapaz de conec-
tar (“UNABLE TO CONNECT”), pero ¿para
qué pasar por eso si no lo necesita?. Si sabe
que está usando el circuito en una aplicación
de sólo J 1850 VPW (protocolo 2), entonces
debe emitir el comando AT SP 2 la primera vez
que se alimente el circuito. De aquí en más,
permanecerá en el protocolo 2, falle o no para
hacer una conexión.
Según las circunstancias, puede simplificar
este circuito aún más, usando la conexión
USB para obtener 5V para el ELM 327 en el
lugar del regulador 78L05 mostrado. Algunos
protocolos (el CAN, por ejemplo), pueden
tomar más corriente que la que su conexión
USB puede suministrar, de modo que revise
esto primero.
El conector macho J 1962 (estándar OBD
II) tiene que encajar en el conector del vehícu-
lo y puede ser difícil de conseguir en algunos
lugares. Ud. podría tentarse de hacer sus pro-
pias conexiones a la parte trasera del conector
de su vehículo. Al hacerlo, le recomendamos
que no haga nada que comprometa la integri-
dad de la red OBD del vehículo. El uso de
cualquier conector que podría fácilmente cor-
tocircuitar patas (por ejemplo el conector tele-
fónico RJ 11) no se recomienda en absoluto.
Por último, en la figura 6 se brinda una
sugerencia para la placa de circuito impreso,
teniendo presente que el diseño contempla la
inclusión de componentes del tipo SMD.
INSTALACIÓN DE LA INTERFASE
Una vez armado el circuito de la interfase,
el primer paso consiste en cargar los drivers
USB en la computadora, los que podrá des-
cargar desde nuestra web: www.webelectroni-
ca.com.ar, haciendo clic en el ícono password
e ingresando la clave: “usbelm327”. Esto es
para que la computadora PC pueda dialogar
con el escáner y éste, a su vez, con la compu-
tadora de a bordo.
Para ello, descargue los drivers al disco
rígido de su PC e instálelos. Luego conecte la
interfase y asegúrese de que la misma sea
reconocida por la computadora. En caso que
le diga que Windows encontró un nuevo dis-
positivo y le pregunte si quiere instalarlo auto-
máticamente, Ud. digale que NO, que va a
seleccionar los drivers desde una ubicación
específica. Luego localice dichos drivers (los
que Ud. descargó desde el link dado en nues-
tra página) y selecciónelos para que sean
reconocidos por la interfase.
Para comprobar que la
interfase está funcionando
correctamente vamos al ícono
de inicio de Windows/
Administrador de Sistemas,
aparecerá una lista de todos
los aditamentos que tiene en
la PC. Busque la opción de
puertos y selecciónela hacien-
do clic; deberá aparecer una
leyenda que diga: “Serial
USB Converter” y hacemos
doble clic sobre ella. También
puede hacer clic con el botón
derecho del mouse sobre el
2121Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
Figura 7
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 21
 
ícono de MI PC, seleccionar la opción
Propiedades, luego la ventana
Hardware y en ella: Administración de
Dispositivos (aparecerá la imagen de
la figura 7, en la que hemos desplegado
la opción “Puertos COM & LPT).
NOTA: Si no aparece la leyenda
“Serial USB Converter” significa que la
interfase no fue instalada correctamente
y deberá repetir el procedimento desde
el inicio.
Cuando haga doble clic sobre la
opción Serial USB Converter se abrirá
una ventana con la información de la
interfase, la cuál le dirá en qué puerto está
conectado el circuito que armó, por ejemplo:
COM1, COM2, COM3, etc. Es importante veri-
ficar en qué puerto está conectada la interfase
ya que será el mismo que deberá seleccionar
en el programa que utilice para la lectura de
códigos OBD desde el vehículo. Si el puerto
que aparece en la ventana no es COM1,
COM2 ó COM3, entonces seleccione la opción
“Selección de Puerto”, luego la opción “AVAN-
ZADO” y elija cualquiera de las 3 opciones
antes mencionada (figura 8). Luego presione
“Aceptar”. Debe hacer esto para que el pro-
grama de diagnóstico que usará para leer los
códigos de error pueden ofrecerle solamente
la opción de los tres puertos mencionados.
Importante: asegúrese que en la ventana
de selección de puertos figure la leyenda “este
puerto funciona correctamente”. Caso contra-
rio, vuelva a repetir todo el procedimiento
desde el inicio.
Una vez que está todo correcto estamos
seguros de que la interfase fue conectada
correctamente y ahora podremos utilizar cual-
quier programa de diagnóstico, como el
Scantool, el Scan Master, etc.
DEFINICIÓN DE OBD II
Pretendemos que el lector tenga los ele-
mentos suficientes para poder encarar el diag-
nóstico de fallas en un vehículo mediante la
lectura de códigos DTC, gracias al sistema
OBD II. OBD (On Board Diagnostics) es un sis-
tema de diagnóstico a bordo en vehículos
(coches y camiones) empleado mundialmente
y con protocolos de comunicación normaliza-
dos para vehículos fabricados a partir de 2008.
Sin embargo, este sistema data de muchos
años antes, ya que en 1994 se fabricaban
automóviles con computadoras de a bordo
pero que se comunicaban con el escáner por
medio de distintos protocolos. En este artículo
veremos qué es OBD II, cuáles son los dife-
rentes protocolos empleados y qué caracterís-
ticas debe reunir un escáner para que pueda
ser empleado en la mayoría de los vehículos.
Tal como mencionamos al comienzo de
este capítulo, OBD (On Board Diagnostics) es
un sistema de diagnóstico a bordo en vehícu-
los (coches y camiones). Actualmente se
emplea OBD-II (Estados Unidos), EOBD
(Europa) y JOBD (Japón), estándar que apor-
tan un control casi completo del motor y otros
dispositivos del vehículo.
OBD I fue la primera regulación de OBD
que obligaba a los productores a instalar un
sistema de monitoreo de algunos de los com-
ponentes controladores de emisiones en auto-
móviles. Obligatorios en todos los vehículos a
partir de 1991, los sistemas de OBD I no eran
tan efectivos porque solamente monitoreaban
algunos de los componentes relacionados con
las emisiones, y no eran calibrados para un
nivel específico de emisiones.
OBD II es la abreviatura de On Board
Diagnostics (diagnóstico de a bordo) II, la
Electrónica del Automóvil
2222 Escáners e Interfases OBD II
Figura 8
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 22
 
segunda generación de los requerimientos del
equipamiento autodiagnosticable de a bordo
de los Estados Unidos de América. La deno-
minación de este sistema se desprende de
que el mismo incorpora dos sensores de oxí-
geno (sonda Lambda) uno ubicado antes del
catalizador y otro después del mismo, pudien-
do así comprobarse el correcto funcionamien-
to del catalizador. 
Las características de autodiagnóstico de a
Bordo están incorporadas en el hardware y el
software de la computadora de a bordo de un
vehículo para monitorear prácticamente todos
los componentes que pueden afectar las emi-
siones. Cada componente es monitoreado por
una rutina de diagnóstico para verificar si está
funcionando perfectamente. Si se detecta un
problema o una falla, el sistema de OBD II ilu-
mina una lámpara de advertencia en el cuadro
de instrumentos para avisarle al conductor. La
lámpara de advertencia normalmente lleva la
inscripción "Check Engine" o "Service Engine
Soon". 
El sistema también guarda informaciones
importantes sobre la falla detectada para que
un mecánico pueda encontrar y resolver el
problema. En los Estados Unidos de América,
todos los vehículos de pasajeros y los camio-
nes de gasolina y combustibles alternos a par-
tir de 1996 deben contar con sistemas de OBD
II, al igual que todos los vehículos de pasaje-
ros y camiones de diesel a partir de 1997.
Además, un pequeño número de vehículos de
gas fueron equipados con sistemas de OBD II.
Para verificar si un vehículo está equipado con
OBD II, busque las palabras OBD II en la eti-
queta de control de emisiones en el lado de
abajo de la tapa del motor o pregúntele a su
mecánico de confianza.
EOBD es la abreviatura deEuropean On
Board Diagnostics (diagnóstico de a Bordo
Europeo), la variación europea de OBD II. Una
de las diferencias es que no se monitorean las
evaporaciones del tanque. Sin embargo,
EOBD es un sistema mucho más sofisticado
que OBD II ya que usa "mapas" de las entra-
das a los sensores de diagnóstico basados en
las condiciones de operación del motor, y los
componentes se adaptan al sistema calibrán-
dose empíricamente. Esto significa que los
repuestos necesitan ser de alta calidad y espe-
cíficos para el vehículo y modelo.
OBD II EN LA ACTUALIDAD
Sabemos que los vehículos vienen equipa-
dos con computadoras. También sabemos que
las computadoras han evolucionado estos últi-
mos años de tal manera que la capacidad de
procesamiento de los últimos adelantos en
computación no tenían por qué ser ajenos a
los vehículos.
La diferencia entre OBD II y los sistemas
computarizados anteriores a 1996 consiste,
elementalmente, en que el sistema OBD II es
un sistema que generaliza la forma de leer los
códigos de la computadora de a bordo, lo que
quiere decir que no necesita adaptadores para
hacer la conexión, sin importar si los vehículos
son de fabricación nacional o extranjera; ni
tampoco andar rastreando por todo el vehícu-
lo tratando de ubicar el bendito conector que
sirve para apagar la luz de: "chequear el
motor", "servicio rápido", "check engine", etc.
A partir de enero de l996 se requiere que
los vehículos vendidos en muchos países de
la región sean compatibles con OBD II. La
mayoría de fabricantes de los Estados Unidos
ya venían equipando sus vehículos con OBD II
desde l994. La Agencia de Protección
Ambiental es la que impone normas y regula-
ciones para la protección del medio ambiente.
Los sistemas OBD II reúnen los requisitos
adecuados para monitorear y detectar fallas,
permanentes o intermitentes que podrían
hacer que un vehículo contamine el medio
ambiente. Almacena una gran cantidad de
códigos generales de problemas, junto con
códigos específicos de los fabricantes. Estos
códigos se clasifican en:
Código B Sistemas de la carrocería.
Código C Sistemas del chasis.
Código U Comunicaciones de la red.
Código P Sistemas del tren de potencia
(Motor y Transmisión).
Nota: Un motor controlado por una compu-
2323Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 23
 
tadora es similar al viejo motor no computari-
zado, debido a que el principio de combustión
interna es el mismo (pistones, bujías, válvulas,
cigueñal, árbol de levas, etc.). Igualmente los
sistemas de carga, arranque y encendido son
similares. En otras palabras, los probadores
de encendido, los medidores de compresión,
las bombas de vacío y las lámparas de sin-
cronización siguen siendo útiles.
Un escáner no precisa de ningún otro equi-
po o accesorio. Una interfase se usa en con-
junto con una computadora, la que tiene insta-
lado el programa que interpretará los códigos
leídos por la interfase. 
Existen escáners “originales” u oficiales
para cada marca de vehículo (y hasta para
determinados modelos) pero, en general, para
leer códigos de error se puede usar cualquier
sistema genérico. Debe tener en cuenta que
en muchos casos las computadoras de los
vehículos poseen llaves o restricciones (reali-
zadas por programación) para que sólo se
comuniquen con determinados tipos de equi-
pos y está en la habilidad del técnico para
decodificar dichas llaves a los efectos de no
necesitar equipos costosísimos y poder emple-
ar dispositivos genéricos como el que propo-
nemos armar en este artículo.
En la figura 9 podemos observar un escá-
ner o lector de códigos (auto scanner OBD II).
Este tipo de escáner no necesita batería, sólo
se acopla al conector del vehículo con un
cable como el de la figura 10 y se procede a
leer códigos. En la figura 11 se muestra un
ejemplo de dónde debe conectarse el cable en
un coche para poder realizar la lectura de
códigos.
Los códigos obtenidos deben ser
interpretados, en forma específica, recu-
rriendo al manual del vehículo ya que
cada fabricante programa su computado-
ra con sus propios códigos.
Esto podría ser un inconveniente pero
la ventaja es que en el tomo Nº65 del
Club SE nosotros dimos la interpretación
de los códigos y que en la red existen
direcciones de fácil acceso que tienen a
disposición del visitante bancos de datos
de estos códigos, totalmente gratis. En otras
palabras, cualquier persona puede acceder a
la lectura de códigos de su vehículo y encon-
trar la interpretación en la red. 
Para esto no necesita experiencia previa
(este conector suele estar ubicado a un lado
de la columna de dirección, abajo del tablero
de control).
Las normas exigen que en el caso de no
encontrarse el conector en esta ubicación, el
fabricante deberá pegar una etiqueta en este
lugar, indicando en qué lugar se encuentra.
Hasta aquí estamos de acuerdo en que el sis-
tema OBD II facilita la forma de acceder a los
códigos que almacena la computadora de a
bordo. Pero si usted cree que después de leer
Electrónica del Automóvil
2424 Escáners e Interfases OBD II
Figura 9
Figura 10
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 24
 
los códigos e interpretar su significado solucio-
nó su problema, se equivoca. Porque aquí es
donde se verá la sabiduría, experiencia, y
capacidad de discernimiento del mecánico.
Los códigos obtenidos con el lector electró-
nico sólo pueden servir de referencia debido a
lo siguiente:
* La computadora del sistema OBD II tiene
comunicación con el módulo de encendido y
con el módulo de la transmisión, lo que signifi-
ca que para efecto de activar uno de sus
actuadores, se vale de la información que tie-
nen estos módulos.
Si usted por alguna razón (por presumido)
cambió el tipo de llantas de su vehículo, la
computadora recibirá datos contradictorios
entre las vueltas de la transmisión y la revolu-
ción de las llantas.
Recuerde que el sistema OBD II lo que pre-
tende es optimizar el consumo de combustible
y para esto se vale de sensores colocados en
diferentes partes relacionadas al funciona-
miento del vehículo. Cualquier alteración de
los componentes del vehículo engañará a los
sensores y por lo tanto la información que reci-
be la computadora será falsa y falsa será la
interpretación y decisión que origine una orden
a cualquiera de los actuadores.
La computadora del sistema OBD II contro-
la el suministro de combustible, la velocidad de
marcha en vacío, el avance por vacío y los
controles de emisiones. En algunos casos las
computadoras de a bordo controlan la transmi-
sión, los frenos y el sistema de suspensión.
Los sensores instalados en los vehículos
son pequeños dispositivos que miden las con-
diciones de operación y las traducen en seña-
les que la computadora pueda entender. Por
ejemplo: sensores térmicos, (sensor de tempe-
ratura), potenciómetros (sensor de posición de
la válvula reguladora de aire), generador de
señales (sensor de oxígeno).
Los actuadores son dispositivos eléctricos
que pueden ser activados por la computadora.
Entre éstos se incluyen los solenoides y relés.
Los sensores, actuadores, generadores de
señales y potenciómetros no son baratos. 
Si usted decide cambiarlos debe estar
seguro de que realmente están defectuosos y
que la falla no venga de una mala conexión,
cableado flojo o un mal funcionamiento del
motor, originado por falla mecánica básica
(bujías, cables, tapa rotor, empaques, bombas,
bandas o correas, etc.).
En conclusión: el sistema OBD II generali-
za y facilita la forma de leer códigos almace-
nados en la computadora de a bordo, pero es
el mecánico el encargado de analizar estos
códigos, para discernir y encontrar la razón u
origen del problema de un motor, una trans-
misión, o un sistema de frenos.
Los sistemas computarizados de los vehí-
culos actuales, aparte de controlar las opera-
ciones del motor, también pueden ayudarlo a
encontrar problemas.
Estas computadoras han sido programadas
con habilidades especiales de prueba. Estas
pruebas verificanlos componentes conecta-
dos a la computadora que se usan para sumi-
nistro de combustible, control de velocidad de
marcha en vacío, sincronización de encendido,
sistemas de emisión y cambios de marcha en
la transmisión.
La computadora de control del motor ejecu-
ta pruebas especiales que dependen del fabri-
cante, motor, año del modelo, etc. No existe
una prueba universal que sea la misma para
todos los vehículos.
Asimismo, con este sistema, puede borrar
los códigos almacenados y apagar la luz de
2525Capítulo 2
MONTAJE DE UNA INTERFASE OBD II CON ELM 327
Figura 11
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 25
 
advertencia después de atender los servicios
requeridos. Sólo tenga en cuenta que los lla-
mados códigos duros representan problemas
que volverán a manifestarse encendiendo la
luz si usted no soluciona el problema. Para
acceder a los códigos de la computadora, sólo
necesita un lector de códigos (escáner o scan-
ner OBD ll) o armarse un cable y bajar un pro-
grama a su PC. El precio promedio en el mer-
cado de este tipo de aparato es de aproxima-
damente 150 dólares americanos.
Igualmente en este rubro de lectores OBD
II, también existen a la venta scanners por un
precio similar que se pueden trabajar con pro-
gramas en la computadora de su casa y que le
permite hacer un examen minucioso de los
códigos y funcionamiento de la computadora
de a bordo. 
Como hemos dicho, cada marca y modelo
de coche emplea sus códigos y, por lo tanto,
presentarán diferentes interpretaciones aun-
que, en general, son siempre los mismos.
Existen códigos que son reservados por los
fabricantes. Igualmente, cuando un motor por
razones mecánicas, altera sus revoluciones, la
computadora detectará alteraciones de señal
en los sensores relacionados al sistema de
emisiones (humo). Esto no significa que los
sensores necesariamente deben cambiarse;
use el sentido común y tome como base su
experiencia en el funcionamiento básico del
motor.
COMPONENTES DE UN SISTEMA OBD II
En América Latina, a comienzos de este
siglo, las empresas automotrices comenzaron
a aplicar este sistema en la mayoría de las uni-
dades fabricadas y podemos afirmar que en la
actualidad casi la totalidad de unidades cuen-
tan con sistemas de diagnóstico a bordo
(OBD).
Se entiende que periódicamente pueden
generarse y aprobarse nuevos códigos de
diagnóstico [DTCs]. Al ocurrir esto, los conjun-
tos lógicos del escáner OBD II o de la interfa-
se, serán actualizados. 
No hay un período de tiempo establecido
para la actualización de la base de datos.
El sistema OBD II nos permite leer códigos
con facilidad, pero eso no soluciona el proble-
ma; los códigos mencionan áreas con sus res-
pectivos sensores, pero no es cambiando los
sensores como se arreglará el problema.
El sistema OBD II está compuesto de un
procesador de datos o computador y un grupo
de sensores y actuadores. Por lo regular la
computadora controla un tipo de corriente que
circula por el sensor, la cual genera una ten-
sión que se mide en milivolt. 
Básicamente el funcionamiento es el
siguiente: Cuando el motor está frío, al activar
la llave de encendido la computadora activa su
función en el modo de open loop (circuito
abierto) permitiendo que el motor funcione.
Desde este momento la computadora se man-
tiene pendiente esperando la señal del sensor
de temperatura y del sensor de oxígeno.
En cuanto el motor se calienta la señal del
sensor de temperatura hace que la computa-
dora cierre el circuito (close loop) pasando su
función al modo de "control". Desde este
momento, la computadora lee la señal del sen-
sor de oxígeno, y chequea las alteraciones del
voltaje de referencia que entregan cada uno
de los otros sensores.
Como el sensor de oxígeno instalado en el
manifold de escape (o en alguna parte del tubo
de escape en su recorrido hacia el exterior)
genera su propio voltaje, la computadora
interpreta la lectura de este sensor, determi-
nando si los residuos son consecuencia de
mezcla rica o pobre.
Los sensores reciben una señal de voltaje
como referencia básica, las alteraciones a este
voltaje la computadora también los interpreta
de acuerdo con su programa interno; los com-
para, y siguiendo su lógica de funcionamiento,
puede hacer uso de sus actuadores (solenoi-
des) para alterar o corregir el balance de la
mezcla aire/gasolina que ingresa a la cámara
de combustión; así como mover el avance o
retardo del tiempo de encendido con la pre-
tensión básica de eliminar al máximo las emi-
Electrónica del Automóvil
2626 Escáners e Interfases OBD II
 Cap 2 Interfase OBD II 2/7/11 5:08 PM Página 26
 
siones contaminantes; sin disminuir la poten-
cia que el vehículo requiere para su desplaza-
miento y autonomía. 
El funcionamiento básico del motor es el
mismo… los conductores o choferes seguire-
mos siendo los mismos… nuestra inclinación a
seguir malos hábitos de manejo seguirán sien-
do los mismos… si a ello le sumamos la pobre-
za de mantenimiento, sea por descuido, o falta
de mecánicos especializados; estaremos de
acuerdo en que las posibilidades de contami-
nar el medio ambiente son altas.
El sistema OBD II pretende corregir este
problema colocando sensores y actuadores en
diferentes partes del motor y/o transmisión así
como en diferentes partes del vehículo que
ayuden a que la unidad se desplace funcio-
nando y consumiendo estrictamente lo nece-
sario; tratando de eliminar cualquier residuo
que se considere contaminante al medio
ambiente. En otras palabras, la computadora
corrige las deficiencias consecuentes de un
mal hábito de manejo, así como alerta al con-
ductor cuando, por razones lógicas, no puede
corregir el problema debido a fugas o cortocir-
cuitos, en los componentes electrónicos y/o
problemas de funcionamiento básico del
motor.
El sistema OBD II necesita una computa-
dora central y según se requiera también
puede poseer módulos auxiliares, los cuales
pueden estar enlazados a dicho procesador
central.
Como aquí tratamos de simplificar el enten-
dimiento, podemos decir que un vehículo tiene
componentes en diferentes áreas, los mismos
que sincronizan su funcionamiento logrando
con ésto que el vehículo se desplace pero un
problema en alguno de estos componentes da
como resultado un bajo rendimiento del com-
bustible y, en consecuencia, los residuos con-
taminantes serán altos.
El sistema OBD II monitorea las áreas
donde tiene instalados sensores, administra
voltaje en sensores y actuadores; pero no
detecta ni tiene códigos para acusar un motor
roto, una bujía quebrada o desconectada, ni
tampoco, puede detectar un manifold flojo o
quebrado, así como gasolina u aceite contami-
nado. El problema es el mismo en los frenos
y/o transmisión. 
En otras palabras, el entendimiento y
seguimiento de diagnóstico en un sistema
OBD II tiene como base previa, un conoci-
miento avanzado de lo que es un sistema de
encendido: mezcla de combustible, medidas
de presión y/o vacío dentro del manifol de
admisión, así como conocer perfectamente el
funcionamiento básico del motor y/o las medi-
das de presión en el sistema de enfriamiento
del motor y/o escape.
¿Cómo seguir un diagnóstico en forma lógi-
ca?
Antes de continuar tome nota de lo siguien-
te: No haga pruebas ni conexiones entre la
corriente de la batería y las conexiones que
administra la computadora; podría quemar cir-
cuitos o componentes. La computadora admi-
nistra una corriente atenuada de bajo ampera-
je y sólo puede ser testeada por aparatos o
probadores de bajo amperaje que miden el
voltaje en milivolt. El mercado está inundado
de aparatos o dispositivos que se presentan
como solución al diagnóstico automotriz; cada
quien defiende su producto destacando sus
ventajas particulares pero a usted le toca
defender su economía. Es oportuno tener en
cuenta la velocidad o facilidad con la que un
aparato de éstos se discontinúa o pierde
actualización, dejando su inversión en el nivel
de "gasto no recuperable".
Volviendo al sistema de funcionamiento
básico del motor, el sistema OBD II monito-