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



В первой части я рассказывал, как наши разработки 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 был развернут внутри бортового компьютера, то еще на этапе заказа мог бы сказать бэкенду, что конкретно этот автомобиль не подходит. А качество сервиса было бы выше.

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

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

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

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

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

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

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

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

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

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

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

2. Security

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

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

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

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

3. Scale

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

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

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

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

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

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

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

5. Multitenancy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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