DOU Labs: как GlobalLogic помогает создавать автомобили будущего

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на [email protected].

Нашумевший за последний год автопилот Tesla и стремительный бум электрокаров — далеко не единственная причина всеобщего внимания к автомобильной индустрии. Традиционные производители авто также держат высокий темп в сфере инноваций и из года в год только увеличивают инвестиции в R&D и разработку ПО. Простой пример: в программном обеспечении современного high-end-автомобиля более 100 миллионов строк кода! Для сравнения в Boeing 787 «всего» чуть более 15 миллионов, а весь Facebook (вместе с back-end) помещается в 60+ миллионов строк кода. Еще больше удивительных открытий вас ждет в инфографике по ссылке, но речь сейчас не об этом.

Перспективность инноваций в автопроме — причина, по которой многие сервисные IT-компании, в том числе в Украине, стремятся войти на этот рынок. Их цель — предоставлять свои услуги по разработке ПО для известных автобрендов или компаний, которые что-то для этих автобрендов делают. GlobalLogic не исключение. Но мы пошли еще дальше, создав собственное программное решение, которое уже через несколько лет появится во многих современных автомобилях ведущих европейских и американских производителей. Речь идет о платформе Nautilus, которая служит для создания развлекательно-информационной системы современного авто (так называемая infotainment-система).

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

Смартфон на колесах

На практике «засунуть смартфон в автомобиль» не так уж просто. Ведь все автомобильные системы должны соответствовать строгим нормативам надежности и безопасности. Если операционная система вашего авто неожиданно зависает и уходит в перезагрузку, это может плохо кончиться для водителя и его пассажиров. Чтобы этого не произошло, автомобильные системы перед выходом на рынок тщательно тестируются, вот почему разработка таких решений занимает, как правило, 4-7 лет. За это время iOS и Android успевают обновиться уже много раз.

Платформа Nautilus — наше решение этой проблемы и возможность достаточно быстро создавать современные infotainment-системы для авто без угрозы надежности и безопасности. Суть решения в виртуализации на одном автомобильном компьютере двух операционных систем: автомобильной RTOS (например, Automotive Grade Linux) для управления всеми критически-важными функциями машины и Android — для построения информационно-развлекательной системы. Гибридная архитектура позволяет обезопасить критически важные функции автомобиля (CAN/MOST автомобильные сервисы, driver assistance и т.п.) от возможных сбоев Android (мультимедийные сервисы, навигация, облачные сервисы и сторонние приложения) и использовать вычислительные ресурсы автомобильного оборудования наиболее оптимальным образом.

От идеи к ее воплощению

Идея реализовать собственную систему виртуализации родилась в подразделении GlobalLogic, которое занимается embedded — встраиваемыми системами. Анализируя доступные на рынке решения, наши инженеры пришли к выводу, что наиболее эффективным будет развитие системы, построенной на продукте с открытым кодом (open source). Вариантов было несколько, но наш выбор пал на гипервизор Xen, который имеет уже достаточно долгую историю успешного применения в разных областях, например, data-центарах. Требования к надежности и безопасности последних никак не меньше требованиям к авто.

Xen, как opensource-продукт, позволил нам сконцентрироваться на решении новых необходимых конкретно автомобильной промышленности задач, а не реализовывать заново давно известные решения. Около 2-х лет понадобилось нашим инженерам, чтобы привнести и адаптировать лучшие решения виртуализации в Nautilus.

Как видно из схемы, первым на аппаратной платформе (SoC или System-on-Chip) запускается Xen, в котором виртуализируются два домена — один для Linux (или любой другой автомобильной RTOS), второй — для Android. Каждая система ответственна за свой набор сервисов и задач, которые никак не пересекаются.

Под капотом у Nautilus

Среди множества требований, предъявляемых к системам виртуализации, наиболее важные для embedded-систем — производительность и расширяемость, то есть добавление новых возможностей. Проанализировав Xen как возможную базовую платформу, наши инженеры приняли решение сделать основной акцент в Nautilus на виртуализации драйверов устройств (audio, USB и т. п.) и сопроцессоров, как наиболее востребованную функциональность в современном автомобиле.

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

В подавляющем большинстве случаев, даже если вы запускаете на автомобильном компьютере несколько виртуальных машин, каждая из них будет напрямую взаимодействовать с программным обеспечением (firmware или прошивками) графического сопроцессора, отправляя туда определенные команды и получая какой-то результат. Если в случае отправки неверной команды графическая подсистема выйдет из строя и уйдет в перезагрузку, какое-то время она будет недоступна ни для одной из виртуальных машин.

Мы придумали, как решить эту проблему, осознав, что вместо взаимодействия с реальным графическим сопроцессором, каждая виртуальная машина должна работать со своей собственной прошивкой для GPU. Если виртуальной машине № 1 нужно отработать какой-то графический запрос, она загружает в GPU свою версию прошивки, выполняет запрос и «выгружается», освободив ресурс графического сопроцессора для другой виртуальной машины. Такой цикл повторяется каждый раз, когда одной из виртуальных машин нужен ресурс GPU.

