Automotive Connected Mobility: з чого все починалось, як та над чим працюємо зараз, чого очікуємо в майбутньому

2022 року у світі було продано понад 67 мільйонів авто, а у 2023, цей показник вищий за позначку в 70 мільйонів. Майже всі продані авто мають можливість підключення до інтернету та взаємодії з інфраструктурою навколо, в тому числі завдяки розробкам нашої команди. В цьому матеріалі розкажу про те, якими були перші проєкти в напрямку, над створенням яких розробок працюємо зараз, та куди прямує прогрес в Automotive Connected Mobility.

Разом з командою ми працюємо над технологіями під загальною назвою Connected Mobility, що є одним з ключових напрямків Connected, Autonomous, Shared, Electric трендів автомобілебудування. Наші розробки дають можливість автомобілю підключатися до мережі, хмарних сервісів, супутників та інших пристроїв для взаємодії з зовнішнім світом.

Напрямок складається з двох частин: «in-vehicle» та «off-board» компонентів, де «off-board» — це хмарні платформи, такі як Microsoft CVP або AWS CMS, мікросервіси, а також Web- та мобільні застосунки. Ключовою ж «in-vehicle» ланкою є Телематичний Юніт Керування, що являє собою систему, яка інтегрується в автомобіль та дозволяє йому обмінюватись інформацією шляхом використання технологій передачі даних мобільного радіозв’язку (2G/EDGE, 3G, 4G/LTE, 5G).

Основними компонентами Телематичного Юніту є низькорівневий мікроконтролер, наприклад Renesas або Infineon, з операційною системою реального часу (RTOS, Real Time Operating System) та системою на чипі (SoC, System-on-Chip), найрозповсюдженішими з яких у застосуванні є Qualcomm, MediaTek або Huawei, з операційною системою Linux. Мікроконтролер за допомогою великої кількості комунікаційних інтерфейсів керує периферією та взаємодіє з іншими компонентами автомобіля (Electronic Control Units), отримуючи від них дані через CAN-шину або Automotive Ethernet. SoC, у свою чергу, надає доступ до аудіо каналу та каналу даних бездротової передачі.

Ми працюємо над розробкою Телематичних Юнітів для багатьох всесвітньо відомих європейських, американських та японських автовиробників протягом останніх 8 років.

Перший проєкт команди в Connected Mobility, до того як це стало мейнстримом

Розробку в Connected Mobility ми стартували у 2016 році. Тоді цей напрям ще не було виділено в окремий домен, як зараз, а розглядався він як складова частина розробки інформаційно-розважальних систем автомобіля (IVI, In-Vehicle Infotainment). Це був вбудований в автомобіль пристрій доступу до мережі (NAD, Network Access Device), дуже схожий за функціоналом на мобільний телефон, але на вигляд як «black box» без кнопок і дисплею, розміром 10×15 см і роз’ємами під антени та інші конектори. На початку ми розробляли його як proof of concept для одного з відомих американських автовиробників (OEM, Original Equipment Manufacturer), а пізніше він став основою для комерційного продукту і демо прикладом для інших замовників.

Пристрій доступу до мережі був досить простим і міг виконувати лише базовий функціонал: встановлювати зв’язок з тестовим центром допомоги (PSAP, Public Safety Answering Point) через закодований і зашифрований аудіо канал, та відправляти повідомлення з мінімально необхідною інформацією про стан автомобіля у разі аварії. Пакет мінімально необхідної інформації (MSD, Minimum Set of Data) містить обов’язкову інформацію про місцеперебування та напрямок руху автомобіля, мітки часу, коли відбулася подія, тип транспортного засобу та його ідентифікаційний номер (VIN, Vehicle Identification Number), яка може бути розширена додатковою інформацією про кількість пасажирів, стан ременя та подушки безпеки тощо. На той час у нас не було GNSS/GPS передавача, ми власноруч симулювали зміну координат та даних CAN-шини, аби показати що концепт працює.

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

