Como lidar com leituras incorretas de combustível sem perder a cabeça
Um relatório de combustível é algo rotineiro. Ele mostra quanto combustível um veículo consumiu e se houve algo fora do normal durante o trajeto. É assim que costuma funcionar. Agora imagine abrir um relatório que diz que um ônibus abasteceu 12 vezes, teve combustível drenado 5 vezes e consumiu apenas 0,35 litro em 85 km. Por onde você começaria?
Analisamos cuidadosamente três dias de dados brutos dos rastreadores e usamos o Navixy IoT Logic para impedir que leituras incorretas distorcessem o relatório. A mesma abordagem pode ajudar com outros dados de sensores que, às vezes, deixam relatórios e alertas sem sentido. Mas vamos analisar esse caso passo a passo.
Um relatório de combustível que não fecha
Uma frota de 26 ônibus recebeu um relatório de combustível que trouxe mais perguntas do que respostas. Um dos ônibus supostamente percorreu 85 km com 0,35 litro de combustível, com 12 abastecimentos e 5 drenagens de combustível ao longo do dia. É muita movimentação para um único dia (e nada disso realmente aconteceu).
O gráfico do nível de combustível mostrou de onde vieram esses eventos. Várias vezes ao dia, a linha caía para perto de zero, permanecia baixa por um tempo e depois subia de repente. A plataforma fazia o que havia sido projetada para fazer. Interpretava cada queda como combustível saindo do tanque e cada salto como combustível entrando, e os alertas vinham em seguida.
Por mais estranho que parecesse, a conta fechava. O combustível no início do dia, mais os abastecimentos, menos as drenagens, menos o combustível restante no fim resultava em 62,2 + 95,13 − 106,98 − 50 = 0,35 litro. A fórmula estava correta. Então, obviamente, o problema estava nas leituras.
A primeira solução não bastou para normalizar as leituras de combustível
O cliente sugeriu uma solução simples. As quedas pareciam começar quando o motor era ligado, então ele pediu que ignorássemos as leituras de combustível por 20 segundos após ligar a ignição. Implementamos a ideia, mas as quedas continuaram. Algumas duravam muito mais de 20 segundos. Outras se estendiam por todo o período em que o ônibus ficava estacionado, mesmo com o motor desligado havia bastante tempo. As suposições já tinham chegado ao limite, então fomos aos dados brutos.
15:44:31 ignição desligada combustível 24,9 L
15:44:34 ignição ligada combustível 0,0 L motor 740 rpm
15:45:16 ignição ligada combustível 5,4 L motor 744 rpm
15:45:17 ignição desligada combustível 5,4 L
mais 276 mensagens ao longo de 47 minutos, todas indicando 5,4 L
16:32:33 ignição desligada combustível 5,4 L
16:32:34 ignição ligada combustível 21,6 L
16:35:56 ignição ligada combustível 25,3 L veículo a 45 km/h
Um ônibus, 43 segundos de funcionamento do motor e depois 47 minutos em que o tanque parecia quase vazio. Estas são as mensagens brutas do rastreador, exatamente como ele as enviou.
No relatório, essa única parada parece uma retirada de cerca de 20 litros do tanque, seguida da reposição de cerca de 20 litros 47 minutos depois.
Os abastecimentos reais também ficaram confusos. Em um dos ônibus, o abastecimento aconteceu entre várias partidas curtas do motor. Um único abastecimento de cerca de 30 litros apareceu no gráfico como uma queda para quase zero, seguida de uma subida para 62 litros.
Então, por que a solução simples não funcionou?
A maioria das configurações de combustível considera apenas os números. Cada uma falha aqui de uma maneira diferente.
| Abordagem | O que acontece com esses dados |
|---|---|
| Suavizar as leituras ou calcular sua média | O ruído se mistura aos valores reais. Um período de 47 minutos com leituras de 5,4 L reduz a média, então a falsa queda fica menos acentuada, mas continua lá. |
| Ignorar leituras abaixo de um limite | Um tanque que realmente está quase vazio também fica oculto. O ruído acima do limite, como as leituras de 15 a 18 litros que encontramos, continua passando. |
| Aumentar o limite de alerta | Há menos alertas, mas o gráfico de combustível e o relatório de consumo continuam errados. |
| Regras que consideram o contexto | O IoT Logic verifica o que uma pessoa verificaria. O motor está funcionando? Há quanto tempo foi ligado? O novo valor se mantém? O ruído é descartado, e os abastecimentos e as drenagens reais são preservados. |
Os 43 segundos de funcionamento do motor são a pista decisiva. Para rejeitar a leitura de 5,4 L, o fluxo precisa saber o que o ônibus estava fazendo quando o rastreador a recebeu. Uma regra baseada apenas no valor do combustível não consegue distinguir uma leitura incorreta de um tanque quase vazio.
Quatro perguntas feitas a cada leitura
O IoT Logic fica entre os rastreadores e tudo que usa seus dados, incluindo mapas, relatórios e alertas. Você cria um fluxo em uma área de trabalho visual, conectando blocos. Alguns blocos verificam uma condição, enquanto outros calculam um novo valor. As fórmulas nesses blocos podem consultar mensagens anteriores e o horário exato em que cada mensagem foi registrada no veículo. Cada mensagem passa pelo fluxo, e a plataforma recebe apenas o que sai dele.
Nosso fluxo faz até quatro perguntas a cada leitura de combustível, em sequência.
O fluxo mantém o último nível confiável até que uma leitura passe pelas verificações.
Nos dados registrados, as leituras de combustível levaram pouco mais de 7 minutos para se estabilizar após a partida mais lenta. Por isso, definimos um período de estabilização de 7,5 minutos. Durante a condução normal, o nível nunca variou mais de 3,5 litros entre duas mensagens, o que também correspondia ao limite solicitado pelo cliente. Escolhemos 5 minutos porque nenhuma leitura com ruído nos dados registrados permaneceu estável por tanto tempo com o motor funcionando, enquanto os níveis após abastecimentos e drenagens reais se mantiveram.
Com essas verificações, um abastecimento ou uma drenagem pode levar até cerca de 12 minutos de funcionamento do motor para aparecer no relatório. O fluxo espera o período de estabilização e verifica se o novo nível se mantém antes de deixar a leitura passar.
O fluxo grava o nível corrigido no mesmo campo que o sensor de combustível já utiliza, então gráficos, relatórios e alertas passam a usá-lo automaticamente. Quando é ativado pela primeira vez, ele deixa as leituras inalteradas até receber uma leitura confiável após um período completo de estabilização. Isso impede que o próprio fluxo crie um evento falso caso comece a processar dados no meio de uma parada com leituras incorretas.
Uma tarde, antes e depois
Os dados do rastreador registrados durante uma tarde, reprocessados pelo fluxo. A linha cinza aparece apenas onde os dois valores diferem.
| Horário | Valor informado pelo rastreador | Valor exibido pela plataforma | O que aconteceu |
|---|---|---|---|
| 15:44:31 | 24,9 L | 24,9 L | Veículo estacionado |
| 15:44:34 | 0,0 L | 24,9 L | O motor é ligado, e a primeira leitura é ruído |
| 15:45:17 | 5,4 L | 24,9 L | O motor é desligado após 43 segundos. O rastreador mantém sua última leitura |
| 16:32:34 | 21,6 L | 24,9 L | Nova partida, 47 minutos depois. O período de estabilização começa |
| 16:40:44 | 26,2 L | 26,2 L | O período de estabilização terminou, e as leituras voltam a ser confiáveis |
| 16:47:23 | 62,5 L | 26,3 L | Abastecimento logo após uma nova partida, então a leitura fica em espera |
| 17:00:10 | 62,3 L | 62,3 L | O novo nível se manteve por 5 minutos de funcionamento do motor, então é aceito |
Como verificamos que funciona
Antes de ser usado em um ônibus real, o fluxo foi testado com rastreadores virtuais que reproduziam as situações mais problemáticas da frota. Os cenários incluíam a queda de 47 minutos, um abastecimento entre várias partidas curtas, combustível furtado durante a condução, leituras caindo para zero durante o trajeto e a ativação do fluxo durante uma parada com leituras incorretas. Todos os nove cenários de teste passaram. Depois, o fluxo foi executado em um rastreador real na nossa bancada de testes.
Também reprocessamos todos os dados registrados, cerca de 34.000 mensagens de três ônibus ao longo de três dias em agosto de 2026, usando as mesmas regras. Contamos os saltos de mais de 3,5 litros de uma mensagem para a seguinte. Para dois dos ônibus, o fluxo identificava se o motor estava funcionando a partir da rotação do motor.
Para colocar o fluxo em operação, basta um arquivo. Importe o fluxo, escolha os veículos e ative-o. Não é necessário visitar os veículos nem alterar rastreadores, sensores ou regras de alerta. Ao desativar o fluxo, a plataforma volta a usar as leituras brutas.
A mesma ideia funciona muito além do combustível
O padrão é comum. Um valor só pode ser considerado confiável sob determinadas condições. Neste caso, o fluxo verificava o estado da ignição, o tempo desde a partida e se o novo nível se mantinha. Outras leituras problemáticas podem ser verificadas de acordo com as condições adequadas para elas.
- Alertas de excesso de velocidade causados por saltos na posição GPS. Considerar que um veículo está acima da velocidade permitida apenas quando houver satélites suficientes visíveis e a velocidade permanecer elevada por 10 segundos.
- Sensores que precisam de um período de estabilização. Ignorar leituras de temperatura ou pressão nos primeiros minutos após um dispositivo ser ligado.
- Picos isolados. Aceitar um novo valor apenas depois que ele se repetir ou se mantiver por um período definido.
Essas condições podem ser verificadas antes que uma leitura chegue aos relatórios ou alertas. Neste caso, isso fez com que 43 segundos de funcionamento do motor deixassem de parecer uma drenagem de combustível seguida de um abastecimento, enquanto as mudanças que se mantinham por tempo suficiente continuavam passando.
Para criar fluxos no IoT Logic, comece pela documentação do IoT Logic. Se você quer entender como essa abordagem se aplicaria à sua frota ou aos seus sensores, entre em contato com nossa equipe.