AI-система для снижения затрат на горючее: 8–15% экономии

AI оптимизация расхода топлива: где ломается учёт

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

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

Показательно, что ни один источник сам по себе не даёт ответа. Уровень в баке не отличает слив от честной заправки, трек не видит недолив, а путевой лист не знает про простой под погрузкой. Решение появляется, когда несколько независимых каналов сводятся в одну модель: AI-система для снижения затрат на горючее сопоставляет их по времени и месту, гасит погрешность измерений и отделяет реальный слив от ложной тревоги на уклоне.

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

Измеримый эффект: расход, простои, ресурс техники

Эффект считается не по ощущениям, а по отчётности, которая уже ведётся в парке: литры на километр и на моточас, наработка, число обращений в ремонт. Первое, что видно после запуска — снижение расхода топлива на 8–15% по сопоставимым маршрутам. Часть даёт обученная рекомендательная модель: она разбирает разгон, торможение, выбор передачи и работу на холостом ходу в разрезе конкретной машины и смены, и передаёт водителю подсказку до того, как он сожжёт лишнее.

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

Ресурс двигателя растёт как следствие того же режима: меньше холодных пусков под нагрузкой, меньше работы на повышенных оборотах без необходимости, ровнее тепловой режим. Для парка это означает более длинный срок службы до капитального ремонта и меньше внеплановых остановок по одной и той же единице.

Отдельный эффект — снятая нагрузка с диспетчеров. Рекомендации по маршруту, загрузке и заправке приходят в смену, а не разбираются постфактум по итогам месяца, поэтому решения принимаются там, где ещё можно что-то изменить. Итог сверяется по каждой машине до и после: экономия топлива автопарка становится цифрой в отчёте, а не обещанием.

Режимы работы: аналитика, подсказки, авто-ограничения

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

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

На практике режимы комбинируют: аналитика и контроль заправок работают постоянно, а ограничения включаются там, где уже накоплена статистика по маршруту. Такой набор даёт снижение затрат на горючее в пределах 8–15% без остановки парка и без риска «зажать» машину на сложном участке.

Внедрение: от аудита данных до передачи регламентов

Проект по AI-оптимизации расхода горючего начинается не с модели, а с данных: пока неизвестно, что и с какой частотой пишет телеметрия, любой прогноз строится на догадках. Поэтому первый шаг — аудит источников и оценка их пригодности под конкретную задачу.

1. Аудит данных телеметрии. Разбираем бортовые логи, датчики уровня, рейсы и заправки: частота опроса, пропуски, дрейф датчиков, расхождения между системами. На выходе — карта качества данных с перечнем разрывов, которые закрываем до обучения.
2. Схема интеграций. Определяем, откуда приходят данные и куда уходит результат: шлюзы, очереди, промежуточное хранилище, учётные и диспетчерская системы. Фиксируем задержку доставки и поведение при обрыве связи.
3. Настройка моделей. Собираем признаки: маршрут, профиль дороги, загрузка, сезонность, режим вождения, простой с работающим двигателем. Горизонт прогноза и пороги срабатывания подбираем так, чтобы рекомендации были выполнимы для водителя.
4. Проверка на истории. Прогоняем модель на закрытых периодах и сравниваем с фактическим расходом, включая рейсы с ремонтом и нештатные ситуации. Смотрим не среднюю ошибку, а устойчивость эффекта по всему парку.
5. Опытная эксплуатация. Запускаем на ограниченной группе машин в режиме рекомендаций, без автоматического вмешательства. Сверяем прогноз с фактом каждую смену, донастраиваем пороги, собираем реакцию диспетчеров.
6. Передача регламентов. Отдаём порядок работы с отчётами: что делать при отклонении, как пополнять данные, когда переобучать модель. Обучение диспетчеров и точка контакта по инцидентам закрывают проект.

Что остаётся у заказчика: модели, схемы, регламенты

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

• Настроенные модели — рабочие конфигурации с набором признаков, порогами срабатывания и границами применимости по типам техники и маршрутам, плюс процедура дообучения на новых данных.
• Карта источников данных — перечень датчиков расхода и уровня топлива, данных о заправках и сливах, позиционирования, справочников автопарка, с периодичностью поступления и ответственным за каждый источник.
• Документация по интеграциям — схемы обмена с телематикой, топливной и учётной системами: форматы, частота опроса, поведение при обрыве связи и повторной выгрузке.
• Политики доступа — роли диспетчера, аналитика и руководителя автопарка: что видно в интерфейсе, что выгружается, кто вправе менять пороги срабатывания.
• Регламент реагирования на аномалии — слив, недолив, перерасход на рейсе, длительный простой с работающим двигателем: кому уходит сигнал, за какое время и какое действие предписано.
• Инструкции для диспетчеров — как разобрать сигнал, подтвердить или отклонить его, оставить комментарий по рейсу, чтобы обратная связь попадала в данные для дообучения.
• Журнал качества модели — доля ложных срабатываний, покрытие рейсов расчётом, расхождение расчётного и фактического расхода по контрольным группам.

Приёмка идёт по этим артефактам, а не по демонстрации: инженеры заказчика проверяют карту источников и политики доступа, диспетчеры проходят обучение на своём парке. Опишите задачу — вернёмся с оценкой и планом передачи.

Кейс автопарка: метрики до и после внедрения

Парк на 60 единиц: магистральные тягачи, среднетоннажные грузовики и развозные фургоны. До старта расход считали по путевым листам и чекам с заправок — расхождение с фактическим заливом доходило до 9%, а перерасход списывали на сезон и пробки. Единого норматива на маршрут не было: одна и та же модель на разных плечах показывала разброс до трети.

Меняли не машины, а контур учёта. Поставили датчики уровня в бак и считывание с бортовой шины, свели расход, моточасы и загрузку по каждому рейсу в один отчёт — Wialon. Дальше норматив считали на маршрут, а не на модель: загрузка, рельеф, число остановок, сезон. Отклонение больше 10% на плече поднимало сигнал механику в тот же день, а не в конце месяца.

Эффект распределился неравномерно, и это важно для планирования. На магистральных плечах экономия дошла до 15% — там длинный ровный участок и предсказуемая загрузка. На короткой развозке получилось 6–8%: плечо короче, холостой ход на погрузке занимает большую долю смены. Именно его сокращение почти вдвое и дало основную часть результата — меньшую, чем замена машин или топлива.

Чем отличается контроль расхода от прогноза потребления?

Контроль расхода топлива работает на факте: телеметрия уровня в баке, штатный расходомер, пробег и координаты. Система сопоставляет фактический расход с нормой на маршрут и помечает расхождение — слив, недолив при заправке, перерасход из-за стиля вождения или неисправности. Управленческое решение принимается уже после рейса, когда топливо израсходовано.

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

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

Поэтому на практике их не разделяют. Сначала наводят порядок в данных: калибровка датчиков уровня, отсечение ложных скачков на уклонах и прогревах, привязка заправок к первичным документам. На такой основе контроль перестаёт генерировать ложные сигналы, а прогноз укладывается в несколько процентов на рейс. Тогда «сколько залить» и «куда ушло» отвечают на один вопрос с двух сторон — разбираем, как это закрывается.

Технические сомнения: данные, интеграции, безопасность

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

Технику придётся доукомплектовывать?

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

Кто и что увидит в системе?

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

Обсудим задачу: какие данные нужны для оценки

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

• Телеметрия за несколько месяцев: расход, обороты, нагрузка на двигатель, время работы под нагрузкой и на холостом ходу — с привязкой к машине и времени.
• Данные по заправкам и сливам: ведомости, топливные карты, показания датчиков уровня, чтобы сверить фактический расход с расчётным.
• Маршруты и рейсы: путевые листы или выгрузки из системы мониторинга — протяжённость, тип дорог, рельеф, доля городских участков.
• Состав парка: типы машин, их назначение, возраст и нормативный расход по каждой группе.
• Загрузка: масса груза, число рейсов, доля порожних пробегов, сезонные пики и простои.
• Справочники и ограничения: регламент техобслуживания, правила работы водителей, кто согласует изменения процесса.
• Контакт на вашей стороне: инженер или диспетчер, который знает, как собирались данные, — поможет увидеть пропуски и искажения.

По этому набору мы считаем объём работ, выбираем базу для сравнения и границы пилота на части парка — обычно это одна группа машин со сопоставимыми маршрутами. Опишите задачу — вернёмся с оценкой и планом.