AI-аналітика телематичних даних автопарку

Візьмемо типовий автопарк із 200 вантажівок. Щодня вони генерують 50 ГБ даних: GPS-координати, показники CAN-шини, події датчиків. Без аналізу ці цифри лежать мертвим вантажем, а непродуктивні простої, агресивне водіння та витоки пального з'їдають до 25% операційного бюджету. Наші ML-рішення перетворюють сирий потік на конкретні метрики: скоринг водіїв із точністю 92%, передбачення відмов за 200 мото-годин до події, економія пального 12–15%. Середній проект окупається за 4–6 місяців, приносячи економію до 15 000 грн на одну машину на місяць. Аналогічне зниження Total Cost of Ownership (TCO) становить до 18% вже через півроку.

Ми спеціалізуємося на промисловій аналітиці автопарків: від інтеграції GPS і CAN-даних до продуктових ML-моделей, що працюють у реальному часі. Використовуємо фреймворки PyTorch і Hugging Face, розгортання через Triton Inference Server для low-latency інференсу. Наша система підтримує масштабування до тисяч транспортних засобів і обробку подій із затримкою менше 100 мс.

У результаті клієнти отримують не просто дашборд, а повноцінний інструмент для управління парком: driver scoring із контекстною корекцією, предиктивне обслуговування з упередженням поломок, оптимізацію маршрутів і пального. Впровадження займає від 3 тижнів до 3 місяців залежно від глибини інтеграції.

Дані телематики

GPS і рух:

• Координати з частотою 1–30 секунд
• Швидкість, азимут руху
• Геозони: в'їзд/виїзд із зон (клієнти, склад, заправки)

Дані автомобіля (через CAN/OBD):

vehicle_telemetry = {
    'engine_rpm': 'оберти',
    'vehicle_speed': 'швидкість з ECU (точніше GPS)',
    'fuel_consumption_instant': 'миттєва витрата л/100км',
    'fuel_level': 'рівень пального %',
    'coolant_temp': 'температура охолоджувальної рідини',
    'dtc_codes': 'коди несправностей',
    'odometer': 'пробіг',
    'ignition_status': 'увімкнено/вимкнено',
    'harsh_events': 'різке прискорення/гальмування/поворот'  # ±0.3-0.4g пороги
}

Події водія:

• Перевищення швидкості: > ліміт + 10 км/год, > ліміт + 20 км/год
• Різке прискорення / гальмування / поворот (harsh events) — з акселерометра
• Простій з увімкненим двигуном > 5 хвилин
• Використання мобільного телефону (якщо датчик є)

Чому скоринг водіїв з ML точніший за статичні правила?

Composite Driver Score:

def calculate_driver_score(driver_events, distance_km):
    """
    Нормалізована оцінка на 100 км пробігу
    """
    per_100km = lambda count: count / distance_km * 100

    score = 100  # початкова оцінка

    # Перевищення швидкості
    score -= per_100km(driver_events['speeding_minor']) * 2    # > +10 км/год
    score -= per_100km(driver_events['speeding_major']) * 5    # > +20 км/год

    # Harsh driving
    score -= per_100km(driver_events['harsh_acceleration']) * 3
    score -= per_100km(driver_events['harsh_braking']) * 4  # небезпечніше прискорення
    score -= per_100km(driver_events['harsh_cornering']) * 2

    # Холостий хід
    idle_minutes = driver_events['idle_minutes']
    score -= max(0, idle_minutes - 10) * 0.5  # > 10 хвилин = штраф

    return max(0, min(100, score))

ML-корекція умов:

Просте правило не враховує: затори (не вина водія), погана дорога (harsh events на вибоїнах), нічна зміна (втома). ML-модель коригує raw score з урахуванням контексту, забезпечуючи контекстний скоринг. Приклад фіч:

context_features = {
    'traffic_congestion_index': here_maps_traffic[route],
    'road_quality_index': osm_road_type,
    'weather_conditions': weather_api['conditions'],
    'time_of_day': hour,
    'trip_duration_hours': trip_hours
}
# Скоригований score = raw_score / context_adjustment_factor

Застосування:

• Рейтинг водіїв → навчання відстаючих
• Insurance telematics: знижки за безпечне водіння (UBI — Usage-Based Insurance)
• Гейміфікація: щотижневі/щомісячні лідерборди

Оптимізація маршрутів і витрати пального

Fuel Efficiency Analysis:

def analyze_fuel_efficiency(trips_df):
    """
    Питома витрата vs. норматив для даного типу авто та маршруту
    """
    # Очікувана витрата: LightGBM на основі дистанції, навантаження, рельєфу
    expected_consumption = fuel_norm_model.predict(trips_df[route_features])
    actual_consumption = trips_df['fuel_consumed_liters']

    efficiency_ratio = actual_consumption / expected_consumption

    # Ratio > 1.15 → водій витрачає на 15% більше норми
    over_consumers = trips_df[efficiency_ratio > 1.15]
    return over_consumers, efficiency_ratio

Idle Time Reduction:

Простій із заведеним двигуном — прямі гроші. Детекція шаблонів: де і коли відбувається зайвий простій:

• Ранкове "прогрівання" (у сучасних авто не потрібно > 1 хвилини)
• Очікування біля об'єктів клієнтів
• Обідня перерва з увімкненим мотором

ETA та оптимальні вікна:

ML ETA prediction (враховує затори, історичну швидкість на сегменті дороги) → планувальник вікон доставки.

Як предиктивне обслуговування знижує витрати на ремонт?

Патерни деградації:

def detect_component_stress(vehicle_id, telemetry_window_days=30):
    telemetry = get_telemetry(vehicle_id, days=telemetry_window_days)

    stress_indicators = {
        # Гальмівна система
        'brake_stress': telemetry['harsh_braking_per_100km'].mean(),

        # Двигун
        'engine_overrev': (telemetry['rpm'] > 4500).mean(),
        'coolant_spikes': (telemetry['coolant_temp'] > 100).sum(),

        # Трансмісія
        'high_load_hours': (
            (telemetry['engine_load'] > 80) & (telemetry['speed'] < 40)
        ).sum() / 60,  # години

        # Підвіска (з G-сенсора)
        'road_roughness_index': telemetry['vertical_acceleration'].std()
    }

    risk_score = component_stress_model.predict([list(stress_indicators.values())])
    return stress_indicators, risk_score

За нашими даними, перехід від регламентного ТО до стану з урахуванням реального навантаження скорочує витрати на обслуговування на 20–30% і знижує позапланові простої на 40%. Додаткова економія може досягати 20 000 грн на рік на одне ТС за рахунок запобігання дорогим поломкам. Предиктивне обслуговування дозволяє планувати ремонти точно вчасно.

Як впровадити AI-аналітику телематики: покрокова інструкція

1. Інтеграція даних. Підключаємося до GPS-платформи, CAN-шлюзів, OBD-адаптерів. Результат — стабільний потік сирих телеметричних даних за 1–2 тижні.
2. Базовий дашборд. Розгортаємо вітрину: завантаження парку, скоринг водіїв за правилами. Отримуєте дашборд Grafana/Kibana з ключовими KPI за 2–3 тижні.
3. ML-моделювання. Навчаємо моделі для контекстного скорингу, прогнозу пального, предиктивного ТО. Постачаємо API інференсу, інтеграція за 4–6 тижнів.
4. Продуктові функції. Додаємо сповіщення, гейміфікацію, звіти для керівництва. Система стає повнофункціональною за 2–4 тижні.
5. Тестування та введення в експлуатацію. Запуск у паралельному режимі, порівняння з фактом, коригування. Підписання акта приймальних випробувань — 2 тижні.

Що входить у роботу

Аналітика парку: ключові метрики

Строки під ключ: від 3–4 тижнів для базової версії до 2–3 місяців для повного функціоналу. Вартість розраховується індивідуально — залежить від кількості ТЗ, джерел даних та глибини ML-аналізу. Оцінимо ваш проект за 2 робочі дні після brief.

Гарантуємо: після впровадження ви отримуєте працюючу систему — не прототип, а промисловий інструмент. Замовте попередній аудит вашого парку — ми визначимо потенціал економії та підготуємо roadmap. Зв'яжіться з нами через форму на сайті або електронною поштою, щоб отримати консультацію інженера. Економія пального — лише перший крок, а повний ефект від AI Fleet Analytics розкривається в комплексному управлінні парком.

Наш досвід — понад 5 років у AI/ML, десятки впроваджень на автопарках від 50 до 2000 одиниць. Використовуємо відкриті фреймворки: PyTorch для навчання моделей і Hugging Face для обробки текстових даних (якщо є логи з коментарями водіїв).

Які проблеми прогнозування часових рядів зустрічаються найчастіше?

Фінансовий директор запитує прогнозування часових рядів продажів на квартал. Аналітик будує SARIMA, досягає MAPE 8.3% на тестовій вибірці — і з гордістю деплоїть. Через два місяці в production метрика падає до 23%. Причина класична: модель навчалася на даних до COVID, тестувалася на стабільному періоді, а production потрапив на промо-акцію та збій поставок. Data leakage + distribution shift = гарні цифри в ноутбуці та непрацюючий прогноз в реальності. Ми стикалися з цим десятки разів. Наш досвід — 5+ років у прогнозуванні часових рядів для рітейлу, фінтеху та IoT, більше 50 завершених проєктів.

Неправильна крос-валідація. Стандартний train_test_split для часових рядів — помилка. Випадкове розбиття створює data leakage: модель бачить «майбутні» значення в навчанні. Правильно — TimeSeriesSplit або walk-forward validation з expanding window.

Множинна сезонність. Погодинні дані споживання електроенергії мають три сезонності: добову (24 год), тижневу (168 год), річну (8760 год). SARIMA справляється лише з однією. Prophet обробляє кілька, але повільно масштабується на тисячі рядів.

Пропуски та аномалії в даних. Пропуск у сенсорних даних — це інформація (датчик відключився), а не просто NaN. Лінійна інтерполяція вбиває цей сигнал. Правильна обробка залежить від природи пропуску.

Cold start при ієрархічному прогнозуванні. Новий SKU в асортименті з 50 000 позицій: історичних даних немає, потрібен прогноз. Стандартні підходи тут не працюють — потрібні cross-learning підходи або feature-based методи.

Які інструменти і коли застосовувати?

Prophet (Meta) — чудовий старт для бізнес-даних із зрозумілою сезонністю та святами. Швидко налаштовується, інтерпретований, вбудована обробка викидів і пропусків. Падає в точності при нерегулярних патернах і не масштабується на десятки тисяч рядів без паралелізації. Prophet (Facebook) — офіційна документація.

Gradient boosting на фічах (LightGBM, XGBoost) — часто недооцінений підхід. Створюєте фічі вручну: лаги (t-1, t-7, t-28), ковзні середні, категоріальні ознаки (день тижня, місяць), екзогенні змінні. Модель навчається на всіх рядах одночасно — вирішує cold start через схожі ряди. MAPE на рітейл-прогнозуванні часто кращий за нейронні мережі при правильній feature engineering.

TFT (Temporal Fusion Transformer) — трансформер, спеціально розроблений для інтерпретованого прогнозування з коваріатами. Вбудовані механізми: variable selection (які ознаки важливі), temporal self-attention (які часові точки впливають на прогноз), квантильні передбачення. Доступний у pytorch-forecasting. Вимагає ~10 000+ записів на ряд для стабільного навчання. Temporal Fusion Transformer — академічна публікація.

PatchTST — трансформер, який ділить часовий ряд на патчі (аналогічно ViT для зображень). Краще захоплює локальні патерни, ніж класичні трансформери. Добре працює для long-horizon forecasting (прогноз на 96–720 кроків). Реалізація в neuralforecast від Nixtla.

N-HiTS, N-BEATS — нейронні архітектури без attention, швидші за TFT, конкурентна точність. N-BEATS виграє на M4/M5 benchmark для задач без коваріат.

Як ми розгортаємо TFT в production?

TFT потребує ретельної підготовки даних. Типовий пайплайн через pytorch-forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 днів
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 днів
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

