> 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/ru/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Понимание серых зон в отчетах по уровню топлива
Серые зоны в отчетах по уровню топлива возникают из логики непрерывности данных, а не из-за отсутствующих показаний. Рассматриваются валидность GPS и датчика, а также способы уменьшить пробелы в отчетности.
### Обзор
Клиенты время от времени сообщают о серых зонах или разорванных линиях в отчетах по уровню топлива, предполагая, что платформа неправильно обрабатывает данные датчиков. Такое поведение может вызывать путаницу, поскольку может казаться, что показания датчиков отсутствуют или игнорируются.
В действительности платформа продолжает корректно обрабатывать данные датчиков. Серые зоны являются следствием логики непрерывности данных платформы, которая предназначена для предотвращения неточной интерполяции между длительными разрывами в передаче данных.
В этом документе объясняется, как платформа обрабатывает данные датчиков, почему появляются разорванные интервалы и что можно сделать, чтобы свести их к минимуму.
### Валидные данные датчиков vs. невалидные данные GPS
Первое понятие, которое нужно понять, заключается в том, что валидность GPS и валидность датчиков независимы.
Местоположение считается невалидным, когда:
* Нет доступных спутников GPS.
* Доступно менее трех спутников.
* Широта или долгота равна 0.
Хотя само местоположение считается невалидным, значения датчиков, содержащиеся в том же пакете, остаются валидными и всегда обрабатываются.
Например:
Хотя координаты GPS не могут быть отображены на карте из-за отсутствия спутников, значение avl\_io\_9 (датчик уровня топлива) по-прежнему:
* Получено
* Сохранено
* Обработано
* Отображается в отчетах по топливу
* Используется в IoT Logic
Иными словами, невалидные данные GPS не делают данные датчиков невалидными.
### Непрерывность данных датчиков
Один из самых распространенных вопросов, касающихся отчетов по уровню топлива, заключается в том, почему на графике отображаются разорванные участки, хотя отдельные показания датчиков присутствуют в отчете.
С точки зрения клиента такое поведение может казаться неверным, потому что значения датчиков видны, но график не отображается как одна непрерывная линия. Во многих случаях клиенты воспринимают эти разрывы как отсутствие данных или некорректную обработку, хотя на самом деле они являются результатом логики непрерывности платформы.
#### Логика непрерывности
Платформа группирует показания датчиков в непрерывные интервалы на основе разницы во времени между последовательными записями.
Когда прошедшее время между двумя последовательными показаниями датчиков превышает 30 минут, платформа считает, что предыдущий интервал завершен и начинается новый интервал. В результате график делится на независимые сегменты, а не отображается как одна непрерывная линия.
Такое поведение является преднамеренным и применяется независимо от того, выглядят ли значения датчиков до и после разрыва связи согласованными. Непрерывность графика определяется интервалом передачи данных, а не схожестью измеренных значений.
В результате отдельные показания датчиков продолжают сохраняться, обрабатываться и включаться в отчеты, но они не соединяются визуально, когда относятся к разным интервалам непрерывности.
#### Почему платформа не соединяет сегменты?
Основная цель механизма отчетности состоит в том, чтобы отображать только ту информацию, которая действительно была передана устройством.
Если бы платформа автоматически соединила две точки, разделенные длительным разрывом связи, она бы неявно предположила, что происходило в период, когда данные не поступали. Поскольку у платформы нет информации, описывающей поведение датчиков в течение этого интервала, любая линия, соединяющая эти точки, представляла бы собой оценку, а не реально зарегистрированные данные.
Во время разрыва связи могли произойти многочисленные ситуации.
* Значение датчика могло оставаться полностью стабильным на протяжении всего разрыва в передаче данных.
* Значение датчика могло постепенно увеличиваться со временем.
* Значение датчика могло последовательно уменьшаться в течение интервала.
* Могло произойти внезапное событие, например заправка или кража топлива, но оно никогда не было передано из-за отсутствия данных.
* Само устройство могло быть Оффлайн или временно прекращать передачу данных в этот период.
Такая конструкция гарантирует, что каждая линия, отображаемая в отчете, представляет собой последовательность реальных измерений, а не предположений. Хотя такой подход может вызывать визуальные разрывы на графике, он сохраняет целостность данных и не позволяет пользователям делать выводы на основе информации, которая никогда не была передана устройством.
### Сокращение разрывов в передаче данных
В большинстве ситуаций разорванные интервалы возникают из-за конфигурации устройства, а не из-за самого механизма отчетности.
Первый аспект, который следует проверить, — это стратегия передачи данных датчиков. Многие трекеры настроены на передачу данных датчиков только при обнаружении изменения вместо отправки периодических обновлений. Хотя такое поведение снижает сетевой трафик и потребление полосы пропускания, оно естественным образом создает длительные периоды без показаний датчиков всякий раз, когда измеряемое значение остается неизменным.
Еще одним важным фактором является частота передачи данных устройством. Увеличение частоты интервала передачи данных обычно приводит к более непрерывным наборам данных и, следовательно, к более плавной визуализации отчета.
Следует также учитывать управление питанием. В зависимости от конфигурации устройства оно может переходить в Sleep, Deep Sleep или другой режим энергосбережения при выключенном зажигании. В этих состояниях устройство может продолжать обмениваться с сервером пакетами heartbeat, временно приостанавливая передачу данных датчиков. Хотя сервер по-прежнему считает устройство подключенным, новые значения датчиков не поступают, что в итоге создает новые интервалы непрерывности.
По этой причине наиболее эффективный способ сократить серые зоны — это проверить конфигурацию устройства, включая:
* Частота передачи данных датчиков.
* Приоритет передачи данных датчиков.
* Передача по событиям или периодическая передача.
* Конфигурация Sleep и Deep Sleep.
* Источник питания устройства и поведение зажигания.
Оптимизация этих параметров позволяет платформе получать показания датчиков чаще, обеспечивая более длинные непрерывные интервалы и более полное графическое представление при сохранении точности и целостности записанных данных.
---
# 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/ru/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.