Para entender el OBD II de los automóviles


Para entender el OBD II de los automóviles
      Autores

Hoy en día es común escuchar sobre la contaminación ambiental y la forma en que contribuyen las emisiones de los automóviles. En las regiones donde es más severa, los gobiernos han buscado vigilarlas y, como parte de dicho control, se realiza la revisión periódica de los autos en centros especializados, y es en estos sitios donde se ha vuelto tan famoso como misterioso el OBD II (cuadro 1).
     En palabras sencillas, el protocolo OBD es el lenguaje con el cual la computadora del automóvil conversa con la del centro de verificación. Entre otras cosas, le dice: “hola, ¿cómo estás?”, “¿qué has hecho?”, y detalles por el estilo, lo que, en lenguaje más técnico significa que, primero, establece un enlace de datos; después, por medio de comandos y respuestas, envía tanto el estado actual como el guardado en memoria.
     Constantemente, la computadora del vehículo o ECU (Electronic Control Unit) monitorea el estado de los sensores; pero, no sólo los vigila: su magia principal reside en regular el funcionamiento del motor por medio de válvulas y actuadores para hacerlo más eficiente y menos contaminante. Por lo que, si presenta fallas en alguno de ellos, éstas son detectadas y se guardan en un código junto con otros datos.

Pero, ¿qué significa OBD? Primero, un poco de historia: durante los años setentas tuvieron su momento dorado los autos grandes con motores poderosos, pero relativamente sencillos; sin embargo, los ochentas marcaron el despertar hacia la ecología y aparecieron las primeras iniciativas ecológicas en los autos —aunque la tecnología era mecánica—, por lo que los motores se llenaron de mangueras y válvulas hasta llenar cada hueco debajo del cofre. Pero también se presentó otra revolución: los microprocesadores, pequeños aditamentos que fueron remplazando el control mecánico junto con algoritmos para hacer más eficiente el motor.  
     Por aquellos días, fueron estrenados los centros de verificación, cuya certificación era requerida cada año. Si algo estaba mal se sabía hasta entonces y, encima, había multa. Así surgió la idea de monitorear el motor para detectar fallas y poder ir a un taller antes de la verificación: he aquí que nació el famoso foco check engine que, en traducción libre del inglés significa “vaya y revise el motor”.
     El término OBD proviene de las siglas en inglés On Board Diagnostics, o “diagnóstico a bordo”, y así, en los inicios de los noventas surgieron los primeros protocolos conocidos como OBD (uno), los que solamente constituían mensajes básicos del motor y cada fabricante tenía los suyos.
     El gobierno de los Estados Unidos de América vio que esto era bueno y estableció una serie de estándares; así, la Sociedad de Ingenieros Automotrices (en inglés SAE) se encargó, principalmente, de normalizar dichos protocolos de comunicación.


     Entonces, no sólo se reguló la comunicación del ECU con la computadora externa de diagnóstico, sino también entre las demás de a bordo, además de usar datos de funcionamiento en tiempo real. Mensajes fijos universales fueron creados para cualquier vehículo, independientemente de la marca, y todos los vendidos en los Estados Unidos, a partir de 1996, tuvieron que apegarse a dichos estándares. Así, 1996 quedó para la historia como el año de nacimiento del OBD versión 2, o simplemente OBD II
     La Unión Europea también reconoció sus bondades y, en 2001, implementó su propia versión del OBD, conocida como EOBD (del inglés European OBD), cuyos estándares tomaron forma a través de la Organización Internacional para Estandarización (conocida como ISO, del griego isos: iguales, en referencia con su meta de ser el mismo en cualquier nación).
     En cuestión de mensajes, OBD y EOBD (OBD de los Estados Unidos) son prácticamente iguales; su principal diferencia reside en la manera como los unos y ceros —“1s” y “0s”— digitales se representan por niveles de voltaje. Japón tuvo su versión 2005, conocida como JOBD; igual, pero diferente en la codificación de “unos y ceros”. Para 2008, había cuatro versiones o protocolos OBD II con las mismas similitudes y diferencias (cuadro 2).
     La década 2000 tuvo su avance importante con el desarrollo de la comunicación CAN-BUS. Cada vez aparecieron más ECU a bordo, y este sistema se desarrolló para propiciar la comunicación de los protocolos entre sí. CAN-BUS permite esta comunicación a gran velocidad con sólo dos cables, algo parecido al USB. La industria vio que esto funcionaba y ahora, prácticamente, todos los autos vendidos a partir de 2008 lo utilizan.
     Los autos actuales incorporan una gran cantidad de sensores y actuadores que permiten a las ECU decidir cómo controlar el motor. En caso de que alguno se salga de sus límites, el sistema OBD lo detecta y graba el código de falla; entonces, el check engine se enciende para avisar al conductor que algo anda mal y es indispensable acudir al taller. Si la falla no vuelve a aparecer, el indicador se apaga después de la tercera vez que se enciende el motor, aunque queda grabado el código en memoria. 

La información más famosa que da el OBD son los códigos de falla conocidos como DTC (del inglés Diagnostic Trouble Code), los cuales, en caso de detectar una falla, quedan grabados en la ECU. Por ejemplo, el código P0301 avisa la presencia de una falla en el encendido del cilindro 1. Los códigos están definidos por el estándar SAE J2012 y pueden consultarse en internet, donde hay varios sitios con definiciones y recomendaciones.
     El otro grupo de datos que provee el OBD son los códigos de información de parámetros (del inglés Parameter ID o PID). Los PID entregan información de funcionamiento en tiempo real, como la velocidad, las revoluciones del motor, su temperatura, entre otros.
     Todo el OBD se divide en grupos llamados “modos OBD”; los más populares son el Modo 1, que maneja los PID, y el 3, los DTC. El Modo 4 permite borrar los DTC para apagar el check engine.

El punto de acceso para platicar con el auto es a través del conector OBD, para lo cual se requiere, primero, ponerse de acuerdo con la ECU en dos puntos: ponerse de acuerdo en la forma de representar unos y ceros digitales mediante señales eléctricas; algo parecido a decir que vamos a relacionar el símbolo “a” con el sonido “a”; en este caso, el “1” o el “0” puede ser voltaje alto, bajo, diferencia entre los dos, u otra manera. En OBD hay cinco maneras diferentes de hacerlo.
     El siguiente punto es ponerse de acuerdo en los grupos de unos y ceros: ¿cuál será su significado?  Así como el grupo de símbolos “g”, “a”, “t”, “o” juntos significan “gato” o animal felino, los símbolos 0000 0001 0000 0101 juntos significan el comando OBD para la temperatura (0x0105).
     Los comandos OBD se manejan enviando bytes o grupos de ocho bits (uno o cero), utilizando alguna de las cinco maneras de codificar el voltaje. La mala noticia es que así tal cual estos voltajes no se pueden conectar a una PC o tablet; la buena, es que el circuito integrado ELM327 de ELM Electronics establece un puente entre el OBD y una comunicación serial que se puede utilizar. El integrado puede detectar solito el protocolo OBD y traducirlo a una salida serial tipo UART. Dicha salida permite conectarse a interfaces RS232, USB, bluetooth o directo a un arduino. Hasta los bytes son convertidos en números y letras, código conocido como ASC II hexadecimal.
     Hay en el mercado varios dispositivos económicos OBD a bluetooth pensados para tablets o teléfonos. EL ELM327 es, prácticamente, la mitad de una herramienta de diagnóstico; sólo hace falta agregar un intérprete a los datos que entrega. La gran mayoría de los equipos están construidos con base en este IC o una versión clonada. Aunque este IC apoya todos los protocolos OBD II, no todos los equipos tienen completo el soporte para cualquier vehículo.    

ECU (Electronic Control Unit.


     Si se escuchara en español una plática entre un vehículo y un equipo de diagnóstico (llamado la compu) sería algo así: “Hola auto, soy la compu, ¿cómo está tu temperatura?”. Y el auto le contesta “hola compu, soy el auto, mi temperatura es de 83 grados”. Realmente las compus no hablan español (de hecho, ningún lenguaje humano), ellas se comunican intercambiando bytes en forma de números y letras. Para este ejemplo, el mensaje en bytes real es “41 6B 10 01 05”. Los primeros “41 6B 10” es el “hola auto, soy la compu” con el que se inicia la plática. Se llama encabezado e incluye datos como: a quién se está hablando (dirección destino) y quién habla (dirección fuente). Lo siguiente: “01 05” es la pregunta en sí (comando OBD).
     Normalmente, al platicar no se repite en cada oración “hola amigo, soy fulano…”. Pero, en OBD se tiene que repetir en cada mensaje. Cuando se trata de diagnóstico, el diálogo siempre va a ser entre computadora y ECU, por lo que el ELM327 lo esconde y maneja sólo los datos como en el ejemplo “01 05”. 
     El primer byte corresponde al modo y el segundo al PID; así, siguiendo el ejemplo anterior, el primero es el modo “01” y el segundo es el PID “05”. Los bytes enviados y recibidos son:

  • > 01 05 “la pregunta”
  • > 41 05 7B “la respuesta”

     La respuesta es “41”; luego, el mismo PID “05” y, después, el dato codificado de acuerdo con los estándares americanos normalizados por la SAE. En el ejemplo y siguiendo el estándar, 0x7B en hexadecimal es 123 decimales menos 40, lo que da la temperatura de 83 grados centígrados.
     Para hacer una computadora casera con un arduino, el primer paso es platicar con el ECU a través de una interfaz. Se puede buscar en el integrado los pines UART y conectarse directo. Lo siguiente es crear por software un intérprete de OBD; es decir, hacer una lista de PID y un selector switch para que “interprete” cada uno. Así resulta fácil hacer un monitor de los parámetros del vehículo en tiempo real. 

Alejandro García Blanco

Es egresado de Ingeniería en Electrónica y Comunicaciones del ITESM – campus Monterrey. Es Maestro en Ciencias de la Computación por el Instituto Tecnológico de Nogales y, actualmente es candidato a Doctor en Mecatrónica por la Universidad Popular Autónoma del Estado de Puebla. Cuenta con 20 años de experiencia en la industria en diversas áreas relacionadas con el desarrollo y fabricación de productos tecnológicos para diversos sectores del mercado. C. e.:  alex_g_blanco@hotmail.com

Av. Insurgentes Sur 1582, Col. Crédito Constructor • Alcaldía. Benito Juárez C.P.: 03940, México, CDMX Tel: (55) 5322-7700
Comentarios, sugerencias y dudas sobre este sitio de internet y sus sistemas:
Centro de Contacto y Soporte Técnico  

DERECHOS RESERVADOS © 2019
Políticas de Privacidad