Назад

Как создать собственный отчет Качества вождения в DataHub

Andrew M., VP of Data and Solutions
Автор

Andrew M., VP of Data and Solutions

20 октября 2025 г.
Driver performance case study DataHub

Когда вы управляете сотнями транспортных средств, «стандартные показатели безопасности» не дают полной картины. Операционному отделу нужно отслеживать потери топлива, службе комплаенс требуются аудиты, а финансовому отделу нужны обоснованные цифры. Узнайте, как наш клиент в регионе LATAM создал в Navixy DataHub индивидуальный отчет по поведению водителей, который отвечал их бизнес-потребностям и дал измеримые результаты.

Ключевые выводы

  • Превращайте телематику в бизнес-доказательства. Коррелируйте поведение водителей с расходами, обслуживанием и страховыми KPI, используя SQL-готовые, верифицируемые данные.
  • Создавайте индивидуальную логику качества вождения. Определяйте пороговые значения и формулы подсчета очков в соответствии с вашими целями.
  • Предоставляйте аналитику быстрее. Передавайте данные телематики напрямую в BI-инструменты.
  • Вовлекайте водителей с прозрачной обратной связью. Используйте честную систему оценки для сокращения расходов на топливо, аварии и техобслуживание.

Кейс: как один логистический автопарк превратил телематические данные в систему улучшения качества вождения

Будем честны — большинство отчетов по качеству вождения скучны. Они перечисляют нарушения, назначают произвольные баллы и на этом всё. Но когда вы управляете 1200 грузовиками, сжигающими тысячи литров топлива в неделю, такая отчетность не дает результата. Вам нужна аналитика, которая объясняет поведение, а не просто наказывает за него.

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

Отправная точка: Слишком много данных, слишком мало ясности

Как и большинство крупных автопарков, этот логистический провайдер располагал большим объемом данных, чем мог когда-либо использовать — GPS-сигналы, метрики CAN-шины, журналы температуры и идентификаторы водителей. Однако их аналитические инструменты едва ли могли ответить на следующие вопросы:

  • Какие водители постоянно превышали скоростные лимиты в городских зонах?
  • Как резкие торможения коррелируют с увеличением затрат на техническое обслуживание?
  • И самый важный — действительно ли наши «показатели качества вождения» связаны с экономией, или это просто цифры на панели управления?

IT-команда пыталась собрать всё воедино через API и экспорт CSV. Результат: ночные марафоны в Excel, непоследовательные пороговые значения и панели управления, которые ломались каждый раз при обновлении телематической платформы.

«У нас было пять различных "официальных" отчетов по топливной экономичности, и ни один из них не совпадал», — признался их операционный директор. «Наш BI-менеджер превращался в переводчика».

Знакомство с Navixy DataHub: основа данных для реальной аналитики

Подключив телематические потоки к Navixy DataHub, команда получила прямой SQL-доступ ко всему массиву данных (скорость, обороты двигателя, направление и временные метки), организованному в структурированном бронзовом слое DataHub. Никаких API, скриптов опроса и ночных пакетных заданий.

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

  • Пороговые значения превышения скорости варьировались по регионам и типам дорог.
  • Весовые коэффициенты штрафов основывались на влиянии на затраты, а не на догадках.
  • Баллы нормализовались на 100 км, что позволяло справедливо сравнивать водителей коротких и дальних маршрутов.

Наконец, они перестали подгонять свой бизнес под программное обеспечение и заставили программное обеспечение соответствовать их бизнесу. Первая интерактивная панель была запущена в течение недели. За месяц у них появились тренды производительности по всем 1200 водителям — не просто уведомления, а контекст: какие маршруты, время или условия провоцировали рискованное поведение.

Многомерное влияние на бизнес

Главная победа заключалась не только в снижении расхода топлива (хотя они действительно сократили потребление на 11% за первые три месяца). Настоящий прорыв произошел благодаря вовлеченности водителей. Когда водители увидели, что логика оценки имеет смысл, а штрафы отражают реальные риски и затраты, они начали соревноваться в улучшении своих показателей.

В цифрах: расходы на техническое обслуживание снизились на 8%, страховые случаи уменьшились на 15%, и их страховщик обратил на это внимание. Компания сейчас ведет переговоры со своей страховой компанией о модели премий, основанной на использовании и построенной на тех же показателях качества вождения.


Практический чек-лист от логистического провайдера из LATAM

