Автомобильная промышленность переходит от архитектуры, состоящей из множества децентрализованных вычислительных блоков, к архитектуре, которая объединяет множество функций в нескольких централизованных вычислительных блоках, позволяющих внедрять новые возможности, такие как обновления по беспроводной сети.
AAOS SDV использует существующую систему и инфраструктуру Android для предоставления решения. Кроме того, производители оборудования ищут решения, которые могут работать в облаке, поскольку это облегчает раннюю разработку и открывает новые возможности для тестирования.
Дизайн
Рисунок 1. Архитектура ядра SDV.
AAOS для SDV Core (SDV Core) — это операционная система, основанная на Android. В силу своей встраиваемой природы, она не использует стек JVM Android, а вся системная функциональность разработана нативно.
SDV Core в первую очередь разработан для виртуализированной среды, и некоторые проектные решения предполагают именно такую интеграцию. Тем не менее, запустить SDV Core можно и в нативном режиме, но это потребует больше работы по интеграции по сравнению с другими версиями Android.
SDV Core разработан для локальной распределенной системы, например, предполагается, что несколько экземпляров SDV Core (или его производных) работают рядом друг с другом либо на одном чипе, либо на нескольких системах и могут взаимодействовать через сетевое соединение. Поэтому ключевым аспектом архитектуры системы является реализация функциональности в виде сервисов, которые могут размещаться на любом из экземпляров.
SDV Core — это минимальный набор функций для разработки бортовых приложений для автомобилей. Типичный сервис получает несколько сигналов, обрабатывает их и передает результат другим сервисам. Это ограничение по области применения сделано намеренно, поскольку позволяет SDV Core работать на большом количестве SoC (систем на кристалле), которые могут не содержать передовых процессоров, и экономить средства.
Детальный дизайн
Рисунок 2. Подробная архитектура ядра SDV.
SDV Core основан на Android, поэтому его архитектура стремится максимально соответствовать Android. По сути, это означает, что SDV Core также использует GKI, драйверы, HAL и основные библиотеки Android, а также добавляет компоненты, необходимые для сервисной архитектуры.
В следующих разделах будут подробно рассмотрены компоненты системы.
Среда хоста и виртуализация
SDV Core разрабатывается с предположением, что он будет работать в виртуальной среде, поэтому мы делаем некоторые предположения относительно среды хоста:
В хост-среде работает гипервизор, поддерживающий устройства Virtio. Кроме того, гипервизор должен поддерживать Ethernet или vsock, состояния питания и блочные устройства. Более того, гипервизор должен поддерживать работу Android/Linux.
Что касается аппаратной части, SDV Core предполагает наличие процессора и блока управления памятью (MMU) с поддержкой аппаратной виртуализации, а также подключение системы через Ethernet. Система не обязана иметь графический процессор (GPU), межпроцессорный процессор (IPU), интерфейс CSI, медиадвижки, дисплей или другие автомобильные коммуникационные шины (например, CAN, LIN).
Базовая версия Android
SDV Core основан на Android, но сводит функциональность системы к основным системным функциям и добавляет среду выполнения SDV. Это означает, что SDV также использует GKI, собственные системные службы (например, adbd и logd ) и системные функции, но не включает JVM, службы на основе JVM или системные приложения, а также функции, реализованные для JVM.
Это также означает, что SDV будет адаптировать стратегию обновления Android и структуру разделов. У него схожие требования к безопасности, но отсутствует графический интерфейс пользователя.
GKI, драйверы и HAL
В SDV Core используется ядро Android GKI с ядром Android 6.1 . Преимущество использования GKI заключается в том, что изменения, внесенные в основной репозиторий, в конечном итоге попадают в Android. Кроме того, Android использует одно ядро для всех своих систем. Например, патчи применяются централизованно, а не к ядрам разных производителей.
Это также позволяет SDV иметь стабильный интерфейс ядра. Например, можно компилировать драйверы в виде модулей, работающих с GKI, даже если развернуто новое ядро с исправлениями безопасности операционной системы.
Для ядра GKI установлены фиксированные сроки: изменения от поставщиков, которые должны войти в следующее ядро GKI, должны быть включены в основную ветку ядра Linux до конца года.
В GKI драйверы устройств и модули, не требующие загрузки, будут компилироваться как модули ядра и будут содержаться в оперативной памяти (ramdisk), загружаемой на ранней стадии загрузки. Конфигурации устройств на самых ранних этапах, которые не могут ждать интерфейса модуля ядра (например, случайная инициализация), должны выполняться в дереве устройств. Модули ядра не обязательно должны быть включены в основную ветку разработки, но должны быть скомпилированы с учетом интерфейсов GKI.
Поскольку SDV Core предполагает, что он построен на основе гипервизора, совместимого с Virtio, драйверы поставляются в виде модулей ядра Virtio, если эта функция поддерживается, или в виде другого открытого стандарта (например, Open Profile для DICE и драйвер ядра open-dice для trust).
Такое сочетание Virtio (и открытых стандартов) и гипервизора приводит к аппаратной абстракции. Поэтому потребность в HAL в SDV минимальна, но некоторые из них все же необходимы из-за отсутствия поддержки Virtio. Например, HAL KeyMint для аппаратной криптографии и тесно связанный с ним HAL IRemotelyPrivisionedComponent для аттестации между виртуальными машинами SDV.
Сетевой и коммуникационный стек
Рисунок 3. Основной сетевой и коммуникационный стек SDV.
В отношении сетевого взаимодействия SDV Core предполагает наличие либо vsock, либо Ethernet для обмена данными между виртуальными машинами; для внутривиртуального взаимодействия также могут использоваться механизмы межпроцессного взаимодействия, такие как binder.
SDV поддерживает последовательную связь только в целях отладки.
Рисунок 4. Поддержка последовательного порта в ядре SDV для отладки.
В рамках одного гостевого приложения SDV предоставляет несколько вариантов, которые зависят от модели связи и требований к производительности.
Всок
VSock — это предпочтительный канал для локальной связи между несколькими виртуальными машинами или между хостом и виртуальной машиной. Виртуальные машины должны использовать прямую связь VSock друг с другом, чтобы оптимизировать количество копий.
Общая память
Разделяемая память используется только для связи с виртуальной машиной в рамках межпроцессного взаимодействия (IPC), но не предлагается в качестве обычного канала связи между несколькими виртуальными машинами. Хост может использовать разделяемую память для обмена информацией с гостевой системой, но это не предназначено для высокочастотного сетевого трафика.
ЭН
Для связи между несколькими SoC, то есть для внутрисалонной связи, будет использоваться Ethernet. Это могут быть как виртуализированные системы, так и нативные системы или устаревшие ЭБУ.
Сеть транспортных средств достаточно мала, поэтому адресного пространства IPv4 достаточно для идентификации всех доступных систем. Тем не менее, для обеспечения совместимости системы с потенциальными каналами связи и будущим развитием необходимо поддерживать IPv4 и IPv6.
VLAN
VLAN — это механизм создания виртуальных сетевых архитектур, позволяющий изолировать различные подсети и формировать локальные сети. Это может использоваться для создания различных зон безопасности, и именно для этой цели он применяется в автомобилях. Поддержка VLAN обязательна.
Протоколы
TCP и UDP
В зависимости от сценария использования система требует либо надежного, либо ненадежного, но быстрого протокола связи. Поэтому будут поддерживаться протоколы TCP и UDP.
Туннель данных
Data Tunnel — это недавно разработанный механизм связи для SDV, предлагающий быстрый канал связи по модели «публикация-подписка»: например, одно приложение публикует тему, а одно или несколько приложений могут её прослушивать. Внутри системы он использует либо общую память и FMQ (быстрые очереди сообщений) внутри виртуальной машины, либо vsock или Ethernet для связи между виртуальными машинами.
(SDV) RPC
SDV RPC реализует удаленные вызовы процедур для SDV с использованием Binder. Он использует предопределенный API для вызова удаленной процедуры. Подобно Data Tunnel, он использует либо общую память для связи внутри виртуальной машины, либо vsock или Ethernet для связи между виртуальными машинами.
Фреймворки
СОМЕЙП
SOMEIP используется для связи с системами, не поддерживающими SDV. Он построен на основе протоколов TCP и UDP и не требует специального оборудования или драйверов. Google разработает эталонный образец.
Агент обнаружения служб (SD Agent)
Он обеспечивает обнаружение сервисов, аутентификацию и авторизацию для SDV. Для связи он может использовать любой из ранее упомянутых методов. Для аутентификации и авторизации агенту SD потребуется доступ к оборудованию безопасности и работающая цепочка доверия.
Промежуточное программное обеспечение
Компания SDV разрабатывает фреймворк для упрощения использования всех этих различных протоколов, называемый промежуточным программным обеспечением (Middleware). Он также реализует источник достоверной информации для всех сигналов транспортных средств с помощью нового языка VSIDL.
Нейтральная зона
Для изоляции частей системы и предотвращения атак со стороны менее доверенной части (например, IVI с установленными пользовательскими приложениями) в сети могут быть введены различные зоны, включая демилитаризованные зоны. На практике это означает, что подсети физически или логически разделены, и через эти границы может проходить только трафик, включенный в список разрешенного.
Менеджер подключения
В Android распространена практика ограничения количества приложений и служб, которые могут самостоятельно открывать сокетные соединения. Вместо этого за открытие и управление соединениями отвечает центральный экземпляр. Поскольку Android реализует эту функциональность в Java-сервисе, SDV создаст собственный менеджер подключения.
Возможность обновления
Ключевой особенностью SDV является возможность обновления. Новые функции можно устанавливать на протяжении всего срока службы SDV посредством обновлений системы Android и пакетов APEX.
Обновления системы Android
Android уже предоставляет механизм для установки обновлений. В последних версиях используются A/B-обновления и виртуальные A/B-обновления, и SDV Core будет использовать этот механизм. A/B-обновления создают каждый раздел дважды, что дает два преимущества: система может обновляться в фоновом режиме, и если обновление не удается, система может откатиться к последней известной версии, чтобы продолжить работу.
Пакеты APEX
Помимо разделения системы на несколько разделов и обеспечения возможности их обновления, Android также предоставляет пакеты APEX — механизм для размещения приложений и библиотек в небольших пакетах, которые можно устанавливать и обновлять независимо от системных обновлений.
SDV Core будет использовать контейнеры APEX для динамической установки сервисов на экземпляре SDV, а также для управления развертыванием нескольких сервисов в рамках одного процесса: только сервисы, объединенные в один APEX и использующие один и тот же сертификат, могут быть развернуты в одном исполняемом файле, чтобы снизить риски безопасности.
Механизм установки пакетов APEX в Android использует некоторый код Java для управления APK-файлами и проверки пакетов. SDV Core потребуется реализовать нативную альтернативу, позволяющую динамически устанавливать пакеты APEX.
Управление обновлениями
Экземпляры SDV не являются полностью независимыми единицами в автомобиле и нуждаются в координации с другими экземплярами SDV и автомобильными сервисами. Например, для установки зависимостей сервисов или для обеспечения установки обновлений только в безопасном состоянии системы.
SDV рассматривает возможность использования разделов на нескольких виртуальных машинах. Это требует координации между этими виртуальными машинами, поскольку они зависят друг от друга по данным: должна быть основная виртуальная машина для обновления этих разделов, а также механизм уведомления других виртуальных машин об обновленном разделе и синхронизация для одновременного обновления всех виртуальных машин, чтобы гарантировать сохранение ранее известного рабочего состояния.
Начиная
В нашем руководстве по началу работы подробно описаны исходный код, сборка и запуск приложений с помощью Cuttlefish.