Всі розробки стали основою системи автоматичного оповіщення про дорожні пригоди на автотранспорті (eCall, emergency Call), наявність якого є обов’язковою у кожному автомобілі, що вироблений або проданий у країнах Європи починаючи з 2018 року. З великою ймовірністю і в вашому автомобілі є вбудований Телематичний Юніт, який можна активувати за необхідності.

З цих часів минуло вже 8 років. На основі колись базового проєкту, було розроблено Телематичний Юніт і запущено у масове виробництво ще п’ять його поколінь.

Функціонал кожного наступного покоління був ширшим, а розробка ставала складнішою та цікавішою. Зокрема були додані можливості:

1. віддаленого контролю автомобілем з телефона та Web-інтерфейса: відкриття та закриття дверей, старт та стоп двигуна, подача звукового чи світлового сигналів тощо;
2. збору повної інформації про стан кожного електронного блоку керування, автомобіля вцілому та парку автомобілів, для подальшої обробки на державних або приватних серверах та хмарних сервісах;
3. віддаленої діагностики та прогнозованого обслуговування, оновлення системи Over-The-Air;
4. відстежування місцеперебування автомобіля у разі його викрадення, обмеження зон і швидкості керування для підлітків;
5. точок доступу WiFi всередині автомобіля шляхом маршрутизації пакетів даних мобільного радіозв’язку;
6. розширеної навігації, функцій онлайн трафіку та отримання інформації про небезпеку на дорогах;
7. голосового помічника;
8. передачі відеопотоку для доповненої реальності та віддаленого керування автомобілем.

Життєвий цикл розробки кожного покоління Телематичного або іншого блоку керування близько 15 місяців, хоча є тенденції до зменшення завдяки можливості віддаленого оновлення програмного забезпечення. Остання модель автомобіля з розробленим нашою командою Телематичним Юнітом вийшла ще у 2021 році. Проте, команда все ще підтримує та покращує програмне забезпечення через періодичні оновлення. Загалом, кількість вироблених Телематичних Юнітів за цей період для даного автовиробника вимірюється мільйонами одиниць.

Раніше Connected Mobility та Телематики не існувало як окремого напрямку. Вже після початку робіт над проєктом, прийшло багато інших замовників, бо Телематичний Юніт став «must-have» сучасного транспортного засобу. Наша команда мала можливість спостерігати як Connected Mobility став окремим доменом та оферингом в компанії, і як вплинув на розвиток автоіндустрії в цілому.

Особливості розробки в Connected Mobility

Хоча кожен проєкт має свої технічні складнощі та виклики, саме eCall в Європі, чи його аналоги helpNet в Японії й 911 в США, були й залишаються одними з найскладніших продуктів для розробки.

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

Окремі вимоги висуваються до апаратної архітектури. Мінімально необхідними компонентами, окрім самого пристрою та доступу до мережі або модему, є:

• інтерфейс CAN-шини для отримання даних, що будуть заповнені у MSD пакеті;
• додатковий обсяг пам’яті для збереження показників стану автомобіля за останні декілька хвилин;
• блок управління живленням та вбудованим резервним акумулятором для можливості продовження роботи при від’єднанні від основного джерела;
• аудіо інтерфейс (мікрофон та динамік) для двостороннього голосового з’єднання;
• мінімальний функціональний блок людино-машинного інтерфейсу;
• годинник реального часу для забезпечення оновлення даних, навіть коли бортова система автомобіля вимкнена;
• GNSS/GPS, що надає інформацію про місцеперебування;
• наявність декількох антен стільникової мережі, що дублюються на випадок, якщо одна вийде з ладу.

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

Кожен апаратний компонент також має свою програмну складову і відповідні вимоги до них. Так, наприклад, якість передачі голосу і звуку повинна відповідати певним критеріям, для чого використовуються алгоритми ехо- та шумоподавлення (ECNR, Echo Cancellation Noise Reduction). Ехоподавлення передбачає розпізнавання головного і другорядного голосового сигналу, що повторюється з деякою затримкою, зміщені за фазою. Як тільки сигнал, що повторюється, розпізнаний, він видаляється за допомогою його віднімання з переданого або отриманого сигналів. Інші неосновні сигнали, розпізнані як шум, подавляються. А для отримання більш точного місцеперебування, особливо в умовах обмеженої можливості зв’язку зі супутниками або багатопроменевого поширення хвилі, як у підземному паркінгу, тунелі або в містах з високою забудовою, використовуються алгоритми обчислення мертвих точок (Dead Reckoning), що визначають місцеперебування рухомого об’єкта за вихідними початковими координатами й параметрами руху, такими як швидкість руху і курс у конкретний момент часу, шляхом інтерполяції й коригування помилок даних.

Однією з нетривіальних задач, над якою ми працювали, було виявлення автоматичного тригера запуску eCall для двоколісних транспортних засобів. Річ у тім, що досить важко розпізнати критерії автоматичного тригера без сигналу від спрацювання подушки безпеки та підтверджених даних акселерометра та гіроскопа, бо у мотоциклів вони можуть відповідати нормальному стану залежно від кута нахилу при повороті чи наїзді на яму/виступ, а також при здійсненні трюків. Для виявлення критеріїв падіння мотоцикла вводиться науковий алгоритм, що враховує кутову швидкість і нахил по осях x, y, z та їх зміну у часі. І це тільки деякі особливості, з якими стикаються розробники програмного забезпечення.

Також поділюсь цікавою закономірністю, яку ми виявили: життєвий цикл автомобіля складає приблизно 15 років, що значно довше за життєвий цикл мобільного пристрою (3-4 роки) й, що важливіше, інфраструктури операторів мобільного зв’язку. Оператори мобільного зв’язку у багатьох країнах почали поступово відмовлятись від мереж 2G/3G і переходити на мережі 4G/5G. Отже, Телематичні Юніти, модеми яких не підтримують 4G/5G, перестануть функціонувати, в тому числі й функція eCall. А це означає, що наступний челендж, який стоїть перед нами — це реалізація нового стандарту eCall NG (emergency Call Next Generation), взаємодія з PSAP якого буде реалізована на основі дата каналу (IMS, Internet Protocol Multimedia System). Це надасть додаткові можливості:

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

Задачі, робота над якими здавалась неможливою ніколи, та стала реальною зараз

Згадаймо, 8 років тому ми робили proof of concept якоїсь фічі. З тих часів відбулось дуже багато змін в інфраструктурі. Значно зросла потужність процесорів, які знаходиться у SoC — якщо раніше для програмування ми використовували C, то зараз ми можемо використовувати різні framework-и, писати на C++. Деякі високорівневі застосунки взагалі пишуться на Java під віртуальні машини, що надає можливість їх динамічно встановлювати, переносити та видаляти з систем.

Так само і на стороні MCU відбулись зміни: обчислювальні можливості стали значно вищими, а з появою стандартів AUTOSAR (AUTomotive Open System ARchitecture) було узгоджено підхід до програмної розробки, інтеграції й перевикористання базових компонентів системи.

З’явилась необхідність підтримувати великий об’єм даних, який проходить всередині машини й, до того ж експонентно зростає:

• обробляти не тільки CAN-шину, а ще й Ethernet-шину, яка повʼязує локальні зʼєднання в авто;
• опрацьовувати діагностичні дані та отримувати їх з різних ECU;
• перепрошивати не тільки Телематичний Юніт (Self-Update), а й інші ECU через On-Air-Update.

Все це формувало додаткові великі обсяги даних. Раніше пересилання інформації для перепрошивки проходило через «Transport protocol», який базувався на CAN-шині. Він міг передавати лише 4 кб даних за десятки секунд, чого обʼєктивно замало для прошивки девайсу. Ми реалізували TP-on-TP, що дозволило нам збільшити обʼєм передачі даних, але це своєю чергою збільшило і час транспортування пакетів до десятків хвилин. Звичайно, це не може застосовуватись, коли нам потрібно оновити навігаційні бази даних чи прошивку головного юніта. Тому ці протоколи змінюються, і зараз в більшості випадків використовуються ті, що базуються на Automotive Ethernet. Тож, якщо раніше MCU являли собою якісь звичайні контролери, зараз це вже більш потужні процесори різних сімейств для обробки великих масивів даних.

Змінились не тільки технології навколо, а і наша команда стала більш досвідченою і готовою до більш масштабних проєктів.

Софтверна архітектура Телематичного Юніта є трирівневою, в основі лежить базовий рівень: пакет підтримки плати (BSP, Board Support Package) від виробника апаратної частина з драйверами та шаром апаратних абстракцій (HAL, Hardware Abstraction Layer), файловою системою, ядром операційної системи. Середній рівень, middleware, в нашому випадку він ще називається SDK, Software Development Kit або Телематична Платформа, що являє собою набір сервісів, наприклад: сервіси для конфігурації модема, управлінням каналами аудіо чи даних, локаційний або термал сервіси, менеджер живлення й багато інших. Сервіси є сталими, не змінюються від продукту до продукту протягом декількох років і надають абстрактні інтерфейси для швидшої та легшої реалізації додатків. Використовуючи доступні інтерфейси, що надає платформа легко реалізовувати велику кількість Телематичних додатків (рівень applications) зі своєю унікальною для кожного автовиробника чи продукту бізнес-логікою.

У більшості наших проєктів ми довгий час займалися розробкою додатків, тоді як Телематична платформа була для нас бажаним, але закритим «полем», бо це інтелектуальна власність наших замовників і їх конкурентна перевага, якою вони не хотіли ділитись з іншими. Проте, крок за кроком нас почали долучати до розробок на рівні платформи, а потім і на рівні BSP (Board Support Package), дозволивши безпосередньо взаємодіяти з виробниками апаратних частин, обговорювати їх проблеми й інтегрувати пакети оновлення. Раніше ми навіть не могли уявити, що отримаємо можливість не тільки працювати всередині Телематичних платформ, а й повністю відповідати за її підтримку і подальшу розробку. Рівень залученості, який зараз повністю на нашому боці можна описати просто — від нашої роботи залежить життєвий цикл десятків продуктів різних автовиробників, що налічує десятки мільйонів одиниць.

Але хотілось би бути залученими в більш передові «технологічні» роботи, піти на наступний рівень, зробити новий крок для розвитку напрямку. Брати участь в розробці наступних поколінь Телематичних платформ, які вже інтенсивно розробляються багатьма автовиробниками всередині, але наразі не виносяться на аутсорс.

Найцікавіший кейс за 8 років досвіду

Очевидно, що з переходом інфраструктури на 5G технології найсуттєвіші зміни найближчим часом відбудуться у сфері удосконалених систем допомоги водію (ADAS, Advanced Driver Assistance Systems), які потребують не тільки розпізнавання об’єктів завдяки комп’ютерному зору, побудові моделей навколишнього середовища використовуючи радари, лідари, ультразвуковиі сенсори, навігацію високої чіткості, високоточних GNSS/GPS тощо, а ще й безпосередньої взаємодії з іншими учасниками дорожнього руху. Навіть у випадку, якщо останні перебувають у «сліпих» зонах. Також важливою є й взаємодія з інфраструктурою, для покращення прогностичної моделі поведінки. Цей концепт називається зв’язок автомобіля з усім навколо (V2X, Vehicle to Everything), і де як не в Телематичному Юніті повинен бути реалізований цей функціонал.

Нещодавно ми працювали над некомерційним R&D проєктом, proof of concept в напрямку V2X. Це була реалізація кейсів взаємодії автомобіля з інфраструктурою (V2I, Vehicle 2 Infrastructure) та автомобіля з автомобілем (V2V, Vehicle 2 Vehicle). Шляхом впровадження новітніх протоколів Cellular V2X (C-V2X) та Dedicated Short Range Communications (DSRC), вдається забезпечити надійну та безпечну передачу більшого об’єму даних з меншими затримками, за рахунок фізичних властивостей технологій бездротової передачі даних, що мають можливості багатоадресної передачі від точки до точки в ближній і середній зоні дії прийомопередавача без взаємодії з базовою станцією.