Часта помилка: target_normalizer за замовчуванням (StandardScaler) ламає передбачення для рядів з нульовими значеннями (немає продажів у вихідні). GroupNormalizer з transformation="softplus" — правильний вибір для count-даних.

Покрокова інструкція з налаштування TFT

1. Збір та підготовка даних. Обробити пропуски (маркувати NaN, інтерполювати лише якщо це технічний збій), агрегувати до потрібної частоти, сформувати коваріати (свята, промо, ціни).
2. Створення TimeSeriesDataSet. Вказати group_ids (наприклад, магазин+SKU), часовий індекс, горизонт прогнозу. Налаштувати target_normalizer з урахуванням розподілу таргета.
3. Навчання baseline. Спочатку Prophet або LightGBM — щоб зрозуміти, наскільки складніше завдання.
4. Тренування TFT. Запустити TemporalFusionTransformer з loss=QuantileLoss(), підібрати learning rate та розміри hidden шарів. Використовувати pytorch_forecasting або neuralforecast.
5. Валідація та інтерпретація. Перевірити walk-forward, проаналізувати variable selection, побудувати attention heatmap.

Кейс: прогноз попиту в рітейлі. Мережа з 120 магазинів, 8000 SKU, горизонт прогнозу 28 днів. Вихідна система: SARIMA окремо для кожного ряду, MAPE 18.4%, повний цикл перенавчання — 6 годин. TFT на PyTorch + pytorch-forecasting: одна модель на всі ряди, MAPE 11.2%, перенавчання — 40 хв на A10G. Додатковий бонус: feature importance через variable selection — з'ясувалося, що day_before_holiday впливає сильніше, ніж сама дата свята. Середня економія бюджету на інференсі для клієнта склала значну суму.

Як правильно оцінювати якість прогнозів?

Не використовуйте RMSE як єдину метрику — вона сильно штрафує за великі помилки на великих значеннях. Наш набір метрик для рітейл-прогнозування:

• MAPE — інтерпретована, але нестабільна при значеннях близьких до нуля
• sMAPE — симетрична версія, уникає ділення на маленькі числа
• MASE (Mean Absolute Scaled Error) — нормалізована відносно наївного сезонного прогнозу, чудово підходить для порівняння між рядами з різними масштабами
• Quantile loss / Pinball loss — для ймовірнісного прогнозування, оцінка покриття інтервалів

Гарантуємо: ми надаємо model card з цими метриками на валідаційній вибірці та результати walk-forward тесту на історії не менше 6 місяців.

Що входить в роботу

• Документація щодо обраної архітектури, обґрунтування вибору гіперпараметрів.
• Відтворюваний пайплайн навчання та інференсу (Docker + CI/CD + Airflow/Prefect).
• Код з коментарями та модульними тестами на ключові компоненти.
• Навчання вашої команди: як перенавчати модель, як інтерпретувати виходи, як деплоїти нові версії.
• Підтримка протягом 3 місяців після здачі: консультації, виправлення багів, доналаштування.

Процес роботи

Починаємо з EDA: візуалізація, тест ADF на стаціонарність, STL-декомпозиція, аналіз пропусків та викидів. Це 2–3 дні, але часто виявляє системні проблеми даних, які блокують прогнозування.

Потім: baseline (наївний seasonal, Prophet), feature engineering для LGBM, вибір архітектури нейронної мережі якщо потрібно. Walk-forward validation з реалістичним горизонтом. Деплой через API з автоматичним перенавчанням за розкладом через Airflow або Prefect.

Строки орієнтовно: MVP-прогноз на одному типі даних — 3–6 тижнів. Ієрархічна система прогнозування з автоматизацією — 2–5 місяців. Вартість розраховується індивідуально.

Наша команда — сертифіковані ML-інженери (AWS ML Specialty, GCP Professional ML Engineer). За 5 років на ринку реалізували понад 50 проєктів з прогнозування. Зв'яжіться з нами для безкоштовного аналізу ваших даних — ми оцінимо завдання та дамо перші рекомендації за 1–2 дні. Замовте консультацію і переконайтеся, що ваші прогнози працюють в production, а не тільки в ноутбуці.