> 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/analytics/ru/explorer-for-iotquery/historical-reports.md).

# Исторические отчеты

Анализируйте закономерности датчиков, активности, поведения при вождении, смен, пробега, поездок и простоев за заданные периоды времени для оптимизации автопарка

Исторические отчеты превращают ваши операционные данные в стратегические выводы, анализируя закономерности, тренды и показатели эффективности за заданные вами периоды времени, что позволяет принимать решения на основе данных для оптимизации автопарка и планирования ресурсов.

## Отчет по измерительному датчику

![](https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-952970e16a2d04c34b63dedf81b6c6aafdd09187%2Fimage-20250813-124709.png?alt=media)

**Когда использовать**: Планирование управления уровнем топлива, прогнозного техобслуживания и выявление закономерностей в работе оборудования на нескольких транспортных средствах и за разные периоды времени.

**Какие данные вы видите**: Измерения датчиков временных рядов, агрегированные в статистические сводки, показывающие средние, минимальные и максимальные значения для каждого датчика за выбранный вами период.

<details>

<summary>Логика обработки данных</summary>

Система обрабатывает данные датчиков с помощью сложного анализа временных рядов:

* **Агрегация по временным интервалам**: Сырые показания датчиков группируются в 15-секундные интервалы с помощью функции PostgreSQL `time_bucket` создавая удобные для анализа точки данных из непрерывных потоков данных датчиков. Этот подход сочетает аналитическую точность с эффективностью обработки.
* **Корреляция данных нескольких датчиков**: Запрос соединяет `business_data.sensors_data_by_hours` с `raw_business_data.objects` для объединения измерений датчиков с контекстом транспортного средства. Когда доступны данные калибровки датчика, каждое показание датчика преобразуется в понятные единицы измерения (литры для топлива, градусы для температуры).
* **Статистический расчет**: Для каждого временного интервала система рассчитывает средние, минимальные и максимальные значения по всем показаниям. Если данные калибровки датчика отсутствуют или недействительны, необработанные значения отображаются без изменений, чтобы обеспечить прозрачность данных.
* **Фильтрация качества**: Проверка качества GPS гарантирует, что в контекст датчиков попадают только надежные данные о местоположении (спутников > 3, ненулевые координаты), а недействительные показания исключаются из статистических расчетов.

Все метки времени преобразуются в UTC для согласованного анализа независимо от географического положения транспортного средства, что позволяет точно выявлять тенденции в разных операционных зонах.

</details>

## Отчет по активности объекта

![](https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-db482b7e85e745b002ec281db2e66de626b1ef9e%2Fimage-20250813-124725.png?alt=media)

**Когда использовать**: Анализ оптимизации маршрутов, оценки использования транспортных средств и измерения операционной эффективности за заданные периоды и сегменты автопарка.

**Какие данные вы видите**: Комплексные метрики активности, включая общий пробег, длительность поездок, среднюю скорость и маршруты для каждого транспортного средства в выбранной вами части автопарка.

<details>

<summary>Логика обработки данных</summary>

Этот отчет объединяет исторические данные и данные в реальном времени с помощью сложного формирования треков:

* **Гибридное получение данных**: Система интеллектуально выбирает между `processed_common_data.trips` для исторического анализа и `raw_telematics_data.tracking_data_core` для свежих данных в зависимости от выбранного вами временного диапазона. Периоды длиннее 12 часов используют предварительно обработанные поездки для оптимальной производительности, а для недавних периодов поездки формируются из сырых телематических данных.
* **Восстановление трека**: Для анализа в реальном времени система применяет алгоритмы определения движения, используя пороги скорости (≥3 km/h) и временные промежутки (>300 seconds) для выявления отдельных поездок. Сырые данные координат (хранящиеся как целые числа) преобразуются в десятичные градусы делением на 10,000,000 для географических расчетов.
* **Расчет расстояния**: Географическое расстояние рассчитывается с помощью функций PostGIS для точных измерений между последовательными точками GPS, а расчет длительности основан на разнице меток времени между начальной и конечной точками трека.
* **Интеграция зон**: Географический анализ сопоставляет позиции транспортного средства с заданными зонами с использованием `ST_DWithin` вычислений, предоставляя операционный контекст для мест начала и окончания поездки.

