DOU Labs: как в EPAM делают облачную платформу, которая откроет разработчикам доступ в автомобиль

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на [email protected].

Всем привет. Меня зовут Алекс, я руковожу направлением Automotive & Embedded Systems в EPAM. Чуть больше полутора лет назад мы начали проект разработки облачной платформы для автомобилей. И этим проектом занимаются ребята из киевского офиса. Надеемся, в ближайшие годы он позволит автопроизводителям перестроиться на новые рельсы и глобально подружиться с software и облачными сервисами.

Эта платформа — внутренняя инициатива EPAM. Сегодня мы используем ее как наш value add, когда предлагаем наши услуги для автомобильных компаний.

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

Мостик между разработчиками и автоиндустрией

Automotive — интенсивно развивающийся сегмент в любой IT-компании. Автомобильные компании все больше уходят в software, и это прекрасно видно по машинам, которые уже продаются. Все мировые производители поголовно говорят о будущем self-driving car. А мы только успеваем вносить их заявления в презентации.

По объемам индустрия automotive никак не меньше того, что недавно происходило с мобильными или с веб-технологиями. Однако и вызовы она ставит не меньшие. Автомобилестроение в отличие от мобильных, финансовых приложений или e-commerce отличается главным: разработка программного обеспечения для автомобиля сложна и требует жесткого контроля процесса разработки и качества. Потому что автомобиль в случае самой маленькой программной неисправности может травмировать или лишить жизни человека.

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

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

И вот, допустим, какая-то компания хочет использовать автомобиль в своем бизнес-процессе и должна провести интеграцию с ним с точки зрения программного обеспечения. Если делать по законам разработки ПО для авто, в очень быстром режиме это может занять 1,5 года. В среднем — 2,5-3 года. Для них это нормально. А в digital-индустрии вообще непонятно, зачем начинать разработку, если речь о таких сроках.

Это и есть основной конфликт в диджитализации автомобильной индустрии. Разрабатывать софт по законам и со скоростью digital-индустрии автоотрасль не может. А диджитализация не должна влиять на безопасность — авто 100% должно функционировать без сбоев и проблем.

Так в EPAM родилась идея фундаментальной облачной платформы для connected vehicle — связующего звена между разработчиками digitlal-сервисов и производителями авто.

Не просто еще одна платформа

На первый поверхностный взгляд не очень понятно, в чем революция. Если открыть Google-поиск и набрать «connected vehicle platform», в результатах вывалится порядка 2500 разных продуктов от всех возможных производителей. Зачем нужна еще одна?

Загвоздка в том, что все нынешние варианты рассматривают автомобиль, как монолитное устройство, с которого можно получать данные. Как с датчика движения в умном доме (или пусть даже устройства посложнее).

Схема подобных платформ выглядит примерно так. Вся бизнес-логика для реализации конкретного приложения или сервиса делается на стороне облака. Она рассчитана на то, что данные через всяческие aftermarket devices или специальные Telecommunication Units принимаются из авто и складываются в облако. И только тогда конкретное бизнес-приложение или сервис используют эти данные для реализации бизнес-логики.

Выглядит просто, привычно и понятно, если бы не очевидный минус. Даже два.

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

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

Общая логика платформы такова:

1. Разработчикам платформа позволяет создавать сервисы без оглядки на то, что одним из элементов сервиса является автомобиль. Они пишут свой сервис теми языками, используя процессы, как уже это делают в мобильных приложениях, e-commerce или cloud services.
2. Автопроизводители должны без опаски разрешать service vendors интегрировать автомобили в свою систему. Платформа же заботится о том, чтобы бизнес-сервисы никоим образом не спровоцировали сбой в safety и security critical частях ПО. Даже если кто-то разработал сервис с багами.

Так система позволяет совместить два подхода в разработке ПО: классический, сертифицированный waterfall в автомобилестроении и гибкие digital-сервисы с возможностью быстрого изменения бизнес-логики и обновления версий.

Очевидно, что подобная платформа не может существовать без аппаратной поддержки. Мы договорились о партнерстве с японской компанией Renesas Electronics — одним из лидеров по разработке и производству процессоров для автомобильных компьютерных систем. Мы совместно строим платформу, которая хорошо оптимизирована и интегрирована именно с их процессорами, особенно по части safety, security и performance. Но, если возникнет потребность интегрировать платформу с другими процессорами, это тоже возможно.

Если сравнивать наше решение с любой существующей connected platform, подобного сейчас не делает никто. Причина проста: для реализации такого продукта нужно интегрироваться с автопроизводителем на этапе проектирования автомобиля. Это долгий и ресурсоемкий процесс, поэтому разработчики connected vehicle platform ждут, пока автопроизводители дойдут до глубокой интеграции с software.

Мы решили не ждать, а помочь автопроизводителям ускорить этот процесс. И работаем на будущее — 4-5 лет вперед.

Примеры сервисов

Разницу между «традиционными» платформами и продуктом EPAM легко объяснить на примерах.

1. No connection

Эта вещь, которая от разработчика не зависит и может случиться в любой момент. Используя существующие платформы остается только ждать, пока коннект восстановится.

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

2. Fleet control

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

Как работают классические платформы? Автомобиль, который катается по зоне А, каждую секунду или полсекунды посылает в сеть свои координаты. Оператор, который сидит «где-то там» за компьютером, следит, чтобы автомобили не выезжали из своих зон. Но вот перегруз сети, место плохого сигнала — и связь между авто и облаком исчезает. Оператору не на что опираться, ведь точка на карте замерла или вовсе пропала. А с ней — и контроль за соблюдением границ рабочей зоны.

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

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

Все это может работать безо всякой связи с интернетом. Эту логику мы спроектировали, когда думали, как имплементируем свой сервис.

Более того, даже если связь не пропадает, модуль, работающий в автомобиле, может оптимизировать использование коммуникационного канала. Вместо того, чтобы слать GPS-координаты в облако каждую секунду, он может делать это в 5-10 раз реже — чисто для мониторинга. И продолжать контролировать зону нахождения авто изнутри самого авто.

3. Predictive maintenance

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

4. Quality of Service

Как по мне, это самый приземленный и понятный пример.

Представьте, что вы находитесь в Киеве и собираетесь ехать в аэропорт. Вызываете Uber. По правилам сервиса водитель узнает, куда вас вести, только по прибытию к вам. Он приезжает, вы садитесь, называете пункт назначения. И оказывается, что бензина в автомобиле хватит только на полдороги. А вам нужно ехать и побыстрее.

С нашей платформой Uber мог бы установить в автомобиль свой сервис, который еще на этапе заказа мог бы сказать Uber-бэкенду о состоянии автомобиля: сколько бензина в баке, какой расход, подкачены ли колеса. И ситуация с нерелевантной машиной не произошла бы.

Кто участвует в разработке?

Есть три типа software-инженеров, которых мы задействуем в разработке платформы.

Первый — low level embedded developer — эти ребята знают, как правильно работать с железом, виртуализацией, как работает Linux на уровнях kernel-драйверов и т.п.

Второй — классический embedded developer — ребята понимают, как софт разрабатывается и живет во встроенных системах, где есть ограничение по памяти, дисковому пространству, ЦПУ. Что нельзя писать программы и аллоцировать 20 Мб памяти на стэке просто потому, что мне так удобно.

Третий — high level developer — специалисты по разработке распределенных cloud-сервисов. Понимают, что это такое, как делать сервисы, как происходит CI/CD, как строятся сервисы, способные обслуживать большое количество пользователей и оперировать большим количеством данных, как использовать современные облачные технологии и инструменты.

Что до самой структуры, то в автомобильной ее части мы используем подход виртуализации и контейнеризации — для того, чтобы изолировать mission critical ПО от ПО, которое может прийти из облака.

На автомобильном компьютере устанавливается система виртуализации, где есть отдельная виртуальная машина, которая контролируется облаком. В нее могут деплоиться контейнеры.

Контейнеры — не просто обыкновенные, как Docker, а легковесные, которые мы разработали специально для этой платформы. Чтобы более-менее спокойно деплоить что-то из облака в авто, это что-то должно быть небольшим — в пределах нескольких Мб. Во-первых, для автомобиля, у которого на onboard-компьютере всего 2 Гб памяти, привычные cloud-разработчикам контейнеры по 1 Гб — это очень много. Во-вторых, опять-таки нестабильные коммуникационные каналы. И чем меньше будет контейнер, тем больше шансов, что он действительно задеплоится, а не прервется где-то посередине.

Следующий этап — контейнеризация. И верхний уровень — система управления деплойментом между cloud и автомобилем.

Фишка нашей системы в том, что люди, которые разрабатывают сервисы для connected vehicle на базе платформы, ничего специфического про автомобиль знать не должны. Они могут продолжать пользоваться Javascript, .NET, Python или любым другим языком, в котором делают cloud-сервисы. А платформа обеспечит магию: возьмет часть микросервисов, которые должны быть в автомобиле, установит их туда и будет заботиться, чтобы они работали, не вредили друг другу и никак не помешали критическим функциям.

Вызовы, или Что занимает наши головы

Конечно, разработка такой платформы — не прогулка выходного дня. Самая большая сложность — концептуальная. Приходится пробиваться сквозь стереотипы автопроизводителей и объяснять, что правильно разработанное ПО будет помогать, а не вредить. Пока что в их головах cloud, software, Agile = зло.

Если говорить о сложных технических вопросах, решаем следующие:

1. Виртуализация. Все о ней говорят, все понимают, что такое виртуальная машина и зачем она нужна. Но как это использовать в автомобильном компьютере?

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

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

2. Использование GPU. Механические спидометры почти ушли в небытие, а бортовой компьютер выводит все показания на мониторы. Но чтобы это работало и рисовало красивые приборы, нужен GPU. Как поделить его ресурс, когда есть несколько виртуальных машин, которые им пользуются? Что сделать, чтобы внезапная фатальная ошибка GPU от одной из систем, не положило его для других частей?

3. Надежность. Об этом я неоднократно говорил выше, и это приоритетный вопрос. Как правильно построить архитектуру, чтобы cloud software никоим-никоим образом не смогло привести к ошибке в safety software?

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

Мы получаем очень положительные отзывы от автопроизводителей. Хотя все движется медленнее, чем нам бы хотелось, но мы помним, что у автомобилестроения свой таймлайн.

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

Сроки и люди

Над платформой в EPAM работают несколько десятков человек. Мы стартовали в конце 2016 года. В середине 2017-го начали показывать ее потенциальным клиентам. А в этом январе на CES-2018 вместе с Renesas Electronics презентовали платформу широкой общественности.

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

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

Команда разработки воспользовалась концепцией американского Агентства национальной безопасности, которая называется Defense in Depth. В нашей платформе мы имплементируем этот подход: многоуровневая система безопасности, при этом каждый уровень независим друг от друга. И если даже злоумышленнику удается взломать один из уровней, он застревает на этом уровне и не может пройти дальше.

Дополнительную секьюрность дают процессоры Renesas — они дают для этого большой спектр hardware-опций. В итоге, количество ресурсов, которое необходимо потратить на взлом, по отношению к бизнес-бенефиту становится непропорционально большим. И эта система постоянно совершенствуется.

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

Важный момент напоследок.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU