Поделиться через

Эталонная архитектура для обмена сообщениями, данных и аналитики

  • Статья

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

Архитектура

Схема высокоуровневой архитектуры.

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

  • Автомобиль содержит коллекцию устройств. Некоторые из этих устройств определяются программным обеспечением и могут выполнять рабочие нагрузки программного обеспечения, управляемые из облака. Автомобиль собирает и обрабатывает широкий спектр данных, от информации датчика от электро механических устройств, таких как система управления батареей до файлов журнала программного обеспечения.
  • Службы обмена сообщениями транспортных средств управляют связью с автомобилем и с нее. Он отвечает за обработку сообщений, выполнение команд с помощью рабочих процессов и медиатирование транспортного средства, пользователя и серверной части управления устройствами. Кроме того, он отслеживает регистрацию и подготовку транспортных средств, устройств и сертификатов.
  • Серверная часть управления автомобилями и устройствами — это системы OEM, которые отслеживают конфигурацию транспортных средств от фабрики до ремонта и обслуживания.
  • Оператор имеет ИТ и операции , чтобы обеспечить доступность и производительность как транспортных средств, так и серверной части.
  • Службы аналитики данных предоставляют хранилище данных и обеспечивают обработку и аналитику для всех пользователей данных. Это превращает данные в аналитические сведения, которые позволяют принимать лучшие бизнес-решения.
  • Производитель транспортных средств предоставляет цифровые услуги в качестве ценности для конечного клиента, от приложений-компаньонов до ремонта и обслуживания приложений.
  • Для нескольких цифровых служб требуется бизнес-интеграция с внутренними системами, такими как управление дилерами (DMS), управление отношениями клиентов (CRM) или системы планирования ресурсов предприятия (ERP).
  • Серверная часть управления согласием является частью управления клиентами и отслеживает авторизацию пользователей для сбора данных в соответствии с географическим законодательством страны или региона.
  • Данные, собранные из транспортных средств, являются входными данными в процесс цифровой инженерии с целью непрерывного улучшения продукта с помощью аналитики и машинного обучения.
  • Экосистема интеллектуальной мобильности может подписаться и использовать как динамическую телеметрию, так и агрегированные аналитические сведения для предоставления дополнительных продуктов и услуг.

Корпорация Майкрософт входит в рабочую группу Eclipse Software Defined Vehicle, форум для открытой совместной работы с использованием открытый код для платформ программного обеспечения автомобилей.

Поток данных

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

Транспортное средство в облачные сообщения

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

Схема потока данных обмена сообщениями.

  1. Автомобиль настроен для клиента на основе выбранных параметров с помощью API управления. Конфигурация содержит следующее:
    1. Сведения о подготовке транспортных средств и устройств.
    2. Начальная конфигурация сбора данных о транспортных средствах на основе рекомендаций рынка и бизнеса.
    3. Хранение начальных параметров согласия пользователя на основе параметров транспортного средства и принятия пользователем.
  2. Автомобиль публикует сообщения телеметрии и событий через клиент телеметрии очереди сообщений (MQTT) с определенными разделами в компоненте брокера MQTT Сетка событий Azure в службах обмена сообщениями транспортных средств.
  3. Сетка событий направляет сообщения разным подписчикам на основе атрибутов раздела и сообщений.
    1. Сообщения с низким приоритетом, которые не требуют немедленной обработки (например, сообщения аналитики) направляются непосредственно в хранилище с помощью экземпляра Центров событий для буферизации.
    2. Сообщения с высоким приоритетом, требующие немедленной обработки (например, изменения состояния, которые должны быть визуализированы в пользовательском приложении) направляются в функцию Azure с помощью экземпляра Центров событий для буферизации.
  4. Сообщения с низким приоритетом хранятся непосредственно в озере данных с помощью записи событий. Эти сообщения могут использовать пакетное декодирование и обработку для оптимальной стоимости .
  5. Сообщения с высоким приоритетом обрабатываются с помощью функции Azure. Функция считывает параметры согласия устройства, устройства и пользователя из реестра устройств и выполняет следующие действия.
    1. Проверяет, зарегистрирован и активен ли автомобиль и устройство.
    2. Проверяет, предоставлен ли пользователь согласие на тему сообщения.
    3. Декодирует и обогащает полезные данные.
    4. Добавляет дополнительные сведения о маршрутизации.
  6. Концентратор событий телеметрии live в решении аналитики данных получает декодированные сообщения. Azure Data Explorer использует прием потоковой передачи для обработки и хранения сообщений по мере их получения.
  7. Уровень цифровых служб получает декодированные сообщения. служебная шина предоставляет уведомления приложениям о важных изменениях или событиях состояния транспортного средства. Azure Data Explorer предоставляет последнее известное состояние транспортного средства и краткосрочной истории.

