> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Comprendre les zones grises dans les rapports de niveau de carburant
Les zones grises dans les rapports de niveau de carburant proviennent de la logique de continuité des données, et non de relevés manquants. Couvre la validité du GPS par rapport à celle du capteur et la manière de réduire les lacunes de reporting.
### Vue d'ensemble
Les clients signalent parfois des zones grises ou des lignes discontinues dans les Rapports de niveau de Carburant, en supposant que la plateforme ne traite pas correctement les Données du capteur. Ce comportement peut créer de la confusion, car il peut sembler que les relevés des capteurs manquent ou sont ignorés.
En réalité, la plateforme continue de traiter correctement les Données du capteur. Les zones grises sont une conséquence de la logique de continuité des données de la plateforme, conçue pour éviter une interpolation inexacte entre de longues lacunes dans les Rapports.
Ce document explique comment la plateforme traite les Données du capteur, pourquoi des intervalles discontinus apparaissent et ce qui peut être fait pour les réduire.
### Données du capteur valides vs données GPS invalides
Le premier concept à comprendre est que la validité du GPS et celle du capteur sont indépendantes.
Une position est considérée comme invalide dans les cas suivants :
* Aucun satellite GPS n'est disponible.
* Moins de trois satellites sont disponibles.
* La latitude ou la longitude est égale à 0.
Bien que la position elle-même soit considérée comme invalide, les valeurs des capteurs contenues dans le même paquet restent valides et sont toujours traitées.
Par exemple :
Bien que la position GPS ne puisse pas être affichée sur la carte en raison de l'absence de satellites, la valeur de avl\_io\_9 (capteur de niveau de carburant) est toujours :
* Reçue
* Stockée
* Traitée
* Affichée dans les Rapports de Carburant
* Utilisée par IoT Logic
Autrement dit, des données GPS invalides n'invalident pas les Données du capteur.
### Continuité des Données du capteur
L'une des questions les plus fréquentes concernant les Rapports de niveau de Carburant est de savoir pourquoi le graphique affiche des segments discontinus, alors même que les relevés individuels des capteurs sont présents dans le rapport.
Du point de vue du client, ce comportement peut sembler incorrect parce que les valeurs des capteurs sont visibles, mais le graphique n'est pas rendu sous la forme d'une seule ligne continue. Dans de nombreux cas, les clients interprètent ces interruptions comme des données manquantes ou un traitement incorrect, alors qu'en réalité elles résultent de la logique de continuité de la plateforme.
#### Logique de continuité
La plateforme regroupe les relevés des capteurs en intervalles continus en fonction de l'écart de temps entre des enregistrements consécutifs.
Lorsque le temps écoulé entre deux relevés consécutifs des capteurs dépasse 30 minutes, la plateforme considère que l'intervalle précédent est terminé et qu'un nouvel intervalle commence. Par conséquent, le graphique est divisé en segments indépendants au lieu d'être rendu sous la forme d'une ligne continue.
Ce comportement est intentionnel et s'applique indépendamment du fait que les valeurs des capteurs avant et après la coupure de communication semblent cohérentes. La continuité du graphique est déterminée par l'intervalle de transmission plutôt que par la similarité des valeurs mesurées.
En conséquence, les relevés individuels des capteurs continuent d'être stockés, traités et inclus dans les Rapports, mais ils ne sont pas reliés visuellement lorsqu'ils appartiennent à différents intervalles de continuité.
#### Pourquoi la plateforme ne relie-t-elle pas les segments ?
L'objectif principal du moteur de rapports est de représenter uniquement les informations qui ont réellement été transmises par l'appareil.
Si la plateforme reliait automatiquement deux points séparés par une longue coupure de communication, elle supposerait implicitement ce qui s'est produit pendant la période où aucune donnée n'a été reçue. Comme la plateforme ne dispose d'aucune information décrivant le comportement du capteur pendant cet intervalle, toute ligne reliant ces points représenterait une estimation plutôt que des données réellement enregistrées.
Pendant une coupure de communication, de nombreuses situations ont pu se produire.
* La valeur du capteur a peut-être été complètement stable pendant toute la coupure de transmission.
* La valeur du capteur a peut-être augmenté progressivement au fil du temps.
* La valeur du capteur a peut-être diminué progressivement pendant l'intervalle.
* Un événement soudain, comme un ravitaillement ou un vol de Carburant, a pu se produire, mais n'a jamais été signalé en raison de l'absence de données.
* L'appareil lui-même a pu être hors-ligne ou avoir temporairement arrêté de transmettre des données pendant cette période.
Cette conception garantit que chaque ligne affichée dans le rapport représente une suite de mesures réelles plutôt que des hypothèses. Bien que cette approche puisse produire des interruptions visuelles dans le graphique, elle préserve l'intégrité des données et empêche les utilisateurs de tirer des conclusions fondées sur des informations qui n'ont jamais été transmises par l'appareil.
### Réduire les coupures de communication
Dans la plupart des situations, les intervalles discontinus proviennent de la configuration de l'appareil plutôt que du moteur de rapports lui-même.
Le premier aspect à examiner est la stratégie de transmission des données des capteurs. De nombreux appareils de suivi sont configurés pour transmettre les informations des capteurs uniquement lorsqu'un changement est détecté, au lieu d'envoyer des mises à jour périodiques. Bien que ce comportement réduise le trafic réseau et la consommation de bande passante, il produit naturellement de longues périodes sans relevés des capteurs lorsque la valeur mesurée reste inchangée.
Un autre facteur important est la fréquence de transmission de l'appareil. Augmenter la fréquence de l'intervalle de transmission aboutit généralement à des ensembles de données plus continus et donc à une visualisation des Rapports plus fluide.
La gestion de l'alimentation doit également être prise en compte. Selon la configuration de l'appareil, celui-ci peut passer en mode veille, en mode veille profonde ou dans un autre mode d'économie d'énergie lorsque le contact est coupé. Dans ces états, l'appareil peut continuer à communiquer avec le serveur au moyen de paquets de pulsation tout en suspendant temporairement les transmissions des capteurs. Bien que le serveur reconnaisse toujours l'appareil comme connecté, aucune nouvelle valeur de capteur n'est reçue, ce qui crée finalement de nouveaux intervalles de continuité.
Pour cette raison, le moyen le plus efficace de réduire les zones grises est d'examiner la configuration de l'appareil, notamment :
* Fréquence de transmission des capteurs.
* Priorité de transmission des capteurs.
* Transmission basée sur les événements ou périodique.
* Configuration des modes veille et veille profonde.
* Source d'alimentation de l'appareil et comportement du contact.
L'optimisation de ces paramètres permet à la plateforme de recevoir des relevés des capteurs plus fréquemment, ce qui se traduit par des intervalles continus plus longs et une représentation graphique plus complète, tout en préservant la précision et l'intégrité des données enregistrées.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.