自動車のメッセージング、データおよび分析の参照アーキテクチャ
この参照アーキテクチャは、OEM 自動車メーカーとモビリティ プロバイダーが高度なコネクテッド車両アプリケーションとデジタル サービスの開発を行うのをサポートするように設計されています。 その目標は、信頼性が高く効率的なメッセージング、データ、分析インフラストラクチャを提供することです。 このアーキテクチャには、マネージド API を介してさまざまなサービスの統合を促進する、メッセージ処理、コマンド処理、状態ストア機能が含まれています。 また、デジタル エンジニアリングと広範なモビリティ エコシステムとのデータ共有のための、スケーラブルで安全な方法によるデータのストレージとアクセシビリティを保証する、データと分析のソリューションについても説明します。
Architecture
アーキテクチャの概要図には、自動車のメッセージング、データおよび分析ソリューションの主要な論理ブロックとサービスが示されています。 詳細については、次のセクションを参照してください。
- 車両には、一連のデバイスが含まれています。 これらのデバイスの一部は "ソフトウェア定義" されており、クラウドから管理されているソフトウェア ワークロードを実行できます。 車両では、バッテリ管理システムなどの電気機械デバイスのセンサー情報からソフトウェア ログ ファイルまでのさまざまなデータを収集して処理します。
- 車両メッセージング サービスでは、車両との間の通信を管理します。 ここでは、メッセージの処理やワークフローを使用したコマンドの実行のほか、車両、ユーザー、デバイス管理バックエンドの仲介を行います。 また、車両、デバイス、証明書の登録とプロビジョニングも追跡します。
- 車両およびデバイス管理バックエンドは、工場から修理およびメンテナンスに至るまでの車両構成を追跡する OEM システムです。
- オペレーターは、車両とバックエンドの両方の可用性とパフォーマンスを確保するために IT と運用を行います。
- データおよび分析サービスでは、データ ストレージを提供し、すべてのデータ ユーザーのための処理と分析を可能にします。 データはビジネス上の意思決定を向上させる分析情報に変換されます。
- 車両メーカーは、コンパニオン アプリから修理およびメンテナンス アプリケーションに至るまでのデジタル サービスを、エンド カスタマーへの付加価値として提供しています。
- 一部のデジタル サービスは、ディーラー管理 (DMS)、顧客関係管理 (CRM)、エンタープライズ リソース プランニング (ERP) システムなどのバックエンド システムとのビジネス統合が必要です。
- 同意管理バックエンドは顧客管理の一部であり、地理的国およびリージョンの法律に従ってデータ収集のためのユーザーの認可を追跡します。
- 車両から収集されたデータはデジタル エンジニアリング プロセスに入力されます。これは分析と機械学習を使用して製品を継続的に改善することを目的としています。
- スマート モビリティ エコシステムでは、ライブ テレメトリと集計された分析情報の両方をサブスクライブおよび使用して、より多くの製品とサービスを提供できます。
Microsoft は、車両ソフトウェア プラットフォーム用のオープンソースを使用したオープン コラボレーションのフォーラムである Eclipse Software Defined Vehicle ワーキング グループのメンバーです。
データフロー
このアーキテクチャではパブリッシャー/サブスクライバーのメッセージング パターンを使用して、サービスから車両を切り離します。
車両からクラウドへのメッセージ
"車両からクラウドへの" データフローは、車両からのテレメトリ データを処理するために使用されます。 テレメトリ データは、定期的 (車両の状態や車両センサーからの収集) またはイベント (エラー状態でのトリガー、ユーザー アクションへの反応) に基づいて送信できます。
- "車両" は、管理 API を使用して選択したオプションに基づいて顧客向けに構成されます。 構成には次のものが含まれます。
- 車両とデバイスのプロビジョニング情報。
- 市場とビジネスに関する考慮事項に基づく初期の車両データ収集構成。
- 車両オプションとユーザーの承認に基づく初期のユーザーの同意設定の保存。
- 車両は、定義済みのトピックを含むメッセージ キュー テレメトリ転送 (MQTT) クライアントを介して、テレメトリとイベント メッセージを、車両メッセージング サービスの Azure Event Grid の MQTT ブローカー機能に発行します。
- Event Grid は、トピック属性とメッセージ属性に基づいて、さまざまなサブスクライバーにメッセージをルーティングします。
- 即時処理を必要としない優先度の低いメッセージ (分析メッセージなど) は、バッファリングのために Event Hubs インスタンスを使用してストレージに直接ルーティングされます。
- 即時処理を必要とする優先度の高いメッセージ (ユーザー向けアプリケーションで視覚化する必要がある状態の変更など) は、バッファリングのために Event Hubs インスタンスを使用して Azure 関数にルーティングされます。
- 優先度の低いメッセージは、イベント キャプチャを使用してデータ レイクに直接格納されます。 これらのメッセージでは、コストを最適化するためのバッチによるデコードと処理を使用できます。
- 優先度の高いメッセージは Azure 関数を使用して処理されます。 関数は、車両、デバイス、ユーザーの同意の設定をデバイス レジストリから読み取り、次の手順を実行します。
- 車両とデバイスが登録され、アクティブであることを確認します。
- ユーザーがメッセージ トピックに同意したことを確認します。
- ペイロードをデコードしてエンリッチします。
- ルーティング情報をさらに追加します。
- "データおよび分析ソリューション" のライブ テレメトリ Event Hub では、デコードされたメッセージを受信します。 Azure Data Explorer では、ストリーミング インジェストを使用して、受信したメッセージを処理して格納します。
- "デジタル サービス" レイヤーでは、デコードされたメッセージを受信します。 Service Bus では、車両の状態の重要な変更/イベントに関する通知をアプリケーションに提供します。 Azure Data Explorer では、車両の最後の既知の状態と短期間の履歴が提供されます。
クラウドから車両へのメッセージ
"クラウドから車両への" データフローは多くの場合、車両でのリモート コマンドをデジタル サービスから実行するために使用されます。 これらのコマンドには、ドアのロックまたはロック解除、温度調整 (好みの車内温度の設定) や構成変更などのユース ケースが含まれます。 正常に実行できるかどうかは車両の状態に依存し、完了するまでに時間がかかる場合があります。
車両の機能とアクションの種類に応じて、コマンドの実行には複数の方法が考えられます。 次の 2 つのバリエーションについて説明します。
- クラウドからデバイスへのダイレクト メッセージ (A) では、ユーザーの同意確認を必要とせず、応答時間は予測可能です。 これは個々の車両と複数の車両の両方へのメッセージが対象となります。 たとえば、気象情報の通知などです。
- 車両コマンド (B) では、車両の状態を使用して成功かどうかを判断し、ユーザーの同意が必要です。 メッセージング ソリューションには、ユーザーの同意を確認し、コマンドの実行状態を追跡し、完了したらデジタル サービスに通知するコマンド ワークフロー ロジックが必要です。
次のデータフロー ユーザー コマンドは、例としてコンパニオン アプリのデジタル サービスから発行されています。
ダイレクト メッセージは、可能な限り最高のパフォーマンスを得るために最小ホップ数で実行されます。(A)
- コンパニオン アプリは、Event Grid にメッセージを発行できる認証済みサービスです。
- Event Grid では、コンパニオン アプリ サービスの認可を確認し、指定されたトピックにメッセージを送信できるかどうかを判断します。
- コンパニオン アプリでは、特定の車両/コマンドの組み合わせからの応答がサブスクライブされます。
車両状態に依存するコマンドがユーザーの同意を必要とする場合 (B):
- 車両所有者/ユーザーは、デジタル サービス (この例ではコンパニオン アプリ) に対してコマンドとコントロールの機能の実行に同意します。 これは通常、ユーザーがアプリをダウンロードまたはアクティブ化し、OEM が自分のアカウントをアクティブにするときに行われます。 これにより、MQTT ブローカーで関連するコマンド トピックをサブスクライブするように車両の構成変更がトリガーされます。
- コンパニオン アプリでは、コマンドとコントロールのマネージド API を使用して、リモート コマンドの実行を要求します。
- コマンドの実行には、タイムアウト、ストア、転送オプションなどのオプションを構成するために、パラメーターが多くなる場合があります。
- コマンド ロジックでは、トピックとその他のプロパティに基づいてコマンドを処理する方法が決定されます。
- ワークフロー ロジックでは、実行の状態を追跡する状態を作成します
- コマンド ワークフロー ロジックでは、ユーザーの同意情報をチェックして、メッセージを実行できるかどうかを判断します。
- コマンド ワークフロー ロジックでは、コマンドとパラメーター値を使用して Event Grid にメッセージを発行します。
- 車両内のメッセージング モジュールは、コマンド トピックにサブスクライブされ、通知を受け取ります。 コマンドを適切なワークロードにルーティングします。
- メッセージング モジュールでは、ワークロードの完了 (またはエラー) を監視します。 ワークロードは、コマンドを (物理的に) 実行する役目を担います。
- メッセージング モジュールでは、コマンドの状態レポートを Event Grid に発行します。
- ワークフロー モジュールでは、コマンドの状態の更新にサブスクライブされ、コマンド実行の内部状態が更新されます。
- コマンドの実行が完了すると、サービス アプリではコマンドとコントロールの API を介して実行結果を受け取ります。
車両とデバイスのプロビジョニング
このデータフローでは、車両とデバイスを "車両メッセージング サービス" に登録してプロビジョニングするプロセスについて説明します。 このプロセスは通常、車両の製造の一環として開始されます。
- ファクトリ システムでは、車両デバイスが目的の構築状態になるよう指示します。 これには、ファームウェアおよびソフトウェアの初期インストールと構成が含まれる場合があります。 このプロセスの一環として、ファクトリ システムでは "公開キー基盤" プロバイダーから作成されたデバイス "証明書" を取得して書き込みます。
- ファクトリ システムでは、"車両およびデバイス プロビジョニング API" を使用して車両およびデバイスを登録します。
- ファクトリ システムでは、デバイス プロビジョニング クライアントを トリガーして "デバイス登録" に接続し、デバイスをプロビジョニングします。 デバイスでは "MQTT ブローカー" への接続情報が取得されます。
- "デバイス登録" アプリケーション では MQTT ブローカーを使用してデバイス ID を作成します。
- ファクトリ システムは、デバイスをトリガーして、初めて "MQTT ブローカー" への接続を確立します。
- MQTT ブローカーでは、"CA ルート証明書" を使用してデバイスを認証し、クライアント情報を抽出します。
- "MQTT ブローカー" では、ローカル レジストリを使用して、許可されたトピックの認可を管理します。
- 部品交換の場合、OEM ディーラー システムで新しいデバイスの登録をトリガーできます。
Note
通常、ファクトリ システムはオンプレミスであり、クラウドへの直接接続はありません。
データ分析
このデータフローでは、車両データの分析について説明します。 工場やワークショップ オペレーターなどの他のデータ ソースを使用して、車両データをエンリッチし、コンテキストを提供できます。
- "車両メッセージング サービス" レイヤーでは、双方向通信から車両へのテレメトリ、イベント、コマンド、構成メッセージを提供します。
- "IT と運用" レイヤーでは、車両で実行されているソフトウェアと関連するクラウド サービスに関する情報を提供します。
- 複数のパイプラインにより、データの処理が改善された状態になります
- 生データからエンリッチおよび重複除去された車両データへの処理。
- 車両データの集計、主要業績評価指標、分析情報。
- 機械学習用のトレーニング データの生成。
- さまざまなアプリケーションで、改善された集計データが使用されます。
- Power BI を使用した視覚化。
- Dataverse への統合を含む Logic Apps を使用したビジネス統合ワークフロー。
- 生成されたトレーニング データは、ML モデルを生成するために ML Studio などのツールによって使用されます。
スケーラビリティ
コネクテッド車両およびデータ ソリューションは、何百万台もの車両と何千ものサービスにスケーリングできます。 スケーラビリティと弾力性を実現するには、デプロイ スタンプ パターンを使用することをお勧めします。
個々の "車両メッセージング スケール ユニット" は、定義された車両の母集団 (たとえば、年式で区分された特定の地理的地域の車両) をサポートします。 "アプリケーション スケール ユニット" は、車両へのメッセージの送受信を必要とするサービスをスケーリングするために使用されます。 "共通サービス" は、任意のスケール ユニットからアクセスでき、アプリケーションとデバイスのためのデバイス管理とサブスクリプション サービスが提供されます。
- "アプリケーション スケール ユニット" では、関心のあるメッセージがアプリケーションでサブスクライブされます。 共通サービスでは、車両メッセージング スケール ユニット コンポーネントのサブスクリプションが処理されます。
- 車両ではデバイス管理サービスを使用して、車両メッセージング スケール ユニットへの割り当てを検出します。
- 必要に応じて、車両とデバイスのプロビジョニング ワークフローを使用して車両がプロビジョニングされます。
- 車両は、"MQTT ブローカー" にメッセージを発行します。
- Event Grid では 、サブスクリプション情報を使用してメッセージがルーティングされます。
- 処理と要求のチェックを必要としないメッセージの場合は、対応するアプリケーション スケール ユニットのイングレス ハブにルーティングされます。
- 処理を必要とするメッセージは、デコードと認可 (ユーザーの同意) のために D2C 処理ロジック にルーティングされます。
- アプリケーションは、アプリ イングレス イベント ハブ インスタンスからのイベントを使用します。
- アプリケーションは車両のメッセージを発行します。
- それ以上の処理を必要としないメッセージは、"MQTT ブローカー" に発行されます。
- より多くの処理、ワークフロー制御、および認可を必要とするメッセージは、Event Hubs インスタンス経由で関連する C2D 処理ロジック にルーティングされます。
Components
この参照アーキテクチャでは、次の Azure コンポーネントが参照されます。
接続
- Azure Event Grid では、MQTT v5 を介したデバイス オンボード、AuthN/Z、pub-sub を使用できます。
- Azure Functions では、車両メッセージが処理されます。 また、短期間の実行を必要とする管理 API を実装するためにも使用できます。
- Azure Kubernetes Service (AKS) は、マネージド API の背後にある機能が、コンテナー化されたアプリケーションとしてデプロイされた複雑なワークロードで構成されている場合の代替手段です。
- Azure Cosmos DB には、車両、デバイス、ユーザーの同意の設定が格納されます。
- Azure API Management では、車両ライフサイクル管理 (OTA を含む) やユーザーの同意管理などの既存のバックエンド サービスに、マネージド API ゲートウェイが提供されます。
- Azure Batch では、車両通信トレース インジェストなど、大規模なコンピューティング集中型タスクが効率的に実行されます。
データと分析
- Azure Event Hubs を使用すると、大量のテレメトリ データの処理と取り込みができます。
- Azure Data Explorer では、時系列ベースの車両テレメトリ データの探索、キュレーション、分析が可能です。
- Azure Blob Storage には、大きなドキュメント (ビデオやトレースなど) とキュレーションされた車両データが格納されます。
- Azure Databricks には、大規模なエンタープライズ レベルのデータ ソリューションを保守するためのツール セットが用意されています。 大量の車両データに対する長時間の操作に必要です。
バックエンド統合
- Azure Logic Apps では、車両データに基づいてビジネス統合のための自動化されたワークフローが実行されます。
- Azure App Service では、ユーザー向け Web アプリとモバイル バックエンド (コンパニオン アプリなど) が提供されます。
- Azure Cache for Redis では、ユーザー向けアプリケーションでよく使用されるデータのメモリ内キャッシュが提供されます。
- Azure Service Bus では、車両の接続をデジタル サービスとビジネス統合から切り離すブローカーが提供されます。
代替
メッセージ処理とマネージド API を実装するための適切な種類のコンピューティングの選択は、さまざまな要因に左右されます。 「Azure コンピューティング サービスを選択する」ガイドを使用して、適切なサービスを選択します。
例 :
- Azure Functions: テレメトリ インジェストなど、イベントドリブンで短期間のプロセス向け。
- Azure Batch: 大規模な CAN トレース/ビデオ ファイルのデコードなどのハイ パフォーマンス コンピューティング タスク向け
- Azure Kubernetes Service: コマンドとコントロールのワークフロー管理などの複雑なロジックの完全なマネージド オーケストレーション向け。
データ レイク レベルでバッチ同期を実行することが目的の場合は、イベント ベースのデータ共有の代わりに Azure Data Share を使用することもできます。
シナリオの詳細
OEM 自動車メーカーでは、変わらない製品の生産からソフトウェア定義のコネクテッド車両の提供に移行するという大きな変革が起こっています。 車両には、無線での更新、リモート 診断、パーソナライズされたユーザー エクスペリエンスなどのさまざまな機能が用意されています。 この移行により、OEM はリアルタイムのデータと分析情報に基づいて製品を継続的に改善しながら、新しいサービスや収益の流れを取り入れるようにビジネス モデルを拡張することができます。
この参照アーキテクチャにより、自動車メーカーとモビリティ プロバイダーは次のことができます。
- フィードバック データをデジタル エンジニアリング プロセスの一環として使用して、製品の継続的な改善を推進し、問題の根本原因に積極的に対処し、新しい顧客価値を生み出します。
- 新しいデジタル製品とサービスを提供し、エンタープライズ リソース プランニング (ERP) や顧客関係管理 (CRM) などのバックエンド システムとのビジネス統合により運用をデジタル化します。
- より広範な スマート モビリティ エコシステムを使用して、データを安全に共有し、ユーザーの同意に関する国およびリージョン固有の要件に対処します。
- 車両ライフサイクル管理と同意管理用のバックエンド システムと統合することで、ソフトウェア定義の車両 DevOps ツールチェーンを使用したコネクテッド車両ソリューションの展開と管理を簡素化および高速化できます。
- 車両と分析のための大規模なコンピューティングを格納および提供します。
- コスト効率の高い方法で何百万台ものデバイスへの車両接続を管理します。
考えられるユース ケース
"OEM 自動車のユース ケース" は、車両の性能、安全性、ユーザー エクスペリエンスの向上に関するものです。
- 継続的な製品改善: リアルタイム データを分析して更新をリモートで適用することで、車両の性能を向上させます。
- エンジニアリング テスト フリート検証: テスト フリートからデータを収集して分析することで、車両の安全性と信頼性を確保します。
- コンパニオン アプリとユーザー ポータル: カスタマイズされたアプリと Web ポータルを使用して、リモート車両のアクセスと制御を有効にします。
- プロアクティブな修復とメンテナンス: データ駆動型の分析情報に基づいて車両のメンテナンスを予測およびスケジュールします。
"より広範なエコシステムのユース ケース" により、コネクテッド車両アプリケーションが拡張され、輸送環境全体で、フリート運用、保険、マーケティング、路上支援サービスが改善されます。
- 接続された商用フリートの運用: リアルタイムの監視とデータ主導の意思決定によるフリート管理の最適化。
- デジタル車両保険: 運転行動に基づいて保険料をカスタマイズし、事故報告を直ちに提供します。
- 場所ベースのマーケティング: 場所と好みに基づいて、ターゲットを絞ったマーケティング キャンペーンをドライバーに配信します。
- ロードサイド サービス: 車両の位置と診断データを使用して、必要なドライバーにリアルタイムのサポートと支援を提供します。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
- 信頼性を高めるために水平スケーリングを検討してください。
- スケール ユニットを使用して、規制が異なる地理的地域を分離します。
- 自動スケーリングと予約インスタンス: 需要に基づいて動的にスケーリングし、事前に割り当てられたインスタンスを使用してコストを最適化することで、コンピューティング リソースを管理します。
- geo 冗長性: フォールト トレランスとディザスター リカバリーのために、複数の地理的な場所にデータをレプリケートします。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
- 車両接続のセキュリティ保護: X.509 証明書を使用して安全な車両通信を確立する方法については、証明書管理に関するセクションを参照してください。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
- 車両あたりのコストに関する考慮事項: 通信コストは、提供されるデジタル サービスの数に依存します。 運用コストに対するデジタル サービスの RoI を計算します。
- メッセージ トラフィックに基づいてコスト分析のプラクティスを確立します。 コネクテッド車両のトラフィックは、サービスの追加に伴って増加する傾向があります。
- ネットワークとモバイルのコストを考慮する
- MQTT トピックの別名を使用してトラフィック量を減らします。
- ペイロード メッセージをエンコードして圧縮するための効率的な方法を使用します。
- トラフィック処理
- メッセージの優先順位: 車両は日次または週次で需要のピークを作る、繰り返しの使用パターンを持つ傾向があります。 メッセージ プロパティを使用して、重要ではないメッセージまたは分析メッセージの処理を遅延させ、読み込みをスムーズにし、リソースの使用を最適化します。
- 需要に基づいて自動スケーリングします。
- データをホット/ウォーム/コールドに格納する期間を検討します。
- コストを最適化するために予約インスタンスを使用することを検討します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
- 統合 IT 運用の一環として、車両ソフトウェア (ログ/メトリック/トレース)、メッセージング サービス、データと分析サービス、関連するバックエンド サービスを監視することを検討してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
- 複数の地理的地域が必要な場合は特に、50,000 台を超えるデバイスをスケーリングするソリューションにはスケールの概念 を使用することを検討してください。
- データを取り込む最善の方法 (メッセージング、ストリーミング、バッチ処理) を慎重に検討してください。
- ユース ケースに基づいてデータを分析する最適な方法を検討してください。
次のステップ
- 自動運転とアシスト運転のための自動車デジタル エンジニアリングについて視野を拡げるための自律運転車運用 (AVOps) ソリューションを作成します。
関連リソース
次の記事では、アーキテクチャで使用される概念の一部について説明します。
- クレーム チェック パターンは、ファイルのアップロードなどの大量メッセージの処理をサポートするために使用されます。
- デプロイ スタンプでは、ソリューションを何百万台もの車両にスケーリングするために必要な一般的な概念について説明します。
- 調整は、車両からの例外的な数のメッセージを処理するために必要な概念のことをいいます。
次の記事では、アーキテクチャ内のコンポーネント間の相互作用について説明します。