XEN і майбутнє automotive: як опенсорс-гіпервізор стає конкурентом комерційним автомобільним рішенням

Це історія в двох частинах – про новий етап розвитку automotive. В першій Алекс Агізім, CTO, Automotive & Embedded Systems, EPAM розповість про віртуалізацію в автомобільному комп’ютері. А також як і чому опенсорсний гіпервізор XEN може стати повноцінним конкурентом комерційним рішенням для автомобільної індустрії.

Одразу маю попередити — я не буду кидати в читача фрагментами коду та інженерними тонкощами. Мова йтиме про глобальні речі, які, як ми вважаємо, змінять автомобільну індустрію в найближчі 2-4 роки. Так само, як 12 років тому мобільні телефони змінилися назавжди з появою Android та Apple iOS.

В EPAM Automotive ми працюємо над двома великими блоками: віртуалізацією та хмарною платформою для деплойменту сервісів просто в автівку. Ця розповідь – про перший.

Якщо ви слідкуєте за автомобільною темою, то напевно помітили, як активно Google розвиває тему інфотейнменту зі своїм Android Auto OS. З кінця минулого року компанія уклала кілька стратегічних партнерств з автовиробниками щодо інтеграції Android Auto OS в автомобіль.

Але у виробників, як і раніше, є побоювання. Головна причина - безпека. В сучасних і майбутніх автомобілях Infotainment Cluster та Instrumental Cluster, що містить "життєво важливі" прилади та індикатори, стають єдиним цілим і використовують ті самі ресурси. Фізичні стрілки та індикатори змінилися зображеними. Однак водій повинен бачити правдиві показники швидкості, рівня паливу, стану гальмівної системи, двигуна, не зважаючи ні на що. Неприпустимо, якщо десь в дорозі екрани раптом зависнуть і вимагатимуть перезавантаження. А з досвіду смартфонів на Android ми знаємо, що це цілком ймовірно.

Виробники автомобілів вирішують таку проблему «в лоб»: ставлять два або більше комп'ютерів. Наприклад, перший опікується візуалізацією та обслуговуванням панелі приладів. А в другому бігає Android Auto OS і показує навігацію, музику, додатки тощо.

Цей варіант має певні мінуси. По-перше, кілька комп'ютерів все ж таки дорожчі за один. По-друге, ускладнюється імплементація: потрібно забезпечувати обмін інформацією між Android-частиною і insturmental cluster, узгодженість і безліч інших аспектів.

Інший варіант - за прикладом хмари використовувати віртуалізацію за допомогою гіпервізора. Потужностей і можливостей сучасних мікропроцесорів в автомобільних комп'ютерах цілком достатньо. До комп'ютера підключаються мінімум два екрани. Один - для Android - інфотейнмент. Інший - для обслуговування панелі приладів. Дві операційні системи бігають в ізольованих віртуальних машинах. Навіть якщо Android "втомиться" і впаде, перезавантажиться тільки та віртуальна машина, в якій він виконується.

З такою консолідацією ми можемо працювати на одному комп'ютері і зробити інтеграцію набагато простішою. Але і тут є нюанси.

У дата-центрі гіпервізор займається тільки тим, що нарізає процесор, пам'ять і сховище між різними віртуальними машинами. А ще стежить, щоб "віртуалки" не влазили у простір один одного. При цьому всі вони мають однаковий набір сервісів, який отримують від серверної платформи.

В автомобільному комп'ютері, крім CPU, оперативної пам'яті і сховища, є різні копроцесори для специфічних завдань. Наприклад, GPU, який потрібен і Android, і панелі приладів. Отже, завдання гіпервізора - надати можливість обом операційним системам користуватися копроцесорами. До того ж, зробити так, щоб Android не затикнув копроцесор якоюсь нелегальною командою або програмної помилкою.

Це вимога functional safety – Instrumental Cluster має працювати та не зважати на жодні «танці» Android. Тому гіпервізор має бути достатньо просунутим та мати спеціальні механізми, які забезпечують повну ізоляцію.

Апаратно таку ізоляцію вже забезпечують сучасні процесори. Ми ж беремо на себе програмну частину. А саме - модифікуємо опенсорсний XEN Hypervisor, щоб він міг працювати в автомобілі з урахуванням всіх нюансів середовища. У ньому ми передбачили наступні блоки.

По-перше, у комп'ютера багато периферії, кнопки, тачскрін network тощо. Віртуалізація периферії вже підтримується набором драйверів.

По-друге, ми віртуалізуємо GPU і копроцесори. Якщо одна з віртуальних машин щось зробить з будь-яким з копроцесорів в системі, то на роботі іншої віртуальної машини це жодним чином не позначиться.

По-третє, реалізована віртуалізація TEE Support - trusted execution environment. Це спеціальна, апаратно захищена зона в процесорі, яка виконує різні сек’юрні процедури. Але, оскільки операційних систем більше однієї, запити від них до TEE теж розділені.

Нижче можна побачити статус компонент та, якщо цікаво, подивитися код. 

Будь-яка операційна система керує живленням та продуктивністю і може переводити комп'ютер в режим низького споживання енергії у відповідності з поточними завданнями та завантаженням. Те саме може захотіти зробити і автомобільний Android: якщо немає поточних завдань, він вирішить відправити процесор в power save mode. Але ОС, яка відповідає за прилади, повинна продовжувати працювати. Цей конфлікт ми вирішуємо спеціальним розширенням гіпервізора. Воно контролює стан цілої системи і управляє живленням та продуктивністю.

Наступний момент – реал тайм. Система повинна працювати з гарантованим розкладом. Над цим ми теж працюємо в рамках XEN Real-Time Scheduler.

Останній у списку, але перший за значенням блок для майбутнього автоіндустрії. Виробники автомобілів сьогодні розуміють, що віртуалізаційний підхід допоможе їм створювати значно гнучкіші та потужніші системи для обслуговування digital cockpit. Для цього потрібен automotive-grade гіпервізор.

На ринку представлені 3-4 комерційних рішення automotive-grade гіпервізорів. Але усі комерційні продукти мають недоліки:

• Висока вартість ліцензії;
• Відсутність можливості з легкістю замінити дещо в ПЗ відповідно до власних потреб;
• Виробник за таке ломить чек та терміни;
• vendor lock.

Всі ці проблеми усуває опенсорсний гіпервізор. На початках безкоштовний. Є доступ до першоджерел, завдяки чому можна робити будь-які зміни. Для цього можна зібрати власну команду або звернутися до сервісних компаній. Зберігається повна свобода, адже під час зміні постачальника першоджерело залишається у виробника.

На шляху в опенсорс залишається остання, але ключова перепона. Відкритий гіпервізор для автомобіля повинен бути functional safety compliant. До недавнього часу всі вважали, що зробити його таким неможливо. Наразі є зрушення.

Останнім часом ми активно працюємо з XEN Hypervisor опенсорс ком'юніті. Завдання - адаптувати процес розробки, щоб XEN можна було сертифікувати по safety.

В кінці березня відбувся саміт у Кембриджі, де зібралися усі зацікавлені сторони. По-перше, це всі основні компанії, які займаються розробкою XEN: Citrix, ARM, Xilinx, Renesas, EPAM. По-друге, компанії, які займаються сертифікацією. По-третє, компанії, які надають інструменти для автоматичного аналізу системи і виявлення проблемних місць.

В результаті саміту ми розробили план, за яким можливо зробити опенсорс гіпервізор functional safety compliant. До кінця поточного року ми плануємо отримати конкретний набір необхідних артефактів, щоб під час інтеграції XEN в автомобільні комп'ютери їх можна було сертифікувати по safety.

XEN стає повноцінним конкурентом комерційним рішенням в автопромисловості і відбирає в них останній аргумент про відсутність safety сертифікації.

Зі свіжих новин - в середині липня відбувся Xen Developer Summit. Function Safety була однією з основних тем. Ми презентували підхід до вирішення Functional Safety.

Ймовірно, це питання виникло у деяких ще з самого початку.

Проєкт XEN існує з 2003 року і, в порівнянні з іншими опенсорсними рішеннями, він має дуже широкий деплоймент в дата-центрах. Проєкт став досить зрілим. З 2012 року XEN має нативну підтримку ARM-архітектури. А процесори саме цієї архітектури, в основному, використовуються в автопромисловості.

Крім того, ми провели велику роботу, проаналізували різні рішення і добилися дуже високих показників продуктивності. Наприклад, якщо продуктивність операційної системи, яка бігає на процесорі без віртуалізації, дорівнює Х, то на віртуальній машині це 0,96-0,97X. А в комерційних гіпервізорах падіння продуктивності може досягати 30%. Різниця виглядає переконливо.

Отже, XEN здається нам вдалим базовим рішенням. Тому EPAM драйвить цей проєкт. Є вже кілька європейських автовиробників, які займаються оцінкою рішення на базі XEN для майбутніх автомобілів з digital cockpit, Android всередині і іншими речами, про які я згадав вище.

Паралельно з цією великою історією ми розвиваємо власну connected vehicle платформу Aos. Її основна ідея в тому, що ми, з одного боку, даємо розробникам connected services можливість деплоїти їх просто в автомобільний комп'ютер, а з іншого - ізолюємо їх від критичних функцій, гарантуючи безпеку.