Это точный алгоритм, которому следовал клиент Navixy — логистический провайдер из LATAM — чтобы максимально эффективно использовать отчет по качеству вождения и превратить мониторинг поведения водителей в измеримое улучшение бизнес-показателей:

  1. Определите основной KPI: контроль расходов на топливо, снижение рисков или соблюдение требований.
  2. Разработайте диапазоны нарушений и весовые коэффициенты штрафов совместно с операционным и финансовым отделами.
  3. Создайте SQL для обнаружения событий превышения скорости, резкого торможения/ускорения и крутых поворотов.
  4. Нормализуйте оценки (на 100 км/час) для корректного сравнения показателей.
  5. Опубликуйте детализированные и сводные таблицы; подключите их к BI-инструменту через PostgreSQL.
  6. Запланируйте регулярные обзоры; корректируйте весовые коэффициенты по мере развития политик и сетей.

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


Практическое руководство: как создать индивидуальный отчет по качеству вождения в Navixy DataHub

С Navixy DataHub создание отчета по качеству вождения — это не заполнение шаблона. Это определение собственной логики без ограничений API и необходимости ночных выгрузок. Давайте рассмотрим, как это работает на практике.

Шаг 1. Определите входные данные

Исходные данные поступают непосредственно с телематических устройств: скорость, местоположение, направление движения и временные метки.

Шаг 2. Настройте пороговые значения и штрафы

Установите специфичные для бизнеса пороговые значения и весовые коэффициенты штрафов за нарушения при вождении:

  • Превышение скорости: баллы для диапазонов, таких как +0–20 км/ч, +20–40 км/ч и т.д. (могут группироваться по типу дороги/региону)
  • Резкое торможение: замедление сверх установленного порога.
  • Резкое ускорение: быстрое ускорение выше выбранного предела.
  • Крутые повороты: внезапные изменения курса на высоких скоростях.

Каждому событию можно присвоить штрафной балл, отражающий приоритеты бизнеса. Например, страховая компания может назначить более высокие штрафы за превышение скорости, в то время как оператор автопарка может больше сосредоточиться на резком торможении, которое увеличивает расходы на техническое обслуживание. Весовые коэффициенты штрафов отражают воздействие на затраты или риски. Финансовый и операционный отделы могут совместно управлять таблицей штрафов, чтобы она соответствовала бюджетам и политикам.

Шаг 3. Логика обнаружения событий (техническая часть)

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

3.1. Сбор правильных сигналов

Из Bronze слоя Navixy DataHub получите:

  • Скорость (для обнаружения превышения скорости и расчета ускорений).
  • Временные метки (для измерения изменений во времени).
  • Курс (для обнаружения резких поворотов).
  • Расстояние (для нормализации показателей на 100 км).

3.2. Обнаружение событий вождения

Каждый тип нарушения выявляется путем сравнения текущих значений с бизнес-пороговыми значениями. Реализуйте правила обнаружения с помощью SQL (или Python-блокнотов, которые считывают данные из SQL):

Обнаружение событий превышения скорости
При итерации по временному ряду, когда скорость > базового лимита, мы открываем (или продолжаем) «событие» превышения скорости. Когда скорость падает до лимита или ниже, мы закрываем событие и вычисляем:

  • Продолжительность (короткие всплески ≤ 60 секунд игнорируются как льготные),
  • Пик превышения лимита во время события.

Штраф за это событие представляет собой *фиксированные баллы, основанную исключительно на том, насколько сильно водитель превысил лимит:

  • 0–20 км/ч → speed_range1 баллов
  • 20–40 км/ч → speed_range2 баллов
  • 40–60 км/ч → speed_range3 баллов
  • 60 км/ч → speed_range4 баллов
def speeding_points(max_over, penalties):
if max_over < 20: return penalties['speed_range1']
if max_over < 40: return penalties['speed_range2']
if max_over < 60: return penalties['speed_range3']
return penalties['speed_range4']

Почему пик, а не продолжительность? Это упрощает политику и облегчает проверку: один четкий штраф за инцидент вместо математических расчетов «за минуту».

Обнаружение резких маневров (по ускорению)

Рассчитайте ускорение, сравнивая скорости в соседних точках:

  • Переведите км/ч в м/с и разделите изменение на время между точками.
  • Если замедление ниже порога торможения (например, −3,5 м/с²) и транспортное средство двигалось (≥ 10 км/ч), добавьте баллы harsh_brake.
  • Если ускорение выше порога ускорения (например, +3,0 м/с²) и скорость была ≥ 10 км/ч, добавьте баллы harsh_accel.
def mps(kmh):
    return kmh / 3.6

def detect_harsh_maneuvers(speeds, timestamps, decel_threshold=-3.5, accel_threshold=3.0, min_speed=10):
    points = {'harsh_brake': 0, 'harsh_accel': 0}
    for i in range(1, len(speeds)):
        prev_speed, curr_speed = speeds[i-1], speeds[i]
        dt_seconds = timestamps[i] - timestamps[i-1]

        # пропустить, если временная дельта слишком мала или скорость слишком низка
        if dt_seconds <= 0.1 or prev_speed < min_speed:
            continue

        acc = (mps(curr_speed) - mps(prev_speed)) / dt_seconds

        if acc < decel_threshold:
            points['harsh_brake'] += 1
        elif acc > accel_threshold:
            points['harsh_accel'] += 1

    return points

Обнаружение резких поворотов (по изменению направления)

При наличии двух последовательных GPS-точек мы оцениваем направление движения (курс). Резкий поворот фиксируется, когда изменение курса между точками превышает Ваш пороговый показатель (например, 150°), а транспортное средство движется со скоростью не менее минимального значения (например, 30 км/ч). Каждое обнаружение добавляет баллы harsh_turn.

from math import sin, cos, radians, atan2, degrees

def bearing_deg(lat1, lon1, lat2, lon2):
    phi1, phi2 = radians(lat1), radians(lat2)
    d_lon = radians(lon2 - lon1)
    y = sin(d_lon) * cos(phi2)
    x = cos(phi1) * sin(phi2) - sin(phi1) * cos(phi2) * cos(d_lon)
    return (degrees(atan2(y, x)) + 360) % 360

def delta_heading(h1, h2):
    return abs((h2 - h1 + 180) % 360 - 180)

def detect_sharp_turns(gps_points, speed_threshold=30, heading_threshold=150):
    sharp_turns = []
    for i in range(1, len(gps_points)):
        lat1, lon1, t1 = gps_points[i-1]
        lat2, lon2, t2 = gps_points[i]
        h1 = bearing_deg(lat1, lon1, lat2, lon2)
        if i < len(gps_points) - 1:
            lat3, lon3, t3 = gps_points[i+1]
            h2 = bearing_deg(lat2, lon2, lat3, lon3)
            delta_h = delta_heading(h1, h2)
            speed = calculate_speed(lat1, lon1, lat2, lon2, t1, t2)  # implement this
            if delta_h > heading_threshold and speed >= speed_threshold:
                sharp_turns.append((lat2, lon2, t2, delta_h))
    return sharp_turns

3.3. Агрегирование в баллы

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

  • По водителю: для сравнения производительности и выявления потребностей в обучении.
  • По парку: для оценки подверженности рискам и операционных расходов.
  • На 100 км: для нормализации по различным уровням использования транспортных средств.

Формула расчета баллов:

points_per_norm = (total_points / distance_km) * norm_distance # например, на 100 км 
score = max(0, max_score - points_per_norm) # ограничение нулем

Пример:
Если фургон проехал 250 км и набрал 8 баллов, при norm_distance = 100 и max_score = 100, то points_per_norm = (8/250)*100 = 3,2 → score = 96,8. Если фургон проехал 250 км и набрал 8 баллов, при norm_distance = 100 и max_score = 100, то points_per_norm = (8/250)*100 = 3,2 → score = 96,8.

Движок отчетности суммирует все нарушения в модель оценки. Например, один водитель может накапливать 45 штрафных баллов на 100 км, тогда как другой в среднем набирает только 12. Эти результаты напрямую влияют на бизнес-КПЭ: модели страховых рисков, прогнозирование технического обслуживания или цели устойчивого развития.

Шаг 4. Формирование отчета

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

  • Сводная таблица: общее количество нарушений по типам, накопленные штрафные баллы и нормализованные показатели (например, баллы на 100 км).
  • Детальная таблица: каждое нарушение с меткой времени, типом и штрафом. Эта таблица может использоваться для аудита, а затем визуализироваться в выбранном Вами инструменте BI через коннекторы PostgreSQL.

Такое двойное представление позволяет осуществлять как тактический контроль (кто что делал и когда), так и стратегический анализ (агрегированные показатели по транспортным средствам или временным периодам).

Заключение: превратите мониторинг поведения водителей в стратегию данных

Качество вождения часто рассматривается как дополнительная опция, как галочка в списке функций. Но как понятно из кейса, когда вы контролируете логику данных с помощью Navixy DataHub, это становится стратегическим инструментом. Он не превратит каждого водителя в святого за одну ночь. Тем не менее когда данные точны, прозрачны и соответствуют бизнесу, улучшения перестают быть лекциями и становятся культурой. Именно это обнаружил партнер Navixy в Латинской Америке, и все началось с четкого понимания того, что действительно важно.

Хотите изучить разницу между готовыми дашбордами и аналитикой для принятия решений? Свяжитесь с отделом продаж, чтобы включить возможности Navixy DataHub для Вашего бизнеса.