Разработка AI-систем для автономного транспорта и беспилотных систем

AI-системы для транспорта: где отказывает автоматика

AI-системы на транспорте устроены как связка «восприятие — решение — исполнение», и отказ возникает чаще всего на стыке блоков, а не внутри одного из них. Восприятие отдаёт уверенную, но неверную оценку сцены, планировщик принимает её за факт и строит траекторию — дальше ошибка не гасится, а накапливается. Поэтому автономное управление транспортом проверяют не по отдельным модулям, а по тому, как связка ведёт себя при расхождении источников.

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

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

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

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

Эффект от AI-систем в транспортном парке и на площадке

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

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

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

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

Форматы внедрения: от подсказок оператору до автономии

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

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

Этапы работ: от аудита данных до передачи в эксплуатацию

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

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

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

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

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

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

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

Кейс: автономная техника на закрытой территории

Опытную эксплуатацию запускали на карьере с грунтовыми дорогами: шесть единиц техники, маршрут «загрузка — переезд — разгрузка». До этого машины ехали под дистанционным управлением: оператор вёл одну-две единицы и вмешивался в среднем раз в шесть циклов — поправить курс у бровки, объехать лужу, подтвердить проезд перекрёстка. Цикл занимал около 14 минут, а ложных остановок набиралось 10–12 за смену: пыль, косое солнце и блики на кузове читались как препятствие.

Что изменили

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

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

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

Что делать, если телематика и диспетчеризация уже внедрены

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

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

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

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

Сбои на сложной дороге и ложные срабатывания: частые сомнения

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

Датчик отказал — система это заметит?

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

Данных для обучения мало — редкие сценарии останутся непокрытыми?

Редкое собираем целенаправленно: размеченные проезды на полигоне, синтетические сцены, дополнение отснятых фрагментов. Приёмка считает долю закрытых сценариев из перечня опасных, а не среднюю точность — по логике ISO 21448.

Как устроена передача управления оператору?

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

Обсудим задачу: режим работы и состав поставки под объект

Чтобы вернуться с оценкой и планом работ, а не с общими сроками, нам нужны вводные по объекту. Они определяют состав поставки, глубину проверок и то, какие этапы пойдут параллельно, а какие — только последовательно.

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

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