Cómo lidiar con lecturas erróneas de combustible sin perder la cabeza

Un reporte de combustible es algo de rutina. Les dice cuánto combustible consumió un vehículo y si ocurrió algo fuera de lo normal durante el recorrido. Así suele funcionar. Ahora imaginen abrir uno que dice que un autobús cargó combustible 12 veces, registró 5 extracciones y consumió apenas 0.35 litros en 85 km. ¿Por dónde empezarían?

Revisamos a fondo tres días de datos sin procesar del rastreador y usamos Navixy IoT Logic para evitar que las lecturas erróneas distorsionaran el reporte. El mismo enfoque podría servir para otros datos de sensores que a veces hacen que los reportes y las alertas no tengan ni pies ni cabeza. Pero vamos a revisar este caso paso a paso.

Un reporte de combustible que no cuadra

Una flota de 26 autobuses recibió un reporte de combustible que dejó más preguntas que respuestas. Supuestamente, uno de los autobuses recorrió 85 km con 0.35 litros de combustible, con 12 cargas y 5 extracciones durante el día. Son demasiadas operaciones para un solo día (y ninguna ocurrió en realidad).

La gráfica de combustible mostraba de dónde salían esos eventos. Varias veces al día, la línea caía hasta acercarse a cero, se mantenía baja un rato y luego volvía a subir de golpe. La plataforma hacía lo que debía hacer. Interpretaba cada caída como una salida de combustible del tanque y cada salto como una entrada, y generaba las alertas correspondientes.

Por raro que pareciera, las cuentas sí cuadraban. El combustible al inicio del día, más las cargas, menos las extracciones y menos el combustible restante al final daba 62.2 + 95.13 − 106.98 − 50 = 0.35 litros. La fórmula estaba bien. Así que, claramente, el problema estaba en las lecturas.

La solución más obvia no bastó para normalizar las lecturas de combustible

El cliente propuso una solución sencilla. Las caídas parecían empezar al arrancar el motor, así que nos pidió ignorar las lecturas de combustible durante los primeros 20 segundos después de activar el encendido. Lo implementamos, pero las caídas siguieron apareciendo. Algunas duraban mucho más de 20 segundos. Otras se prolongaban durante toda una parada, mucho después de apagar el motor. Ya no tenía sentido seguir haciendo suposiciones, así que fuimos a los datos sin procesar.

Lo que revelaron 34,000 mensajes

Un rastreador envía un flujo constante de pequeños mensajes con una marca de tiempo, una posición y los datos que reporta el vehículo. El nivel de combustible viene de la computadora del autobús, que lo transmite a través de la red de datos interna del vehículo, la misma que alimenta el indicador de combustible del tablero.

Exportamos tres días de datos sin procesar de tres autobuses, unos 34,000 mensajes, y los revisamos uno por uno. Tres patrones explicaban casi todo.

1. Estacionado significa sin datos nuevos

Con el motor apagado, no llegan datos nuevos de combustible, así que el rastreador sigue enviando el último nivel que recibió. Durante 36 paradas de un mismo autobús, el nivel de combustible reportado no cambió ni una sola vez. Las lecturas enviadas mientras el autobús está estacionado no aportan información nueva.

2. Los primeros minutos después del arranque no son confiables

Justo después de arrancar el motor, mientras los sistemas del vehículo se ponen en marcha, las primeras lecturas de combustible no siempre corresponden a la realidad. A menudo indicaban que el tanque tenía entre 0 y 6 litros, sin importar cuánto combustible hubiera realmente. Por lo general, esto se resolvía en segundos. En aproximadamente uno de cada cinco arranques tardaba más, y el más lento tomó poco más de 7 minutos.

3. Un arranque breve deja una caída prolongada

Al combinar los dos primeros patrones, aparecen las caídas más pronunciadas. Un conductor arranca el motor y lo apaga menos de un minuto después. La última lectura que recibió el rastreador fue uno de esos valores poco confiables del arranque. Con el motor apagado, ese es el único valor que tiene, así que lo repite durante toda la parada.

