Android Automotive OS в ВКР: от мультимедиа к архитектуре software-defined vehicle
Google вывел Android Automotive OS за пределы информационно-развлекательного экрана и заявил о расширении «открытой инфраструктуры» на несafte-части бортового компьютера автомобиля. Если раньше ОС жила в магнитоле, то теперь речь идёт о настоящем software-defined vehicle — машине, где софт управляет большинством функций, кроме критичных для безопасности. Для выпускника ИТ это редкий шанс зайти в тему, где скрещиваются встраиваемые ОС, облако, OTA-обновления и кибербезопасность. Работодатели в автопроме и на промышленном Edge сейчас ищут именно таких специалистов. Разберёмся, как из новости сделать защищаемую ВКР, а не пересказ пресс-релиза.
Частые вопросы студентов по теме SDV
Что брать за основу: Android Automotive OS, QNX или AUTOSAR Adaptive?
Всё зависит от домена. Android Automotive OS — идеальный объект исследования для несafte-зоны (кластеры, HMI, телеметрия, сервисы). Для критичных по безопасности задач в авто принято ссылаться на QNX и AUTOSAR Adaptive, и об этом стоит написать в главе 1 как о смежных подходах. Не пытайтесь объять всё — в ВКР выигрывает узкий срез.
Где взять данные, если реального автомобиля нет?
Используйте публичные эмуляторы Android Automotive OS (эмулятор в Android Studio с образом Automotive), открытые репозитории AOSP, наборы трасс CAN-шины (OpenXC, comma2k19) и синтетические генераторы нагрузки. В главе 3 честно укажите: тестирование проводилось на эмуляторе, погрешность оценена так-то.
Какие метрики считать для OTA-обновлений?
Успешность доставки обновления (%), доля откатов (rollback rate), среднее время установки (MTTU), MTTR при неудачном апдейте, объём трафика на одно обновление, latency отклика сервисов после обновления. Все эти метрики хорошо ложатся в раздел «Эффективность» и легко защищаются на слайдах.
Нужна ли отдельная модель угроз для «несafte»-контура?
Да, и это сильный ход для ВКР. Несafte-контур не означает «безопасный» — именно через него злоумышленник может добраться до шлюзов и CAN-шины. Проработайте модель угроз по STRIDE или в терминах ISO 21434 и увяжите с OWASP-практиками для API.
Темы ВКР, которые можно собрать из этой новости
-
Тема 1. Проектирование сервисной архитектуры Android Automotive OS для несafte-домена автомобиля.
Актуальность: Google расширяет «открытую инфраструктуру» на бортовой компьютер, и производителям нужна типовая сервисная модель.
Цель: разработать архитектуру сервисов для не-safety-частей SDV с изоляцией от критичных модулей.
Задачи: анализ AOSP/Car Service; выбор hypervisor-модели; проектирование C4-диаграмм; обоснование границ изоляции.
Структура: Гл.1 — обзор SDV и фрагментации ПО; Гл.2 — проектирование (C4, UML, AIDL-интерфейсы); Гл.3 — нагрузочное тестирование эмулятора и оценка задержек. -
Тема 2. Оценка эффективности OTA-обновлений в software-defined vehicle на базе Android Automotive.
Актуальность: чем больше функций уходит в софт, тем чаще нужна безопасная доставка обновлений.
Цель: построить конвейер OTA и оценить его метрики.
Задачи: спроектировать CI/CD для артефактов; реализовать staged rollout; собрать телеметрию (OpenTelemetry); сравнить стратегии A/B-обновлений.
Структура: Гл.1 — обзор OTA-стандартов и Uptane; Гл.2 — реализация пайплайна и collector'а метрик; Гл.3 — эксперименты и таблица метрик. -
Тема 3. Модель угроз и защита канала обновлений для head-unit и вспомогательных ECU.
Актуальность: интеграция Android в «мозг» авто расширяет поверхность атаки за пределы мультимедиа.
Цель: построить модель угроз и предложить меры защиты канала обновлений.
Задачи: STRIDE/threat modeling; анализ OWASP API Top 10; проверка подписи пакетов; оценка риска.
Структура: Гл.1 — классы атак на SDV; Гл.2 — проектирование защищённого пайплайна (mTLS, подпись, PKI); Гл.3 — сценарии пентеста и метрики покрытия.
Куда именно вставить статью в текст диплома
Глава 1. Аналитическая
Новость The Verge — идеальный триггер для раздела «Тенденции». Опишите переход Android Automotive от мультимедиа к не-safety контуру, подкрепите ссылкой и добавьте проблему фрагментации: производители собирают авто из десятков модулей разных вендоров. Здесь же уместно сравнить подходы — QNX, AUTOSAR Adaptive, Android Automotive — в таблице по критериям: лицензия, домен применения, поддержка OTA, сертификация.
Глава 2. Проектная
Вводите архитектуру. Минимум — C4-диаграмма: контекст (авто ↔ облако ↔ мобильное приложение), контейнеры (Head Unit, Gateway, OTA-Orchestrator, Backend), компоненты Car Service и VHAL. Для интерфейсов между сервисами используйте UML Component и AIDL-описания. Схему V-модели разработки тоже стоит показать — она отлично объясняет, почему несafte и safety-контуры разделены.
Глава 3. Экспериментальная
Собирайте телеметрию и считайте метрики. Ниже — минимальный конфиг OpenTelemetry Collector, который принимает OTLP от эмулятора и раскладывает метрики по бэкенду. Такой листинг легко защищается как «часть реализации системы мониторинга».
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch: {}
attributes/sdv:
actions:
- key: vehicle.domain
value: infotainment
action: upsert
exporters:
prometheus:
endpoint: "0.0.0.0:8889"
service:
pipelines:
metrics:
receivers: [otlp]
processors: [attributes/sdv, batch]
exporters: [prometheus]
Диаграммы и метрики
| Артефакт | Где использовать | Зачем на защите |
|---|---|---|
| C4 (Context/Container) | Глава 2 | Показывает границы доверия и изоляцию несafte-контура |
| UML Component | Глава 2 | Обосновывает модульность и развязку сервисов |
| STRIDE / ISO 21434 | Глава 3 | Формализует перечень угроз и мер |
| Метрики OTA (success rate, MTTU, rollback) | Глава 3 | Даёт измеримую эффективность |
Чему вы научитесь, пока пишете эту ВКР
- Проектировать отказоустойчивые схемы с чётким разделением safety и non-safety доменов.
- Строить CI/CD для доставки OTA-артефактов и staged rollout.
- Настраивать сбор телеметрии через OpenTelemetry и считать прикладные метрики.
- Оформлять архитектурные схемы по UML/C4 и ТЗ в соответствии с ГОСТ 34 и ГОСТ 19.
- Формализовать модель угроз и обосновывать меры по ISO/IEC 25010 и OWASP.
- Задачи из введения дословно совпадают с выводами глав — иначе снимут баллы.
- Схемы (C4, UML) пронумерованы, подписаны и упомянуты в тексте до их появления.
- Метрики в главе 3 имеют формулу, единицу измерения и базу сравнения.
- Термины SDV, OTA, VHAL расшифрованы при первом употреблении.
- Оформление ссылок и рисунков соответствует ГОСТ 7.32 и требованиям вуза.
- Листинги кода вынесены в приложения, в тексте — только ключевые фрагменты.
- Антиплагиат по вашей теме проверен, цитаты из новости оформлены корректно.
- Путают Android Auto и Android Automotive OS. Первое — зеркалирование телефона, второе — полноценная ОС в авто. В статье речь именно о второй, и в тексте это надо развести с самого начала.
- Игнорируют разделение safety/non-safety. Нельзя проектировать архитектуру Android в контуре управления тормозами — только в несafte-зоне. Это принципиальный момент для защиты.
- Не измеряют результат. Один листинг без метрик — половина оценки. Обязательно приводите числа: успешность обновлений, задержки, объём трафика.
Источник: Google’s Android Automotive is moving from the dashboard to the ‘brain’ of the car (опубликовано 2026-03-24)