Los PID OBD-II ( ID de parámetros de diagnóstico a bordo ) son códigos que se utilizan para solicitar datos de un vehículo y se utilizan como herramienta de diagnóstico.
La norma SAE J1979 define muchos PID OBD-II. Todos los vehículos y camiones de carretera que se venden en Norteamérica deben admitir un subconjunto de estos códigos, principalmente para las inspecciones de emisiones obligatorias por el estado . Los fabricantes también definen PID adicionales específicos para sus vehículos. Aunque no es obligatorio, muchas motocicletas también admiten PID OBD-II.
En 1996, los vehículos livianos (menos de 8500 lb o 3900 kg) fueron los primeros en ser obligatorios, seguidos por los vehículos medianos (8500–14 000 lb o 3900–6400 kg) en 2005. [1] Se requiere acceder a ambos a través de un conector de enlace de datos estandarizado definido por SAE J1962 .
Los vehículos pesados (de más de 14 000 lb o 6400 kg) fabricados después de 2010 [1] , que se venden en los EE. UU., pueden admitir diagnósticos OBD-II a través del estándar SAE J1939-13 (un conector de diagnóstico redondo) de acuerdo con CARB en el título 13 CCR 1971.1. Algunos camiones pesados en América del Norte utilizan el conector de diagnóstico OBD-II SAE J1962 que es común en los automóviles de pasajeros, en particular Mack y Volvo Trucks, sin embargo, utilizan identificadores CAN de 29 bits (a diferencia de los encabezados de 11 bits que utilizan los automóviles de pasajeros).
En la última norma OBD-II SAE J1979 se describen 10 servicios de diagnóstico. Antes de 2002, la norma J1979 se refería a estos servicios como "modos". Son los siguientes:
Los fabricantes de vehículos no están obligados a ofrecer todos los servicios. Cada fabricante puede definir servicios adicionales por encima del n.° 9 (por ejemplo, el servicio 22 según lo definido por SAE J2190 para Ford/GM, el servicio 21 para Toyota) para otra información, por ejemplo, el voltaje de la batería de tracción en un vehículo eléctrico híbrido (HEV). [2]
Los servicios UDS que no son OBD comienzan en 0x10 para evitar la superposición del rango de ID.
La siguiente tabla muestra los PID estándar de OBD-II según lo definido por SAE J1979. Se proporciona la respuesta esperada para cada PID, junto con información sobre cómo traducir la respuesta en datos significativos. Nuevamente, no todos los vehículos admitirán todos los PID y puede haber PID personalizados definidos por el fabricante que no estén definidos en el estándar OBD-II.
Tenga en cuenta que los servicios 01 y 02 son básicamente idénticos, excepto que el servicio 01 proporciona información actual, mientras que el servicio 02 proporciona una instantánea de los mismos datos tomados en el momento en que se estableció el último código de diagnóstico de problemas. Las excepciones son PID 01, que solo está disponible en el servicio 01, y PID 02, que solo está disponible en el servicio 02. Si el PID 02 del servicio 02 devuelve cero, entonces no hay instantánea y todos los demás datos del servicio 02 no tienen sentido.
Al utilizar la notación codificada por bits, cantidades como C4 significan el bit 4 del byte de datos C. Cada bit está numerado del 0 al 7, por lo que 7 es el bit más significativo y 0 es el bit menos significativo (ver a continuación).
El servicio 02 acepta los mismos PID que el servicio 01 , con el mismo significado [5], pero la información proporcionada corresponde al momento en que se creó el cuadro congelado [6] . Tenga en cuenta que el PID $02 se utiliza para obtener el DTC que activó el cuadro congelado.
La persona debe enviar el número de cuadro en la sección de datos del mensaje.
0F 19, A = 0Fy B = 19. Donde aparece un (?), se dispone de información contradictoria o incompleta.Algunos de los PID de la tabla anterior no se pueden explicar con una fórmula sencilla. A continuación se ofrece una explicación más detallada de estos datos:
Una solicitud de este PID devuelve 4 bytes de datos ( Big-endian ). Cada bit, desde MSB hasta LSB , representa uno de los siguientes 32 PID y especifica si se admite ese PID.
Por ejemplo, si la respuesta del automóvil es BE1FA813 , se puede decodificar de la siguiente manera:
Por lo tanto, los PID admitidos son: 01 , 03 , 04 , 05 , 06 , 07 , 0C , 0D , 0E , 0F , 10 , 11 , 13 , 15 , 1C , 1F y 20.
Una solicitud de este PID devuelve 4 bytes de datos, etiquetados A, B, C y D.
El primer byte (A) contiene dos datos. El bit A7 ( MSB del byte A) indica si la luz indicadora de mal funcionamiento (MIL, por sus siglas en inglés) está encendida o no. Los bits A6 a A0 representan la cantidad de códigos de diagnóstico de problemas que se encuentran actualmente marcados en la ECU.
El segundo, tercer y cuarto bytes (B, C y D) proporcionan información sobre la disponibilidad y la integridad de ciertas pruebas a bordo ("verificaciones de preparación OBD"). El tercer y cuarto bytes se deben interpretar de manera diferente según si el motor es de encendido por chispa (por ejemplo, motores Otto o Wankel) o de encendido por compresión (por ejemplo, motores diésel). En el segundo byte (B), el bit 3 indica el tipo de motor y, por lo tanto, cómo interpretar los bytes C y D, donde 0 es de encendido por chispa (Otto o Wankel) y 1 (configurado) es de compresión (diésel). Los bits B6 a B4 y B2 a B0 se utilizan para obtener información sobre pruebas que no son específicas del tipo de motor y, por lo tanto, se denominan pruebas comunes . Tenga en cuenta que para los bits que indican la disponibilidad de la prueba, un bit configurado en 1 indica que está disponible, mientras que para los bits que indican la integridad de la prueba, un bit configurado en 0 indica que está completa.
Los bits del byte B que representan indicadores de prueba comunes (aquellos que no son específicos del tipo de motor) se asignan de la siguiente manera:
Los bytes C y D se asignan de la siguiente manera para los tipos de motores de encendido por chispa (por ejemplo, motores Otto o Wankel):
Los bytes C y D se asignan alternativamente de la siguiente manera para los tipos de motores de encendido por compresión (motores diésel):
Una solicitud de este PID devuelve 4 bytes de datos. Los datos devueltos tienen un formato idéntico al devuelto para el PID 01 , con una excepción: el primer byte siempre es cero.
Una solicitud de uno de estos dos PID devolverá 9 bytes de datos. El PID 78 devuelve datos relacionados con los sensores EGT para el banco 1, mientras que el PID 79 devuelve de manera similar datos para el banco 2. El primer byte es un campo codificado en bits que indica qué sensores EGT son compatibles con el banco respectivo.
El primer byte está codificado en bits de la siguiente manera:
Los bytes B a I proporcionan números enteros de 16 bits que indican las temperaturas de los sensores. Los valores de temperatura se interpretan en grados Celsius en el rango de -40 a 6513,5 (escala 0,1), utilizando la fórmula habitual (MSB es A, LSB es B). Solo son significativos los valores para los que se admite el sensor correspondiente.
Una solicitud de este servicio devuelve una lista de los DTC que se han configurado. La lista está encapsulada mediante el protocolo ISO 15765-2 .
Si hay dos o menos DTC (hasta 4 bytes), se devuelven en un único marco ISO-TP (SF). Tres o más DTC de la lista se informan en varios marcos, y el recuento exacto de marcos depende del tipo de comunicación y los detalles de direccionamiento.
Cada código de problema requiere 2 bytes para su descripción. En estos bytes se codifican una categoría y un número. Normalmente se muestra decodificado en un formato de cinco caracteres como " U0158 ", donde el primer carácter (aquí 'U') representa la categoría a la que pertenece el DTC y los cuatro caracteres restantes son una representación hexadecimal del número de esa categoría. Los dos primeros bits ( A7 y A6 ) del primer byte (A) representan la categoría. Los 14 bits restantes representan el número. Cabe destacar que, dado que el segundo carácter está formado por solo dos bits, solo puede estar dentro del rango de 0 a 3 .
Un ejemplo de DTC de " U0158 " se decodificaría de la siguiente manera:
El código de cinco caracteres resultante, por ejemplo, " U0158 ", se puede buscar en una tabla de DTC OBD-II para obtener una descripción real de lo que representa. Cabe destacar que, si bien algunos bloques de códigos DTC tienen significados genéricos que se aplican a todos los vehículos y fabricantes, los significados de otros pueden variar según el fabricante o incluso el modelo.
También vale la pena señalar que a veces los DTC pueden encontrarse en formato de cuatro caracteres, por ejemplo, " C158 ", que es simplemente la representación hexadecimal simple de los dos bytes, sin que se haya realizado una decodificación adecuada con respecto a la categoría.
Proporciona información sobre el rendimiento en uso de la pista para bancos de catalizadores, bancos de sensores de oxígeno, sistemas de detección de fugas por evaporación, sistemas EGR y sistema de aire secundario.
El numerador de cada componente o sistema registra la cantidad de veces que se cumplieron todas las condiciones necesarias para que un monitor específico detecte un mal funcionamiento. El denominador de cada componente o sistema registra la cantidad de veces que el vehículo funcionó en las condiciones especificadas.
El recuento de elementos de datos debe informarse al principio (el primer byte).
Todos los elementos de datos del registro de Seguimiento del rendimiento en uso constan de dos bytes y se informan en este orden (cada mensaje contiene dos elementos, por lo tanto, la longitud del mensaje es 4).
Proporciona información sobre el rendimiento en uso en pista para el catalizador NMHC, el monitor del catalizador NOx, el monitor del adsorbente NOx, el monitor del filtro PM, el monitor del sensor de gases de escape, el monitor EGR/VVT, el monitor de presión de refuerzo y el monitor del sistema de combustible.
Todos los elementos de datos constan de dos bytes y se informan en este orden (cada mensaje contiene dos elementos, por lo tanto, la longitud del mensaje es 4):
Algunos PID deben interpretarse de forma especial y no necesariamente están codificados de forma exacta en cada bit ni en ninguna escala. Los valores de estos PID se enumeran .
Una solicitud de este PID devuelve 2 bytes de datos. El primer byte describe el sistema de combustible n.° 1. El segundo byte describe el sistema de combustible n.° 2 (si existe) y está codificado de manera idéntica al primer byte. El significado asignado al valor de cada byte es el siguiente:
Cualquier otro valor es una respuesta no válida.
Una solicitud de este PID devuelve un solo byte de datos que describe el estado del aire secundario.
Cualquier otro valor es una respuesta no válida.
Una solicitud de este PID devuelve un único byte de datos que describe los estándares OBD que esta ECU debe cumplir. Los diferentes valores que puede contener el byte de datos se muestran a continuación, junto con su significado:
Este PID devuelve un valor de una lista enumerada que proporciona el tipo de combustible del vehículo. El tipo de combustible se devuelve como un solo byte y el valor se proporciona en la siguiente tabla:
Cualquier otro valor está reservado por la ISO/SAE. Actualmente no existen definiciones para vehículos de combustible flexible .
La mayoría de los PID OBD-II que se utilizan no son estándar. En la mayoría de los vehículos modernos, la interfaz OBD-II admite muchas más funciones que las que cubren los PID estándar, y existe una superposición relativamente pequeña entre los fabricantes de vehículos en lo que respecta a estos PID no estándar.
Hay muy poca información disponible en el dominio público sobre los PID no estándar. La fuente principal de información sobre los PID no estándar de diferentes fabricantes la mantiene el Equipment and Tool Institute, con sede en EE. UU. , y solo está disponible para los miembros. El precio de la membresía de ETI para acceder a los códigos de escaneo varía según el tamaño de la empresa, definido por las ventas anuales de herramientas y equipos automotrices en América del Norte:
Sin embargo, ni siquiera la membresía de ETI proporcionará documentación completa para los PID no estándar. ETI afirma: [7] [8]
Algunos fabricantes de equipos originales se niegan a utilizar ETI como fuente única de información sobre herramientas de escaneo. Prefieren hacer negocios con cada empresa de herramientas por separado. Estas empresas también exigen que usted firme un contrato con ellas. Los cargos varían, pero aquí se muestra un resumen de los cargos por año al 13 de abril de 2015:
Según lo definido en la norma ISO 15765-4, los protocolos de emisiones (incluidos OBD-II, EOBD, UDS, etc.) utilizan la capa de transporte ISO-TP (ISO 15765-2). Todas las tramas CAN enviadas mediante ISO-TP utilizan una longitud de datos de 8 bytes (y DLC de 8). Se recomienda rellenar los bytes de datos no utilizados con 0xCC.
La consulta y respuesta de PID se produce en el bus CAN del vehículo. Las solicitudes y respuestas OBD estándar utilizan direcciones funcionales. El lector de diagnóstico inicia una consulta utilizando el ID CAN 7DFh, que actúa como una dirección de transmisión, y acepta respuestas de cualquier ID en el rango de 7E8h a 7EFh. Las ECU que pueden responder a las consultas OBD escuchan tanto el ID de transmisión funcional de 7DFh como un ID asignado en el rango de 7E0h a 7E7h. Su respuesta tiene un ID de su ID asignado más 8, por ejemplo, de 7E8h a 7EFh.
Este enfoque permite hasta ocho ECU, cada una de las cuales responde de forma independiente a las consultas OBD. El lector de diagnóstico puede utilizar el ID en el marco de respuesta de la ECU para continuar la comunicación con una ECU específica. En particular, la comunicación de múltiples marcos requiere una respuesta al ID de la ECU específica en lugar de al ID 7DFh.
El bus CAN también se puede utilizar para comunicaciones que van más allá de los mensajes OBD estándar. El direccionamiento físico utiliza identificadores CAN específicos para módulos específicos (por ejemplo, 720h para el panel de instrumentos de Ford) con cargas útiles de chasis patentadas.
La consulta PID funcional se envía al vehículo a través del bus CAN en el ID 7DFh, utilizando 8 bytes de datos. Los bytes son:
El vehículo responde a la consulta PID en el bus CAN con identificadores de mensajes que dependen de qué módulo respondió. Normalmente, el motor o la ECU principal responden con el identificador 7E8h. Otros módulos, como el controlador híbrido o el controlador de batería en un Prius, responden con 07E9h, 07EAh, 07EBh, etc. Estos son 8h más altos que la dirección física a la que responde el módulo. Aunque la cantidad de bytes en el valor devuelto es variable, el mensaje usa 8 bytes de datos independientemente ( el protocolo de bus CAN tiene el formato Frameformat con 8 bytes de datos). Los bytes son:
