Хабрахабр

Kubernetes для автомобиля: как открыть разработчику доступ к бортовому компьютеру и сделать это безопасно

Это история в двух частях — о новом витке развития automotive. Эта «серия» посвящена собственной разработке EPAM – Aos Connected Vehicle Platform. Алекс Агизим, CTO, Automotive & Embedded Systems, объясняет, чем она отличается от традиционного облачного решения и как дает software-разработчикам доступ в автомобиль. Ознакомиться с первой частью можно здесь.

image

Это один из барьеров перед широким применением в индустрии. В первой части я рассказывал, как наши разработки XEN Hypervisor позволяют изолировать сервисную часть автомобильного ПО от safety required software. Впервые опенсорсный гипервизор станет полноценным конкурентом закрытым коммерческим решениям.

Чтобы вывести автомобильные сервисы на новый уровень, нужно «пустить» в него сервис-компании и разработчиков, далеким от embedded и automotive. Но это только первая ступенька. Чтобы разработчик пользующийся современными фреймворками в разработке софтваре мог, не переучиваясь, дизайнить свои сервисы для автоиобилей. Для этого требуется следующий уровень абстракции.

Я, к примеру, купил Android-планшет для автомобиля, настроил нужные сервисы и вполне счастлив». Возможно, после прочтения вы захотите сказать: «Зачем такие сложности? Но давайте посмотрим шире. Это классический инженерный подход, очень поддерживаю. Я расскажу, каким ее будущее видим мы и что для этого делаем. Автомобильная индустрия с точки зрения software как раз таки давно застряла в классических подходах. А в конце пройдемся по основным сложностям.

Итак.

Зачем вообще нужно пускать разработчика сервисов в бортовой компьютер автомобиля? И что сейчас не так?

Автомобиль становится все более сложным устройством. Он напичкан датчиками на все случаи жизни, а производительности бортовых компьютеров позавидуют космические корабли. При всем этом автомобиль остается весьма ограниченным в возможностях. Software-разработка идет вперед, но в 90% проходит мимо него.

До 2007-9 года написать приложение, которое исполнялось бы на разных мобильных телефонах, было достаточно тяжело. Близкая аналогия — смартфоны. Если же бизнес хотел, чтобы его сервисом или апликацией пользовалось большое количество людей, начиналась проблема с поддержкой на разных операционных системах и фреймворках. На рынке сражалась масса операционных систем и фреймворков: решения от Symbian, Motorola, Ericsson и т.д… Количество людей с навыками разработки под них было мало.

Чтобы сервис поддерживался разными автопроизводителями, приходится подстраиваться под множество фреймворков и набор правил. Ровно то же происходит сегодня в автомобильной индустрии. Под Mercedes отдельно, под Toyota отдельно и т.д.

В АВТОмобильной же продолжается конфликт двух основных парадигм. Когда в 2007 появилась iOS, год спустя — Android — мобильная индустрия сразу сделала рывок.

Автомобильный бортовой компьютер — закрытое устройство, доступ к которому есть только у самого производителя. Первая — традиционная. Надежно, но не без изъянов. Сторонним разработчикам сюда дороги нет: safety и security прежде всего. Пенять в сторону разработчиков сторонних сервисов не придется. С одной стороны, производитель замыкает все на себе. Полностью покрыть «хотелки» клиента один автопроизводитель не может. С другой, не получается быть на острие прогресса. И ожидаемый connected self-driving car отодвигается все дальше. Цикл разработки и выхода на рынок слишком длинный, команда, даже очень раздутая, все равно ограничена. Как и интеграция в shared economy.

То есть просто собирать данные от всех автомобильных сенсоров, паковать и отправлять в облако на обработку. Другая крайность — считать автомобиль IoT-девайсом. Так на автомобиль пытаются смотреть сотни облачных проектов, включая Google, Microsoft и Amazon. При необходимости повторить много тысяч раз. Но это немного ошибочно.

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

Что мы придумали взамен?

Мы выбрали другую идеологию. Автомобиль — не просто источник информации от сенсоров. Это полноценный вычислительный узел, на котором сервис может выполнять свою бизнес-логику.

Она позволяет открыть автомобиль как софтверную платформу. Для этого автомобилю нужен базовый элемент — Connected Vehicle Platform. А с другой стороны — использовать инструменты, принятые в cloud-сервисах, чтобы заниматься деплойментом и оркестрацией сервисов, которые должны работать на бортовом компьютере.

Точно так же, как сегодня в cloud-сервисах он жмет кнопку, запускает CI/CD, деплоймент всех необходимых компонент по всем необходимым нодам. Если наш прогноз справедлив, в конечном итоге получится экосистема, когда программист сможет действовать привычно и какую-то часть бизнес-логики задеплоить в автомобильный компьютер. А мы даем фреймворк, который умеет это делать. В нашем случае одним из нодов для деплоймента будет автомобиль. Поэтому и называем нашу облачную платформу «Kubernetes для автомобилей».

Концепция в нашем видении разделена на 2 части:

  1. изолировать safety software от connected services software;
  2. дать необходимый уровень абстракции для компаний, которые хотят разрабатывать или уже делают connected vehicle services. Они должны не заморачиваться с embedded, а разрабатывать сервисы своими привычными инструментами и использовать бортовой компьютер как edge-девайс.

Автомобильный бортовой компьютер должен стать edge-компьютером для будущих мобильных сервисов. Мы избавляем производителей автомобилей от самостоятельного придумывания сервисов и открываем автомобиль для разработчиков. Как это когда-то произошло со смартфонами.

Какие кейсы это может закрыть?

Корневой кейс — отсутствие коннективити. В классическом облачном варианте у сервиса при этом пропадает доступ к автомобилю. В варианте Connected Vehicle Platform разработчик может это предусмотреть и заранее «прошить» логику внутрь авто. А для облачной ее части — как минимум буферизировать данные.

Связь с облаком для этих сервисов становится если не необязательной, то гораздо менее востребованной. Платформа также поможет существенно улучшить упарвление автопарком и систему организации диагностического технического обслуживания (fleet management & predictive maintenance).

Сейчас они реализованы на смартфонах, отлично работают с картами и платежами, но никак не могут учитывать состояния автомобиля. Совсем понятный пример — работа такси-сервисов. Заранее водитель это понять бы не мог. К примеру, вы опаздываете в аэропорт, приезжает Uber – и вдруг выясняется, что бензина у водителя хватит только на часть пути. А качество сервиса было бы выше. Но если бы сервис Uber был развернут внутри бортового компьютера, то еще на этапе заказа мог бы сказать бэкенду, что конкретно этот автомобиль не подходит.

Например, сервис, который будет следить за техническим состоянием автомобиля (пример с Uber и бензином сюда тоже годится). В случае будущей экономики совместного использования (shared economy) нужно иметь в автомобиле набор сервисов, которые будут вообще без UI. Или сервис, наблюдающий за тем, как человек водит, и дающий эти данные страховым или прокатным компаниям.

Сегодня они выкручивается сервисами, которые работают только с помощью дополнительных телеком-юнитов. Страховым или прокатным компаниям при этом нужно, чтобы пассажир и водитель не могли их удалить или отключить. На это уходит много времени и денег. А это покупка, установка, интеграция, написание самого сервиса.

Одна сторона — просто подключение к интернет-сервисам. Поэтому мы всегда смотрим на Connected Vehicle в двух аспектах. Для этого все базовые элементы должны быть интегрированы в автомобиль на этапе его производства. Вторая — авто как элемент shared economy. Поэтому мы говорим либо с производителями автомобилей, либо с производителями автомобильных компьютеров.

С мобильными телефонами было то же. Одна из проблем индустрии — не удается придумать юзкейсы, потому что не хватает платформенного подхода. Но они все очень монолитные. Можно, к примеру, сказать, что есть 2800 компаний, делающих решения для fleet management. Ведь хочется сделать что-то такое, чего этот агрегат сделать не может. Если нужно что-то поменять, приходится менять бортовые и телеком-компьютеры.

Как безопасно заделиверить бизнес-сервис из облака в автомобиль? Что этому может помешать и как мы это решаем?

1. Контейнеры

Но с автомобильным компьютером это сложно. Раз уж мы идем от идей Kubernetes, то его главное умение — деплоить контейнеры.

Залить такое через сотовый канал может получиться, а может и нет. Во-первых, даже если на Python мы напишем пару строчек кода, который печатает «Hello, world», размер контейнера может достигать 50 Мб. Так что нужно повысить шансы. Даже мистический 5G обладает теми же проблемами, что и любая другая связь: покрытие, ширина полосы, стабильность.

На нем бегает множество других программ. Во-вторых, автомобильный компьютер очень хорош по вычислительной мощности, но все же значительно более ограничен, чем любой самый маленький сервер в клауде. Нельзя просто так прийти и «съесть» 200 Мб оперативной памяти.

Проблема с размером решается так: все базовые вещи, которые нужны разработчику для работы сервиса, не нужно нести из облака. Поэтому первым делом мы описали свой тип контейнера в рамках стандарта OCI. Нужно принести только сам код, который занимает в худшем случае сотни килобайт. Они уже предустановлены на автомобильном компьютере.

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

Security 2.

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

Оно говорит следующее: при проектировании своей секьюрити-системы вы должны в первую очередь минимизировать количество мест потенциальной атаки, а также строить секьюрити как слоеный пирог. Мы реализовали продвинутую модель согласно рекомендациям Агентства национальной безопасности США. Нужно это заметить и приложить максимум усилий, чтобы не пустить на следующий. Взломали на каком-то уровне?

В нашей модели «пирог» выглядит так:

  1. Мы используем контейнеры — как некий изолятор на уровне Linux OS. Вырваться из контейнера очень тяжело;
  2. Вырвался из контейнера? Но Connected Vehiclle Platform исполняется в отдельной виртуальной машине — для чего нам и нужен XEN. Эта виртуальная машина изолирована от всей периферии. Общение с периферией может происходить только через какие-то API, которые предоставляются производителем автомобиля;
  3. Поломал контейнер и виртуальную машину? У нас есть еще один барьер — virtual machine introspection: анализ паттернов, по которым работает виртуальная машина. К примеру, виртуальная машина вдруг настойчиво пытается добраться до какой-то памяти, которую обычно не трогает. Можно отреагировать: отключить эту виртуальную машину, откатиться на стабильную версию и т.п.

3. Scale

Не особенно. Критично ли время обновления на смартфонах пользователей для условного мобильного банкинга? У cloud-сервисов вопрос скейла особо не стоит. Лишь бы по дороге ничего не сломалось.

Допустим, вы арендовали машину и хотите использовать свой сервис, который дает вам хороший полис по страховке, потому что вы хорошо водите. C автомобилем не так. Но для этого нужно, чтобы в автомобиль задеплоился сервис, который дает ваши данные в страховую компанию.

Логично, если за эти 3 секунды машина примет все необходимые для поездки сервисы. Вы сели в машину, вставили ключ в замок, поворачиваете и через 3 секунды готовы ехать. Система, которая деплоит сервисы в автомобиль, должна уметь делать это быстро. Но если таких машин не одна, а 10 000? Время установки должно быть постоянным независимо от количества автомобилей для установки.

Она позволяет легко делать scale up и scale down системы в зависимости от того, сколько нодов нужно использовать. Мы решили этот вопрос с помощью разработанной нами надстройкой над RabbitMQ.

Каналы связи 4.

Мы используем Mutual TLS для аутентификации. Когда происходит деплоймент из клауда в автомобиль, канал связи должен быть зашифрован. Все это базируется на сертификатах. Она работает в две стороны: машина авторизуется в клауде, клауд — в машине. Если сертификаты не подходят или кто-то пытается их подменить, авторизация не произойдет и доступ к бортовому компьютеру не будет получен.

Предположим, кто-то украл ключ, сертификат и смог попасть на канал передачи контейнеров. Кроме того, каждый канал, по которому происходит деливери контейнеров из клауда в автомобиль, зашифрован своим собственным набором ключей. О чем поступит индикация. Но он сможет попасть только на канал этого конкретного автомобиля. Это избавляет нас от проблемы сетей IoT, когда один взломанный сертификат может скомпрометировать все девайсы. Можно обновить сертификаты, на них начнет работать новый Mutual TLS encryption — и все усилия по взлому свелись на нет.

Multitenancy 5.

В ней есть производители девайсов и операторы сети. Представьте себе обычную IoT-сеть умного дома. Жизненный цикл тоже достаточно стабилен: если вы и начнете менять одни умные лампочки на другие, то нескоро и делать это будете нечасто. Как правило, зависимости между девайсами и операторами статичны.

Есть автопроизводитель. В случае автомобиля и shared economy эти зависимости очень динамичны. Есть оператор сервиса. И есть конечный пользователь. Есть покупатель/владелец — допустим, это компания, предоставляющая каршеринг.

В понедельник с утра автомобиль принадлежит некоему банку, оператор — компания A. Владелец, оператор и пользователь могут все время меняться. Пользователи у разных операторов тоже могут быть разными. После обеда им оперирует уже компания B. Но при этом сервисы, которые им принадлежат, должны мигрировать за ними по разным автомобилям.

Роли сервис-провайдера и сервис-оунера уже определены, никакой дополнительной логики наворачивать не нужно. У нас это называется Multitenancy и в нашей системе управления деплойментом сервисов поддерживается by design. Допустим, автомобиль переходит к другому владельцу. Можно назначить на один автомобиль разные сервисы. Сегодняшние IoT-сети и тот же Kubernetes не годятся — они с таким юзкейсом просто не сталкивались. Сервисы предыдущего автоматически уберутся, а сервисы нового автоматически поставятся.

Контроль за работой сервисов 6.

Он стандартизован организацией W3C. Для общения сервиса с автомобилем есть стандартизированный API, который называется VIS – Vehicle Information Services. Connected vehicle service оказывается под полным контролем. Этот API в нашей концепции имплементируется и контролируется производителем автомобиля.

А разработчику становится все равно, для какого производителя он делает сервис. Разные производители начинают поддерживать этот API.

Как в смартфонах: у Galaxy S9 и S10 один и тот же базовый API, но в каждом есть вещи, справедливые для конкретной модели. Конечно, каждый производитель автомобиля может делать какие-то исключения. А для специфических вещей свои нюансы. В автомобиле базовую информацию тоже можно получать независимо от его типа. Это дает возможность производителям придумывать какие-то уникальные, отличающие их вещи с добавленной ценностью.

На чем написаны компоненты платформы? И на чем можно будет писать сервисы для автомобилей?

Сама платформа написана на Python. Верхнеуровнево управление деплоймент-системой написано на Python. Вся embedded-часть написана на C.

По просьбе нескольких производителей автомобилей добавили . Что касается сервисов, то первым мы сделали поддержку Python, добавили JavaScript. Идут разговоры о Java. NET.

Не бывает программистов JavaScript — бывают программисты. Вообще это вопрос тактический. В их голове всегда будет мелькать лампочка «что делать в случае, если нет коннективити?» Вне зависимости от того, что у нас в воздухе — 5G или 10G. Думаю, с развитием automotive появятся программисты, которые занимаются конкретно connected vehicle services. Беспроводное подключение не работает 100% времени.

Как на платформу реагируют производители автомобилей?

У любого автопроизводителя сегодня есть внутреннее подразделение, которое занимается разработкой connected services. Эти люди способны работать быстро. Но их тормозят собственные же отделы по внутреннему аппаратно-программному обеспечению.

Приносим инструмент, с помощью которого их же собственные отделы разработки могут работать быстрее и гибче. Мы подсвечиваем это. А ребята из embedded, которые сейчас меняют одну строчку кода 2 года, с платформой смогут сделать это один раз — дальше система позволит быть от них независимым.

Но с интересом — ведь это открывает для них новые возможности. В целом, производители смотрят на Aos достаточно осторожно. Также, думаю, однажды они придут к модели маркетплейса. Например, они могут выстроить бизнес-модель подобно Amazon, Google, Microsoft: назначить сервису комиссию за использование бортового компьютера, API и т.д. То есть разработчики software и connected services будут платить комиссию за то, что пользователь установил их сервис.

Но мы понимаем: люди не меняют автомобиль каждый год. В мобильной индустрии это произошло быстро. Поэтому то, о чем мы сегодня говорим с автопроизводителями, начнет появляться в виде каких-то пилотов вряд ли раньше 2022 года. Цикл разработки автомобильного софта занимает 4-6 лет.

Пытаемся ли мы скопировать или конкурировать с Tesla?

Нет и даже наоборот. Tesla в отличие от других умеет по воздуху обновить любое ПО, которое исполняется в любом компьютере в автомобиле. Так они постоянно могут внедрять новые фичи. Но их компьютер не является платформой для разработки сервисов каршеринга. Нельзя купить 10 машин, нанять 2 программистов и написать классный сервис по каршерингу. Поэтому Tesla — тоже один из наших потенциальных клиентов. Причем из наиболее продвинутых.

Ведь никто в приложениях для клауда уже не разрабатывает свой Kubernetes. С нашей платформой ни Tesla, ни другим производителям не придется тратить время на придумывание велосипеда. Наше видение — это же должно произойти с Connected Vehicle Platform.

Как оказалось, автомобильная индустрия еще очень закрыта. Если говорить о конкуренции в целом, пока что мы еще не видели ни одного конкурента, который хотя бы рассказывал о том, о чем мы говорим. И многие вещи в платформе — ту же поддержку FOTA и SOTA — мы делаем не просто потому, что они нужны сейчас, а с опережением.

Скорее всего, будет 2-3 крупных. Вместе с тем, не думаю, что в будущем будет одна платформа для всех автомобилей. А с другой — опять же дадут возможность использования современных фреймворков программирования. С одной стороны, они объединят производителей автомобилей. И мы увидим совсем новые кейсы, которые сейчас и не представляем.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть