CENTRO DE FORMACIÓN PROFESIONAL

DE YUCATÁN
UNIVERSIDAD MAYA MÉRIDA

TRANSMICIÓN DE DATOS MULTIPLEZADOS

TRABAJO:

ACTIVIDAD 6

NOMBRE DEL DOCENTE:

MAESTRO JORGE REMIGIO HUCHIM YAM

GRADO Y GRUPO:

6-B

NOMBRE DEL ALUMNO

DZUL POOT DANIEL ALBERTO

MÉRIDA, YUCATÁN, MÉXICO

2022
 ACTIVIDAD 6: PROTOCOLO OBD II
CONTENIDO DEL INSTRUMENTO DE EVALUACIÓN

TEORÍA

El protocolo, se define como las reglas para la transmisión de la información entre dos
puntos. Un protocolo de red de comunicación de datos es un conjunto de reglas que
gobierna el intercambio ordenado de datos dentro de la red.

Los elementos básicos de un protocolo de comunicaciones son: un conjunto de símbolos

llamados conjunto de caracteres, un conjunto de reglas para la secuencia y sincronización
de los mensajes construidos a partir del conjunto de caracteres y los procedimientos para
determinar cuando ha ocurrido un error en la transmisión y como corregir el error. El
conjunto de caracteres se formará de un subconjunto con significado para las personas
(usualmente denominado como caracteres imprimibles) y otro subconjunto que transmite
información de control (usualmente denominado caracteres de control).

INSTRUCCIONES I: REALIZAR UNA INVESTIGACIÓN COMPLETA DEL PROTOCOLO OBD II Y

REALIZA UN INFORME. EL TRABAJO DEBE CONTENER LO SIGUIENTE:

1. Historia.

2. Normas y estándares.

3. Modos de funcionamiento.

4. Estructura de la trama.

5. Conclusión
Es posible que hayas encontrado los términos "OBD" u "OBDII" al leer sobre los vehículos
conectados y el dispositivo GO de Geotab. Estas funciones forman parte de los
ordenadores de a bordo de los coches y tienen una historia que no es muy conocida. En
este artículo te presentamos una visión general del OBDII y una cronología de su
desarrollo.

QUÉ ES EL OBD (DIAGNÓSTICO A BORDO)

El diagnóstico a bordo (OBD) se refiere al sistema electrónico de automoción que

proporciona el autodiagnóstico del vehículo y las capacidades de información para los
técnicos de reparación. Un OBD permite a los técnicos acceder a la información de los
subsistemas con el fin de controlar el rendimiento y analizar las necesidades de reparación.
OBD es el protocolo estándar utilizado en la mayoría de los vehículos ligeros para recuperar
la información de diagnóstico del vehículo. La información la generan las unidades de
control del motor (ECU o módulos de control del motor) dentro de un vehículo. Son como
los ordenadores o el cerebro del vehículo.

¿POR QUÉ ES TAN IMPORTANTE?

OBD es una parte importante de la telemática y la gestión de flotas, ya que permite medir y
gestionar el estado y la conducción de los vehículos. Gracias al OBD, las flotas pueden:

 Seguir las tendencias de desgaste y ver qué piezas del vehículo se desgastan más
rápido que otras.
 Diagnosticar instantáneamente los problemas del vehículo antes de que se
produzcan, apoyando una gestión proactiva en lugar de reactiva.
 Medir el comportamiento de la conducción, la velocidad, el tiempo de ralentí y
mucho más.

¿DÓNDE SE ENCUENTRA EL PUERTO OBDII?

En un vehículo de pasajeros típico, el puerto OBDII se encuentra en la parte inferior del

salpicadero en el lado del conductor del coche. Según el tipo de vehículo, el puerto puede
tener una configuración de 16, 6 o 9 pines.
¿CUÁL ES LA DIFERENCIA ENTRE UN OBD Y UN OBDII?

Un OBDII es, en pocas palabras, la segunda generación de un OBD u OBD I. El OBD I estaba,
en un principio, conectado de manera externa a la consola de un coche, mientras que el
OBDII está ahora integrado dentro del propio vehículo. El OBD original se utilizó hasta que
se inventó el OBDII a principios de los años 90.

HISTORIA DEL OBDII

La historia de los diagnósticos a bordo se remonta a los años 60. Varias organizaciones
sentaron las bases de la norma, entre ellas la Junta de Recursos del Aire de California
(CARB), la Sociedad de Ingenieros del Automóvil (SAE), la Organización Internacional de
Normalización (ISO) y la Agencia de Protección del Medio Ambiente (EPA). Es importante
señalar que antes de la normalización, los fabricantes creaban sus propios sistemas. Las
herramientas de cada fabricante (y a veces los modelos del mismo fabricante) tenían su
propio tipo de conector, requisitos de la interfaz electrónica. También utilizaban sus
propios códigos personalizados para informar de los problemas.

