Comment gérer les mesures de carburant erronées sans perdre la tête

Un rapport de carburant, c’est un document de routine. Il indique combien de carburant un véhicule a consommé et si quelque chose d’inhabituel s’est produit pendant le trajet. En général, c’est comme ça que ça fonctionne. Maintenant, imaginez en ouvrir un qui indique qu’un bus a fait le plein 12 fois, subi 5 retraits de carburant et consommé seulement 0,35 litre sur 85 km. Par où commenceriez-vous ?

Nous avons passé au crible trois jours de données brutes du traceur, puis utilisé Navixy IoT Logic pour empêcher les mauvaises mesures de fausser le rapport. La même approche pourrait servir pour d’autres données de capteurs qui rendent parfois les rapports et les alertes incohérents. Mais reprenons ce cas étape par étape.

Un rapport de carburant qui ne tient pas debout

Une flotte de 26 bus a reçu un rapport de carburant qui soulevait plus de questions qu’il n’apportait de réponses. L’un des bus aurait parcouru 85 km avec 0,35 litre de carburant, avec 12 pleins et 5 retraits de carburant dans la journée. Cela fait beaucoup d’opérations pour une seule journée (et aucune n’a réellement eu lieu).

La courbe de carburant montrait d’où venaient ces événements. Plusieurs fois par jour, elle chutait presque jusqu’à zéro, restait basse pendant un moment, puis remontait brusquement. La plateforme faisait ce pour quoi elle avait été conçue. Elle interprétait chaque baisse comme une sortie de carburant du réservoir et chaque hausse comme une entrée, puis déclenchait les alertes correspondantes.

Aussi étrange que cela puisse paraître, le calcul était juste. Le carburant au début de la journée, plus les pleins, moins les retraits et moins le carburant restant à la fin donnaient 62,2 + 95,13 − 106,98 − 50 = 0,35 litre. La formule était correcte. Le problème venait donc manifestement des mesures.

La solution évidente n’a pas suffi à rétablir des mesures de carburant normales

Le client a proposé une solution simple. Les chutes semblaient commencer au démarrage du moteur, alors il nous a demandé d’ignorer les mesures de carburant pendant les 20 premières secondes après la mise du contact. Nous l’avons mise en place, mais les chutes ont continué. Certaines duraient bien plus de 20 secondes. D’autres se prolongeaient pendant tout un arrêt, longtemps après l’extinction du moteur. Nous avions fait le tour des suppositions, alors nous sommes allés voir les données brutes.

Ce que 34 000 messages ont révélé

Un traceur envoie un flux régulier de petits messages contenant un horodatage, une position et les données transmises par le véhicule. Le niveau de carburant provient du calculateur du bus, qui le transmet sur le réseau de données interne du véhicule, celui-là même qui alimente la jauge du tableau de bord.

Nous avons exporté trois jours de données brutes de trois bus, soit environ 34 000 messages, et les avons examinés un par un. Trois comportements expliquaient presque tout.

1. À l’arrêt, aucune nouvelle donnée

Lorsque le moteur est éteint, aucune nouvelle donnée de carburant n’arrive. Le traceur continue donc d’envoyer le dernier niveau reçu. Sur les 36 arrêts d’un même bus, le niveau de carburant transmis n’a pas changé une seule fois. Les mesures envoyées pendant qu’un bus est stationné n’apportent aucune nouvelle information.

2. Les premières minutes après le démarrage ne sont pas fiables

Juste après le démarrage du moteur, pendant que les systèmes du véhicule se mettent en route, les premières mesures de carburant ne correspondent pas toujours à la réalité. Elles indiquaient souvent entre 0 et 6 litres dans le réservoir, quelle que soit la quantité réellement présente. En général, cela se réglait en quelques secondes. Pour environ un démarrage sur cinq, il fallait plus de temps, et le cas le plus lent dépassait légèrement 7 minutes.

3. Un démarrage bref provoque une longue chute

Combinez les deux premiers comportements et vous obtenez les chutes les plus importantes. Un conducteur démarre le moteur, puis l’éteint moins d’une minute plus tard. La dernière mesure reçue par le traceur est l’une de ces valeurs de démarrage peu fiables. Une fois le moteur éteint, c’est la seule valeur dont il dispose, alors il la répète pendant tout l’arrêt.

