> 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 ### 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 prêter à confusion, car il peut sembler que les relevés du capteur sont manquants ou 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 longs intervalles sans remontée de données. 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 contre données GPS invalides Le premier concept à comprendre est que la validité du GPS et la validité du capteur sont indépendantes. Une position est considérée comme invalide lorsque : * 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 du capteur 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 du manque de satellites, la valeur de avl\_io\_9 (capteur de niveau de carburant) est toujours : * Reçu * Stocké * Traité * Affiché dans les rapports de carburant * Utilisé 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 que les relevés individuels du capteur figurent dans le rapport. Du point de vue du client, ce comportement peut sembler incorrect, car les valeurs du capteur 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 du capteur en intervalles continus en fonction de la différence de temps entre les enregistrements consécutifs. Lorsque le temps écoulé entre deux relevés consécutifs du capteur dépasse 30 minutes, la plateforme considère que l'intervalle précédent est terminé et qu'un nouvel intervalle commence. En conséquence, le graphique est divisé en segments indépendants au lieu d'être affiché comme une ligne continue. Ce comportement est intentionnel et s'applique indépendamment du fait que les valeurs du capteur avant et après l'interruption de communication semblent cohérentes. La continuité du graphique est déterminée par l'intervalle de remontée des données plutôt que par la similitude des valeurs mesurées. Par conséquent, les relevés individuels du capteur continuent d'être stockés, traités et inclus dans les rapports, mais ils ne sont pas visuellement reliés lorsqu'ils appartiennent à différents intervalles de continuité. #### Pourquoi la plateforme ne relie-t-elle pas les segments ? L'objectif principal du moteur de génération 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 interruption de communication, elle supposerait implicitement ce qui s'est produit pendant la période au cours de laquelle 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 qu'une donnée enregistrée réelle. Pendant une interruption de communication, de nombreuses situations ont pu se produire. * La valeur du capteur a pu rester complètement stable pendant toute l'interruption de remontée. * La valeur du capteur a pu augmenter progressivement au fil du temps. * La valeur du capteur a pu diminuer 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 peut-être été hors ligne ou a 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 à partir d'informations qui n'ont jamais été transmises par l'appareil. ### Réduire les interruptions de communication Dans la plupart des situations, les intervalles discontinus proviennent de la configuration de l'appareil plutôt que du moteur de génération de rapports lui-même. Le premier aspect à examiner est la stratégie de remontée des données du capteur. De nombreux appareils de suivi sont configurés pour transmettre les informations du capteur 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 du capteur chaque fois que la valeur mesurée reste inchangée. Un autre facteur important est la fréquence de remontée des données de l'appareil. L'augmentation de la fréquence d'envoi conduit généralement à des jeux de données plus continus et donc à une visualisation du rapport plus fluide. La gestion de l'alimentation doit également être prise en compte. Selon la configuration de l'appareil, celui-ci peut passer en veille, en 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 signal de vie tout en suspendant temporairement les transmissions du capteur. Bien que le serveur reconnaisse toujours l'appareil comme connecté, aucune nouvelle valeur du capteur n'est reçue, ce qui finit par créer de nouveaux intervalles de continuité. Pour cette raison, le moyen le plus efficace de réduire les zones grises consiste à examiner la configuration de l'appareil, notamment : * Fréquence d'envoi des données du capteur. * Priorité de transmission du capteur. * Rapport basé 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 plus fréquemment des relevés du capteur, 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.