HECHOS DESTACADOS EN LA HISTORIA DEL OBD

 1968 — Volkswagen presentó el primer sistema informático OBD con capacidad de

escaneo.
 1978 — Datsun presentó un sistema OBD sencillo con capacidades limitadas no
estandarizadas.
 1979 — La Sociedad de Ingenieros de Automoción (SAE) recomienda un conector
de diagnóstico estandarizado y un conjunto de señales de prueba de diagnóstico.
 1980 — GM presentó una interfaz y un protocolo propios capaces de proporcionar
diagnósticos del motor a través de una interfaz RS-232 o, más sencillamente,
haciendo parpadear la luz de revisión del motor.
  1988 — La estandarización de los diagnósticos de a bordo llegó a finales de la
década de 1980 tras la recomendación de la SAE de 1988, que pedía un conector y
un conjunto de diagnósticos estándar.
 1991 — El estado de California exigió que todos los vehículos tuvieran algún tipo de
diagnóstico básico a bordo. A esto se le conoce como OBD I.
 1994 — El estado de California ordenó que todos los vehículos vendidos en el
estado a partir de 1996 tuvieran OBD según lo recomendado por SAE, ahora
denominado OBDII, para poder realizar pruebas de emisiones de forma
generalizada. El OBDII incluía una serie de códigos de problemas de diagnóstico
(DTC) estandarizados.
 1996 — El OBD-II es obligatorio para todos los coches fabricados en Estados Unidos.
 2001 — El EOBD (la versión europea del OBD) pasa a ser obligatorio para todos los
vehículos de gasolina de la Unión Europea.
 2003 — El EOBD pasa a ser obligatorio para todos los vehículos diésel de la UE.
 2008 — A partir de 2008, todos los vehículos de los Estados Unidos están obligados
a implementar el OBDII a través de una Red de Área de Controladores, tal y como
se especifica en la norma ISO 15765-4.

NORMAS Y ESTÁNDARES.
ESTÁNDARES SAE SOBRE OBD-II

 J1113 – Procedimientos de medición de susceptibilidad electromagnética de

componentes en el vehículo
 J1211 – Procedimientos y recomendaciones para diseño de equipo electrónico
 J1213 – Glosario de términos para redes vehiculares
 J1547 – Procedimientos de medición de susceptibilidad electromagnética de
componentes de inyección de modo común
 J1699 – Pruebas de cumplimiento y métodos de prueba para SAE J1850
 J1850 – Define el protocolo serial de datos. Hay dos variantes 10.4 kbit/s (un cable,
VPW) y 41.6 kbit/s (dos cables, PWM). Mayormente usado por fabricantes USA, PCI
(Chrysler, 10.4 kbit/s), Class 2 (GM, 10.4 kbit/s), y SCP (Ford, 41.6 kbit/s)
 J1879 – Calificación general y criterios de aceptación de producción para circuitos
integrados en aplicaciones automotrices
 J1930-DA Comunicación entre el vehículo y equipo externo para diagnóstico de
emisiones. Guia de términos, definiciones, abreviaciones y acrónimos; DA es un
anexo listado en formato digital. Técnicamente equivalente al ISO15031-2
 J1939 - comunicación en vehículos de carga pesada
 J1962 – Define el conector físico para la interface OBD-III
 J1978 – Defines estándares de operación mínimos para herramientas de escaneo
OBD-II
 J1979 – Define estándares para servicios o modos de PIDs del $01 al $0A
 J1979-DA Modos de Prueba. DA es un anexo listado en formato digital.
Técnicamente equivalente al ISO15031-5
 J2008 – Organización recomendada para la información de servicio del vehiculo
 J2012 – Define códigos de problema estándar y definiciones (del inglés DTC
diagnostic Trouble Codes). Técnicamente equivalente al ISO15031-6 y en partes al
ISO27145-2. El estándar con –DA es un anexo con el listado en formato digital
 J2178 Mensajes de comunicación de datos por red clase B en formato serial para
sistemas automotrices
 J2178-1 – Define estándar para formatos de encabezado de mensaje de red y
asignación de dirección física
 J2178-2 – Da definiciones de parámetros de datos
 J2178-3 – Define estándares para IDs de cuadros de mensajes de red para
encabezados de un solo byte (del inglés frame IDs for single-byte forms of headers)
 J2178-4 – Define estándar para mensajes de red con encabezados de tres bytes
 J2186 – Seguridad de Datos. Este estándar estable una práctica uniforme para
proteger los módulos computarizados del vehículo contra accesos no autorizados a
 través del conector de datos del vehículo. Los módulos en cuestión son los que
tienen alguna memoria cuyo contenido puede ser accesado o alterado a través del
conector de datos.
 J2190 – Define modos de prueba extendidos, cubriendo modos de prueba
relacionados con emisiones y otros no relacionados. Este estándar estaba
intencionado a suplementar SAE J1979, sin embargo fue cancelado en 2008 por
poco uso. Algunos estándares cubren partes del mismo
 J2205 – Protocolos expandidos de diagnóstico para herramientas de escaneo
 J2284-3 – Define la capa física y de enlace de datos del CAN de 500 kbit/s
 J2300 – Procedimientos de cumplimientos de pruebas de herramientas de
diagnósticos
 J2411 – Define el protocolo GMLAN (CAN de un solo cable) usado en los vehículos
GM nuevos. Frecuentemente accesible en el conector OBD como pin 1 en los autos
nuevos GM
 J2534 – Practicas Recomendadas para reprogramación de vehículos.

ESTÁNDARES ISO
 ISO 9141: Sistemas de diagnóstico, ISO 1989
Parte 1: Requerimientos para el intercambio de información digital
Parte 2: Requerimientos CARB (California Air Resources Board ) para el intercambio
de información digital. Sistemas de diagnóstico para intercambio de información
serial asíncrono, similar al RS232 y al ISO15031-5
Parte 3: Verificación de la comunicación entre el vehículo y la herramienta de
escaneo OBII
 ISO 11898: Controller area network (CAN). ISO, 2003.
Parte 1: Señalización en la capa física y de enlace de datos
Parte 2: Unidad de medio de acceso de alta velocidad
Parte 3: Interface dependiente del medio, tolerante a errores, de baja velocidad
Parte 4: comunicación disparada por tiempo
 ISO 14229: Servicios de diagnóstico unificado (del inglés UDS Unified Diagnostic
Services) en vehículos terrestres. ISO, 2013
Parte 1: Especificaciones y Requerimientos
Parte 2: Servicios de capa de sesión. Se relaciona para OBD con los protocolos ISO
15765-4 DoCAN e ISO 14230-4 DoK-Line
 Parte 3: UDS en implementaciones sobre CAN (UDSonCAN)
Parte 4: UDS en implementaciones en FlexRay (UDSonFR)
Parte 5: UDS en implementaciones sobre internet (UDSonIP)
Parte 6: UDS en implementaciones de línea K (UDSonK-Line)
Parte 7: UDS en implementaciones sobre Redes Locales (UDSonLAN)
 ISO 14230: sistemas de diagnóstico, protocolo de palabras clave, ISO, 2013.
Parte 1: Capa física
Parte 2: Capa de enlace de datos utilizando línea K (DoK-Line)
Parte 3: Capa de aplicación KWP2000
Parte 4: Requerimientos para sistemas relacionados con emisiones. DoK-Line
diagnóstico sobre línea K o KWP2000,similar al ISO9141-2
 ISO 15031: Comunicación entre vehículos y equipo externo para diagnósticos
relacionados con emisiones, ISO, 2010.
Parte 1: Información general y definición de casos de uso
Parte 2: Guia en el uso de términos, definiciones, abreviaciones y acrónimos.
Técnicamente equivalente al SAE J1930-DA
Parte 3: conector de diagnóstico y circuitos eléctricos relacionados,
especificaciones y usos
Parte 4: Equipo de prueba externo
Parte 5: Servicios de diagnóstico relacionados con emisiones. Modos de prueba.
Técnicamente similar al SAE J1850.
Parte 6: Definiciones de códigos de diagnóstico (del inglés DTC diagnostic Trouble
Codes). Técnicamente equivalente al SAE J2012-DA
Parte 7: Seguridad del enlace de datos
 ISO 15765: Diagnósticos en sistemas Controller Area Networks (del inglés DoCAN
Diagnostic communication over Controller Area Network) ISO 2004
Parte 1: Información General
Parte 2: Servicios de capa de red (del inglés Transport protocol and network layer
services)
Parte 3: Implementación de servicios unificados de diagnóstico (UDS on CAN)
Parte 4: Requerimientos para sistemas relacionados con emisiones DoCAN
diagnostico sobe CAN. Modos o servicios de prueba del $01 al $0A
 ISO 27145: Implementación del diagnóstico armonizado mundial buscando una
sola regulación (del inglés World Wide Harmonized On board Diagnostics WWH-
OBD). ISO 2012
Parte 1: Información General y definición de casos de uso
Parte 2: Diccionario de Datos (códigos) Común
Parte 3: Diccionario de mensajes comunes
Parte 4: Conexión entre el vehículo y equipos de prueba
Parte 5: cumplimiento de aplicaciones del vehículo y de sistemas que lean códigos
 Parte 6: Equipo de prueba externo (requerimientos)

¿CÓMO FUNCIONA EL SISTEMA OBD2 DE UN AUTO?

El sistema OBD2 emite una alerta al conductor cuando el nivel de las emisiones de gases
son 1.5 superior al de los parámetros establecidos. Adicionalmente, el OBD2 comprueba
que todos los sensores involucrados en las emisiones de gases funcionen bien, como la
entrada de aire al motor o la inyección. Por ejemplo, los sensores de oxígeno que están
ubicados antes y después del catalizador, deben certificar el buen funcionamiento químico
del mismo. Cuando el sistema OBD2 encuentra una falla en el vehículo inmediatamente
enciende la luz de falla, llamada MIL (siglas en inglés para Malfunction Indication Lamp) o
Lámpara de indicación de mal funcionamiento en el cuadro de instrumentos.

Para que puedas conocer cuál es la estructura de los códigos OBD2, hoy te traemos este
articulo donde estaremos explicando carácter por carácter el código DTC.
Poder interpretar estos códigos son de una gran ayuda para el mecánico o técnico para
que pueda encontrar o diagnosticar la falla del vehículo.
Es importante destacar que estos códigos OBDII se basan respetando la norma SAE, y este
hace referencia a la combinación de letras y números, dando a resaltar que la letra
especifica una o varias partes físicas del vehículo y los números que arroja la computadora
de a bordo informan o determinan la falla respectiva que está ocurriendo.
Ahora tomemos por ejemplo el código DTC P0301. La descripción de este código nos
indica que hay un fallo de encendido en el cilindro 1.

Entonces, el primer digito de nuestro ejemplo muestra al sistema del tren de potencia, por
la descripción de la información que nos da los caracteres P, B, C y U.
P – POWERTRAIN / Tren de potencia.
B – BODY / Cuerpo.
C – CHASSIS / Chasis.
U – NETWORK / Red.
El segundo digito del código nos indica que es genérico, lo que significa que aplica a
cualquier marca y modelo de vehículo.
0 – GENERIC (SAE) / Genérico.
1 – MANUFACTURER SPECIFIC / Específico del fabricante.
El tercer digito muestra la categoría del código, en este caso, al sistema de ignición o falla
de encendido ya que es el numero 3.
1 – FUEL AND AIR METERING / Medición de combustible y aire.
2 – FUEL AND AIR METERING (INJECTOR CIRCUIT MALFUNCTIONS ONLY) / Medición de
combustible y aire (Sólo fallas en el circuito del inyector).
3 – IGNITION SYSTEM OR MISFIRE / Sistema de ignición o fallo de encendido.
4 – AUXILIARY EMISSION CONTROLS / Controles de la emisión auxiliar.
5 – VEHICLE SPEED CONTROL AND IDLE CONTROL SYSTEM / Control de velocidad del
vehículo y sistema de control de riesgo.
6 – COMPUTER AND AUXILIARY AUTPUTS / salidas de la computadora (EMC) y auxiliares.
7 – TRANSMISSION / Transmisión.
8 – TRANSMISSION / Transmisión.
Por último, los dos dígitos restantes señalan la falla especifica la cual te indica la
descripción del código dtc
SPECIFIC FAULT INDEX / Indice de fallas específico.

CRECIMIENTO MÁS ALLÁ DE OBDII

El OBDII contiene 10 modos estándar para conseguir la información de diagnóstico que
requieren las normas de emisiones. El problema es que estos 10 modos no han sido
suficientes.
A lo largo de los años, desde la implantación del OBDII, se han desarrollado varios modos
de UDS para enriquecer los datos disponibles. Cada fabricante de vehículos utiliza sus
propios PID y los implementa mediante modos UDS adicionales. La información que no era
necesaria a través de los datos OBDII (como el cuentakilómetros y el uso del cinturón de
seguridad) pasó a estar disponible a través de los modos UDS.
La realidad es que el UDS contiene más de 20 modos adicionales, además de los actuales
10 modos estándar disponibles a través del OBDII, lo que significa que el UDS tiene más
información disponible. Pero ahí es donde entra el WWH-OBD, que busca incorporar los
modos UDS con OBDII para enriquecer los datos disponibles para el diagnóstico, sin dejar
de mantener un proceso estandarizado.

CONCLUSIÓN
En el creciente mundo del IoT, el puerto OBD sigue siendo importante para el estado, la
seguridad y la sostenibilidad de los vehículos. Aunque el número y la variedad de
dispositivos conectados para los vehículos aumenta, no todos los dispositivos dan y hacen
un seguimiento de la misma información. Además, la compatibilidad y la seguridad
pueden variar de un dispositivo a otro.
Con la multitud de protocolos OBD, no todas las soluciones telemáticas están diseñadas
para funcionar con todos los tipos de vehículos que existen actualmente. Las buenas
soluciones telemáticas deben ser capaces de entender y traducir un conjunto completo de
códigos de diagnóstico del vehículo.