15:44:31  contact coupé   carburant 24,9 L
15:44:34  contact mis     carburant  0,0 L   moteur 740 tr/min
15:45:16  contact mis     carburant  5,4 L   moteur 744 tr/min
15:45:17  contact coupé   carburant  5,4 L
          276 messages supplémentaires sur 47 minutes, tous à 5,4 L
16:32:33  contact coupé   carburant  5,4 L
16:32:34  contact mis     carburant 21,6 L
16:35:56  contact mis     carburant 25,3 L   roulant à 45 km/h

Un bus, 43 secondes de fonctionnement du moteur, puis 47 minutes pendant lesquelles le réservoir semblait presque vide. Ce sont les messages bruts du traceur, tels qu’il les a envoyés.

Dans le rapport, ce seul arrêt ressemble à un retrait d’environ 20 litres du réservoir, suivi d’un ajout d’environ 20 litres, 47 minutes plus tard.

Les vrais pleins étaient eux aussi déformés. Sur un bus, le plein a eu lieu entre plusieurs démarrages brefs du moteur. Un seul ajout d’environ 30 litres apparaissait sur la courbe comme une chute presque jusqu’à zéro, suivie d’une remontée à 62 litres.

Alors, pourquoi la solution simple n’a-t-elle pas fonctionné ?

La plupart des réglages de carburant ne prennent en compte que les chiffres. Avec ces données, chacun échoue à sa manière.

Approche	Ce qui se passe avec ces données
Lisser les mesures ou calculer une moyenne	Le bruit se mélange aux valeurs réelles. Une période de 47 minutes à 5,4 L fait baisser la moyenne. La fausse chute est atténuée, mais reste présente.
Ignorer les mesures inférieures à un seuil	Un réservoir réellement presque vide est lui aussi masqué. Le bruit au-dessus du seuil, comme les mesures de 15 à 18 litres que nous avons trouvées, continue de passer.
Augmenter le seuil des alertes	Il y a moins d’alertes, mais la courbe de carburant et le rapport de consommation restent incorrects.
Appliquer des règles qui tiennent compte du contexte	IoT Logic vérifie ce qu’une personne vérifierait. Le moteur tourne-t-il ? Depuis combien de temps a-t-il démarré ? La nouvelle valeur se maintient-elle ? Le bruit est écarté, tandis que les vrais pleins et retraits sont conservés.

Ces 43 secondes de fonctionnement du moteur sont l’indice décisif. Pour rejeter la mesure de 5,4 L, le flux doit savoir ce que faisait le bus lorsque le traceur l’a reçue. Une règle fondée uniquement sur le niveau de carburant ne peut pas distinguer une mauvaise mesure d’un réservoir presque vide.

Quatre questions pour chaque mesure

IoT Logic se place entre les traceurs et tout ce qui utilise leurs données, notamment les cartes, les rapports et les alertes. Vous construisez un flux en reliant des blocs dans un éditeur visuel. Certains blocs vérifient une condition, d’autres calculent une nouvelle valeur. Les formules qu’ils contiennent peuvent consulter les messages précédents ainsi que l’heure exacte à laquelle chaque message a été enregistré sur le véhicule. Chaque message passe par le flux, et la plateforme ne reçoit que ce qui en sort.

Notre flux soumet chaque mesure de carburant à quatre questions au maximum, dans l’ordre.

Le flux conserve le dernier niveau fiable jusqu’à ce qu’une mesure passe les vérifications.

Après le démarrage le plus lent observé dans les données enregistrées, les mesures de carburant ont mis un peu plus de 7 minutes à se stabiliser. Nous avons donc fixé la période de chauffe à 7,5 minutes. En conduite normale, le niveau ne variait jamais de plus de 3,5 litres entre deux messages, ce qui correspondait aussi au seuil demandé par le client. Nous avons choisi 5 minutes parce qu’aucune mesure bruitée ne restait stable aussi longtemps avec le moteur en marche, contrairement aux niveaux observés après de vrais pleins et retraits.

Avec ces vérifications, un plein ou un retrait peut mettre jusqu’à environ 12 minutes de fonctionnement du moteur à apparaître dans le rapport. Le flux attend la fin de la période de chauffe et vérifie que le nouveau niveau se maintient avant de laisser passer la mesure.

Le flux écrit le niveau corrigé dans le même champ que celui déjà utilisé par le capteur de carburant. Les courbes, les rapports et les alertes le récupèrent donc automatiquement. Lors de sa première activation, il laisse les mesures inchangées jusqu’à recevoir une mesure fiable après une période de chauffe complète. Cela l’empêche de créer un faux événement s’il commence à traiter les données au milieu d’un arrêt avec des mesures erronées.

Un après-midi, avant et après

Les données enregistrées par le traceur pendant un après-midi, retraitées par le flux. La ligne grise apparaît uniquement là où les deux séries diffèrent.

Heure	Mesure du traceur	Valeur reçue par la plateforme	Ce qui s’est passé
15:44:31	24,9 L	24,9 L	Bus stationné
15:44:34	0,0 L	24,9 L	Le moteur démarre et la première mesure est du bruit
15:45:17	5,4 L	24,9 L	Le moteur est éteint après 43 secondes. Le traceur conserve sa dernière mesure
16:32:34	21,6 L	24,9 L	Nouveau démarrage, 47 minutes plus tard. La période de chauffe commence
16:40:44	26,2 L	26,2 L	La période de chauffe est terminée et les mesures sont de nouveau fiables
16:47:23	62,5 L	26,3 L	Un plein a lieu juste après un nouveau démarrage, donc le flux attend
17:00:10	62,3 L	62,3 L	Le nouveau niveau s’est maintenu pendant 5 minutes avec le moteur en marche, il est donc accepté

Comment nous avons vérifié que cela fonctionne

Avant de l’utiliser sur un vrai bus, nous avons testé le flux avec des traceurs virtuels qui reproduisaient les pires situations de la flotte. Parmi elles, la chute de 47 minutes, un plein entre plusieurs démarrages brefs, du carburant volé pendant un trajet, des mesures tombant à zéro en cours de route et l’activation du flux pendant un arrêt avec des mesures erronées. Les neuf scénarios de test ont été validés. Nous l’avons ensuite testé avec un vrai traceur sur notre banc d’essai.

Nous avons également retraité toutes les données enregistrées, soit environ 34 000 messages de trois bus sur trois jours en août 2026, avec les mêmes règles. Nous avons compté les variations brusques de plus de 3,5 litres entre deux messages consécutifs. Pour deux des bus, le flux déterminait si le moteur tournait à partir du régime moteur.

Un seul fichier suffit pour le déployer. Importez le flux, choisissez les véhicules et activez-le. Aucune intervention sur les véhicules ni modification des traceurs, des capteurs ou des règles d’alerte n’est nécessaire. Désactiver le flux permet à la plateforme de réutiliser les mesures brutes.

La même idée s’applique bien au-delà du carburant

On retrouve souvent le même problème avec d’autres données. Une valeur n’est fiable que dans certaines conditions. Dans ce cas, le flux vérifiait l’état du contact, le temps écoulé depuis le démarrage et la stabilité du nouveau niveau. D’autres mesures problématiques peuvent être vérifiées selon les conditions qui leur correspondent.

• Alertes de vitesse excessive causées par des sauts de position GPS. Ne considérez qu’un véhicule dépasse la vitesse autorisée que si suffisamment de satellites sont visibles et que la vitesse reste élevée pendant 10 secondes.
• Capteurs qui ont besoin d’un temps de chauffe. Ignorez les mesures de température ou de pression pendant les premières minutes après la mise sous tension d’un appareil.
• Pics isolés. N’acceptez une nouvelle valeur que si elle se répète ou se maintient pendant une durée définie.

Ces conditions peuvent être appliquées avant qu’une mesure n’atteigne les rapports ou les alertes. Dans ce cas, un fonctionnement du moteur de 43 secondes ne ressemblait plus à un retrait de carburant suivi d’un plein, tandis que les changements qui duraient suffisamment longtemps continuaient de passer.

Pour créer des flux dans IoT Logic, commencez par la documentation IoT Logic. Si vous souhaitez savoir comment appliquer cette approche à votre flotte ou à vos capteurs, contactez notre équipe.