Это история в двух частях – о новом витке развития автомобилестроения.
Данная «серия» посвящена собственной разработке EPAM — Aos Connected Vehicle Platform. Алекс Агизим , технический директор подразделения автомобильных и встраиваемых систем, объясняет, чем оно отличается от традиционного облачного решения и как оно дает разработчикам программного обеспечения доступ к автомобилю.
Вы можете прочитать первую часть Здесь .
В первой части я рассказал о том, как наши разработки XEN Hypervisor позволяют нам изолировать сервисную часть автомобильного ПО от программного обеспечения, необходимого для обеспечения безопасности.
Это одно из препятствий на пути широкого использования в отрасли.
Впервые гипервизор с открытым исходным кодом станет полноценным конкурентом закрытым коммерческим решениям.
Но это только первый шаг.
Чтобы вывести автомобильные услуги на новый уровень, необходимо привлечь сервисные компании и разработчиков, далеких от встраиваемых и автомобильных технологий.
Для этого требуется следующий уровень абстракции.
Чтобы разработчик, использующий современные среды разработки программного обеспечения, мог проектировать свои сервисы для автомобилей без переподготовки.
Прочитав это, вам, возможно, захочется сказать: «Зачем такая сложность? Например, я купил себе в машину Android-планшет, настроил необходимые сервисы и вполне доволен».
Это классический инженерный подход, я его очень поддерживаю.
Но давайте посмотрим шире.
С точки зрения программного обеспечения автомобильная промышленность уже давно застряла в классических подходах.
Я расскажу вам, каким мы видим его будущее и что мы для него делаем.
И в конце мы пройдемся по основным трудностям.
Так.
Зачем вообще нужно пускать сервис-разработчика в бортовой компьютер автомобиля? Так что же сейчас не так?
Автомобиль становится все более сложным устройством.Он напичкан датчиками на все случаи жизни, а работе бортовых компьютеров позавидуют космические корабли.
При всем при этом автомобиль остается весьма ограниченным в возможностях.
Разработка программного обеспечения движется вперед, но в 90% случаев проходит мимо.
Близкая аналогия — смартфоны.
До 2007–2009 годов написать приложение, которое бы работало на разных мобильных телефонах, было довольно сложно.
На рынке конкурировало множество операционных систем и фреймворков: решения от Symbian, Motorola, Ericsson и т. д. Число людей, обладающих навыками разработки для них, было невелико.
Если бизнес хотел, чтобы его сервисом или приложением пользовалось большое количество людей, проблема начиналась с поддержки в разных операционных системах и фреймворках.
Ровно то же самое происходит сегодня в автомобильной промышленности.
Чтобы сервис поддерживался разными автопроизводителями, вам придется адаптироваться ко многим основам и набору правил.
Для Мерседеса отдельно, для Тойоты отдельно и т.д. Когда в 2007 году появилась iOS, а годом позже — Android, мобильная индустрия сразу же совершила скачок.
В автомобильной отрасли продолжается конфликт двух основных парадигм.
Первый – традиционный.
Бортовой компьютер автомобиля – закрытое устройство, доступ к которому имеет только производитель.
.
Сторонним разработчикам здесь нет пути: безопасность и безопасность на первом месте.
Надежный, но не без недостатков.
С одной стороны, производитель обо всём позаботился.
Не надо винить разработчиков сторонних сервисов.
С другой стороны, невозможно быть в авангарде прогресса.
Один автопроизводитель не может полностью покрыть «хотелки» клиента.
Цикл разработки и вывода на рынок слишком длинный, команда, даже очень раздутая, все равно ограничена.
А ожидаемый подключенный беспилотный автомобиль удаляется все дальше и дальше.
А также интеграция в общую экономику.
Другая крайность рассматривать автомобиль как устройство Интернета вещей .
То есть просто собрать данные со всех автомобильных датчиков, упаковать их и отправить в облако на обработку.
При необходимости повторите много тысяч раз.
Сотни облачных проектов, включая Google, Microsoft и Amazon, пытаются посмотреть на автомобиль именно так.
Но это немного вводит в заблуждение.
Автомобиль – это не умный дом с лампочками, термостатом и телевизором.
У него в сотни раз больше датчиков и собственная вычислительная мощность.
И — самое главное — канал между машиной и центром нестабилен.
Даже если он условно стабилен, вряд ли он захочет пропускать сотни мегабайт данных каждую секунду.
В противном случае другого пути в таком подходе нет — вся бизнес-логика сервиса выполняется в облаке.
Что мы придумали вместо этого?
Мы выбрали другую идеологию.Автомобиль — не просто источник информации с датчиков.
Этот полноценный вычислительный узел, на котором сервис может выполнять свою бизнес-логику .
Для этого автомобилю необходим базовый элемент — Connected Vehicle Platform. Он позволяет открыть автомобиль как программную платформу.
С другой стороны, используйте инструменты, принятые в облачных сервисах, для развертывания и оркестрации сервисов, которые должны работать на бортовом компьютере.
Если наш прогноз верен, в конечном итоге мы получим экосистему, в которой программист сможет действовать как обычно и развернуть некоторую часть бизнес-логики в автомобильном компьютере.
Как и сегодня в облачных сервисах, он нажимает кнопку, запускает CI/CD и разворачивает все необходимые компоненты на все необходимые узлы.
В нашем случае одним из узлов для развертывания будет автомобиль.
И мы предоставляем основу, которая может это сделать.
Вот почему мы называем нашу облачную платформу «Kubernetes для автомобилей».
Концепция в нашем видении разделена на 2 части:
- изолировать программное обеспечение безопасности от программного обеспечения подключенных сервисов;
- обеспечить необходимый уровень абстракции для компаний, которые хотят разрабатывать или уже предоставляют услуги подключенных транспортных средств.
Им стоит не заморачиваться со встроенными, а разрабатывать сервисы привычными инструментами и использовать бортовой компьютер как Edge-устройство.
Мы избавляем автопроизводителей от самостоятельного изобретения сервисов и открываем автомобиль разработчикам.
Как это когда-то произошло со смартфонами.
Какие дела это может закрыть?
Корневой случай - отсутствие связи .В классической облачной версии сервис теряет доступ к автомобилю.
В версии Connected Vehicle Platform разработчик может предусмотреть это и заранее прошить логику внутри автомобиля.
А что касается облачной части, по крайней мере, буферизируйте данные.
Платформа также поможет значительно улучшить система управления автопарком и профилактического обслуживания (управление автопарком и профилактическое обслуживание).
Связь с облаком для этих сервисов становится если не необязательной, то гораздо менее востребованной.
Очень яркий пример – работа служб такси.
Сейчас они реализованы на смартфонах, отлично работают с картами и платежами, но никак не могут учитывать состояние автомобиля.
Например, вы опаздываете в аэропорт, приезжает Uber, и вдруг оказывается, что бензина у водителя хватает только на часть поездки.
Водитель не мог этого понять заранее.
А вот если бы сервис Uber был развернут внутри бортового компьютера, то на этапе заказа он мог бы сказать бэкенду, что именно эта машина не подходит. А качество обслуживания было бы выше.
В случае будущего экономика совместного потребления (совместная экономика) нужно иметь в машине набор сервисов, который вообще не будет иметь пользовательского интерфейса.
Например, сервис, который будет следить за техническим состоянием автомобиля (тут также подойдет пример Uber и бензина).
Или сервис, который следит за тем, как человек ездит, и предоставляет эти данные страховым компаниям или компаниям по прокату автомобилей.
В этом случае страховым или прокатным компаниям необходимо позаботиться о том, чтобы пассажир и водитель не могли их снять или вывести из строя.
Сегодня из этого выходят сервисами, которые работают только с помощью дополнительных единиц связи.
А это покупка, установка, интеграция, написание самого сервиса.
Это требует много времени и денег.
Поэтому мы всегда рассматриваем подключенный автомобиль с двух сторон.
Одна сторона просто подключается к интернет-услугам.
Второе – автомобиль как элемент долевой экономики.
Для этого все основные элементы должны быть интегрированы в автомобиль во время его производства.
Поэтому мы разговариваем либо с производителями автомобилей, либо с производителями автомобильных компьютеров.
Одна из проблем отрасли заключается в том, что невозможно придумать варианты использования из-за недостаточного платформенного подхода.
То же самое было и с мобильными телефонами.
Можно, например, сказать, что существует 2800 компаний, создающих решения для управления автопарком.
Но все они очень монолитны.
Если нужно что-то менять, то приходится менять бортовые и телекоммуникационные компьютеры.
Ведь вы хотите сделать то, чего не может сделать этот агрегат.
Как безопасно перенести бизнес-сервис из облака в автомобиль? Что может этому помешать и как это решить?
1. Контейнеры Поскольку мы исходим из идей Kubernetes, то его основная возможность — развертывание контейнеров.А вот с автомобильным компьютером это сложно.
Во-первых, даже если мы напишем на Python пару строк кода, выводящего «Hello, world», размер контейнера может достигать 50 МБ.
Возможно, удастся загрузить это через сотовый канал, а может и нет. Даже у мистического 5G есть те же проблемы, что и у любого другого соединения: покрытие, пропускная способность, стабильность.
Значит, вам нужно повысить свои шансы.
Во-вторых, автомобильный компьютер очень хорош с точки зрения вычислительной мощности, но все же значительно более ограничен, чем любой из самых маленьких серверов в облаке.
Он запускает множество других программ.
Нельзя просто прийти и «съесть» 200 МБ ОЗУ.
Поэтому первое, что мы сделали — описали тип нашего контейнера в рамках стандарта OCI. Проблема с размером решается так: все базовые вещи, которые нужны разработчику для работы сервиса, не нужно нести из облака.
Они уже предустановлены на автомобильном компьютере.
Вам нужно только принести сам код, который в худшем случае занимает сотни килобайт. Проблема с ресурсами бортового компьютера решена за счет их описания в нашей спецификации контейнера.
Это позволяет очень легко определить квоты, которые будет контролировать автомобильный компьютер.
И установленный сервис никогда не сможет их превысить.
2.Безопасность Kubernetes изначально был разработан для развертывания и оркестрации сервисов в облаке.
То есть в контролируемой, поддерживаемой и защищенной среде.
Но у нас есть машина, а у злоумышленников неограниченная фантазия.
Они могут вытащить бортовой компьютер, взломать его каким-нибудь устройством или проникнуть в канал между автомобилем и облаком.
Поэтому безопасность – наша постоянная первоочередная задача.
Мы реализовали продвинутую модель согласно рекомендациям Агентства национальной безопасности США.
Там сказано следующее: проектируя свою систему безопасности, вы должны в первую очередь минимизировать количество потенциальных мест атак, а также строить безопасность как слоеный пирог.
Взломан на каком-то уровне? Нужно это заметить и приложить все усилия, чтобы подобное не повторилось в следующий раз.
В нашей модели «пирог» выглядит так:
- Мы используем контейнеры как своего рода изолятор на уровне ОС Linux. Из контейнера очень сложно выбраться;
- Сбежал из контейнера? Но платформа подключенных транспортных средств работает на отдельной виртуальной машине, поэтому нам нужен XEN. Эта виртуальная машина изолирована от всех периферийных устройств.
Связь с периферийными устройствами может осуществляться только через некоторые API, предоставляемые производителем автомобиля;
- Сломали контейнер и виртуальную машину? У нас есть еще один барьер — самоанализ виртуальной машины: анализ закономерностей, по которым работает виртуальная машина.
Например, виртуальная машина вдруг настойчиво пытается добраться до какой-то памяти, которую она обычно не трогает. Вы можете отреагировать: отключить эту виртуальную машину, откатиться на стабильную версию и т.д.
Лишь бы ничего не сломалось по пути.
Для облачных сервисов вопрос масштабирования не имеет особого значения.
С автомобилем все не так.
Допустим, вы арендовали автомобиль и хотите воспользоваться вашими услугами, что дает вам хороший страховой полис, поскольку вы хороший водитель.
Но для этого вам понадобится встроенный в автомобиль сервис, который передает ваши данные страховой компании.
Вы садитесь в машину, вставляете ключ в замок, поворачиваете его и через 3 секунды вы готовы к поездке.
Логично, если за эти 3 секунды автомобиль получит все необходимые для поездки услуги.
А что, если таких машин не одна, а 10 000? Система, которая развертывает сервисы в автомобиле, должна уметь делать это быстро.
Время установки должно быть постоянным независимо от количества устанавливаемых транспортных средств.
Мы решили эту проблему с помощью дополнения, которое мы разработали для RabbitMQ. Это позволяет легко увеличивать и уменьшать масштаб системы в зависимости от того, сколько узлов вам нужно использовать.
4. Каналы связи Когда развертывание происходит из облака в автомобиль, канал связи должен быть зашифрован.
Мы используем Mutual TLS для аутентификации.
Это работает двумя способами: машина авторизуется в облаке, облако авторизуется в машине.
Все это на основании сертификатов.
Если сертификаты не подходят или кто-то попытается их подменить, авторизация не произойдет и доступ к бортовому компьютеру не будет получен.
Кроме того, каждый канал, по которому контейнеры доставляются из облака в машину, шифруется собственным набором ключей.
Допустим, кто-то украл ключ, сертификат и смог проникнуть в канал передачи контейнера.
Но попасть на канал он сможет только этой конкретной машины.
Что будет указано? Вы можете обновить сертификаты, на них начнет работать новое шифрование Mutual TLS — и все усилия взлома сойдут на нет. Это избавляет нас от проблемы сетей IoT, когда один взломанный сертификат может скомпрометировать все устройства.
5.Мультиарендность Представьте себе обычную IoT-сеть умного дома.
В него входят производители устройств и сетевые операторы.
Как правило, зависимости между устройствами и операторами статичны.
Жизненный цикл тоже достаточно стабилен: даже если вы начнете заменять одну умную лампочку на другую, то сделаете это не скоро и не очень часто.
В случае с автомобилем и общей экономикой эти зависимости очень динамичны.
Есть автопроизводитель .
Есть покупатель/собственник — допустим, это компания по каршерингу.
Есть оператор службы.
И есть финал пользователь .
Владелец, оператор и пользователь могут постоянно меняться.
Утром в понедельник машина принадлежит определенному банку, оператор — компания А.
После обеда ее уже обслуживает компания Б.
Пользователи у разных операторов тоже могут быть разными.
Но при этом принадлежащие им сервисы должны мигрировать за ними по разным автомобилям.
Мы называем это мультитенантностью, и в нашей системе управления развертыванием сервисов это предусмотрено замыслом.
Роли поставщика и владельца сервиса уже определены; никакой дополнительной логики не требуется.
На один автомобиль можно назначить разные услуги.
Допустим, машина переходит из рук в руки.
Сервисы предыдущего будут автоматически удалены, а сервисы нового автоматически установлены.
Сегодняшние IoT-сети и тот же Kubernetes не подходят — они просто не встречали такого варианта использования.
6. Мониторинг работы сервисов Для связи между сервисом и автомобилем существует стандартизированный API под названием VIS — Vehicle Information Services. Он стандартизирован организацией W3C. Этот API в нашей концепции реализован и контролируется производителем автомобиля.
Сервис подключенных автомобилей находится под полным контролем.
Различные производители начинают поддерживать этот API. И разработчику все равно, для какого производителя он делает услугу.
Конечно, каждый производитель автомобилей может сделать некоторые исключения.
Как и смартфоны: Galaxy S9 и S10 имеют один и тот же базовый API, но в каждом есть особенности, характерные для конкретной модели.
В автомобиле также можно получить основную информацию независимо от его типа.
И в конкретных вещах есть свои нюансы.
Это позволяет производителям создавать уникальные товары с добавленной стоимостью, которые отличают их.
На чем написаны компоненты платформы? А на чем можно будет писать сервисы для авто?
Сама платформа написана на Python. Управление верхнего уровня системы развертывания написано на Python. Вся встроенная часть написана на C. Что касается сервисов, то мы были первыми, кто поддержал Python и добавил JavaScript. По просьбе нескольких автопроизводителей был добавлен .NET. Речь идет о Java. В общем, это тактический вопрос.
Нет программистов на JavaScript — есть программисты.
Я думаю, что с развитием автомобилестроения появятся программисты, которые будут заниматься именно услугами подключенных транспортных средств.
В голове всегда будет мигать лампочка «что делать, если нет связиЭ» Вне зависимости от того, что у нас в воздухе — 5G или 10G. Беспроводное соединение не работает в 100% случаев.
Как автопроизводители реагируют на платформу?
Сегодня у любого автопроизводителя есть внутреннее подразделение, занимающееся разработкой подключенных сервисов.Эти люди умеют работать быстро.
Но их тормозят собственные внутренние аппаратные и программные отделы.
Мы фокусируемся на этом.
Мы предлагаем инструмент, с помощью которого собственные отделы разработки смогут работать быстрее и гибче.
А ребята из Embedded, которые сейчас меняют одну строчку кода в течение 2 лет, смогут сделать это один раз с платформой — тогда система позволит им быть независимыми от них.
В целом производители смотрят на Aos достаточно настороженно.
Но с интересом – потому что это открывает для них новые возможности.
Например, они могут построить бизнес-модель как у Amazon, Google, Microsoft: назначить сервису комиссию за использование бортового компьютера, API и т. д. Также, я думаю, однажды они придут к модели маркетплейса.
То есть разработчики программного обеспечения и подключенных сервисов будут платить комиссию за то, что пользователь установил их сервис.
Это быстро произошло в мобильной индустрии.
Но мы понимаем: люди не меняют машину каждый год. Цикл разработки автомобильного программного обеспечения занимает 4-6 лет. Поэтому то, о чем мы говорим сегодня у автопроизводителей, вряд ли начнет появляться в виде каких-то пилотов раньше 2022 года.
Пытаемся ли мы копировать Tesla или конкурировать с ней?
Нет, и даже наоборот. Tesla, в отличие от других, может обновлять любое программное обеспечение, работающее на любом компьютере в автомобиле, по беспроводной сети.Таким образом, они могут постоянно внедрять новые функции.
Но их компьютер не является платформой для разработки сервисов каршеринга.
Вы не можете купить 10 машин, нанять 2 программистов и написать крутой сервис каршеринга.
Поэтому Tesla также является одним из наших потенциальных клиентов.
И один из самых продвинутых.
С нашей платформой ни Tesla, ни другим производителям не придется тратить время на разработку велосипеда.
В конце концов, никто из облачных приложений больше не разрабатывает собственный Kubernetes. Мы считаем, что то же самое должно произойти и с платформой подключенных транспортных средств.
Если говорить о конкуренции в целом, то мы пока не видели ни одного конкурента, который хотя бы говорил о том, о чем мы говорим.
Как оказалось, автопром по-прежнему очень закрыт. И мы многое делаем в платформе — ту же поддержку FOTA и SOTA — не просто потому, что они нужны сейчас, а заранее.
При этом я не думаю, что в будущем будет одна платформа для всех автомобилей.
Скорее всего будет 2-3 больших.
С одной стороны, они объединят автопроизводителей.
С другой стороны, они вновь дадут возможность использовать современные среды программирования.
И мы увидим совершенно новые случаи, которые сейчас не можем себе представить.
Теги: #Kubernetes #Микросервисы #Xen Cloud Platform #автомобильная промышленность
-
Google Adsense –
19 Oct, 24 -
Создать Сайт Может Каждый!
19 Oct, 24 -
Отправка Документов «По Старинке»
19 Oct, 24 -
Запуск Google Chrome Под Wine
19 Oct, 24 -
Сосчитай До Трёх
19 Oct, 24 -
Quintura Устроила Поиски Детей
19 Oct, 24
