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 приймаються з авто і складаються в хмару. І тільки тоді конкретний бізнес-додаток або сервіс використовують ці дані для реалізації бізнес-логіки.

Виглядає просто, звично і зрозуміло, якби не очевидний мінус. Навіть два.

Залежність від постійного інтернет-з'єднання. Погана або відсутній зв'язок між автомобілем і хмарою — це реальність. Зв'язок пропадає — сервіс не може працювати: дані не передаються, розташування автомобіля невідомо і т. д. і т. п.
Автомобіль не знає, які дані можуть знадобитися конкретного сервісу. Тому він робить дуже просту річ — збирає всі можливі дані і шле це великим потоком в хмару. Але канал зв'язку між автомобілем і хмарою досить лімітований. Виходить, що він використовується неефективно. А з урахуванням того, що ці канали ніде і ніколи не відзначаються досконалістю, сервіс стає нездійсненним.

Тому, на відміну від інших хмарних платформ, в нашому варіанті комп'ютер автомобіля може виконувати частину бізнес-логіки. Прямо на ньому може виконуватися програмний код, який я, як вендор сервісу, пишу для кожного конкретного сервісу. Але! Він повинен виконуватися так, щоб стовідсотково не торкнутися safety і security critical частини софта, який забезпечує безпечне і надійне функціонування автомобіля.

Загальна логіка платформи така:

Розробникам платформа дозволяє створювати сервіси без оглядки на те, що одним з елементів сервісу є автомобіль. Вони пишуть свій сервіс тими мовами, використовуючи процеси, як це вже роблять в мобільних додатках, e-commerce або cloud services.
Автовиробники повинні без побоювання дозволяти 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

Як на мене, це самий приземлений і зрозумілий приклад.

Уявіть, що ви знаходитеся в Києві та збираєтеся їхати в аеропорт. Викликаєте ?ber. За правилами сервісу водій дізнається, куди вас вести, тільки по прибуттю до вас. Він приїжджає, ви сідайте, називаєте пункт призначення. І виявляється, що бензину в автомобілі вистачить тільки на півдороги. А вам потрібно їхати і швидше.

З нашою платформою ?ber міг би встановити в автомобіль свій сервіс, який ще на етапі замовлення міг би сказати 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 презентували платформу широкої громадськості.

За весь цей час у нас не було кардинальних змін маршруту. Зрозуміло, що зазвичай відбуваються якісь поправки і коригування. Ми говоримо з потенційними клієнтами, і у кожного є свої міркування, обмеження, переваги. Ми колекціонуємо всю інформацію, обробляємо і вирішуємо, як і що потрібно змінити, додати, прибрати.

Приміром, у автомобілістів величезні вимоги до сек'юріті. Тому ми постійно моніторимо апдейтим тему безпеки. Адже якщо ми дозволяємо хмарного сервісу встановити микросервис прямо в автомобіль, то теоретично можна припустити, що прийде злий дядько-хакер і підмінить сервіс того ж ?ber на свій шкідливий. І потрібно розуміти, як це не допустити. Або мінімізувати наслідки.

Команда розробки скористалася концепцією американського Агентства національної безпеки, яка називається Defense in Depth. У нашій платформі ми імплементуємо цей підхід: багаторівнева система безпеки, при цьому кожний рівень незалежний один від одного. І якщо навіть зловмиснику вдається зламати один з рівнів, він застряє на цьому рівні і не може пройти далі.

Додаткову секьюрность дають процесори Renesas — вони дають для цього великий спектр hardware-опцій. У результаті, кількість ресурсів, який необхідно витратити на злом, по відношенню до бізнес-бенефиту стає непропорційно великою. І ця система постійно вдосконалюється.

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

Важливий момент наостанок.

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

Опубліковано: 21/08/18 @ 07:43
Розділ Різне

SEO Блог