Acabo de escanear mi vehículo por primera vez para verificar el código de Check Engine Light. Sentí curiosidad por saber si estos códigos de falla se registran en algún lugar con una marca de fecha y hora de algún tipo en el momento en que se lanzaron. Estoy imaginando algún diseño similar al Registro de eventos que se usa en los sistemas operativos de las computadoras, pero puedo estar totalmente equivocado con este.
¿Cuál es exactamente el diseño en torno a estos códigos de falla en cuanto a cómo se registran? Un aspecto obvio del diseño es el uso de códigos únicos específicos para algún problema en particular. ¿Es esa la historia completa con una falla? ¿Hay otros metadatos relacionados con una instancia de falla que se puedan buscar? ¿Cómo funcionan los historiales de fallas en los vehículos? ¿Las historias incluso se registran o las fallas son simplemente una cosa binaria, ya sea que estén encendidas o apagadas actualmente, independientemente de si alguna vez estuvieron encendidas en algún momento de la vida del vehículo? Sé que puede borrar códigos usando herramientas de escáner, ¿sugiere esto que las fallas permanecerán marcadas en un sistema a perpetuidad hasta que las borre manualmente? Esto me llevaría a creer que la luz de verificación del motor permanecería encendida incluso después de reparar la causa raíz de una falla. ¿Es esto exacto?
Realmente depende de la implementación de OBD2. Lo que registra mi Subaru 1997 (prácticamente nada) en comparación con un Chevy Cruise 2015 son cosas completamente diferentes.
Sin embargo, en la mayoría de los casos, se registra un Código de problema de diagnóstico (DTC) con un cuadro congelado , que es un almacenamiento completo de todos los ID de parámetros (PIDS). Estos parámetros cubren todo, desde RPM, velocidad del vehículo, datos del sensor de O2, datos de flujo de aire masivo, ajustes de combustible a largo y corto plazo, avance de encendido, admisión y temperatura del refrigerante, y quizás docenas más. Se accede a ellos a través del Modo 2 de OBD2. Se accede a las fallas de DTC "Pxxxx" simples a través del Modo 3 de OBD2, que a menudo es el alcance que pueden mostrar las herramientas de escaneo simples del consumidor.
En herramientas de escaneo más sofisticadas, se pueden mostrar los datos de "imagen congelada" del modo 2, que son datos invaluables, ya que revelan la condición de funcionamiento exacta en el mismo instante en que se estableció el código DTC.
La historia de dichos códigos varía nuevamente con la implementación de OBD2, y muy probablemente cuán nuevo sea el vehículo. En mi Subaru 1997, los datos son limitados, dado que OBD2 no fue obligatorio hasta el año modelo 1996.
Sin embargo, todos los vehículos tienen dos categorías de DTC: "Pendiente", que es una falla detectada, pero no establece Check Engine Light (CEL, SES) hasta que la condición se detecta nuevamente una cierta cantidad de veces. (Se accede a esto a través del modo OBD2 7). La cantidad de "ciclos de manejo" necesarios para promover un "pendiente" a CEL depende de la falla, la implementación y el vehículo.
La otra categoría de DTC es "almacenada" o "registrada". Estos son códigos de falla verdaderos que han sido promovidos del estado "pendiente" a un código de falla real, y por definición OBD2 deben establecer el CEL.
Además, algunas unidades/módulos de control del motor (ECU/ECM) tienen la capacidad de registrar algunos o docenas de códigos de falla "históricos", independientemente de si se han reparado o borrado. Esto proporciona antecedentes a un técnico astuto, incluso cuando no hay fallas de DTC actuales pendientes o registradas .
Los códigos DTC NO tienen que borrarse "manualmente". Si la condición que causó la falla se repara, o simplemente ya no ocurre (la eficiencia del catalizador P0420 es un ejemplo clásico), el código se "borrará solo", por así decirlo, después de una cierta cantidad de ciclos de manejo sin que la falla vuelva a ocurrir. La cantidad de ciclos de manejo necesarios para borrar un DTC de CEL activo depende de la falla y la implementación del software. Sin embargo, en la mayoría de los casos, un técnico borra estos códigos después de una reparación válida para asegurarle al cliente que la reparación está completa. Pero no TENEMOS que hacerlo; es una cortesía. La ECU/ECM monitorea constantemente el PID y las condiciones de emisión, y eventualmente cederá, dados suficientes ciclos de conducción "limpios".
Aparte, hay una categoría de DTC que causa una CEL INTERMITENTE . Estos difieren dramáticamente del CEL "encendido continuo", en que si se enciende y permanece encendido, es una indicación de que algo anda mal, y el conductor debe buscar servicio en una oportunidad conveniente. Sin embargo, una CEL INTERMITENTE indica que algo anda muy mal y que podría dañar el vehículo. Por lo general, esto es una indicación de una condición demasiado rica, generalmente causada por fallas graves en el encendido o en la inyección de combustible que, si no se toman en cuenta, podrían dañar un costoso convertidor catalítico. Estas luces de control del motor "parpadeantes" deben abordarse de inmediato: algunos fabricantes de equipos originales sugieren detener el vehículo y remolcarlo.
Para complicar aún más este proceso, borrar un CEL elimina el código de falla de la categoría "activa", pero al igual que la analogía de su computadora, es un ALT_CTRL-DEL. Restablece completamente la ECU/ECM y borra lo que se conoce como "monitores".
Los monitores son una gran cantidad de pruebas que se ejecutan de forma continua o, en la mayoría de los casos, cuando se cumplen ciertos criterios de PID (temperatura, carga del motor, nivel de combustible, ciclo de conducción). (Esto es lo que hace que sea particularmente difícil pasar los monitores del sistema de emisiones evaporativas; los criterios son exactos e incluso dependen de la cantidad de combustible que haya en el tanque).
Se necesita un cierto número de ciclos de manejo exitosos, obedeciendo todos los criterios requeridos, para "pasar" estas pruebas de monitoreo. En este punto, el vehículo puede pasar una inspección de emisiones OBD2, cuando todos los monitores hayan pasado. (En Nueva York, los vehículos producidos antes de 2001 pueden tener dos pruebas de monitor incompletas, 2001 y posteriores tienen permitida una, y puede ser que a los vehículos recientes no se les permita ninguna incompleta. Esto es solo una trivialidad).
El resultado es que, si bien un vehículo puede haber tenido las reparaciones adecuadas y los códigos de falla se borraron, esto NO significa que pasará una inspección de emisiones OBD2. Esto evita la técnica del árbol de la sombra de desconectar la batería y llevarla inmediatamente a inspección. El vehículo debe completar la cantidad requerida de ciclos de manejo con todos (o la mayoría) de los criterios cumplidos para obtener la calificación aprobatoria. Si bien un vehículo llamado "no listo" no falla en las pruebas de emisiones, tampoco pasa. Después de la lobotomía ALT-CTRL-DEL ECU/ECM, el vehículo se asienta y no está "listo" para la inspección hasta que se prueba a sí mismo que todos los monitores funcionan y que el vehículo funciona sin problemas.
Hay dos tipos de códigos de falla; solo viaje y dos viajes.
Un código de falla de un solo viaje es generalmente una falla importante, como una falla de encendido severa. Esto iluminará la luz de verificación del motor inmediatamente después de la detección.
Un código de falla de dos viajes tiene que ser verificado en dos viajes. El primer viaje establece un código pendiente sin encender la luz. Si se vuelve a detectar la falla, la luz se encenderá.
Teóricamente, cuando una falla fuerte (luz encendida) pasa la prueba dos veces consecutivas, la luz se apagará. Luego, el código se degrada a pendiente desde un error grave. Esto está estipulado si la prueba aún se ejecuta con una falla grave. Hay algunos casos en los que la prueba se suspende con una falla grave y luego limpiar la luz con una herramienta de escaneo es la única forma de apagar la luz. Un código pendiente desaparecerá si la prueba pasa 60 ciclos de conducción consecutivos (encender y apagar el automóvil 60 veces no constituye un ciclo de conducción)
Cada vez que se almacena un código, los datos del cuadro congelado se almacenan con él. Freeze frame data (FFD) es una instantánea de los datos más comunes cuando se detectó la falla. El problema es que los valores almacenados difieren según el fabricante y el año del vehículo. Los valores pueden incluir pero no se limitan a; temperatura del refrigerante, rpm, temperatura del aire, ajuste de combustible a corto plazo, viaje de combustible a largo plazo, estado del circuito, cuánto tiempo en un ciclo de conducción se establece la falla, cuántos ciclos de conducción han pasado desde que se estableció la falla... la lista sigue y sigue.
Los vehículos más antiguos solo podían almacenar un solo cuadro de FFD y el código de falla más grave tenía prioridad. Los vehículos más nuevos pueden almacenar varios marcos FFD. Si bien es posible que pueda averiguar en qué orden ocurrieron los códigos, no hay una marca de tiempo proverbial como en un registrador de eventos.
¡Respuestas muy detalladas ya! Solo quería agregar algo sobre las pruebas de emisiones después de borrar los códigos de falla. Algunos fabricantes incluyen una forma de crear las condiciones que determinarán si los componentes de emisiones pasan/fallan sin tiempos de conducción prolongados. El software VCDS que tengo para Volkswagen (y sus otras marcas) tiene una opción de "establecer preparación" en la CPU del motor. Lo guía a través de los componentes de emisiones paso a paso, indicando cuánto tiempo debe mantener el motor a ciertas RPM y cuándo se realiza la prueba. Los vehículos más nuevos tomarán automáticamente el control y acelerarán el motor, mientras que los más antiguos deben hacerlo con precisión alguien en el asiento del conductor manteniendo RPM bastante precisas. En breve,
vini_i
dlu
vini_i