Компания Cognitive Pilot, разрабатывающая системы автоматического управления для сельхозтехники, раскрыла внутреннее устройство процесса тестирования своих автопилотов. Материал опубликовал руководитель отдела тестирования роботизированных систем, работающий в компании с 2020 года. Он начал карьеру с должности ведущего геодезиста на железнодорожном проекте, затем перешёл в автоматизацию и занялся созданием HIL-стендов и эмуляторов CAN-протоколов, а позже возглавил направление тестирования роботизированных систем. По его словам, сельхозтехника привлекла масштабом проекта и тем, что результат работы виден физически: ошибка проявляется не в логах, а в поле, когда трактор съезжает с рядка или комбайн не останавливается вовремя.

Ключевое отличие тестирования автопилотов от обычного программного обеспечения заключается в невозможности откатить последствия ошибки: неправильное решение системы приводит в движение многотонные машины. Поэтому максимум проверок выполняется до выезда в поле — на HIL-стенде с симулятором и на эмуляторах отдельных узлов. Система представляет собой не одно приложение, а бандл из планшетного приложения для механизатора, автопилота на вычислителе, CAN-сервисов, прошивок контроллеров актуаторов и веб-сервисов диагностики. У каждого компонента своя версия, и баг часто возникает на стыке двух из них. Добавляется множество конфигураций железа: комбайн, трактор, минитрактор и даже трамвай, разные вычислители, рулевые узлы (гидравлика через блок управления, электромоторы, Danfoss PVED-CL), планшеты на Android 7 и 10 с разным интерфейсом. Отдельно учитывается фактор реального времени: важна не только корректность, но и своевременность — частота кадров камер, работа ГНСС, IMU, время выполнения нейросети и планировщика. Сезонность добавляет сложности: настоящее поле с урожаем доступно лишь несколько месяцев в году, всё остальное время требуется убедительная замена.

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

По трудозатратам основная часть приходится на HIL-стенды, где сочетаются ручные проверки и автотесты, тогда как полевые испытания занимают меньший объём. Полный регресс одной версии бандла занимает 3–4 рабочих дня, а при проблемной сборке растягивается до 5–7 дней. Автотесты уже экономят на каждом регрессе 1,5–2 рабочих дня, что составляет около 30% времени, которое потребовалось бы без них, и эта доля растёт по мере автоматизации новых кейсов. Контроль качества начинается задолго до стенда — на производстве. За выходную продукцию отвечает ОТК, проверяющий соответствие ГОСТам, техническим условиям и конструкторской документации. Все платы и сенсоры проходят проверку на отказоустойчивость в климатической камере в диапазоне от −45 до +70 °C, а каждый вычислительный блок перед установкой подвергается автопроверке CAN-шин, камер, приёмников, накопителей, запущенного ПО, производительности обработчиков и FPS сенсоров на записи. Сводный отчёт по каждому блоку сохраняется в общей таблице.

Отдельного внимания заслуживает эволюция симулятора. Первая версия HIL-стенда работала на Farming Simulator 19: техникой и орудиями управляли через самописный мод на Lua. Однако ограничения игры в итоге привели к разработке собственного симулятора, тем более что как раз вышел Unreal Engine 5. Сейчас основной симулятор собственный, на UE5, а FS19 остался в прошлом — за несколько лет в нём так и не прошли ни одной миссии. Поля в симуляторе строятся на сплайнах: кромка поля, техколея, маркер разметки и другие элементы формируют реалистичную среду для проверки алгоритмов. Такой подход позволяет воспроизводить сценарии, которые сложно или дорого организовать на реальном поле, и делает тестирование воспроизводимым независимо от сезона.

Команда тестирования роботизированных систем состоит всего из трёх человек, но каждый имеет многолетний опыт работы с подобными системами. Работа ведётся по Agile на канбан-доске и синхронизируется со спринтами разработки: как только задача переходит из «В разработке» в «Тестирование», она берётся в работу. Результат помечается тегом прямо в комментарии — #qapass, #qafail, #qablock или #qaskip. Для сбора статусов по каждому тестировщику и по сборке написана небольшая утилита, которая также отслеживает изменения после проверки: если задачу изменили, статус становится «Expired» и её нужно перепроверить. Та же утилита сравнивает версии пакетов внутри бандлов и показывает, какие компоненты изменились, то есть что именно перетестировать. Такой подход позволяет небольшой команде удерживать контроль над сложной системой без раздувания штата и лишних согласований.

Для российского рынка сельхозтехники описанный подход показывает, как небольшая команда может выстроить полноценный процесс тестирования автономных систем в условиях ограниченного доступа к реальным полям и сезонности работ. Опыт Cognitive Pilot демонстрирует, что ставка на собственный симулятор и HIL-стенды позволяет сокращать цикл регресса и снижать риски дорогостоящих ошибок в поле. В перспективе остаются открытые вопросы: насколько полно удастся автоматизировать проверки, связанные с реальными сенсорами и погодными условиями, и как будет масштабироваться процесс при расширении продуктовой линейки. Тем не менее уже сейчас сочетание эмуляторов, симуляции на Unreal Engine 5 и полевых выездов формирует многоуровневую систему контроля, где каждый следующий этап отсеивает то, что не удалось поймать на предыдущем.