Сообщения об облаке для транспортных средств

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

В зависимости от возможностей и типов действий транспортных средств существует несколько возможных подходов к выполнению команд. Мы рассмотрим два варианта:

  • Прямое облако к сообщениям устройств (A), которые не требуют проверки согласия пользователя и с прогнозируемым временем отклика. В этом разделе рассматриваются сообщения как для отдельных, так и для нескольких транспортных средств. Пример включает уведомления о погоде.
  • Команды транспортного средства (B), использующие состояние транспортного средства для определения успешности и требования согласия пользователя. Решение для обмена сообщениями должно иметь логику рабочего процесса команды, которая проверяет согласие пользователя, отслеживает состояние выполнения команды и уведомляет цифровую службу при завершении.

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

Схема потока данных команды и управления.

Прямые сообщения выполняются с минимальным количеством прыжков для оптимальной производительности (A):

  1. Приложение-компаньон — это служба, которая может публиковать сообщения в Сетке событий.
  2. Сетка событий проверяет авторизацию службы приложений-компаньонов, чтобы определить, может ли она отправлять сообщения в указанные разделы.
  3. Приложение-компаньон подписывается на ответы из конкретного транспортного средства или сочетания команд.

Если командам, зависящим от состояния транспортного средства, требуется согласие пользователя (B):

  1. Владелец транспортного средства или пользователь предоставляет согласие на выполнение функций управления и команд для цифровой службы (в этом примере приложение-компаньон). Обычно это делается, когда пользователь загружает или активирует приложение, и OEM активирует свою учетную запись. Он активирует изменение конфигурации на транспортном средстве, чтобы подписаться на связанный раздел команды в брокере MQTT.
  2. Приложение-компаньон использует управляемый API команд и управления ими для запроса выполнения удаленной команды.
    1. Выполнение команды может иметь дополнительные параметры для настройки таких параметров, как время ожидания, хранение и пересылка параметров и т. д.
    2. Логика команды решает, как обрабатывать команду на основе раздела и других свойств.
    3. Логика рабочего процесса создает состояние для отслеживания состояния выполнения.
  3. Логика рабочего процесса команды проверяет сведения о согласии пользователя, чтобы определить, можно ли выполнить сообщение.
  4. Логика рабочего процесса команды публикует сообщение в Сетке событий с помощью команды и значений параметров.
  5. Модуль обмена сообщениями в транспортном средстве подписан на раздел команды и получает уведомление. Она направляет команду в нужную рабочую нагрузку.
  6. Модуль обмена сообщениями отслеживает рабочую нагрузку для завершения (или ошибки). Рабочая нагрузка отвечает за (физическое) выполнение команды.
  7. Модуль обмена сообщениями публикует отчеты о состоянии команд в Сетке событий.
  8. Модуль рабочего процесса подписан на обновления состояния команд и обновляет внутреннее состояние выполнения команды.
  9. После завершения выполнения команды приложение-служба получает результат выполнения по API команд и управления.

Подготовка транспортных средств и устройств

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

Схема потока данных подготовки.

  1. Система фабрики закомаждает устройство транспортного средства в требуемом состоянии строительства. Она может включать начальную установку и настройку встроенного ПО и программного обеспечения. В рамках этого процесса система фабрики получит и напишет сертификат устройства, созданный поставщиком инфраструктуры открытого ключа.
  2. Система фабрики регистрирует автомобиль и устройство с помощью API подготовки транспортных средств и устройств.
  3. Система фабрики активирует клиент подготовки устройств для подключения к регистрации устройства и подготовки устройства. Устройство получает сведения о подключении к брокеру MQTT.
  4. Приложение регистрации устройства создает удостоверение устройства с помощью брокера MQTT.
  5. Впервые система фабрики активирует устройство для установления подключения к брокеру MQTT.
    1. Брокер MQTT проверяет подлинность устройства с помощью корневого сертификата ЦС и извлекает сведения о клиенте.
  6. Брокер MQTT управляет авторизацией для разрешенных разделов с помощью локального реестра.
  7. Для замены части дилерская система OEM может активировать регистрацию нового устройства.

Примечание.

Как правило, системы фабрики являются локальными и не имеют прямого подключения к облаку.

Аналитика данных

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

Схема аналитики данных.

  1. Уровень служб обмена сообщениями транспортных средств предоставляет данные телеметрии, события, команды и сообщения конфигурации от двунаправленного обмена данными с автомобилем.
  2. Уровень ИТ и операций предоставляет сведения о программном обеспечении, работающем на транспортном средстве и связанных облачных службах.
  3. Несколько конвейеров обеспечивают обработку данных в более подробном состоянии
    • Обработка необработанных данных в обогащенные и дедупликированные данные транспортного средства.
    • Агрегирование данных автомобиля, ключевые показатели производительности и аналитические сведения.
    • Создание обучающих данных для машинного обучения.
  4. Различные приложения используют уточненные и агрегированные данные.
    • Визуализация с помощью Power BI.
    • Рабочие процессы бизнес-интеграции с помощью Logic Apps с интеграцией с Dataverse.
  5. Созданные данные обучения используются такими инструментами, как Ml Studio для создания моделей машинного обучения.

Масштабируемость

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

Схема концепции масштабируемости.

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

  1. Единица масштабирования приложений подписывает приложения на сообщения, интересующие вас. Общая служба обрабатывает подписку на компоненты единиц масштабирования обмена сообщениями для транспортных средств.
  2. Средство управления устройствами использует службу управления устройствами для обнаружения назначения в единицу масштабирования обмена сообщениями об транспортных средствах.
  3. При необходимости автомобиль подготавливается с помощью рабочего процесса подготовки транспортных средств и устройств.
  4. Автомобиль публикует сообщение брокеру MQTT.
  5. Сетка событий направляет сообщение с помощью сведений о подписке.
    1. Для сообщений, которые не требуют обработки и проверки утверждений, он направляется в концентратор входящего трафика в соответствующем модуле масштабирования приложения.
    2. Сообщения, требующие обработки, направляются в логику обработки D2C для декодирования и авторизации (согласие пользователя).
  6. Приложения используют события из экземпляра центров событий входящего трафика приложения.
  7. Приложения публикуют сообщения для транспортного средства.
    1. Сообщения, которые не требуют дополнительной обработки, публикуются в брокере MQTT.
    2. Сообщения, требующие большей обработки, управления рабочими процессами и авторизации, направляются в соответствующую логику обработки C2D через экземпляр Центров событий.

Компоненты

Эта эталонная архитектура ссылается на следующие компоненты Azure.

Подключение

  • Сетка событий Azure позволяет подключить устройства, AuthN/Z и pub-sub через MQTT версии 5.
  • Функции Azure обрабатывает сообщения транспортного средства. Его также можно использовать для реализации API управления, для которых требуется кратковременное выполнение.
  • Служба Azure Kubernetes (AKS) — это альтернатива, если функциональные возможности управляемых API состоят из сложных рабочих нагрузок, развернутых в качестве контейнерных приложений.
  • Azure Cosmos DB сохраняет параметры транспортного средства, устройства и согласия пользователя.
  • Azure Управление API предоставляет управляемый шлюз API для существующих внутренних служб, таких как управление жизненным циклом транспортных средств (включая OTA) и управление согласием пользователей.
  • пакетная служба Azure эффективно выполняет большие вычислительные задачи, такие как прием трассировки связи транспортных средств.

Данные и аналитика

  • Центры событий Azure обеспечивает обработку и прием больших объемов данных телеметрии.
  • Azure Data Explorer предоставляет аналитические данные телеметрии на основе временных рядов, а также анализ данных телеметрии на основе временных рядов.
  • Хранилище BLOB-объектов Azure хранит большие документы (например, видео и может отслеживать) и курированные данные транспортного средства.
  • Azure Databricks предоставляет набор средств для поддержки решений данных корпоративного уровня в масштабе. Требуется для длительных операций с большими объемами данных транспортного средства.

Интеграция серверной части

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

Альтернативные варианты

Выбор подходящего типа вычислений для реализации обработки сообщений и управляемых API зависит от множества факторов. Выберите нужную службу с помощью руководства по выбору службы вычислений Azure.

Примеры:

  • Функции Azure для процессов на основе событий, таких как прием телеметрии.
  • пакетная служба Azure для задач высокопроизводительных вычислений, таких как декодирование больших ФАЙЛОВ ТРАССИРОВки и видеофайлов
  • Служба Azure Kubernetes для управляемой, полной оркестрации сложной логики, например управления рабочими процессами и командой.

В качестве альтернативы совместному использованию данных на основе событий также можно использовать Azure Data Share , если цель заключается в выполнении пакетной синхронизации на уровне озера данных.

Подробности сценария

Схема представления высокого уровня.

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

Эта эталонная архитектура позволяет производителям автомобилей и поставщикам мобильности:

  • Используйте данные обратной связи в рамках процесса цифровой инженерии для непрерывного улучшения продукта, упреждающего решения первопричин проблем и создания новой ценности клиента.
  • Предоставление новых цифровых продуктов и служб и операций цифровой интеграции с бизнес-интеграцией с внутренними системами, такими как планирование ресурсов предприятия (ERP) и управление отношениями клиентов (CRM).
  • Безопасное предоставление общего доступа к данным и решение требований к странам или регионам для предоставления согласия пользователей более широким экосистемам интеллектуальной мобильности.
  • Интеграция с внутренними системами для управления жизненным циклом автомобилей и управления согласием упрощает развертывание и управление решениями подключенных транспортных средств с помощью цепочки инструментов Software Defined Vehicle DevOps.
  • Храните и предоставляет вычислительные ресурсы в масштабе для транспортных средств и аналитики.
  • Управление подключением транспортных средств к миллионам устройств экономически эффективным способом.

Потенциальные варианты использования

Варианты использования OEM Automotive предназначены для повышения производительности автомобилей, безопасности и взаимодействия с пользователем.

  • Непрерывное улучшение продукта: повышение производительности транспортных средств путем анализа данных в режиме реального времени и удаленного применения обновлений.
  • Проверка парка инженерных испытаний: обеспечение безопасности и надежности транспортных средств путем сбора и анализа данных из тестовых флотов.
  • Приложение-компаньон и пользовательский портал. Включение удаленного доступа к автомобилям и управление ими с помощью персонализированного приложения и веб-портала.
  • Упреждающий ремонт и обслуживание: прогнозирование и планирование обслуживания автомобилей на основе аналитических сведений на основе данных.

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

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

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

  • Рассмотрите возможность горизонтального масштабирования для добавления надежности.
  • Используйте единицы масштабирования для изоляции географических регионов с различными правилами.
  • Автоматическое масштабирование и зарезервированные экземпляры: управление вычислительными ресурсами путем динамического масштабирования на основе спроса и оптимизации затрат с предварительно размещенными экземплярами.
  • Геоизбыточность: репликация данных в нескольких географических расположениях для отказоустойчивости и аварийного восстановления.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

  • Защита подключения к транспортному средству: ознакомьтесь с разделом по управлению сертификатами, чтобы понять, как использовать сертификаты X.509 для обеспечения безопасного обмена данными об транспортных средствах.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

  • Рекомендации по затратам на автомобиль: затраты на связь должны зависеть от количества предлагаемых цифровых услуг. Вычислите roI цифровых служб по затратам на операции.
  • Рекомендации по анализу затрат на основе трафика сообщений. Подключенный трафик транспортных средств, как правило, увеличивается с течением времени, так как добавляются дополнительные службы.
  • Рассмотрите расходы на сеть и мобильные устройства
    • Используйте псевдоним раздела MQTT для уменьшения объема трафика.
    • Используйте эффективный метод для кодирования и сжатия полезных данных.
  • Обработка трафика
    • Приоритет сообщения: автомобили, как правило, имеют повторяющиеся шаблоны использования, которые создают ежедневные / еженедельные пики спроса. Используйте свойства сообщения, чтобы отложить обработку некритических или аналитических сообщений, чтобы сгладить нагрузку и оптимизировать использование ресурсов.
    • Автомасштабирование на основе спроса.
  • Рассмотрим, сколько времени данные должны храниться горячей/ теплой и холодной.
  • Рассмотрите возможность использования зарезервированных экземпляров для оптимизации затрат.

Эффективность работы

Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".

  • Рассмотрите возможность мониторинга программного обеспечения транспортного средства (журналы, метрики и трассировки), служб обмена сообщениями, служб аналитики данных и связанных внутренних служб в рамках унифицированных ИТ-операций.

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

  • Рассмотрите возможность использования концепции масштабирования для решений, которые масштабируются выше 50 000 устройств, особенно если требуется несколько географических регионов.
  • Тщательно рассмотрите лучший способ приема данных (обмен сообщениями, потоковая передача или пакетная обработка).
  • Рассмотрите лучший способ анализа данных на основе варианта использования.

Следующие шаги

  • Создайте решение для автономных транспортных операций (AVOps) для более широкого просмотра автомобильной цифровой инженерии для автономного и вспомогательного вождения.

В следующих статьях рассматриваются некоторые понятия, используемые в архитектуре:

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

В следующих статьях описано взаимодействие между компонентами в архитектуре: