Исследовательская группа Сайтамского университета во главе с профессором Такуей Адзуми вместе с Astemo проверила систему сквозной трассировки CART в облачной среде для разработки беспилотных автомобилей. О результатах Сайтамский университет сообщил 3 октября 2026 года. Облака точек из симулятора CARLA передавались через ROS 2 приложению AUTOSAR Adaptive Platform для обнаружения объектов, после чего результаты возвращались в Autoware для формирования команд управления.

По сообщению Сайтамского университета, CART восстановила всю ожидаемую цепочку обработки со 100-процентным покрытием. Это позволило анализировать задержки не только внутри отдельных программных платформ, но и на границе между ROS 2 и AUTOSAR Adaptive Platform.

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

Испытательная среда объединила симулятор автономного вождения CARLA, стек Autoware на базе ROS 2, AUTOSAR Adaptive Platform и ранее разработанную CART. CARLA создавала облака точек, похожие на поток данных от лидара. Через ROS 2 эти данные передавались приложению на AUTOSAR AP для обнаружения объектов. Результаты затем через протокольные мосты возвращались в Autoware, где система формировала команду управления автомобилем.

CART объединяла события обеих платформ в одну последовательность. Разработчик мог видеть полный путь данных: от сенсорного ввода и обнаружения объекта до обмена сообщениями и команды исполнительному механизму. При проверенной нагрузке частота приема облаков точек составляла около 33 Гц. Трассировка также различала два варианта поведения: обнаружение объекта приводило к команде остановки либо исполнительная команда не выдавалась.

Представим условную цепочку. В момент T₀ симулятор передал облако точек, приложение на AUTOSAR AP распознало препятствие, а Autoware сформировала команду торможения. Если между этими событиями возникла задержка, единая запись помогает определить, на каком переходе она появилась. Это объяснение механизма, а не отдельный результат эксперимента.

В небольшом тесте компонент ara::log добавил около 0,03 МиБ к использованию памяти и мало нагрузил процессор. В отдельной офлайн-проверке преобразование журналов с 1 млн пар отправки и приема в формат трассировки заняло примерно одну секунду. Эти показатели нельзя без дополнительной проверки переносить на любую автомобильную конфигурацию.

Почему облачной проверки недостаточно

CARLA и программный стек работали на отдельных облачных экземплярах, а не на реальных автомобильных электронных блоках управления. Такая среда помогает приблизить испытание к условиям разработки и найти узкие места до переноса ПО на физическое оборудование. Но она не заменяет проверку на реальных электронных блоках или аппаратно-программном стенде. Кроме того, авторам еще предстоит решить задачу синхронизации часов разных вычислительных систем.

Авторы оценили платформу на уровне технологической готовности TRL 6, поскольку показали ее работу в релевантной симуляционной среде. Проверку на реальных электронных блоках управления или стенде аппаратно-программного моделирования (hardware-in-the-loop) они оставили на будущее. Для практического применения также нужны более масштабные испытания и автоматическое сопоставление сообщений между платформами.

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

Схема показывает, как облако точек из симулятора через ROS 2 поступает в AUTOSAR Adaptive Platform, результаты обнаружения возвращаются в Autoware, а CART объединяет события в одну сквозную цепочку

Фото: ThisIsEngineering / Pexels