Базовая структура запроса адаптируется в зависимости от выбранных параметров, оптимизируя получение исторических данных и формирование трека в реальном времени для предоставления комплексного анализа активности.

</details>

## Отчет по экономичному вождению

![](https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-9c1a786d0dd719779482e1cace9d6bc78b78fb78%2Fimage-20250813-124745.png?alt=media)

**Когда использовать**: Анализ безопасности водителя, отчетность по соблюдению требований страховки и оценка управления рисками автопарка для разработки целевых программ обучения и снижения операционных затрат.

**Какие данные вы видите**: Комплексный анализ поведения при вождении, включая нарушения скорости, события опасного вождения и рассчитанные оценки безопасности для каждого транспортного средства, с точными координатами GPS и метками времени для каждого инцидента.

<details>

<summary>Логика обработки данных</summary>

Анализ экономичного вождения обрабатывает телематические данные с помощью сложного выявления поведенческих закономерностей:

* **Обнаружение нарушений скорости**: Система непрерывно отслеживает скорость транспортного средства относительно настраиваемых ограничений, применяя льготные периоды и структуру штрафов по уровню серьезности. События превышения скорости требуют устойчивого нарушения (>60 seconds), чтобы не штрафовать кратковременные всплески скорости, а штрафные баллы масштабируются от легких нарушений (0-20 km/h over) до серьезных нарушений (>60 km/h over).
* **Анализ опасного вождения**: Расчеты ускорения в реальном времени анализируют изменения скорости по временным интервалам, чтобы выявлять торможение (>3.5 m/s² deceleration), ускорение (>3.0 m/s²) и резкие повороты с использованием порогов изменения курса (>30° at speeds >30 km/h). Каждое событие включает координаты GPS для анализа закономерностей с привязкой к местоположению.
* **Динамическая система оценивания**: Оценки безопасности рассчитываются на основе накопления штрафных баллов, нормализованных по пройденному расстоянию, что позволяет справедливо сравнивать разные длины маршрутов и операционные шаблоны. Система использует настраиваемые максимальные оценки с нормализацией по расстоянию, чтобы обеспечить последовательную оценку.
* **Документирование нарушений**: Каждое обнаруженное событие фиксирует точные координаты GPS, метки времени и показатели серьезности, создавая подробные журналы инцидентов для обучения водителей и отчетности по соблюдению требований.

Основной алгоритм обрабатывает агрегированные GPS-данные за 15 секунд из `raw_telematics_data.tracking_data_core`, применяя расчеты расстояния по haversine для точного географического анализа и вычисления ускорения на основе меток времени для поведенческой оценки.

</details>

## Отчет по сменам

![](https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-20f7651c32b680425f134a5c509ae2c7f619bac4%2Fimage-20250813-124757.png?alt=media)

**Когда использовать**: Анализ производительности персонала, выявление операционных шаблонов и измерение эффективности смен для оптимизации планирования автопарка.

**Какие данные вы видите**: Ежедневные сводки активности, показывающие общее операционное время, среднюю скорость, максимальную скорость и периоды активности каждого транспортного средства, сгруппированные по дате и рабочим сменам.

<details>

<summary>Логика обработки данных</summary>

Анализ смен обрабатывает сырые данные отслеживания через обнаружение операционных шаблонов:

* **Классификация движения**: Система анализирует показания скорости и временные интервалы, чтобы различать активное движение (≥3 km/h), временные остановки и периоды стоянки. Промежутки времени более 300 seconds запускают обнаружение нового периода активности.
* **Определение границ смены**: Сегментация трека использует настраиваемые пороги скорости и анализ временных промежутков для выявления отдельных операционных периодов. Каждый период смены включает точные метки времени начала и окончания с расчетом длительности.
* **Агрегация активности**: Ежедневные сводки объединяют все операционные периоды для каждого транспортного средства, рассчитывая общую длительность активности, среднюю операционную скорость и максимальную скорость, достигнутую в активные периоды.
* **Показатели эффективности**: Система формирует статистику использования, сравнивая активное операционное время с общим прошедшим временем, предоставляя сведения об эффективности для решений по управлению транспортом.

