Автомобильная промышленность переходит от архитектуры со множеством децентрализованных вычислительных блоков к архитектуре, которая объединяет несколько функций в нескольких централизованных вычислительных блоках, что позволяет использовать новые функции, такие как беспроводные обновления.
В AAOS SDV используется существующая система и инфраструктура Android. Кроме того, OEM-производители ищут решения, которые могут работать в облаке, поскольку это упрощает раннюю разработку и открывает новые возможности тестирования.
Дизайн
Рисунок 1. Архитектура SDV Core.
AAOS for SDV Core (SDV Core) – это операционная система на базе Android. Поскольку это встроенная система, в ней не реализован стек JVM Android, а все системные функции разработаны нативно.
SDV Core в основном разрабатывается для виртуализированной среды, и некоторые проектные решения предполагают такую интеграцию. Тем не менее, SDV Core можно запустить нативно, но это потребует большего объема работ по интеграции по сравнению с другими выпусками Android.
SDV Core предназначена для локальной распределенной системы. Например, предполагается, что несколько экземпляров SDV Core (или производных) работают рядом друг с другом на одном чипе или в нескольких системах и могут взаимодействовать через сетевое подключение. Поэтому ключевым аспектом архитектуры системы является реализация функциональности в виде сервисов, которые могут быть размещены на любом из экземпляров.
SDV Core – это минимальный набор функций для разработки автомобильных приложений. Обычно сервис получает несколько сигналов, обрабатывает их и передает результат другим сервисам. Это ограничение сделано намеренно, чтобы SDV Core можно было запускать на различных процессорах, которые могут не содержать продвинутых движков, и экономить средства.
Подробный дизайн
Рисунок 2. Подробная архитектура SDV Core.
SDV Core основан на Android, поэтому его архитектура максимально приближена к Android. По сути, это означает, что SDV Core также использует GKI, драйверы, HAL и основные библиотеки Android и добавляет компоненты, необходимые для архитектуры сервиса.
Ниже подробно описаны компоненты системы.
Среда хоста и виртуализация
SDV Core разрабатывается с учетом того, что он будет работать в виртуальной среде, поэтому мы делаем некоторые предположения о хост-среде:
В хост-среде работает гипервизор, поддерживающий устройства Virtio. Кроме того, гипервизор должен поддерживать Ethernet или vsock, состояния питания и блочные устройства. Кроме того, гипервизор должен поддерживать запуск Android/Linux.
Что касается аппаратного обеспечения, SDV Core предполагает наличие ЦП и MMU с поддержкой аппаратной виртуализации, а также подключение системы через Ethernet. В системе не обязательно должны быть графический процессор, процессор обработки изображений, интерфейс CSI, медиадвижки, дисплей или другие автомобильные шины связи (например, CAN, LIN).
Android Base
SDV Core основана на Android, но в ней оставлены только основные системные функции и добавлена среда выполнения SDV. Это означает, что в SDV также используются GKI, нативные системные сервисы (например, adbd и logd) и системные функции, но не JVM, сервисы или системные приложения на основе JVM, а также функции, реализованные для JVM.
Это также означает, что в SDV будет использоваться стратегия обновления и схема разделов Android. Требования к безопасности у него такие же, но графического интерфейса пользователя нет.
GKI, драйверы и HAL
В SDV Core используется GKI-ядро Android с ядром Android 6.1. Преимущество использования GKI заключается в том, что изменения, вносимые в вышестоящие версии, в конечном итоге попадают в Android. Кроме того, на всех устройствах Android используется одно ядро. Например, исправления применяются централизованно, а не к ядрам нескольких поставщиков.
Это также позволяет SDV иметь стабильный интерфейс ядра. Например, вы можете скомпилировать драйверы как модули, которые работают с GKI, даже если развернуто новое ядро с исправлениями безопасности.
У ядра GKI фиксированный график. Изменения, которые должны войти в следующее ядро GKI, должны быть переданы в ядро Linux до конца года.
При использовании GKI драйверы устройств и модули, не требующие загрузки, будут скомпилированы как модули ядра и помещены на виртуальный диск, который загружается на раннем этапе. Очень ранние конфигурации устройств, которые не могут дождаться интерфейса модуля ядра (например, случайная инициализация), должны выполняться в дереве устройств. Модули ядра не обязательно должны быть в основной ветке, но должны быть скомпилированы с интерфейсами GKI.
Поскольку SDV Core предполагает, что он построен на основе гипервизора, совместимого с Virtio, драйверы поставляются в виде модулей ядра Virtio, если эта функция поддерживается, или в виде другого открытого стандарта (например, Open Profile для DICE и драйвера ядра open-dice для доверия).
Такое сочетание Virtio (и открытых стандартов) и гипервизора приводит к абстракции оборудования. Поэтому потребность в HAL в SDV минимальна, но некоторые из них все же необходимы из-за отсутствия поддержки Virtio. Например, KeyMint HAL для криптографии на аппаратной основе и тесно связанный с ним IRemotelyPrivisionedComponent HAL для аттестации между виртуальными машинами SDV.
Стек сетевых протоколов и протоколов связи
Рисунок 3. SDV Core Networking and Communication Stack.
Для работы сети SDV Core требуется, чтобы для связи между виртуальными машинами был доступен vsock или Ethernet. Для связи внутри виртуальной машины также можно использовать механизмы IPC, например binder.
SDV поддерживает последовательную передачу данных только для отладки.
Рисунок 4. Поддержка последовательного порта SDV Core для отладки.
В рамках одного гостя SDV предоставляет несколько вариантов, которые зависят от модели связи и требований к производительности.
Vsock
Vsock – это предпочтительный канал для локальной связи между несколькими виртуальными машинами или хостом и виртуальной машиной. Виртуальные машины должны использовать прямую связь vsock между собой, чтобы реализация могла оптимизировать количество копий.
Общая память
Общая память используется только для связи с виртуальной машиной для IPC (межпроцессного взаимодействия), но не предлагается в качестве обычного канала для связи между несколькими виртуальными машинами. Хост может использовать общую память для обмена информацией с гостевой системой, но это не предназначено для высокочастотного сетевого трафика.
Ethernet
Ethernet используется для связи между несколькими однокристальными системами, то есть для связи внутри автомобиля. Это могут быть как виртуализированные системы, так и нативные системы или устаревшие блоки управления.
Сеть транспортного средства достаточно мала, чтобы пространства адресов IPv4 было достаточно для идентификации всех доступных систем. Тем не менее, чтобы обеспечить совместимость системы с потенциальными восходящими каналами и будущими разработками, необходимо поддерживать IPv4 и IPv6.
VLAN
VLAN – это механизм создания виртуальных сетевых архитектур, позволяющий изолировать разные подсети и формировать локальные сети. Это позволяет создавать разные зоны безопасности, что и используется в автомобилях. Требуется поддержка VLAN.
Протоколы
TCP и UDP
В зависимости от сценария использования системе требуется либо надежный, либо ненадежный, но быстрый протокол связи. Поэтому будут поддерживаться TCP и UDP.
Туннель данных
Data Tunnel – это новый механизм связи для SDV, который предлагает быстрый канал связи по модели pubsub. Например, одно приложение публикует тему, а одно или несколько приложений могут ее слушать. Для связи внутри виртуальной машины используется общая память и FMQ (быстрые очереди сообщений), а для связи между виртуальными машинами – vsock или Ethernet.
(SDV) RPC
SDV RPC реализует вызовы удаленных процедур для SDV с помощью Binder. Для вызова удаленной процедуры используется предопределенный API. Как и Data Tunnel, он использует общую память для связи внутри виртуальной машины или vsock или Ethernet для связи между виртуальными машинами.
Компоненты Framework
SOMEIP
SOME/IP используется для связи с системами, не относящимися к SDV. Он основан на TCP и UDP и не требует специального оборудования или драйверов. Google реализует цифровой отпечаток.
Агент обнаружения сервисов (агент SD)
Она обеспечивает обнаружение сервисов, аутентификацию и авторизацию для SDV. Для связи могут использоваться любые из упомянутых выше способов. Для аутентификации и авторизации агенту SD потребуется доступ к оборудованию безопасности и работающей цепочке доверия.
Промежуточное ПО
В SDV разрабатывается фреймворк, который упрощает использование всех этих протоколов. Он называется промежуточным ПО. Кроме того, в ней реализован источник достоверных данных для всех сигналов автомобиля с новым языком 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 и используют один и тот же сертификат.
Механизм Android для установки пакетов APEX использует код Java для управления APK, чтобы проверять пакеты. В SDV Core потребуется реализовать нативную альтернативу, чтобы разрешить динамическую установку пакетов APEX.
Управление обновлениями
Экземпляры SDV не являются полностью независимыми блоками в автомобиле и требуют оркестрации с другими экземплярами SDV и автомобильными сервисами. Например, чтобы установить зависимости сервиса или убедиться, что обновления устанавливаются только в безопасном состоянии системы.
В SDV могут использоваться разделы на нескольких виртуальных машинах. Для этого требуется координация между виртуальными машинами, поскольку они зависят от данных друг друга. Должна быть основная виртуальная машина для обновления этих разделов, а также механизм уведомления других виртуальных машин об обновленном разделе и синхронизации для одновременного обновления всех виртуальных машин, чтобы гарантировать, что предыдущее известное рабочее состояние не нарушено.
Начало работы
В руководстве по началу работы вы найдете подробную информацию об исходном коде, сборке и запуске с помощью Cuttlefish.