15:44:31  encendido desactivado   combustible 24.9 L
15:44:34  encendido activado      combustible  0.0 L   motor 740 rpm
15:45:16  encendido activado      combustible  5.4 L   motor 744 rpm
15:45:17  encendido desactivado   combustible  5.4 L
          276 mensajes más durante 47 minutos, todos con 5.4 L
16:32:33  encendido desactivado   combustible  5.4 L
16:32:34  encendido activado      combustible 21.6 L
16:35:56  encendido activado      combustible 25.3 L   circulando a 45 km/h

Un autobús, 43 segundos con el motor en marcha y después 47 minutos con un tanque que parecía casi vacío. Estos son los mensajes sin procesar del rastreador, tal como los envió.

En el reporte, esa sola parada parece una extracción de unos 20 litros del tanque y una carga de unos 20 litros, 47 minutos después.

Las cargas reales también aparecían distorsionadas. En un autobús, la carga ocurrió entre varios arranques breves del motor, y una sola carga de unos 30 litros apareció en la gráfica como una caída hasta casi cero, seguida de una subida a 62 litros.

Entonces, ¿por qué no funcionó la solución sencilla?

La mayoría de los ajustes de combustible solo toman en cuenta los números. Con estos datos, cada uno falla de una manera distinta.

Método	Qué pasa con estos datos
Suavizar las lecturas o calcular un promedio	El ruido se mezcla con los valores reales. Una lectura de 5.4 L durante 47 minutos reduce el promedio, así que la caída falsa se suaviza, pero sigue ahí.
Ignorar las lecturas por debajo de un límite	También se oculta un tanque que realmente está casi vacío. El ruido por encima del límite, como las lecturas de entre 15 y 18 litros que encontramos, sigue pasando.
Aumentar el umbral de las alertas	Hay menos alertas, pero la gráfica de combustible y el reporte de consumo siguen siendo incorrectos.
Aplicar reglas que toman en cuenta el contexto	IoT Logic comprueba lo mismo que revisaría una persona. ¿Está funcionando el motor? ¿Hace cuánto arrancó? ¿Se mantiene el nuevo valor? Se descarta el ruido y se conservan las cargas y extracciones reales.

Esos 43 segundos con el motor en marcha son la pista clave. Para rechazar la lectura de 5.4 L, el flujo necesita saber qué estaba haciendo el autobús cuando el rastreador la recibió. Una regla basada únicamente en el nivel de combustible no puede distinguir una lectura errónea de un tanque casi vacío.

Cuatro preguntas para cada lectura

IoT Logic se sitúa entre los rastreadores y todo lo que utiliza sus datos, incluidos mapas, reportes y alertas. Pueden crear un flujo conectando bloques en un editor visual. Algunos bloques comprueban una condición y otros calculan un nuevo valor. Las fórmulas dentro de los bloques pueden consultar mensajes anteriores y el momento exacto en que cada mensaje se registró en el vehículo. Todos los mensajes pasan por el flujo, y la plataforma solo recibe lo que sale de él.

Nuestro flujo evalúa cada lectura de combustible con hasta cuatro preguntas, en orden.

El flujo conserva el último nivel confiable hasta que una lectura pasa las comprobaciones.

En el arranque más lento de los datos registrados, las lecturas de combustible tardaron poco más de 7 minutos en estabilizarse, así que fijamos el periodo de calentamiento en 7.5 minutos. Durante la conducción normal, el nivel nunca cambió más de 3.5 litros entre dos mensajes, lo que también coincidía con el umbral que había pedido el cliente. Elegimos 5 minutos porque ninguna lectura con ruido se mantuvo estable tanto tiempo con el motor en marcha, mientras que los niveles después de cargas y extracciones reales sí lo hicieron.

Con estas comprobaciones, una carga o extracción puede tardar hasta unos 12 minutos de funcionamiento del motor en aparecer en el reporte. El flujo espera a que termine el periodo de calentamiento y comprueba que el nuevo nivel se mantenga antes de dejar pasar la lectura.

