Поиск подходящего инструмента разработки и платформы для автомобильного HMI

22 марта 2023 г.

Многие производители оригинального автомобильного оборудования (OEM) и поставщики первого уровня разрабатывают свои собственные платформы и реализации встроенных человеко-машинных интерфейсов (HMI), средств связи и автомобильных информационно-развлекательных систем. Для решения этой задачи существует широкий спектр базовых операционных систем и средств разработки пользовательского интерфейса. Каждый из них имеет свои плюсы и минусы, а также поддерживаемый функционал, доступный для интеграции. Эти собственные разработки направлены на оптимизацию процессов для достижения ключевых целей компании, что в конечном итоге приводит к увеличению маржинальности продукта.

Основные направления развития этих типов систем охватывают три основные цели для автомобиля как продукта:

Расширенная информационно-развлекательная система — одна из самых популярных в сегменте легковых автомобилей. Она включает в себя ряд развлекательных функций, доступных в автомобиле, а также системы навигации и распознавания голоса. Последние два являются наиболее ресурсоемкими процессами на головных устройствах и повышают уровень требований к аппаратным реализациям и периферийным устройствам. Например, почти все OEM-производители в пассажирском сегменте планируют добавить поддержку естественного языка в голосовой помощник, для чего требуется стабильное подключение к Интернету и качественная система шумоподавления.
Надежное взаимодействие с транспортным средством включает все типы взаимодействия с внутренними компонентами транспортного средства и требования к этому взаимодействию. Это направление является ключевым с точки зрения брендинга каждого OEM-производителя, поскольку оно агрегирует все типы физических и цифровых интерфейсов для взаимодействия с водителями и пассажирами. Следовательно, с точки зрения функциональности головного устройства Tesla Model Y, New Ford Mustang и Byton имеют совершенно разные конфигурации экранов и элементов управления. При этом нельзя забывать, что в случае с цифровыми приборными панелями приходится учитывать требования ISO 26262. Кроме того, активное развитие функционала ADAS и автономного вождения приводит к значительному усложнению визуализации содержимого экрана через интеграция 3D-рендеринга.
Цель умной ЭКО-системы достаточно гибкая, но ее главная цель — увеличить маржинальность конечного продукта за счет интеграции с внешними сервисами. С одной стороны, это базовые профили пользователей, которые уже есть на смартфонах, а с другой — интеграция с внешними бизнес-сервисами или поставщиками данных. Это направление особенно важно для OEM-производителей коммерческих автомобилей или транспортных средств, которые в значительной степени ориентированы на рынки каршеринга или такси, поскольку оно позволяет им аккумулировать широкий спектр коммерческих услуг без дополнительных затрат.

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

Вот примеры функциональных возможностей, которые скользят по областям:

| Взаимодействие транспортных средств | Информационно-развлекательная | ЭКО система | |----|----|----| | Периферийные устройства — различные аппаратные устройства, подключенные к головному устройству, такие как экраны, аудиоустройства и автомобильные интерфейсы. | Мультимедиа – FM, DAB, SXM, Spotify, YouTube и т. д. | Технические услуги — беспроводные обновления, удаленная диагностика и телеметрия | | Средства управления транспортным средством - Визуальное управление функциями и информацией транспортного средства | Возможности подключения — подключение телефона к автомобилю через Bluetooth и основанные на этом решения для зеркалирования (Android Auto, Apple CarPlay, Baidu и т. д.). | User Profiling - персонализация автомобиля под текущего пользователя на основе внешнего или внутреннего профиля | | Безопасность — критичное значение для функций вождения, таких как спидометр, индикация неисправностей и камера заднего вида. | Навигация — встроенная навигационная система и весь пользовательский опыт (UX), привязанный к ней. | Бизнес-услуги - широкий спектр бизнес-услуг, связанных с автомобилем, включая управление автопарком, каршеринг, такси и т.д. | | ADAS — Визуализация функций ADAS и автономного вождения, включая критические уведомления и 3D-рендеринг дорожного движения. | Голосовой помощник - системы распознавания голоса, решения для генерации речи и диалога на его основе | Платформинг и усилители; 3rd party — Создание платформы на базе головного устройства, с возможностью запуска сторонних приложений и быстрого применения обновлений для различных коммерческих целей. |

Каждый поставщик OEM и Tier 1 учитывает бизнес-цели и поверх них формирует требования к архитектуре основного головного устройства. Стандартный жизненный цикл автомобиля обычно составляет 3-5 лет, поэтому решения с отдельными модулями для каждой из этих целей отходят в сторону, уступая место решениям с единым модулем управления для всех этих целей. Основной движущей силой этого изменения является оптимизация стоимости спецификации автомобиля, что выдвигает более сложные технические требования к таким решениям.

Самые важные из них:

Большинство OEM-производителей уже отказались от аналоговой приборной панели и заменили ее цифровой. Это предъявляет требования для достижения ISO 26262 с минимальным уровнем ASIL B и включает все механизмы, связанные с безопасностью.
Встроенный человеко-машинный интерфейс и бортовая информационно-развлекательная система подчиняются очень строгим требованиям к скорости и стабильности. Например, самое сложное требование для времени загрузки — 2 секунды для отображения камеры заднего вида в соответствии с NHTSA https://www.ecfr.gov/current/title-49/subtitle-B/chapter-V/part-571/subpart-B/section- 571.111 (хотя есть возможность увеличить это время до 4 или 5 секунд за счет более раннего включения драйвера, приближающегося к распознаванию).
В отличие от мобильных систем, автомобильные человеко-машинные интерфейсы (HMI) и автомобильные информационно-развлекательные системы ориентированы на решения с несколькими дисплеями (взять, например, последние модели Volkswagen, Mercedes-Benz, Ford, JRL и т. д. ). Это вводит дополнительные требования к функциональности и производительности этих систем.

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

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

Отходя от отдельных устройств, отвечающих за каждую цель, мы разрабатываем решения на основе гипервизоров первого, второго или аппаратно-зависимого типа. О них написано много; мы не будем обращать на это много внимания. Единственное, что нас интересует, так это то, что метод разделения ресурсов на уровне гипервизора должен оказывать минимальное влияние на доверенную (безопасную) операционную систему и должен достигать уровня ASIL B в качестве автономного решения или в системе с дисплеем.

Первым перекрестком, который влияет на цели компании, является выбранная платформа и операционные системы, используемые для реализации бизнес-логики и пользовательского интерфейса в областях безопасности и информационно-развлекательных систем.

Большую часть этого сегмента автомобильного рынка занимают решения:

| Домен безопасности | Информационно-развлекательный домен | |----|----| | QNX, ОС Green Hill, RTOS (зависит от аппаратного обеспечения) | Linux AGL, Linux COVESA (ext Genivi), Android Automotive (старые неавтомобильные версии уже устарели), QNX |

Здесь необходимо уточнить, что все решения, которые вы можете увидеть на дороге, прошли процесс кастомизации, выполненный поставщиками OEM или Tier1, но за основу, как правило, берется одна из вышеперечисленных баз операционных систем. Верно и то, что есть небольшие кусочки совершенно разных решений. Например, я работал с реализацией на основе Windows CE; честно говоря, количество усилий, вложенных в эту разработку, и качество оставляет их за рамками этой статьи. Конечно, при неограниченных ресурсах и времени реализовать описанные выше функции можно на любой из этих платформ, но на практике всегда необходимо исходить из сроков и бюджета автомобиля.

Попробуем оценить усилия по реализации всего объема работ на каждой из платформ:

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

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

При разработке собственного решения для интерфейса «человек-машина» и автомобильных информационно-развлекательных систем выбор правильной платформы — второй важный этап. По моему опыту было два случая, когда OEM или Tier1 изначально выбрали не тот фреймворк, потратили огромные усилия на внедрение, а в итоге поняли, что он вообще не будет работать.

В настоящее время на рынке доступен широкий спектр таких платформ, а также решения, предоставляемые поставщиками уровня 1 (Harman, Continental, Bosch, LGE и Luxoft). Решения уровня 1 в основном основаны на некоторых распространенных платформах с дополнительными функциями. Общие фреймворки включают в себя: Kanzi (Rightware), Altia, Qt + Qt3DStudio, Candera CGI Studio, EB GUIDE, Android Automotive (Native — стандартная Android Automotive Framework), Android Automotive (Unity/Unreal Engine — комбинация Android Automotive Framework и инъекций Кадры Unity/Unreal Engine для 3D-визуализации). У каждого из перечисленных инструментов есть свои плюсы и минусы, выросшие из исторически сложившегося функционала и адаптированные под сегменты рынка.

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

Если суммировать результаты по операционным системам и фреймворкам, то получится следующая картина:

Основываясь на ограничениях платформы и инфраструктуры, можно выделить группу операционных систем реального времени с решениями для моделирования пользовательского интерфейса, таких как Kanzi (Rightware), Altia и Candera CGI Studio. Эти комбинации удовлетворяют потребности доверенного домена, но требуют больших затрат, когда дело доходит до реализации информационно-развлекательного домена. В основном это связано с циклом разработки инструментов моделирования и ограничениями, налагаемыми областями безопасности.

EB GUIDE Qt + Qt3DStudio позволяют создавать решения для всех операционных систем, но в обоих случаях будут значительные затраты на оптимизацию.

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

Заключительные мысли:

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

Ссылки:

Студия Канзи — https://rightware.com/product/kanzi-studio/

Qt 3D Studio — https://doc.qt.io/qt3dstudio/qt3dstudio-index.html

Студия компьютерной графики Candera — https://cgistudio.at/

EB GUIDE Studio — https://www.elektrobit.com/products/ux/

Альтиа – https://altia.com/design/

QNX — https://blackberry.qnx.com/en

FreeRTOS — https://www.freertos.org/

Автомобильный Linux — https://www.automotivelinux.org/

COVESA — https://www.covesa.global/

Оригинал