自動車テスト車両のデータ分析

Microsoft Fabric
Azure Data Explorer
Azure Event Hubs
Azure Functions
Azure Event Grid

自動車の OEM (相手先ブランド供給) には、テスト ドライブとテスト ドライブ診断データの R&D エンジニアへの提供の間の時間を最小限に抑えるソリューションが必要です。 車両の自動化が進むにつれて、ソフトウェア開発のライフサイクルが短くなり、より高速なデジタル フィードバック ループが必要になります。 新しいテクノロジでは、データ アクセスを民主化し、テスト走行の診断データに関するほぼリアルタイムの分析情報を R&D エンジニアに提供できます。 データ分析に Copilot for Data Science と Copilot for Data Engineering を使用すると、洞察を得るまでの時間をさらに短縮できます。 安全なデータ共有により、OEM とサプライヤー間のコラボレーションが強化され、開発サイクル時間が短縮されます。

この記事のガイダンスは、テレメトリ シナリオとバッチ テスト ドライブ データ インジェストシナリオを対象としています。 このアーキテクチャは、診断データを処理するデータ プラットフォームと、データの視覚化およびデータ レポート用のコネクタに重点を置いています。

Architecture

自動車のストリーミング データとファイルの分析データフローを示す図。

"この記事のすべての図を含む PowerPoint ファイル をダウンロードします。"

データフロー

次のデータフローは、前の図に対応しています。

  1. データ キャプチャ デバイスは車両ネットワークに接続され、高解像度の車両信号データとビデオを収集します。 (1a) デバイスは、リアルタイムのテレメトリ メッセージを発行するか、(1b) MQTT クライアントを使用して、記録されたデータ ファイルの Azure Event Grid MQTT ブローカー機能へのアップロードを要求します。 この機能では、要求チェック パターンが使用されます。

  2. (2a) Event Grid は、ライブ 車両信号データを Azure Functions アプリにルーティングします。 このアプリは、車両信号を JavaScript Object Notation (JSON) 形式にデコードし、Eventstream に投稿します。

    (2b) Event Grid は、デバイス クライアントからレイクハウスへのファイルのアップロードを調整します。 ファイルのアップロードが完了すると、データをデコードし、デコードされたファイルを Parquet や CSV などの取り込みに適した形式で OneLine に書き込むパイプラインがトリガーされます。

  3. (3a) Eventstream は、デコードされた JSON 車両信号をイベントハウスにインジェストするためにルーティングします。

    (3b) データ パイプラインは、レイクハウスからデコードされたファイルのインジェストをトリガーします。

  4. イベントハウスでは、更新ポリシーを使用してデータを強化し、JSON データを適切な行形式に拡張します。たとえば、地理空間分析に合わせて場所データがクラスター化される場合があります。 新しい行が取り込まれるたびに、リアルタイム分析エンジンは関連付けられた Update() 関数を呼び出します。

  5. データ エンジニアとデータ サイエンティストは、Kusto 照会言語 (KQL) を使用して分析のユース ケースを構築します。 ユーザーは、頻繁に使用されるケースを共有可能なユーザー定義関数として格納します。 エンジニアは、集計、時系列分析、地理空間クラスタリング、ウィンドウ処理、Copilot をサポートする機械学習プラグインなどの組み込み KQL 関数を使用します。

  6. R&D エンジニアとデータ サイエンティストは、ノートブックを使用してデータを分析し、テストと検証のユース ケースを構築します。

    1. R&D エンジニアは、KQL クエリセット および リアルタイム インテリジェンス用 Copilot を使用して対話型データ分析を実行します。

    2. データ エンジニアとデータ サイエンティストは、Notebooks を使用して分析プロセスを格納および共有します。 Notebooks を使用すると、エンジニアは Azure Spark を使用して分析を実行し、Git を使用して Notebooks コードを管理できます。 ユーザーは、Copilot for Data Science と Copilot for Data Engineering を利用して、コンテキスト コードの提案を使用してワークフローをサポートできます。

  7. R&D エンジニアとデータ サイエンティストは、動的クエリまたはリアルタイム分析ダッシュボードを備えた Power BI を使用して、ビジネス ユーザーと共有する視覚化を作成できます。 これらの視覚化では、メンテナンスを容易にするためにユーザー定義関数が呼び出されます。

  8. エンジニアは、より多くのツールを Microsoft Fabric に接続することもできます。 たとえば、Azure Managed Grafana をイベントハウスに接続したり、イベントハウスに直接クエリを実行する Web アプリケーションを作成したりできます。

  9. データ エンジニアと R&D エンジニアは、Data Activator を使用して、ビジネス統合のための Power Automate フローのトリガーなど、条件を監視してアクションをトリガーするための反射アイテムを作成します。 たとえば、デバイスの正常性が低下した場合、Data Activator は Teams チャネルに通知できます。

  10. データ コレクターの構成により、エンジニアはデータ キャプチャ デバイスのデータ コレクション ポリシーを変更できます。 Azure API Management は、パートナー構成 API を抽象化してセキュリティ保護し、監視可能性を提供します。

KQL データベース スキーマ

データの抽出、デプロイ、および強化を行う KQL データベースとメソッドを示す図。

テーブル スキーマを設計するときは、fact テーブルと dimension テーブルの違いを考慮してください。 車両信号はストリーミング形式で、または完全な記録の一部として段階的に追加され、テレメトリは変更されません。そのため、テレメトリは fact テーブルです。 フリート メタデータは、更新速度が遅い fact テーブルとして分類されます。

車両テレメトリは生テーブルに格納されます。 次のメッセージ処理の概念を使用して、分析およびレポート用のデータを整理できます。

  • 次のようなメソッドを使用して、JSON テレメトリ ファイルを個々の車両信号レコードに拡張するための更新ポリシーを作成します。

    • mv-expand() は、JSON 構造に格納されている複雑な値を個々のシグナルを含む行に拡張します。
    • geo_point_to_h3cell() または geo_point_to_geohash() は、地理空間分析のために緯度と経度を geohash に変換します。
    • todouble() および tostring() は、動的な JSON オブジェクトから抽出された値を適切なデータ型にキャストします。
    • lookup は、ディメンション テーブルの値を使用してレコードを拡張します。

  • 一意のキーとタイムスタンプの集計関数 take_any() を使用して、重複除去されたシグナルの具体化されたビューを作成します。 この具体化されたビューは、シグナルを重複除去します。

  • タイムスタンプの集計関数 arg_max() を使用して、シグナルの最後の既知の値の具体化されたビューを作成します。 この具体化されたビューは、車両の最新の状態を提供します。

  • 毎時や毎日などのタイム ビンを含む summarize 演算子を使用して、ダウンサンプリングされたシグナルの具体化されたビューを作成します。 この具体化されたビューは、シグナルを集計し、フリート全体のレポートを簡略化します。

  • 異常検出または根本原因分析を提供するユーザー定義関数を作成します。

    • 異常検出と予測の時系列関数を使用して、潜在的な問題を検出し、障害を予測します。

    • scan 演算子を使用して、データからシーケンスをスキャン、照合、およびビルドします。 エンジニアは、scan 演算子を使用してシーケンスを検出できます。 たとえば、特定のイベントが発生した場合、後続のイベントが一定の時間内に発生する必要があります。

    • autocluster などの機械学習プラグインを使用して、個別の属性の一般的なパターンを見つけます。

  • ユーザー定義関数を使用して地理空間分析を実行します。 地理空間分析関数を使用して、座標を適切なグリッド システムに変換し、データに対して集計を実行します。

  • フリート メタデータ テーブルを作成し、車両のメタデータと構成に変更を格納します。 最後に変更された列に基づいて車両車両の最新の状態を格納する フリート メタデータの最後の既知の値 の具体化されたビューを作成します。

コンポーネント

次の主要なテクノロジが、このワークロードを実装します。 アーキテクチャ内の各コンポーネントについては、Well-Architected Framework 内の関連するサービス ガイド (利用可能な場合) を使用します。 詳細については、「Well-Architected Framework サービス ガイド」を参照してください。

  • Fabric Real-Time Intelligence を使用すると、車両テレメトリの分析情報と視覚化をモーションで抽出できます。 イベントストリームと時系列 KQL データベースを使用してデータを保存および分析し、反射神経を使ってイベントに反応することができます。

  • Data Activator は、データのパターンや条件が変化したときにアクションを自動化するために使用できるコード不要のツールです。

  • Event Grid は、MQTT プロトコルをサポートする、高度にスケーラブルで完全に管理されたパブリッシュ/サブスクライブ メッセージ配信サービスです。 車両は Event Grid を使用してトピックを公開およびサブスクライブできます。たとえば、テレメトリを公開したり、コマンドと制御メッセージをサブスクライブしたりできます。

  • Azure Event Hubs は、待機時間が短い 1 秒あたり数百万台の車両イベントをストリーミングするのに適した、リアルタイム データ ストリーミング プラットフォームです。

  • Functions は、任意の言語を使用して、イベント ドリブン トリガーとバインドを使用して、車両テレメトリ イベントの大規模な処理を簡略化するサーバーレス ソリューションです。

  • Azure Managed Grafana は、Grafana Labs のソフトウェアに基づくデータ視覚化プラットフォームです。 マイクロソフトでは、Azure Managed Grafana を管理およびサポートしています。

  • Azure App Service を使用すると、Fabric に格納されている車両テレメトリ データへのアクセスを提供する Web アプリ、モバイル バックエンド、RESTful API を構築してホストできます。 この方法により、従量課金が簡略化されます。

  • API Management は、API のためのハイブリッドなマルチクラウド管理プラットフォームです。

代替

次の Azure サービスを使用して、このアーキテクチャを実装することもできます。

  • Azure Blob Storage には、車両からの記録、ログ、ビデオなど、大量の非構造化データが格納されます。 OneLake ストレージが置き換えられます。

  • Azure Data Explorer は、大量のデータのリアルタイム分析を実現するフル マネージドの高速データ分析サービスです。 Fabric Real-Time Intelligence KQL データベースが置き換えられます。

  • Azure Batch は、複雑なファイルのデコードに使用できる代替手段です。 このシナリオでは、それぞれ 300 メガバイトを超える多数のファイルが含まれます。 ファイルには、ファイルのバージョンまたはファイルの種類に基づいて異なるデコード アルゴリズムが必要です。 Fabric を使用するか、Blob Storage と Azure Data Explorer を使用して次の方法を実装できます。

複雑なファイルをデコードするための代替 Batch 方法を示す図。

  1. ユーザーまたは記録デバイスは、記録されたデータ ファイルをレイクハウスにアップロードします。 アップロードが完了すると、デコードをスケジュールする Functions アプリがトリガーされます。

  2. スケジューラは、ファイルの種類、ファイル サイズ、必要なデコード アルゴリズムに基づいてバッチ ジョブを作成する Functions アプリを開始します。 アプリはプールから適切なサイズの仮想マシンを選択し、ジョブを開始します。

  3. ジョブが終了すると、Batch は結果のデコードされたファイルをレイクハウスに書き戻します。 このファイルは、イベントハウスがサポートする形式で直接取り込むのに適している必要があります。

  4. レイクハウスは、ファイルの書き込み時にデータをイベントハウスに取り込む機能をトリガーします。 この関数は、必要に応じてテーブルとデータのマッピングを作成し、インジェスト プロセスを開始します。

  5. KQL データベースはレイクハウスからデータ ファイルを取り込みます。

この方法には次のような利点があります。

  • Functions プールおよび Batch プールは、スケーラブルなデータ処理タスクを確実かつ効率的に処理できます。

  • Batch プールは、処理統計、タスク キュー、バッチ プールの正常性に関する分析情報を提供します。 状態の視覚化、問題の検出、失敗したタスクの再実行を行うことができます。

  • Functions と Azure Batch の組み合わせは、Docker コンテナーでのプラグ アンド プレイ処理をサポートします。

  • スポット仮想マシンを使用するとピーク時間外にファイルを処理できるため、コストを節約できます。

シナリオの詳細

自動車メーカーは、あらゆる種類の車両機能をテストおよび検証するために、いくつかのプロトタイプとテスト車両を使用します。 テスト手順は、実際のドライバーと車両が必要であり、特定の現実世界の道路テストシナリオを複数回通過する必要があるため、コストがかかります。 統合テストは、複雑なシステムにおける電気、電子、機械コンポーネント間の相互作用を評価するために特に重要です。

車両機能を検証し、異常や故障を分析するには、電子制御ユニット (ECU)、コンピューター ノード、コントローラー エリア ネットワーク (CAN) やイーサネットなどの車両通信バス、およびセンサーからペタバイト単位の診断データを取得する必要があります。

以前は、車両内の小規模なデータ ロガー サーバーに、診断データが測定データ形式 (MDF)、Multimedia Fusion Extension (MFX)、CSV、または JSON ファイルとしてローカルに格納されました。 テスト走行が完了すると、サーバーは診断データをデータセンターにアップロードし、データ センターで処理し、分析のために R&D エンジニアに送信しました。 このプロセスには、数時間、または場合によっては数日かかることがありました。 最近のシナリオでは、Message Queuing Telemetry Transport (MQTT) ベースの同期データ ストリームや、ほぼリアルタイムのファイル アップロードなどのテレメトリ インジェスト パターンが使用されます。

考えられるユース ケース

  • 車両管理では、複数のテスト シナリオで車両ごとのパフォーマンスと収集されたデータを評価します。

  • システムとコンポーネントの検証では、収集された車両データを使用して、車両コンポーネントの動作が走行全体で運用境界内に収まることを確認します。

  • 異常検出では、標準的なベースライン パターンに対するセンサー値の偏差パターンをリアルタイムで見つけます。

  • 根本原因分析では、クラスタリング アルゴリズムなどの機械学習プラグインを使用して、複数のディメンションで値の分布の変化を識別します。

  • 予測メンテナンスでは、複数のデータ ソース、強化された位置データ、および車両信号を組み合わせて、コンポーネントの故障までの時間を予測します。

  • 持続可能性評価では、ドライバーの動作とエネルギー消費量を使用して、車両運用の環境への影響を評価します。

  • レース前、レース中、レース後の車両のパフォーマンスを理解し、改善するための自動車レース。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

  • Azure 可用性ゾーンは、同じ Azure リージョン内の一意の物理的な場所です。 可用性ゾーンは、部分的なリージョンの障害から Azure Data Explorer コンピューティング クラスターとデータを保護できます。

  • Azure Data Explorer における事業継続とディザスター リカバリー (BCDR) により、中断が発生しても業務を継続できます。

  • フォロワー データベースは、運用環境と非運用環境のユース ケースの間でコンピューティング リソースを分離します。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。

自動車メーカーと Microsoft との責任の分担を理解することが重要です。 車両では、メーカーはスタック全体を所有しますが、データがクラウドに移動すると、責任の一部は Microsoft に移譲されます。 Azure PaaS (サービスとしてのプラットフォーム) では、オペレーティング システムを含めて、物理スタックにセキュリティが組み込まれています。

これらの機能はすべて、自動車メーカーが車両テレメトリ データの安全な環境を作成するのに役立ちます。 詳細については、「Fabric のセキュリティ」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このソリューションでは、次の方法を使用してコストを最適化します。

  • raw テーブルと signals テーブルのホット キャッシュとコールド ストレージを正しく構成します。 ホット データ キャッシュは RAM または SSD に格納され、パフォーマンスを向上させます。 ただし、コールド データはコストが 45 分の 1 で済みます。 ユース ケースに適したホット キャッシュ ポリシー (30 日など) を設定します。

  • raw テーブルと signals テーブルに保持ポリシーを設定します。 シグナル データが関連しなくなるタイミング (たとえば、365 日後など) を判断し、それに応じて保持ポリシーを設定します。

  • どのシグナルが分析に関連するかを検討します。

  • シグナルの最後の既知の値、重複除去されたシグナル、およびダウンサンプリングされたシグナルに対してクエリを実行する場合は、具体化されたビューを使用します。 具体化されたビューでは、各クエリでソース テーブルの集計を行うよりも消費されるリソースが少なくなります。

  • リアルタイム データ分析のニーズを考慮します。 ライブ テレメトリ テーブルのストリーミング取り込みを設定して、取り込みとクエリの間の待機時間を 1 秒未満にします。 この方法では、CPU サイクルとコストが増加します。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

  • 記録されたデータ ファイルの数とサイズが 1,000 ファイルを超える場合、または 1 日あたり 300 MB を超える場合は、Batch を使用してデコードを実行することを検討してください。

  • 取り込んで追加のテーブルに格納した後に、一般的な計算と分析を実行することを検討します。

  • KQLクエリのベスト プラクティスを使用して、クエリの実行を高速化します。

  • where 句を使用して時間枠を定義し、クエリされるデータの量を減らします。 一般的な検索条件が時間ベースでない場合、たとえば記録 ID と信号名でフィルタリングする場合は、信号テーブルのデータ パーティション ポリシーを変更することを検討してください。 KQL データベースが数十億または数兆件のレコードを含むまで拡張された場合、特にアクティブなパーティション ポリシーを考慮すると、適切なデータ フィルタリングが不可欠になります。

警告

データ パーティション ポリシーを変更する前に、サポート チームに相談してください。

このシナリオのデプロイ

このシナリオをデプロイするには、詳しいチュートリアルを使用します。 このガイドでは、無料インスタンスをデプロイし、MDF ファイルを解析し、データを取り込み、いくつかの基本的なクエリを実行する方法を説明します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