Kubernetes для автомобіля: як відкрити розробникові доступ до бортового комп’ютера та зробити це безпечно

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

У першій частині я розповідав як наші розробки XEN Hypervisor дозволяють ізолювати сервісну частину автомобільного ПЗ від safety required software. Це один з бар’єрів, що заважає широкому застосуванню в індустрії. Вперше оперсорсний гіпервізор стане повноцінним конкурентом закритим комерційним рішенням.

Але це лише перша сходинка. Аби вивести автомобільні сервіси на новий рівень, потрібно «пустити» в нього сервіс-компанії та розробників, які далекі від embedded и automotive. Для цього потрібний новий рівень абстракції. Щоб розробник, який користується сучасними фреймворками у розробці програмного забезпечення міг без перенавчання дизайнити сервіси для автомобілів.

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

Отже.

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

Найближча аналогія - смартфони. До 2007-09 років написати додаток, який би працював на різних мобільних телефонах, було досить важко. На ринку змагалися численні операційні системи та фреймворки: рішення від 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 для автомобілів».

ізолювати safety software від connected services software;

надати необхідний рівень абстракції для компаній, які хочуть розробляти або вже роблять 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 від початку був спроектований для деплоймента та оркестрації сервісів в хмарі. Тобто в контрольованому, підтримуваному і захищеному від чужого втручання середовищі. Але у нас є автомобіль, а у зловмисників - необмежена фантазія. Вони можуть витягти бортовий комп'ютер, зламати його якимось пристроєм, влізти в канал між авто і хмарою. Тому безпека - це наш постійний пріоритет.
   Ми реалізували просунуту модель згідно з рекомендаціями Агентства національної безпеки США. Йдеться про наступне: при проектуванні власної системи безпеки ви повинні в першу чергу мінімізувати кількість місць потенційної атаки, а також будувати сек'юріті як листковий пиріг. Зламали на якомусь рівні? Потрібно це відстежити і докласти максимум зусиль, щоб не пустити зловмисника на наступний рівень.
   В нашій моделі «пиріг» виглядає таким чином:
   Ми використовуємо контейнери у якості ізоляторів на рівні Linux OS. Вирватися з контейнера дуже важко.
   Припустімо, це вдалося зробити? Але Connected Vehiclle Platform виконується на окремій віртуальній машині - для цього нам і потрібний XEN. Ця віртуальна машина ізольована від усієї периферії. Спілкування з периферією може відбуватися тільки через якісь API, які надаються виробником автомобіля.
   Зламав контейнер і віртуальну машину? У нас є ще один бар'єр - virtual machine introspection: аналіз патернів, за якими працює віртуальна машина. Наприклад, віртуальна машина раптом наполегливо намагається дістатися якоїсь пам'яті, яку зазвичай не чіпає. Можна відреагувати: відключити цю віртуальну машину, відкотитися на стабільну версію тощо.
3. Scale
   Чи критичний час оновлення на смартфонах користувачів для умовного мобільного банкінгу? Не особливо. Аби нічого не зламалося. У cloud-сервісів питання скейл не є найгострішим.
   З автомобілем по-іншому. Наприклад, ви орендували машину і хочете використовувати сервіс, який дає вам хороший страховий поліс, бо ви вправний водій. Але для цього потрібно, щоб в автомобіль задеплоївся сервіс, який надає ваші дані страховій компанії.
   Ви сіли в авто, повернули ключ та за 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. Безпровідна мережа не працює безперебійно.

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

З нашою платформою ані Tesla, ані іншим виробникам не доведеться витрачати час на винахід велосипеду. Адже ніхто в додатках для хмари вже не розробляє свій Kubernetes. На нашу думку, те саме має статися з Connected Vehicle Platform.

Якщо говорити про конкуренцію в цілому, поки що ми ще не бачили жодного конкурента, який хоча б мимохідь згадував те, про що ми говоримо. Як виявилося, автомобільна індустрія ще дуже закрита. І багато речей в платформі - ту ж підтримку FOTA і SOTA - ми робимо не тому, що вона потрібна зараз, а на випередження.

Разом з тим, не думаю, що в майбутньому буде одна платформа для всіх автомобілів. Швидше за все, буде 2-3 великих. З одного боку, вони об'єднають виробників автомобілів. А з іншого - дадуть можливість використання сучасних фреймворків програмування. І ми побачимо зовсім нові кейси, які зараз навіть не уявляємо.