Проверка координат GPS гарантирует, что в расчет расстояния и скорости попадают только надежные данные о местоположении, а стандартизация меток времени в UTC обеспечивает согласованный анализ смен в разных географических областях.

</details>

## Отчет по пробегу

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-22f88d8a9c9db7d72ffcfb0ec226360c6143616b%2Fimage%20(18).png?alt=media" alt=""><figcaption></figcaption></figure>

**Когда использовать**: Анализ использования автопарка, оценка операционной эффективности и выявление шаблонов использования рабочего и нерабочего времени для оптимизации распределения транспортных средств и выявления несанкционированного использования.

**Какие данные вы видите**: Пробег, классифицированный по рабочим часам, нерабочим часам и выходным, с недельными тенденциями распределения, сравнениями по подразделениям и подробной разбивкой по активным дням и максимальной дистанции поездки.

<details>

<summary>Логика обработки данных</summary>

Анализ пробега транспортного средства обрабатывает данные GPS-трека через классификацию по времени и агрегацию расстояния:

* **Классификация временных категорий**: Система оценивает каждый сегмент GPS-трека по настраиваемым рабочим часам и календарным дням, чтобы классифицировать пробег по трем отдельным категориям. Пробег в рабочее время учитывает расстояние, пройденное в настроенные рабочие часы в будние дни, нерабочее время представляет поездки после окончания рабочего дня в будни, а пробег в выходные охватывает все движения в субботу и воскресенье независимо от времени. Эта классификация выполняется на уровне сегмента трека, при этом каждая часть поездки назначается на основе ее метки времени.
* **Расчет расстояния**: Географические измерения расстояния используют алгоритмы координатной геометрии для расчета пройденного расстояния между последовательными точками GPS. Система обрабатывает сырые данные о местоположении из `raw_telematics_data.tracking_data_core`, преобразуя координаты, хранящиеся как целые числа (разделенные на 10,000,000), в десятичные градусы для точных расчетов расстояния по haversine.
* **Временная агрегация**: Анализ недельных шаблонов группирует сегменты трека по номеру недели ISO, суммируя расстояния внутри каждой временной категории. Система формирует как абсолютные итоги пробега (в километрах), так и процентные распределения, чтобы показать, как операционные шаблоны меняются от недели к неделе.
* **Анализ группировки**: Сравнения по подразделениям, объектам и водителям агрегируют данные отдельных транспортных средств в организационные единицы. Система рассчитывает средний месячный пробег на транспортное средство, деля общее расстояние на количество активных дней и приводя его к 30-дневным месяцам, что обеспечивает справедливое сравнение между разными периодами анализа.
* **Обнаружение активности**: Расчеты активных дней определяют календарные даты с зафиксированным пробегом на основе анализа меток времени трека. Определение максимальной дистанции трека обрабатывает отдельные сегменты поездки, чтобы выявить самый длинный непрерывный маршрут для каждой группы, используя пороги обнаружения движения (≥3 km/h) и анализ временных промежутков (>300 seconds) для разделения отдельных поездок.

Проверка качества GPS гарантирует, что в расчет расстояния попадают только надежные данные о местоположении (спутников > 3, ненулевые координаты), а стандартизация меток времени в UTC обеспечивает согласованную классификацию по времени независимо от географического положения транспортного средства.

</details>

## Отчет по поездкам

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-d5c2c30103045d80fa71ba91e24ff1eb197458cb%2Fimage%20(1)%20(1).png?alt=media" alt=""><figcaption></figcaption></figure>

**Когда использовать**: Анализ шаблонов поездок, оценка оптимизации маршрутов и оценка операционного поведения для понимания частоты поездок, распределения расстояния и выявления необычных шаблонов поездок.

**Какие данные вы видите**: Метрики отдельных поездок, включая расстояние, длительность и среднюю скорость, с недельными тенденциями объема, сравнениями на уровне групп и полными подробностями по каждой поездке, показывающими время начала и окончания и назначения водителей.

<details>

<summary>Логика обработки данных</summary>

Анализ поездок транспортного средства выявляет и обрабатывает отдельные поездки с помощью интеллектуального определения движения:

* **Алгоритм обнаружения поездок**: Система анализирует данные GPS-трека и информацию о состоянии транспортного средства, чтобы выявлять отдельные поездки с использованием порогов скорости и времени. Поездка начинается, когда скорость транспортного средства превышает минимальный порог холостого хода (по умолчанию 3 km/h), и заканчивается, когда скорость опускается ниже этого порога на минимальную продолжительность простоя (по умолчанию 5 minutes). Краткие остановки короче порога простоя рассматриваются как паузы внутри той же поездки, а не как границы поездки, что позволяет отфильтровать кратковременные остановки в пробке или задержки при погрузке.
* **Расширенные параметры обнаружения**: Когда доступно, система использует статус зажигания и данные датчика движения для повышения точности обнаружения поездок. Такой многофакторный подход предотвращает ложное завершение поездок во время кратких неподвижных периодов, когда двигатель продолжает работать, обеспечивая завершение поездки только при значимых событиях парковки.
* **Расчет расстояния и длительности**: Для каждой обнаруженной поездки система рассчитывает общее расстояние с помощью географических функций PostGIS между последовательными точками GPS из `raw_telematics_data.tracking_data_core`. Длительность поездки определяется по разнице времени между первой и последней точками трека поездки. Расчет средней скорости делит общее расстояние на длительность, обеспечивая реалистичную рабочую скорость, которая включает любые краткие остановки во время поездки.
* **Временная агрегация**: Недельный анализ группирует поездки по номеру недели ISO, рассчитывая как количество поездок, так и накопленное расстояние. Такой двойной подход к метрикам показывает, связаны ли изменения объема операций с изменениями средней длины поездок — большое количество поездок при малом общем расстоянии указывает на множество коротких поездок, тогда как обратная ситуация предполагает меньшее число, но более длинные поездки.
* **Аналитика групповых сравнений**: Группировки по подразделениям, объектам, водителям и гаражам агрегируют данные о поездках для сравнительного анализа. Система суммирует общее расстояние, подсчитывает отдельные поездки и рассчитывает среднюю длительность поездок для каждой единицы. Эти метрики позволяют выявлять различия в операционных ролях — автопарки доставки показывают много коротких поездок, тогда как транспортные средства для Управление сотрудниками могут совершать меньше, но более длинные поездки.
* **Наличие данных о скорости**: Когда качество сигнала GPS недостаточно или не удается зафиксировать данные о скорости, система не может надежно рассчитать среднюю скорость. Обычно это происходит при потере сигнала GPS в местах с плохой видимостью спутников (тоннели, плотная городская застройка, подземные парковки) или при аномалиях обработки данных. В отчете для затронутых периодов отображается "Данные о скорости недоступны", что означает, что эти поездки требуют проверки или имеют неполные телематические записи.

Все метки времени поездок преобразуются в UTC для согласованного анализа в разных операционных зонах, а проверка качества GPS (спутников > 3, ненулевые координаты) гарантирует, что в обнаружение поездок и расчет расстояния попадают только надежные данные о местоположении.

</details>

## Отчет по простою

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-f0cccbfe333ac6522387e141ee7c1bcd1288303a%2Fimage%20(5)%20(1).png?alt=media" alt=""><figcaption></figcaption></figure>

**Когда использовать**: Оптимизация использования транспортных средств, анализ затрат времени простоя, оценка операционной эффективности и выявление чрезмерного простоя в конкретных местах для повышения производительности автопарка и сокращения расхода топлива.

**Какие данные вы видите**: Комплексный анализ времени простоя, показывающий часы в состояниях «Остановился» и «Стоит», процент использования, распределение статусов активности по времени и зонам, а также подробную разбивку с указанием основных мест простоя для каждого транспортного средства.

<details>

<summary>Логика обработки данных</summary>

Анализ простоя обрабатывает данные GPS и скорости с помощью сложной классификации движения, чтобы выявить и количественно оценить непродуктивное время транспортного средства:

* **Определение порога движения**: Система применяет настраиваемый минимальный порог скорости (по умолчанию 3 km/h) для классификации состояний активности транспортного средства. Когда скорость падает ниже этого порога, транспортное средство переходит в состояние остановки. Этот порог адаптируется к разным операционным контекстам — для строительной техники можно использовать более низкие значения, а для автопарков, работающих на трассах, более высокие, чтобы точно учитывать значимые периоды простоя.
* **Классификация остановок и стоянок**: Система различает краткие остановки и длительную стоянку с помощью временного анализа. Транспортное средство остается в состоянии остановки, когда стоит на месте, но переходит в состояние стоянки только после поддержания нулевой или почти нулевой скорости в течение минимальной длительности стоянки (по умолчанию 5 minutes). Эта иерархическая классификация гарантирует, что краткие остановки в пробке, задержки при погрузке или мгновенные паузы не будут классифицированы как стоянка, тогда как реальные события стоянки будут точно зафиксированы. Все время стоянки также является временем остановки, но не все время остановки считается стоянкой.
* **Агрегация состояний активности**: Для каждого транспортного средства система рассчитывает общее количество часов, проведенных в каждом состоянии — движется, Остановился и Стоит — обрабатывая данные GPS-трека из `raw_telematics_data.tracking_data_core`. Показания скорости проходят непрерывную оценку относительно порога движения, а переходы состояний фиксируются с точными метками времени. Расчет длительности суммирует время, прошедшее в каждом состоянии за период анализа.
* **Расчет простоя**: Общий простой представляет все время без движения (часы остановки + часы стоянки). Система рассчитывает простой как обратную величину использования — когда транспортное средство не движется, накапливается простой. Эта метрика дает полное представление о времени простоя независимо от того, кратко ли транспортное средство остановилось или полностью стоит.
* **Показатели использования**: Процент использования определяется как отношение времени в движении к общему времени активности: (часы движения / общие часы) × 100. Среднее использование по нескольким транспортным средствам рассчитывается по взвешенной формуле на основе общего времени активности каждого транспортного средства. Эти метрики позволяют справедливо сравнивать производительность транспортных средств с разными операционными шаблонами или периодами анализа.
* **Географический анализ простоя**: Система сопоставляет места остановки и стоянки с заданными зонами из `processed_common_data.zones_geom` с использованием пространственных функций PostGIS. Для каждого периода простоя координаты GPS оцениваются относительно границ зоны, чтобы определить, произошел ли простой в известном месте. Основная зона простоя представляет собой зону, в которой транспортное средство накопило больше всего часов в состоянии остановки или стоянки за период анализа.
* **Режимы визуализации времени**: Режим отображения Status показывает временные шаблоны активности, окрашенные по состоянию движения (движется, остановился, стоит), раскрывая, когда транспортные средства переходят между состояниями в течение дня. Режим отображения Zones окрашивает сегменты временной шкалы по географическому местоположению, а не по состоянию активности, показывая, в каких зонах находилось транспортное средство с течением времени. Такой двойной подход к визуализации позволяет проводить как анализ временных шаблонов, так и оценку географического распределения.
* **Агрегация по зонам**: При анализе простоя по зонам система группирует все периоды простоя по их географическому местоположению, рассчитывая общее количество часов остановки и стоянки в каждой зоне. Эта агрегация выявляет узкие места, где транспортные средства проводят слишком много времени в простое — например, погрузочные доки с долгим ожиданием, площадки клиентов с неэффективными процессами или несанкционированные места остановки.

Проверка качества GPS гарантирует, что в классификацию состояний и географический анализ попадают только надежные данные о местоположении (спутников > 3, ненулевые координаты), а стандартизация меток времени в UTC обеспечивает согласованный учет простоя в разных операционных зонах.

</details>

## Следующие шаги

Когда исторический анализ выявляет возможности оптимизации или вызывает конкретные операционные вопросы, переходите к [Конфигуратор пользовательского анализа и SQL](/docs/analytics/ru/explorer-for-iotquery/custom-analysis-sql-configurator.md) чтобы создавать специализированные исследования, отвечающие вашим уникальным требованиям к управлению транспортом и разрабатывать индивидуальные аналитические решения.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/analytics/ru/explorer-for-iotquery/historical-reports.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