Реалізація проєкту складалась з двох етапів:

1. розробка демо платформи й середовища для моделювання;
2. розробка додатків, на основі яких було реалізовано декілька прикладів використання.

За основу демо платформи було використано Qualcomm SoC з нативними BSP та SDK. Ми розширили її функціонал розробивши меседж-менеджер для обміну даними за схемою «Телематичний Юніт — Телематичний Юніт», та «Телематичний Юніт — Придорожні Юніти (Roadside Units)». Меседж-менеджер також включав енкодер та декодер V2X/J2735 повідомлень, вибудовував алгоритми прийняття рішень та мав функції керування автотранспортом. Для моделювання середовища і симуляції використовувались SUMO/TraCi, Vector CANoe та GNSS симулятори.

На базі демо платформи були розроблені програми для реалізації прикладів застосування:

• V2I — GLOSA (Green Light Optimal Speed Advisory);
• V2V — електронного аварійного гальмівного світла (EEBL, Electrical Engine Brake System), попередження про динамічні зміни на дорозі (CLW, Control Loss Warning, FCW, Forward Collision Warning, LCW, Line Change Warning), а також Platooning для автономного руху комерційних вантажівок у колоні.

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

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

Ми мали абсолютну свободу фантазії — моделювали віртуальне середовище, симулювали різну поведінку учасників дорожнього руху і таким чином тестувати нашу імплементацію ITS (Intelligent Transportation Systems) стека. Досить цікаво спостерігати як машини спілкується між собою в динаміці й змінюють свою поведінку залежно від створених ситуацій: перемикання світлофора з зеленого на червоне світло без жовтого, відстань авто до світлофора на момент зміни тощо.

Ця тема досить новітня і цікава, але розлога і потребує окремої статті для висвітлення.

Висновок та очікування щодо майбутнього

З точки зору архітектури автомобіля відбуваються суттєві зміни. Якщо раніше виробники компонентів розробляли як «залізо», так і «софт», продаючи готові рішення, то зараз вони не дуже зацікавлені в таких комплексних підходах. Все як з мобільними телефонами — Nokia чи Samsung, якими користувалася більшість, були абсолютно різними пристроями зі своєю пропрієтарною операційною та екосистемами, а зараз це просто платформа, на якій стоїть майже апаратно незалежний Android чи iOS з відкритими стандартизованими API та маркетплейсами для додатків.

Такий самий декаплінг, як відбувся тоді з телефонним «софтом» і «залізом» відбувається й у нас. Автовиробники хочуть розділити апаратні та програмні платформи, займатись не тільки промисловою конвеєрною збіркою компонентів автомобіля, а й самостійно розробляти ПЗ, монетизувати переваги програмно визначених автомобілів (SDV, Software Defined Vehicle). Це і створює основний тренд на майбутню роботу. Автовиробники створюють спільні підприємства з софтверними компаніями як, наприклад, Volkswagen започаткував CARIAD, яка займається тільки розробкою програмного забезпечення для всього Volkswagen Group.

Це однозначно додає нам оптимізму, бо розробка програмного забезпечення як раз таки наша сильна сторона. Автовиробники поки що не готові розробляти його самостійно і часто приходять до софтверних компаній. Отож, очікуємо збільшення зацікавленості саме в реалізації концепту програмно визначених автомобілів, розробці операційних система (Ford.OS, VW.OS, MB.OS, Tata.OS тощо). Такий підхід буде працювати поки не з’явиться стандартизований автомобільний аналог «iOS» та «Android» зі створеною екосистемою з маркетплейсами для програм сторонніх розробників.

Звичайно саме Телематичний Юніт або Connectivity Gateway є і буде ключовою ланкою у всіх цих розробках, адже даний прогрес неможливий без зв’язку з зовнішнім світом і виходом у мережу.