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

Изготовители автомобильного оригинального оборудования (OEM) нуждаются в решениях для минимизации времени между тест-дисками и доставкой диагностических данных для инженеров R&D. По мере того как транспортные средства становятся более автоматизированными, жизненные циклы разработки программного обеспечения становятся короче, что требует более быстрых циклов цифровой обратной связи. Новая технология может демократизировать доступ к данным и предоставить инженерам R&D практически в реальном времени аналитические сведения о диагностических данных тестового диска. Используйте Copilot для Обработка и анализ данных и Инжиниринг данных для аналитики данных, чтобы сократить время для анализа данных. Безопасный обмен данными может повысить совместную работу между изготовителами оборудования и поставщиками и сократить время цикла разработки.

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

Архитектура

Скачайте файл PowerPoint со всеми схемами в этой статье.

Поток данных

Следующий поток данных соответствует предыдущей схеме:

1. Устройство отслеживания данных подключено к сетям транспортных средств и собирает данные сигнала автомобиля с высоким разрешением и видео. (1a) Устройство публикует сообщения телеметрии в режиме реального времени или (1b) запрашивает отправку записанных файлов данных в функциональность брокера MQTT Сетка событий Azure с помощью клиента MQTT. Эта функция использует шаблон проверки утверждений.

2. (2a) Сетка событий направляет данные сигнала динамического транспортного средства в приложение Функции Azure. Это приложение декодирует сигналы транспортного средства в формате нотации объектов JavaScript (JSON) и отправляет их в поток событий.

   (2b) Сетка событий координирует отправку файла из клиента устройства в lakehouse. Завершенная отправка файла активирует конвейер, который декодирует данные и записывает декодированный файл в OneLine в формате, который подходит для приема, например parquet или CSV.

3. (3a) Поток событий направляет декодированные сигналы транспортного средства JSON для приема в хранилище событий.

   (3b) Конвейер данных активирует прием декодированных файлов из lakehouse.

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

5. Инженеры и специалисты по обработке и анализу данных используют язык запросов Kusto (KQL) для создания вариантов использования аналитики. Пользователи хранят часто используемые варианты в качестве общих определяемых пользователем функций. Инженеры используют встроенные функции KQL, такие как агрегирование, анализ временных рядов, геопространственный кластеризация, окно и подключаемые модули машинного обучения с поддержкой Copilot.

6. Инженеры R&D и специалисты по обработке и анализу данных используют записные книжки для анализа данных и сборки вариантов использования тестов и проверки.

   1. Инженеры R&D используют наборы запросов KQL и Copilot для аналитики в реальном времени для выполнения интерактивного анализа данных.

   2. Инженеры и специалисты по обработке и анализу данных используют записные книжки для хранения и совместного использования процессов анализа. С помощью записных книжек инженеры могут использовать Azure Spark для запуска аналитики и использования Git для управления кодом записной книжки. Пользователи могут воспользоваться преимуществами Copilot для Обработка и анализ данных и Инжиниринг данных для поддержки рабочего процесса с предложениями контекстного кода.

7. Инженеры R&D и специалисты по обработке и анализу данных могут использовать Power BI с динамическими запросами или панелями мониторинга аналитики в режиме реального времени для создания визуализаций для совместного использования с бизнес-пользователями. Эти визуализации вызывают определяемые пользователем функции для удобства обслуживания.

8. Инженеры также могут подключать дополнительные средства к Microsoft Fabric. Например, они могут подключить Управляемый Grafana Azure к eventhouse или создать веб-приложение, которое запрашивает хранилище событий напрямую.

9. Инженеры по обработке и анализу данных и инженеры R&D используют метод "Активация данных" для создания рефлектора для мониторинга условий и действий триггеров, таких как активация потоков Power Automate для интеграции бизнеса. Например, активатор данных может уведомить канал Teams, если работоспособность устройства ухудшается.

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

Схема базы данных KQL

При разработке схемы таблицы следует учитывать разницу между fact таблицами и dimension таблицами. Данные телеметрии — это fact таблица, так как сигналы транспортного средства постепенно добавляются в потоковую передачу или как часть полной записи, а данные телеметрии не изменяются. Вы можете классифицировать метаданные парка как таблицу fact , которая обновляется медленно.

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

• Создайте политики обновления для расширения файлов телеметрии JSON в отдельные записи сигнала транспортного средства с помощью таких методов, как:

  • mv-expand() расширяет сложные значения, хранящиеся в структурах JSON, в строки с отдельными сигналами.
  • geo_point_to_h3cell() или geo_point_to_geohash() преобразует широту и долготу в геошеты для геопространственной аналитики.
  • todouble() и tostring() приводит извлеченные значения из динамических объектов JSON в соответствующие типы данных.
  • lookup расширяет записи со значениями из таблицы измерений.

• Создайте дедупликированное представление сигналов с помощью функции агрегирования take_any() для уникального ключа и метки времени. Это материализованное представление дедупликирует сигналы.

• Создайте представление "Последние известные значения сигналов", материализованное представление с помощью функции arg_max() агрегирования на метке времени. Это материализованное представление обеспечивает актуальное состояние транспортных средств.

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

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

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

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

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

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

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

Компоненты

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

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

• Активация данных — это средство без кода, которое можно использовать для автоматизации действий при изменении шаблонов или условий данных.

• Сетка событий — это полностью масштабируемая полностью управляемая служба распространения сообщений публикации и подписки, которая поддерживает протоколы MQTT. Транспортные средства могут использовать сетку событий для публикации и подписки на разделы, например публикацию телеметрии и подписку на сообщения команд и управления.

• Центры событий Azure — это платформа потоковой передачи данных в режиме реального времени, которая хорошо подходит для потоковой передачи миллионов событий транспортного средства в секунду с низкой задержкой.

• Функции — это бессерверное решение, которое упрощает обработку событий телеметрии транспортного средства в масштабе с помощью триггеров и привязок, управляемых событиями, с помощью выбранного языка.

• Azure Managed Grafana — это платформа визуализации данных, основанная на программном обеспечении из Grafana Labs. Корпорация Майкрософт управляет и поддерживает Управляемый Grafana Azure.

• служба приложение Azure позволяет создавать и размещать веб-приложения, мобильные серверные серверы и API RESTful, которые предоставляют доступ к данным телеметрии транспортного средства, хранящимся в Fabric. Этот подход упрощает потребление.

• Управление API — это гибридная платформа управления несколькими облаками для API.

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

Для реализации этой архитектуры можно также использовать следующие службы Azure:

• Хранилище BLOB-объектов Azure хранит огромные объемы неструктурированных данных, таких как записи, журналы и видео из транспортных средств. Он заменяет хранилище OneLake.

• Azure Data Explorer — это быстрая полностью управляемая служба аналитики данных для анализа в режиме реального времени. Он заменяет базу данных KQL аналитики в режиме реального времени Fabric.

• пакетная служба Azure является альтернативой, которую можно использовать для декодирования сложных файлов. Этот сценарий включает в себя большое количество файлов, размер которых превышает 300 мегабайт. Для файлов требуются различные алгоритмы декодирования на основе версии файла или типа файла. Вы можете использовать Fabric или использовать хранилище BLOB-объектов и Azure Data Explorer для реализации следующего подхода.

1. Пользователь или устройство записи отправляет записанный файл данных в lakehouse. После завершения отправки запускается приложение "Функции", которое планирует декодирование.

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

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

4. Lakehouse активирует функцию, которая отправляет данные в Eventhouse при записи файла. Эта функция создает сопоставление таблиц и данных при необходимости и запускает процесс приема.

5. База данных KQL отправляет файлы данных из lakehouse.

Этот подход обеспечивает следующие преимущества:

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

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

• Сочетание функций и пакетной службы поддерживает обработку подключаемых модулей и воспроизведения в контейнерах Docker.

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

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

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

Чтобы проверить функции транспортного средства и проанализировать аномалии и сбои, необходимо записать петабайты диагностических данных из электронных единиц управления (ECUs), компьютерных узлов, транспортных автобусов связи, таких как сеть контроллеров (CAN) и Ethernet и датчики.

В прошлом небольшие серверы средства ведения журнала данных в транспортных средствах хранят диагностические данные локально как формат данных измерения (MDF), расширение мультимедийного слияния (MFX), CSV или JSON-файлы. После завершения тестовых выпусков серверы отправили диагностические данные в центры обработки данных, которые обработали его и отправили его инженерам R&D для аналитики. Этот процесс может занять несколько часов или иногда дней. В последних сценариях используются шаблоны приема данных телеметрии, такие как транспорт телеметрии сообщений (MQTT) на основе синхронных потоков данных или передачи файлов в режиме реального времени.

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

• Управление транспортными средствами оценивает производительность и собирает данные для каждого транспортного средства в нескольких сценариях тестирования.

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

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

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

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

• Оценка устойчивости использует поведение водителя и потребление энергии для оценки воздействия на окружающую среду операций транспортного средства.

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

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

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

Надежность

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

• Зоны доступности Azure — это уникальные физические расположения в одном регионе Azure. Зоны доступности могут защитить вычислительные кластеры Azure Data Explorer и данные от частичного сбоя региона.

• Непрерывность бизнес-процессов и аварийное восстановление (BCDR) в Azure Data Explorer позволяет бизнесу продолжать работу в условиях сбоя.

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

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

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

Важно понимать разделение ответственности между автомобильным изготовителем оборудования и корпорацией Майкрософт. В транспортном средстве OEM владеет целым стеком, но по мере перемещения данных в облако некоторые обязанности передаются в Корпорацию Майкрософт. Платформа Azure как услуга (PaaS) обеспечивает встроенную безопасность в физическом стеке, включая операционную систему.

• Используйте Политика Azure для применения охранников.

• Ознакомьтесь с общими сведениями об управлении и рекомендациями для Fabric.

• Используйте частные конечные точки для обеспечения безопасности сети для всех служб.

  • Используйте частные конечные точки для Azure Data Explorer.

  • Разрешить доступ к пространствам имен Центров событий через частные конечные точки.

• Шифрование неактивных и передаваемых данных.

• Используйте удостоверения Microsoft Entra и политики условного доступа Microsoft Entra.

• Используйте безопасность на уровне строк (RLS) для баз данных KQL и Azure Data Explorer.

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

Все эти функции помогают автомобильным изготовителям оборудования создавать безопасную среду для данных телеметрии транспортного средства. Дополнительные сведения см. в разделе "Безопасность в Fabric".

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

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

Это решение использует следующие методики для оптимизации затрат:

• Правильно настройте горячие кэши и холодное хранилище для необработанных и сигнальных таблиц. Кэш горячих данных хранится в ОЗУ или SSD и обеспечивает улучшенную производительность. Холодные данные, однако, 45 раз дешевле. Задайте политику горячего кэша, которая подходит для вашего варианта использования, например 30 дней.

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

• Рассмотрим, какие сигналы относятся к анализу.

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

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

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

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

• Рекомендуется использовать пакетную службу для декодирования, если количество и размер записанных файлов данных составляет более 1000 файлов или 300 МБ в день.

• Рассмотрите возможность выполнения общих вычислений и анализа после приема и хранения их в дополнительных таблицах.

• Используйте рекомендации по запросу KQL, чтобы ускорить выполнение запроса.

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

Развертывание этого сценария

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

Соавторы

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

Основные авторы:

• Борис Шолл | Партнер, главный архитектор
• Фрэнк Калек | Автопромышленный помощник по отрасли
• Хеннинг Рауч | Главный диспетчер программ
• Марио Ортегон-Кабрера | Главный диспетчер программ

Другие участники:

• Деванг Шах | Главный диспетчер программ
• Ханс-Питер Голинер | Архитектор облачных решений
• Джейсон Буска | Старший инженер по программному обеспечению

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

• Компонент брокера MQTT в сетке событий
• Добавление назначения базы данных KQL в поток событий
• Получение данных из OneLake
• Материализованные представления
• Создание панели мониторинга в режиме реального времени
• Создание оповещений активатора данных на панели мониторинга в режиме реального времени
• Отчет Power BI
• Визуализация данных из Azure Data Explorer в Grafana
• Эталонная архитектура автоматического обмена сообщениями, данных и аналитики

Связанные ресурсы

• Программно-определяемая цепочка инструментов DevOps
• Руководство по проектированию операций автономного транспортного средства
• Шаблон проверки утверждений