Представить традиционных автомехаников, взявшихся за программно определяемые автомобили — забавная мысль. С набором гаечных ключей и воздушных компрессоров наготове они могут растеряться, столкнувшись с основными функциями, которые с большей вероятностью работают на единицах и нулях, чем на масле и ремнях. Но сегодня в автомобильной промышленности все больше автомобилей оснащаются передовыми системами, созданными с использованием облачной разработки, непрерывной интеграции и доставки (CI/CD), быстрой цифровой итерации и большого количества ИИ.

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

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

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

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

Кабина уже работает в облаке

Команда Android за последние несколько лет вложила значительные силы и время в обеспечение бесшовной разработки множества цифровых систем в автомобильных кабинах. Android Automotive OS (AAOS) работает внутри официальной среды виртуального тестирования Google для Android, Cuttlefish, которая в свою очередь отлично функционирует на инстансах Google Cloud на базе архитектуры Arm. Благодаря такому подход разработчики могут создавать, загружать и тестировать виртуальные версии своих информационно-развлекательных стеков на той же архитектуре Arm, которая поставляется в автомобилях.

А с недавним запуском Android 17 and AAOS SDV эта возможность распространяется и на другие домены при условии использования AAOS SDV. Развертывание этой ОС с Cuttlefish, например, доказывает жизнеспособность модели: релевантное ПО, на релевантной архитектуре, в облаке, по запросу. Вопрос, на который еще предстоит ответить, заключается в том, как распространить эту модель на остальную часть автомобиля, особенно когда задействованы другие операционные системы.

Обвязка вокруг виртуального автомобиля

Здесь в игру вступает RemotiveTopology. Будучи обвязкой вокруг виртуального автомобиля, это тот слой, который соединяет AAOS в Cuttlefish с полной симуляцией электрической и электронной (E/E) архитектуры: остальными бортовыми компьютерами автомобиля, его сетями передачи данных и живыми сигналами, которые заставляют систему функционировать как настоящий автомобиль, а не как набор автономных приложений.

RemotiveTopology автоматически использует существующие файлы сетевого проектирования производителей для создания работающей виртуальной версии автомобильных сетей. Это подход «автомобиль как код»: E/E-архитектура выражена в виде исполняемой спецификации, с поддержкой версий и развертыванием по принципу инфраструктуры как кода (infrastructure-as-code). Таким образом, весь автомобиль можно запустить по запросу. ПО кабины взаимодействует с остальной частью автомобиля точно так же, как и в реальном транспортном средстве. В результате разработчики получают полную и непрерывную видимость сигналов и междоменных связей, что позволяет им видеть состояние системы в реальном времени. А поскольку решение построено на стандартных инструментах Linux, та же топология работает как на ноутбуке, так и в конвейере непрерывной интеграции в Google Cloud.

Интегрируйте системы по доменам раньше, а не позже

Преимущество такого подхода заключается в том, что все бортовые системы могут быть разработаны и интегрированы с помощью программного обеспечения еще до того, как какая-либо из них будет подключена к аппаратному обеспечению автомобиля. Это полезно, поскольку самая сложная (и последняя) интеграция при разработке автомобиля — это объединение всех его систем. Например, передовые системы помощи водителю (ADAS) формируют списки объектов, траектории и запросы режимов, которые кабина должна отображать и на которые должна реагировать, в то время как информационно-развлекательная система и комбинация приборов должны отражать состояние вождения, а узлы кузова и шасси остаются в контуре управления.

Когда полная топология запущена в Google Cloud, информационно-развлекательная система и ADAS могут работать одновременно внутри виртуального автомобиля, обмениваясь реальными сигналами по смоделированной сети. Это означает возможность отрабатывать переходы — такие как появление события ADAS на приборной панели или изменение режима водителя, распространяющееся по доменам, — с первого дня непрерывной интеграции, задолго до того, как стенды и образцы будут готовы. Таким образом, разработчики могут быть уверены, что обнаружат проблемы многодоменной интеграции задолго до окончания процесса, чтобы тестировать систему непрерывно с самого начала.

Границы полноценного автомобиля

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

Конечная цель состоит в том, чтобы то же программное обеспечение, которое работает в облаке, могло выполняться на реальных модулях управления автомобиля без необходимости перенастройки или повторной валидации при переходе между ними. Такая идентичность естественна для облачной инфраструктуры Google Cloud на базе Arm, поскольку и облако, и автомобиль используют один и тот же набор инструкций. Проект Axion от Google упрощает эту задачу: C4A metal, инстанс Arm «голое железо» (bare-metal), предоставляется специально для разработки автомобильных систем и ПО для Android, обеспечивая прямой доступ к оборудованию без лишних программных уровней и гарантируя стабильную производительность, необходимую автомобильным системам.

В совокупности эта комплексная система позволяет командам впервые разработать и провести интеграционное тестирование систем всего автомобиля в облаке, а затем перенести результат на реальный автомобиль без необходимости переписывания кода.

Почему именно сейчас и с чего начать

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

RemotiveTopology предоставляет эту архитектуру в виде автомобильного кода (vehicle-as-code) и делает ее доступной для разработчиков, тестировщиков и автономных ИИ-агентов. Самое приятное то, что для начала работы не нужно осваивать новые сторонние инструменты. Вместо этого RemotiveLabs публикует упрощенный автомобиль с открытым исходным кодом на GitHub, который любой желающий может запустить за считанные минуты, используя стандартные инструменты Linux и уже существующие описания платформ. Полноценные существующие цепочки инструментов подключаются по мере масштабирования автопроизводителем или поставщиком первого уровня (Tier 1), а RemotiveTopology можно легко развернуть в среде Google Cloud на базе архитектуры Arm.

Для тех, кто создает программно-определяемые автомобили, чья виртуальная разработка ограничивается кабиной водителя, самое время начать с примера с открытым исходным кодом, использовать уникальные описания платформ и запустить весь автомобиль в облаке. RemotiveTopology доступна в Horizon для удобного использования в сочетании с другими модулями Horizon.