El flujo escribe el nivel corregido en el mismo campo que ya utiliza el sensor de combustible, así que las gráficas, los reportes y las alertas lo reciben automáticamente. Cuando se activa por primera vez, deja las lecturas sin cambios hasta recibir una lectura válida después de un periodo completo de calentamiento. Esto evita que genere un evento falso si empieza a procesar datos a mitad de una parada con lecturas erróneas.

Una tarde, antes y después

Los datos que registró el rastreador durante una tarde, procesados de nuevo mediante el flujo. La línea gris aparece solo donde las lecturas originales y las corregidas difieren.

Hora	Lectura del rastreador	Valor que recibe la plataforma	Qué ocurrió
15:44:31	24.9 L	24.9 L	Estacionado
15:44:34	0.0 L	24.9 L	Arranca el motor y la primera lectura es ruido
15:45:17	5.4 L	24.9 L	El motor se apaga después de 43 segundos. El rastreador conserva su última lectura
16:32:34	21.6 L	24.9 L	El motor vuelve a arrancar 47 minutos después. Empieza el periodo de calentamiento
16:40:44	26.2 L	26.2 L	Termina el calentamiento y las lecturas vuelven a ser confiables
16:47:23	62.5 L	26.3 L	Hay una carga de combustible justo después de un nuevo arranque, así que el flujo espera
17:00:10	62.3 L	62.3 L	El nuevo nivel se mantuvo durante 5 minutos con el motor en marcha, así que se acepta

Cómo comprobamos que funciona

Antes de usarlo en un autobús real, probamos el flujo con rastreadores virtuales que reproducían los peores momentos de la flota. Entre ellos estaban la caída de 47 minutos, una carga de combustible entre varios arranques breves, un robo de combustible durante la conducción, lecturas que caían a cero a mitad de un recorrido y la activación del flujo durante una parada con lecturas erróneas. Pasó los nueve escenarios de prueba. Después lo probamos con un rastreador real en nuestro banco de pruebas.

También volvimos a procesar todos los datos registrados, unos 34,000 mensajes de tres autobuses durante tres días de agosto de 2026, con las mismas reglas y contamos los saltos de más de 3.5 litros entre un mensaje y el siguiente. En dos de los autobuses, el flujo determinaba si el motor estaba en marcha a partir de las revoluciones del motor.

Para ponerlo en marcha basta con un archivo. Carguen el flujo, elijan los vehículos y actívenlo. No hace falta acudir a los vehículos ni modificar rastreadores, sensores o reglas de alertas. Al desactivar el flujo, la plataforma vuelve a utilizar las lecturas sin procesar.

La misma idea sirve para mucho más que el combustible

Este problema se repite con otros datos. Un valor solo es confiable bajo ciertas condiciones. En este caso, el flujo comprobaba el estado del encendido, el tiempo desde el arranque y si el nuevo nivel se mantenía. Otras lecturas problemáticas se pueden comprobar según las condiciones que correspondan.

• Alertas de exceso de velocidad causadas por saltos del GPS. Consideren que un vehículo excede la velocidad solo cuando hay suficientes satélites visibles y la velocidad se mantiene alta durante 10 segundos.
• Sensores que necesitan calentarse. Ignoren las lecturas de temperatura o presión durante los primeros minutos después de encender un dispositivo.
• Picos aislados. Acepten un nuevo valor solo cuando se repita o se mantenga durante un tiempo determinado.

Estas condiciones se pueden aplicar antes de que una lectura llegue a los reportes o las alertas. En este caso, un arranque de 43 segundos dejó de parecer una extracción de combustible seguida de una carga, mientras que los cambios que se mantenían el tiempo suficiente seguían pasando.

Para crear flujos en IoT Logic, empiecen por la documentación de IoT Logic. Si quieren saber cómo aplicar este enfoque a su flota o sus sensores, pónganse en contacto con nuestro equipo.