Xen сохраняет все состояния прошивок GPU в специальном виртуальном драйвере. Поэтому каждая виртуальная машина начинает работать с прошивкой графической подсистемы с того состояния, в котором она закончила делать это в последний раз. Таким образом, сессия каждой виртуальной машины изолирована и не подвержена влиянию другой виртуальной машины, даже если последняя вызвала в своей прошивке GPU какой-то серьезный сбой. Подобный подход очень повышает надежность графической подсистемы в виртуализированном пространстве и практически не сказывается на ее производительности (в нашем случае падение составило всего 5%). Для этого нам понадобилось существенно оптимизировать использование аппаратных ресурсов в ядре модуля и рационально управлять ими посредством Xen (подробнее о виртуализации GPU — в этой статье).

Еще одна важная особенность решения — использование Automotive Grade Android (AGA) в качестве основной системы для infotainment. Это адаптация Android под нужды автомобильной индустрии, призванная увеличить надежность и стабильность системы.

Например, обычное время загрузки Android — около 40 секунд. Это не критично для мобильного устройства, которое выключается или перезагружается редко. Но, повернув ключ в замке зажигания автомобиля, водитель, как правило, хочет немедленно ехать, а не ждать загрузки навигации и мультимедиа. Именно поэтому AGA был модифицирован таким образом, чтобы водитель мог использовать все мультимедийные сервисы уже через 5-7 секунд после подачи питания. Критически важные функции, как например, камера заднего вида запускается и того быстрее — уже за 1-2 секунды после начала загрузки системы, также оптимизировано время переключения между пользовательскими приложениями и камерой — все происходит в пределах десятых долей секунды.

При этом AGA обеспечивает все стандартные мультимедийные возможности Android — поддержку Bluetooth, Miracast, MirrorLink и Wireless Hotspots. Пользователи могут через облако получать данные о работе автомобиля, управлять многими функциями авто через смартфон, передавать контент со своего смартфона на экран автомобиля и т.п. Платформа также содержит дополнительные компоненты на основе различных мультимедийных сервисов, используя UPnP/DLNA, Audio/Video Playback и Radio. Таким образом, пользователь получает самые разные привычные ему возможности для мультимедийных развлечений в автомобиле.

Nautilus, который изменил нас всех

Как часто бывает в разработке программного обеспечения, новые проекты и новые продукты позволяют приобрести новые навыки, посмотреть на разработку программного обеспечения под другим углом, открыть новые горизонты. Nautilus стал знаковым для компании, он помог сформировать команду профессионалов, заинтересованных в инновациях и готовых реализовывать технически непростые, но интересные решения. Также благодаря Nautilus компания смогла построить партнерские отношения с ведущими отраслевыми ассоциациями, например, Linux Foundation и GENIVI Alliance, производителями автомобилей и автомобильных комплектующих, чтобы в тесном сотрудничестве с партнерами и потенциальными клиентами создавать востребованные для индустрии решения.

В течение нескольких лет мы демонстрировали наш прогресс с Nautlius на ключевых международных выставках, например, CES, а также на многочисленных конференциях. На CES 2017 мы продемонстрировали поддержку Android N и дополнительной автомобильной SoC-платформы. При этом мы неизменно получали положительные отзывы от ведущих игроков рынка. Это большое достижение, потому что до недавнего времени в автомобильной индустрии идея виртуализации особой популярностью не пользовалась. Теперь же у нас есть готовое решение виртуализации на архитектуре ARM, которая фактически становится стандартом в автомобильной индустрии и, по большому счету, все решения для индустрии соревнуются в качестве поддержки именно этой платформы.

Мультимедийная система автомобиля на стенде Texas Instruments (на выставке CES 2017) построена на платформе Nautilus

Мы планируем дальнейшее развитие проекта и реализацию многочисленных новых возможностей, чтобы ускорить появление на рынке таких многообещающих концепций как Connected Car, Autonomous Car и др.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




10 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Вообще-то Vehicle software в современном авто разнесены по ЭБУ. Нету центрального процессора, который управляет всеми ЭБУ. Каждый ЭБУ (и разные ЭБУ производятся совершенно разными производителями: отдельно для двигателя, отдельно для АБС, отдельно для подушек, отдельно для иммо,...) самодостаточен с точки зрения ПО, а для взаимодействия с другими ЭБУ используется обмен данными через CAN шину и не только. Поэтому, не совсем понятно, зачем нужна виртуализация, если каждый ЭБУ работает независимо от других, и для работы развлекательной системы достаточно создать самодостаточный ЭБУ, который будет обмениваться данными с другими, но ничего не будет знать о других ЭБУ, присутствующих в системе и никак не будет влиять на них.

RTOS в виртуальной машине как бы противоречит концепции операционной системы реального времени. Виртуальный Андроид должен быть одной из задач ,выполняемой в RTOS

Подобный подход очень повышает надежность графической подсистемы в виртуализированном пространстве и практически не сказывается на ее производительности (в нашем случае падение составило всего 5%).
Видео с двумя мониторами, если мне не изменяет память, ещё со времен CES2015. 60 fps там не видно, особенно на infotainment дисплее. На одной из презентаций GL сказала, что в glBenchmark 2.0 Egypt что-то около 22fps при виртуализации? Где тут 5%? Правда не было указано ни какой тест выполнялся, ни разрешение дисплея, ни других параметров, но результат чудовищно низкий даже для FullHD дисплея. Перефразируя Линуса, Talk is cheap. Show me your benchmark results :)

Как-то не очень понятно стремление угробить столько времени на допиливание морально и архитектурно устаревшего SGX5xx при том, что на рынке присутствует RGX 6-го и 7-го поколений с аппаратной виртуализацией. Так же непонятен смысл пилить J6 Ex столько времени, при его ограничениях по пропускной способности памяти, например, два дисплея 1920×720 потребуют только 660Mb/s только для обновления двух дисплеев, рендеринг 60 fps на обоих — это ещё столько же. HD камера забъёт гвоздь в гроб системы. Тут даже аппаратным QOS’ом не разрулить проблемы. Я уже молчу про writeback для анализа содержимого кластерной панели. А если подцепить HUD проектор?

Ну и предлагать платформу с поддержкой OpenGL ES 2.0 как инновацию, ну как то несерьёзно в 2017 году.

А если заказчик выберет JDI дисплей? Например, вот этот: www.j-display.com/…​sh/technology/innove.html с разрешением 2880×1080? Я не смог даже без виртуализации обеспечить его работу на приемлимом уровне на SGX544MP2.

Не проще ли поставить два SOCа? Это явно дешевле, даже для миллионного тиража. Виртуализация имеет большой смысл, когда надо запустить андроид авто и чтобы он ничего не сломал, но в других случаях практический смысл имеет только, если в наличии очень мощная платформа типа Intel ApolloLake или R-CarH3.

Почти все автомейкеры заявили ещё 1.5-2 года назад, что они переходят на 64 бита, потому как ограничение в 4Gb RAM или покалеченный LPAE режим уже мало кого устраивает. Большинство заказчиков умудряются положить на лопатки топовые RGX и Intel Iris, потому что хотят сделать красиво.

Теперь же у нас есть готовое решение виртуализации на архитектуре ARM, которая фактически становится стандартом в автомобильной индустрии
Вот только GPU везде разные, nVidia, Mali, Vivante, SGX/RGX, Intel Iris, etc.
и, по большому счету, все решения для индустрии соревнуются в качестве поддержки именно этой платформы.
Уже нет. Да и нет никакого смысла в соревновании качества поддержки ARM, если вся остальная периферия в SoC — это 99%, а сам процессор 1%.
Если операционная система вашего авто неожиданно зависает и уходит в перезагрузку, это может плохо кончиться для водителя и его пассажиров.

Так никто ж не ставит такое на инжекторы или систему охраны. Только отдельно. И связь с основными системами — через отдельный интерфейс с защитой.

Но, повернув ключ в замке зажигания автомобиля, водитель, как правило, хочет немедленно ехать

Вот именно — поэтому эта система вообще не должна влиять на основные функции автомобиля.

Простой пример: в программном обеспечении современного high-end-автомобиля более 100 миллионов строк кода!

То ли это как у Тойоты в системе газа, то ли включили вообще всё, вплоть до используемых раз в 10 лет возможностей того самого андроида. Хотелось бы доказательств (с ресурсов поприличнее, чем «инфографика по ссылке»), и с разделением по блокам (хотя бы — инжектор и вокруг, система охраны, и всё прочее).

Вот именно — поэтому эта система вообще не должна влиять на основные функции автомобиля.
Туда могут засунуть ADAS, но хотел бы я посмотреть в глаза тому архитектору (а такие есть). Обычно многие системы ADAS, такие как line departure warning system или traffic sign recognition строятся на базе специальных процессоров, например ST-ME EyeQ2, либо all-in-one, но на базе отдельного выделенного SoC. Про инжекторы и прочее даже речи нет. Это виртуализация, там нет реалтайма, вообще.
Чтобы этого не произошло, автомобильные системы перед выходом на рынок тщательно тестируются, вот почему разработка таких решений занимает, как правило, 4-7 лет.

habrahabr.ru/…​y/pvs-studio/blog/310862

Спасибо, очень интересная статья.

Молодцы! Примите мои искренние поздравления!

Ожидал увидить название концерна

Підписатись на коментарі