Это история в двух частях — о новом витке развития automotive. В первой Алекс Агизим, CTO Automotive & Embedded Systems в EPAM, расскажет о виртуализации в автомобильном компьютере. А также как и почему опенсорсный гипервизор XEN может стать полноценным конкурентом коммерческим решениям для автомобильной индустрии.
Сразу должен предупредить — я не буду бросать в читателя кусками кода и инженерными тонкостями. Здесь речь пойдет о глобальных вещах, которые, как мы думаем, изменят автомобильную индустрию уже в ближайшие 2-4 года. Так же, как 12 лет назад мобильные телефоны навсегда изменились с появлением Android и Apple iOS.
В EPAM Automotive мы занимаемся двумя крупными блоками: виртуализацией и облачной платформой для деплоймента сервисов прямо в автомобиль. Этот рассказ — о первом.
Если вы следите за автомобильной темой, то наверняка заметили, как активно Google развивает тему инфотейнмента со своим Android Auto OS. С конца прошлого года компания заключила несколько стратегических партнерств с автопроизводителями по интеграции Android Auto OS в автомобиль.
Но у производителей по-прежнему есть опасения. Главная причина — safety. В современных и будущих автомобилях 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, etc… Виртуалиация периферии уже поддерживается набором драйверов.
Во-вторых, мы виртуализируем GPU и копроцессоры. Если одна из виртуальных машин что-то сделает с любым из копроцессоров в системе, то на работе другой виртуальной машины это никак не скажется.
В-третьих, реализована виртуализация TEE Support — trusted execution environment. Это специальная, аппаратно защищенная зона в процессоре, которая занимается исполнением различных секьюрных процедур. Но так как операционных систем больше одной, запросы от них к TEE тоже разделены.
Ниже можно увидеть статус компонент и если интересно посмотреть код
Любая операционная система управляет питанием и производительностью и может переводить компьютер в режим низкого энергопотребления в соответствии с текущими задачами и загрузкой. То же может захотеть сделать и автомобильный Android: если нет текущих задач, он решает отправить процессор в power save mode. Но ОС, которая занимается приборами, должна продолжать работать. Этот конфликт мы решаем специальным расширением гипервизора. Оно контролирует состояние всей системы и управляет питанием и производительностью.
Следующий момент — реалтайм. Система должна работать с гарантированным расписанием. Этим мы тоже занимается в рамках XEN Real-Time Scheduler.
Последний по очереди, но первый по значимости для будущего автоиндустрии блок. Производители автомобилей сегодня понимают, что виртуализационный подход поможет им действительно создавать значительно более гибкие и мощные системы для обслуживания digital cockpit. Для этого нужен automotive-grade гипервизор.
На рынке есть 3-4 коммерческих решения automotive-grade гипервизоров. Но все коммерческие продукты обладают недостатками:
Все эти проблемы устраняет опенсорсный гипервизор. Изначальная бесплатность. Есть доступ к исходникам, можно делать любые изменения. Для этого можно организовать свою команду или обратиться к сервисным компаниям. Сохраняется полная свобода, ведь при смене поставщика исходник остается у производителя.
На пути в опенсорс остается последняя, но ключевая преграда. Открытый гипервизор для автомобиля должен быть 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 (по ссылке PDF).
Вероятно, этот вопрос возник у некоторых еще с самого начала.
Проект XEN существует с 2003 года и по сравнению с другими опенсорсными решениями имеет очень широкий деплоймент в дата-центрах. Он уже стал достаточно зрелым. С 2012 года XEN имеет нативную поддержку ARM-архитектуры. А процессоры именно этой архитектуры в основном используются в автопромышленности.
Кроме того, мы провели много работы, проанализировали разные решения и добились очень хороших показателей производительности. К примеру, если производительность операционной системы, которая бегает на процессоре без виртуализации, равна Х, то на виртуальной машине это 0,96-0,97X. А в коммерческих гипервизорах падение производительности может достигать 30%. Разница на порядок выглядит убедительно.
Поэтому XEN кажется нам подходящим базовым решением. Поэтому EPAM драйвит этот проект. Есть уже несколько европейских автопроизводителей, которые занимаются оценкой решения на базе XEN для будущих автомобилей с digital cockpit, Android внутри и прочими вещами, о которых я говорил выше.
Параллельно этой большой истории мы развиваем собственную connected vehicle платформу Aos. Ее основная идея в том, что мы, с одной стороны, даем разработчикам connected services возможность деплоить их прямо в автомобильный компьютер, а с другой — изолируем их от критических функций, обеспечивая безопасность. Об этом я расскажу в следующей части.
Сразу должен предупредить — я не буду бросать в читателя кусками кода и инженерными тонкостями. Здесь речь пойдет о глобальных вещах, которые, как мы думаем, изменят автомобильную индустрию уже в ближайшие 2-4 года. Так же, как 12 лет назад мобильные телефоны навсегда изменились с появлением Android и Apple iOS.
В EPAM Automotive мы занимаемся двумя крупными блоками: виртуализацией и облачной платформой для деплоймента сервисов прямо в автомобиль. Этот рассказ — о первом.
Два подхода
Если вы следите за автомобильной темой, то наверняка заметили, как активно Google развивает тему инфотейнмента со своим Android Auto OS. С конца прошлого года компания заключила несколько стратегических партнерств с автопроизводителями по интеграции Android Auto OS в автомобиль.
Но у производителей по-прежнему есть опасения. Главная причина — safety. В современных и будущих автомобилях Infotainment Cluster и Instrumental Cluster, содержащий “жизненно важные” приборы и индикаторы, становятся единым целым и используют одни и те же ресурсы. Физические стрелки и индикаторы сменились нарисованными. Однако водитель должен видеть правдивые показания скорости, уровень топлива, состояние тормозной системы, двигателя несмотря ни на что. Недопустимо, если где-то в пути экраны вдруг зависнут и потребуют перезагрузки. А по опыту смартфонов на Android мы знаем, что это вполне возможно.
Производители автомобилей решают такую проблему в лоб: ставят два или больше компьютеров. Например, первый занимается отрисовкой и обслуживанием всей приборной панели. Во втором бегает Android Auto OS и показывает навигацию, музыку, приложения и т.д.
У этого варианта есть несколько минусов. Во-первых, несколько компьютеров все-таки дороже одного. Во-вторых, усложняется имплементация: нужно обеспечивать обмен информацией между Android-частью и insturmental cluster, согласованность и множество других аспектов.
Другой вариант — по примеру клауда использовать виртуализацию с помощью гипервизора. Мощности и возможностей современных микропроцессоров в автомобильных компьютерах вполне достаточно. К компьютеру подключаются минимум два экрана. Один — для Android — инфотейнмент. Другой — для обслуживания приборной панели. Две операционные системы бегают в изолированных виртуальных машинах. Даже если Android “устанет” и упадет, перезагрузится только виртуальная машина, в которой он исполняется.
С такой консолидацией мы можем работать на одном компьютере и сделать интеграцию гораздо проще. Но и здесь есть нюансы.
Автомобильный гипервизор
В дата-центре гипервизор занимается только тем, что нарезает процессор, память и хранилище между разными виртуальными машинами. А еще следит, чтобы “виртуалки” не лезли на пространство друг друга. При этом все они имеют одинаковый набор сервисов, который получают от серверной платформы.
В автомобильном же компьютере, кроме CPU, оперативной памяти и хранилища, есть разные копроцессоры для специфических задач. К примеру, тот же GPU, который нужен и Android, и приборной панели. Значит, задача гипервизора — предоставить возможность обеим операционным системам пользоваться копроцессорами. К тому же, сделать так, чтобы Android не заткнул копроцессор какой-то нелегальной командой или программной ошибкой.
Это требование functional safety – Instrumental Cluster должен работать без оглядки на возможные танцы Android. Поэтому гипервизор должен быть достаточно продвинутым и иметь специальные механизмы, с помощью которых обеспечивается полная изоляция.
Аппаратно такую изоляцию уже обеспечивают современные процессоры. Мы же берем на себя программную часть. А именно — модифицируем опенсорсный XEN Hypervisor, чтобы он мог работать в автомобиле с учетом всех нюансов среды. В нем мы предусмотрели следующие блоки.
1. Полная изоляция виртуальных машин, на которых работают инфотейнмент и приборная панель
Во-первых, у компьютера много периферии, кнопки, тачскрин network, etc… Виртуалиация периферии уже поддерживается набором драйверов.
Во-вторых, мы виртуализируем GPU и копроцессоры. Если одна из виртуальных машин что-то сделает с любым из копроцессоров в системе, то на работе другой виртуальной машины это никак не скажется.
В-третьих, реализована виртуализация TEE Support — trusted execution environment. Это специальная, аппаратно защищенная зона в процессоре, которая занимается исполнением различных секьюрных процедур. Но так как операционных систем больше одной, запросы от них к TEE тоже разделены.
Ниже можно увидеть статус компонент и если интересно посмотреть код
2. Питание и производительность
Любая операционная система управляет питанием и производительностью и может переводить компьютер в режим низкого энергопотребления в соответствии с текущими задачами и загрузкой. То же может захотеть сделать и автомобильный Android: если нет текущих задач, он решает отправить процессор в power save mode. Но ОС, которая занимается приборами, должна продолжать работать. Этот конфликт мы решаем специальным расширением гипервизора. Оно контролирует состояние всей системы и управляет питанием и производительностью.
Следующий момент — реалтайм. Система должна работать с гарантированным расписанием. Этим мы тоже занимается в рамках XEN Real-Time Scheduler.
3. Функциональная безопасность
Последний по очереди, но первый по значимости для будущего автоиндустрии блок. Производители автомобилей сегодня понимают, что виртуализационный подход поможет им действительно создавать значительно более гибкие и мощные системы для обслуживания 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 (по ссылке PDF).
Почему XEN?
Вероятно, этот вопрос возник у некоторых еще с самого начала.
Проект XEN существует с 2003 года и по сравнению с другими опенсорсными решениями имеет очень широкий деплоймент в дата-центрах. Он уже стал достаточно зрелым. С 2012 года XEN имеет нативную поддержку ARM-архитектуры. А процессоры именно этой архитектуры в основном используются в автопромышленности.
Кроме того, мы провели много работы, проанализировали разные решения и добились очень хороших показателей производительности. К примеру, если производительность операционной системы, которая бегает на процессоре без виртуализации, равна Х, то на виртуальной машине это 0,96-0,97X. А в коммерческих гипервизорах падение производительности может достигать 30%. Разница на порядок выглядит убедительно.
Поэтому XEN кажется нам подходящим базовым решением. Поэтому EPAM драйвит этот проект. Есть уже несколько европейских автопроизводителей, которые занимаются оценкой решения на базе XEN для будущих автомобилей с digital cockpit, Android внутри и прочими вещами, о которых я говорил выше.
Параллельно этой большой истории мы развиваем собственную connected vehicle платформу Aos. Ее основная идея в том, что мы, с одной стороны, даем разработчикам connected services возможность деплоить их прямо в автомобильный компьютер, а с другой — изолируем их от критических функций, обеспечивая безопасность. Об этом я расскажу в следующей части.
