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 тижні.

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

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