自律走行車両のデータ操作

Azure Batch

Azure Cosmos DB

Azure Data Factory

Azure Data Lake Storage

Azure Data Share

この記事では、自動運転システムのオフラインデータ操作とデータ管理 (DataOps) を開発するためのソリューションとガイダンスについて説明します。 DataOps ソリューションは、自律車両運用 (AVOps) 設計ガイドに記載されているフレームワークに基づいて構築されています。 DataOps は、AVOps の構成要素の 1 つです。その他の構成要素には、機械学習操作 (MLOps)、検証操作 (ValOps)、DevOps、一元化された AVOps 関数などがあります。

Apache®、Apache Spark、Apache Parquet は、米国およびその他の国の Apache Software Foundation の登録商標または商標です。これらのマークの使用によって、Apache Software Foundation による保証は示されません。

建築

この記事のアーキテクチャ図を含む Visio ファイルをダウンロードします。

データフロー

測定データは、車両のデータストリームに由来します。ソースには、カメラ、車両テレメトリ、レーダー、超音波、および nsg センサーが含まれます。車両内のデータロガーは、ロガー記憶装置に測定データを格納します。ロガーストレージデータは、ランディングデータレイクにアップロードされます。 Azure Data Box や Azure Stack Edge などのサービス、または Azure ExpressRoute などの専用接続は、データを Azure に取り込みます。次の形式の測定データは、Azure Data Lake Storage に格納されます。測定データ形式バージョン 4 (MDF4)、技術データ管理システム (TDMS)、rosbag。アップロードされたデータは、データの受信と検証のために指定された Landing と呼ばれる専用ストレージアカウントに入ります。
Azure Data Factory パイプラインは、ランディングストレージアカウント内のデータを処理するためにスケジュールされた間隔でトリガーされます。パイプラインは、次の手順を処理します。
- チェックサムなどのデータ品質チェックを実行します。この手順では、高品質のデータのみが次のステージに渡されるように、低品質のデータを削除します。 Azure App Service は、品質チェックコードを実行するために使用されます。不完全と見なされたデータは、将来の処理のためにアーカイブされます。
- 系列の追跡では、App Service を使用してメタデータ API を呼び出します。この手順では、Azure Cosmos DB に格納されているメタデータを更新して、新しいデータストリームを作成します。測定ごとに、生データストリームがあります。
- Data Lake Storage の raw 呼び出されたストレージアカウントにデータをコピーします。
- メタデータ API を呼び出して、他のコンポーネントやサービスがデータストリームを使用できるように、データストリームを完了としてマークします。
- 測定をアーカイブし、ランディングストレージアカウントから削除します。
Data Factory と Azure Batch は、生ゾーン内のデータを処理して、ダウンストリームシステムが使用できる情報を抽出します。
- Batch は、生ファイル内のトピックからデータを読み取り、それぞれのフォルダー内の選択されたトピックにデータを出力します。
- 生ゾーン内のファイルのサイズはそれぞれ 2 GB を超えることができるため、並列処理抽出関数は各ファイルで実行されます。これらの関数は、画像処理、gps、レーダー、および GPS データを抽出します。また、メタデータ処理も実行します。 Data Factory と Batch は、スケーラブルな方法で並列処理を実行する方法を提供します。
- ラベル付けと注釈付けが必要なデータの量を減らすために、データはダウンサンプリングされます。
車両ロガーのデータがさまざまなセンサー間で同期されていない場合は、データを同期して有効なデータセットを作成する Data Factory パイプラインがトリガーされます。同期アルゴリズムは Batch で実行されます。
Data Factory パイプラインが実行され、データがエンリッチされます。機能強化の例としては、テレメトリ、車両ロガーデータ、気象、マップ、オブジェクトデータなどのその他のデータがあります。強化されたデータは、たとえば、アルゴリズム開発で使用できる分析情報をデータサイエンティストに提供するのに役立ちます。生成されたデータは、同期されたデータと互換性のある Apache Parquet ファイルに保持されます。エンリッチされたデータに関するメタデータは、Azure Cosmos DB のメタデータストアに格納されます。
サードパーティのパートナーは、手動または自動ラベル付けを実行します。データは、Azure Data Share 経由でサードパーティのパートナーと共有され、Microsoft Purview に統合されています。 Data Share は、Data Lake Storage のラベル付きという名前の専用ストレージアカウントを使用して、ラベル付きデータを組織に返します。
Data Factory パイプラインはシーン検出を実行します。シーンメタデータはメタデータストアに保持されます。シーンデータは、Parquet または Delta ファイルにオブジェクトとして格納されます。
エンリッチメントデータと検出されたシーンのメタデータに加えて、Azure Cosmos DB のメタデータストアには、ドライブデータなどの測定値のメタデータが格納されます。このストアには、抽出、ダウンサンプリング、同期、エンリッチメント、シーン検出のプロセスを経る際のデータ系列のメタデータも含まれています。メタデータ API は、測定値、系列、シーンデータにアクセスし、データが格納されている場所を検索するために使用されます。その結果、メタデータ API はストレージレイヤーマネージャーとして機能します。ストレージアカウント間でデータが分散されます。また、開発者はメタデータベースの検索を使用してデータの場所を取得する方法も提供します。そのため、メタデータストアは、ソリューションのデータフロー全体で追跡可能性と系列を提供する一元化されたコンポーネントです。
Azure Databricks と Azure Synapse Analytics は、メタデータ API に接続し、Data Lake Storage にアクセスし、データに関する調査を行うために使用されます。

コンポーネント

Data Box は、Azure との間でテラバイト単位のデータを迅速かつ安価で信頼性の高い方法で送受信する方法を提供します。このソリューションでは、Data Box を使用して、収集された車両データを地域の運送業者を介して Azure に転送します。
Azure Stack Edge デバイス、エッジの場所で Azure の機能を提供します。 Azure の機能の例としては、コンピューティング、ストレージ、ネットワーク、ハードウェアによる高速化された機械学習などがあります。
ExpressRoute は、プライベート接続を介してオンプレミスネットワークを Microsoft Cloud に拡張します。
Data Lake Storage は、ネイティブの生形式で大量のデータを保持します。この場合、Data Lake Storage は、未加工や抽出などのステージに基づいてデータを格納します。
Data Factory は、抽出、変換、読み込み (ETL) ワークフロー、抽出、読み込み、変換 (ELT) ワークフローの作成とスケジュール設定を行う、フルマネージドのサーバーレスソリューションです。ここでは、Data Factory はバッチコンピューティング介して ETL を実行し、データ移動を調整し、データを変換するためのデータドリブンワークフローを作成します。
Batch は、Azure で大規模な並列コンピューティングおよびハイパフォーマンスコンピューティング (HPC) バッチジョブを効率的に実行します。このソリューションでは、Batch を使用して、データラングリング、データのフィルター処理と準備、メタデータの抽出などのタスクに対して大規模なアプリケーションを実行します。
Azure Cosmos DB は、グローバルに分散された複数モデルのデータベースです。ここでは、格納された測定値のようなメタデータ結果を格納します。
Data Share は、セキュリティが強化されたパートナー組織とデータを共有します。データプロバイダーは、インプレース共有を使用することで、データをコピーしたりスナップショットを作成したりすることなく、データが存在する場所でデータを共有できます。このソリューションでは、Data Share はラベル付け会社とデータを共有します。
Azure Databricks には、エンタープライズレベルのデータソリューションを大規模に維持するための一連のツールが用意されています。これは、大量の車両データに対して長時間実行される操作に必要です。データエンジニアは、分析ワークベンチとして Azure Databricks を使用します。
Azure Synapse Analytics をすると、データウェアハウスやビッグデータシステム全体の分析情報を得る時間が短縮されます。
Azure AI Search は、データカタログ検索サービスを提供します。
App Service は、サーバーレスベースの Web App Service を提供します。この場合、App Service はメタデータ API をホストします。
Microsoft Purview は、組織全体のデータガバナンスを提供します。
Azure Container Registry は、コンテナーイメージのマネージドレジストリを作成するサービスです。このソリューションでは、Container Registry を使用して、トピックを処理するためのコンテナーを格納します。
Application Insights は、アプリケーションのパフォーマンス管理を提供 Azure Monitor の拡張機能です。このシナリオでは、Application Insights を使用すると、測定の抽出に関する可観測性を構築できます。Application Insights を使用してカスタムイベント、カスタムメトリック、およびその他の情報をログに記録し、ソリューションは各測定を抽出のために処理できます。 Log Analytics でクエリを作成して、各測定に関する詳細情報を取得することもできます。

シナリオの詳細

自律走行車用の堅牢な DataOps フレームワークを設計することは、データを使用し、その系列をトレースし、組織全体で使用できるようにする上で重要です。適切に設計された DataOps プロセスがないと、自律走行車が生成する大量のデータがすぐに圧倒的になり、管理が困難になる可能性があります。

効果的な DataOps 戦略を実装すると、データが適切に格納され、簡単にアクセスでき、明確な系列を持っていることを確認できます。また、データの管理と分析が容易になり、情報に基づいた意思決定と車両パフォーマンスの向上につながります。

効率的な DataOps プロセスを使用すると、組織全体にデータを簡単に分散できます。その後、さまざまなチームが、運用を最適化するために必要な情報にアクセスできます。 DataOps を使用すると、共同作業や分析情報の共有が容易になり、組織の全体的な有効性を向上させることができます。

自律走行車のコンテキストでのデータ操作の一般的な課題は次のとおりです。

研究開発車両からの測定データの毎日のテラバイト規模またはペタバイト規模の量の管理。
ラベル付け、注釈、品質チェックなど、複数のチームとパートナー間でのデータ共有とコラボレーション。
バージョン管理と測定データの系列をキャプチャする安全クリティカルな知覚スタックの追跡可能性と系列。
セマンティックセグメント化、画像分類、オブジェクト検出モデルを改善するためのメタデータとデータ検出。

この AVOps DataOps ソリューションは、これらの課題に対処する方法に関するガイダンスを提供します。

潜在的なユースケース

このソリューションは、自動車メーカー (OEM)、階層 1 ベンダー、および自動運転用のソリューションを開発する独立系ソフトウェアベンダー (ISV) にメリットがあります。

フェデレーションデータ操作

AVOps を実装する組織では、AVOps に必要な複雑さのため、複数のチームが DataOps に貢献します。たとえば、データ収集とデータインジェストを担当するチームが 1 人います。別のチームが、データの品質管理を行う可能性があります。そのため、DataOps では、データメッシュアーキテクチャの次の原則を考慮することが重要です。

データの所有権とアーキテクチャのドメイン指向の分散化。 1 つの専用チームが、ラベル付けされたデータセットなど、そのドメインのデータ製品を提供する 1 つのデータドメインを担当します。
製品としてのデータ。各データドメインには、Data Lake で実装されたストレージコンテナー上のさまざまなゾーンがあります。内部で使用するゾーンがあります。また、データの重複を避けるために、他のデータドメインまたは外部使用用の発行済みデータ製品を含むゾーンもあります。
自律的なドメイン指向のデータチームを可能にするプラットフォームとしてデータをセルフサービスします。
一元化されたメタデータストアとデータカタログを必要とする AVOps データドメイン間の相互運用性とアクセスを可能にするフェデレーションガバナンス。たとえば、ラベル付けデータドメインには、データコレクションドメインへのアクセスが必要な場合があります。

データメッシュの実装の詳細については、「クラウドスケール分析の」を参照してください。

AVOps データドメインの構造の例

次の表に、AVOps データドメインを構築するためのアイデアをいくつか示します。

データドメイン	パブリッシュされたデータ製品	ソリューションステップ
データ収集	アップロードおよび検証された測定ファイル	ランディングと生
抽出された画像	選択および抽出された画像またはフレーム、ライダー、レーダーデータ	抽出
抽出されたレーダーまたはlidar	選択および抽出されたlidarとレーダーデータ	抽出
抽出されたテレメトリ	選択および抽出された自動車テレメトリデータ	抽出
ラベル	ラベル付きデータセット	ラベル
再計算	シミュレーションの繰り返し実行に基づいて生成された主要業績評価指標 (KPI)	再計算

各 AVOps データドメインは、ブループリント構造に基づいて設定されます。この構造には、Azure Databricks または Azure Synapse Analytics を介した Data Factory、Data Lake Storage、データベース、Batch、Apache Spark ランタイムが含まれます。

メタデータとデータの検出

各データドメインは分散化され、対応する AVOps データ製品を個別に管理します。データを一元的に検出し、データ製品が配置されている場所を把握するには、次の 2 つのコンポーネントが必要です。

処理された測定ファイルとデータストリーム (ビデオシーケンスなど) に関するメタデータを保持するメタデータストア。このコンポーネントは、ラベル付けされていないファイルのメタデータを検索する場合など、インデックスを作成する必要がある注釈を使用してデータを検出および追跡できるようにします。たとえば、メタデータストアで、特定の車両識別番号 (VIN) のすべてのフレーム、歩行者やその他のエンリッチメントベースのオブジェクトを含むフレームを返す場合があります。
系列、AVOps データドメイン間の依存関係、および AVOps データループに関係するデータストアを示すデータカタログ。データカタログの例として、Microsoft Purviewがあります。

Azure Data Explorer または Azure Cognitive Search を使用して、Azure Cosmos DB に基づくメタデータストアを拡張できます。選択内容は、データ検出に必要な最終的なシナリオによって異なります。セマンティック検索機能には Azure Cognitive Search を使用します。

次のメタデータモデル図は、いくつかの AVOps データループの柱で使用される一般的な統合メタデータモデルを示しています。

生測定データを派生データストリームに変換する方法を示す図。

データ共有は、AVOps データループの一般的なシナリオです。ラベル付けパートナーを統合する場合など、データドメイン間のデータ共有や外部共有が使用されます。 Microsoft Purview には、データループでの効率的なデータ共有のための次の機能が用意されています。

セルフサービスデータの検出とアクセスの
インプレースデータ共有

ラベルデータ交換に推奨される形式には、コンテキスト (COCO) データセット共通オブジェクトと、オートメーションおよび測定システムの標準化協会 (ASAM) OpenLABEL データセットが含まれます。

このソリューションでは、ラベル付けされたデータセットを MLOps プロセスで使用して、知覚モデルやセンサー融合モデルなどの特殊なアルゴリズムを作成します。このアルゴリズムでは、車の車線変更、道路のブロック、歩行者の交通、信号機、交通標識など、環境内のシーンやオブジェクトを検出できます。

データパイプライン

この DataOps ソリューションでは、データパイプライン内のさまざまなステージ間でのデータの移動が自動化されます。このアプローチにより、このプロセスは効率、スケーラビリティ、一貫性、再現性、適応性、およびエラー処理の利点を提供します。全体の開発プロセスを強化し、進歩を加速させ、自動運転技術の安全で効果的な展開をサポートします。

次のセクションでは、ステージ間のデータ移動を実装する方法と、ストレージアカウントを構成する方法について説明します。

階層フォルダー構造

適切に整理されたフォルダー構造は、自動運転開発におけるデータパイプラインの重要なコンポーネントです。このような構造は、データファイルの体系的かつ簡単にナビゲート可能な配置を提供し、効率的なデータ管理と取得を容易にします。

このソリューションでは、raw フォルダー内のデータは、次の階層構造を持ちます。

region/raw/<measurement-ID>/<data-stream-ID>/YYYY/MM/DD

抽出されたゾーンストレージアカウント内のデータは、同様の階層構造を使用します。

region/extracted/<measurement-ID>/<data-stream-ID>/YYYY/MM/DD

同様の階層構造を使用することで、Data Lake Storage の階層型名前空間機能を利用できます。階層構造は、スケーラブルでコスト効率の高いオブジェクトストレージを作成するのに役立ちます。これらの構造により、オブジェクトの検索と取得の効率も向上します。年と VIN でパーティション分割すると、特定の車両から関連する画像を簡単に検索できます。データレイクでは、カメラ、GPS デバイス、または gps センサーやレーダーセンサーなど、センサーごとにストレージコンテナーが作成されます。

ストレージアカウントを Raw ストレージアカウントにランディングする

Data Factory パイプラインは、スケジュールに基づいてトリガーされます。パイプラインがトリガーされると、データがランディングストレージアカウントから Raw ストレージアカウントにコピーされます。

パイプラインは、すべての測定フォルダーを取得し、それらを反復処理します。測定ごとに、ソリューションは次のアクティビティを実行します。

関数は測定を検証します。この関数は、測定マニフェストからマニフェストファイルを取得します。次に、この関数は、現在の測定のすべての MDF4、TDMS、rosbag 測定ファイルが測定フォルダーに存在するかどうかを確認します。検証が成功すると、関数は次のアクティビティに進みます。検証に失敗した場合、関数は現在の測定をスキップし、次の測定フォルダーに移動します。
測定を作成する API に対して Web API 呼び出しが行われ、測定マニフェスト JSON ファイルからの JSON ペイロードが API に渡されます。呼び出しが成功すると、応答が解析されて測定 ID が取得されます。呼び出しが失敗した場合、測定はエラー処理のためにエラー時アクティビティに移動されます。

手記

この DataOps ソリューションは、App Service への要求の数を制限することを前提に構築されています。ソリューションが不確定な数の要求を行う可能性がある場合は、レート制限パターン検討してください。
Web API 呼び出しは、必要な JSON ペイロードを作成することによってデータストリームを作成する API に対して行われます。呼び出しが成功すると、応答が解析され、データストリーム ID とデータストリームの場所が取得されます。呼び出しが失敗した場合、測定はエラー時アクティビティに移動されます。
データストリームの状態を Start Copyに更新する Web API 呼び出しが行われます。呼び出しが成功すると、コピーアクティビティは測定ファイルをデータストリームの場所にコピーします。呼び出しが失敗した場合、測定はエラー時アクティビティに移動されます。
Data Factory パイプラインによって Batch が呼び出され、測定ファイルがランディングストレージアカウントから Raw ストレージアカウントにコピーされます。オーケストレーターアプリのコピーモジュールは、測定ごとに次のタスクを含むジョブを作成します。
- 測定ファイルを Raw ストレージアカウントにコピーします。
- 測定ファイルをアーカイブストレージアカウントにコピーします。
- ランディングストレージアカウントから測定ファイルを削除します。
手記

これらのタスクでは、Batch はオーケストレータープールと AzCopy ツールを使用してデータをコピーおよび削除します。 AzCopy では、SAS トークンを使用してコピーまたは削除タスクを実行します。 SAS トークンはキーコンテナーに格納され、landingsaskey、archivesaskey、および rawsaskeyという用語を使用して参照されます。
データストリームの状態を Copy Completeに更新する Web API 呼び出しが行われます。呼び出しが成功すると、シーケンスは次のアクティビティに進みます。呼び出しが失敗した場合、測定はエラー時アクティビティに移動されます。
測定ファイルは、ランディングストレージアカウントからランディングアーカイブに移動されます。このアクティビティは、ハイドレートコピーパイプラインを介してランディングストレージアカウントに戻すことによって、特定の測定値を再実行できます。このゾーンの測定値が自動的に削除またはアーカイブされるように、このゾーンのライフサイクル管理が有効になります。
測定でエラーが発生した場合、測定は誤差領域に移動されます。そこから、ランディングストレージアカウントに移動して、もう一度実行できます。または、ライフサイクル管理で測定を自動的に削除またはアーカイブすることもできます。

次の点に注意してください。

これらのパイプラインは、スケジュールに基づいてトリガーされます。この方法は、パイプライン実行の追跡可能性を向上させ、不要な実行を回避するのに役立ちます。
各パイプラインは、次のスケジュールされた実行が開始される前に前の実行が完了するようにコンカレンシー値 1 で構成されます。
各パイプラインは、測定値を並列にコピーするように構成されます。たとえば、スケジュールされた実行でコピーする測定値が 10 回取得された場合、パイプラインステップは 10 個の測定値すべてに対して同時に実行できます。
各パイプラインは、パイプラインの完了に予想される時間よりも長い時間がかかる場合に、モニターでアラートを生成するように構成されます。
エラー時アクティビティは、後の可観測性ストーリーで実装されます。
ライフサイクル管理では、部分的な測定値 (たとえば、rosbag ファイルが見つからない測定値など) が自動的に削除されます。

バッチ設計

すべての抽出ロジックは、抽出プロセスごとに 1 つのコンテナーを使用して、異なるコンテナーイメージにパッケージ化されます。バッチは、測定ファイルから情報を抽出するときに、コンテナーワークロードを並列で実行します。

Batch では、ワークロードの処理にオーケストレータープールと実行プールが使用されます。

オーケストレータープールには、コンテナーランタイムがサポートされていない Linux ノードがあります。プールは、Batch API を使用して実行プールのジョブとタスクを作成する Python コードを実行します。このプールは、これらのタスクも監視します。 Data Factory はオーケストレータープールを呼び出し、データを抽出するコンテナーワークロードを調整します。
実行プールには、コンテナーワークロードの実行をサポートするためのコンテナーランタイムを含む Linux ノードがあります。このプールでは、ジョブとタスクはオーケストレータープールを介してスケジュールされます。実行プールでの処理に必要なすべてのコンテナーイメージは、JFrog を使用してコンテナーレジストリにプッシュされます。実行プールは、このレジストリに接続し、必要なイメージをプルするように構成されています。

データの読み取りと書き込みの対象となるストレージアカウントは、NFS 3.0 を介してバッチノードとノード上で実行されるコンテナーにマウントされます。この方法は、バッチノードとコンテナーがデータを迅速に処理するのに役立ちます。データファイルをローカルでバッチノードにダウンロードする必要はありません。

手記

マウントするには、バッチアカウントとストレージアカウントが同じ仮想ネットワーク内にある必要があります。

Data Factory からバッチを呼び出す

抽出パイプラインでは、トリガーはメタデータファイルのパスとパイプラインパラメーター内の生データストリームパスを渡します。 Data Factory では、ルックアップアクティビティを使用してマニフェストファイルから JSON を解析します。パイプライン変数を解析することで、生データストリーム ID を生データストリームパスから抽出できます。

Data Factory は API を呼び出してデータストリームを作成します。 API は、抽出されたデータストリームのパスを返します。抽出されたパスが現在のオブジェクトに追加され、Data Factory は、抽出されたデータストリームパスを追加した後、現在のオブジェクトを渡すことによって、カスタムアクティビティを介して Batch を呼び出します。

{
"measurementId":"210b1ba7-9184-4840-a1c8-eb£397b7c686",
"rawDataStreamPath":"raw/2022/09/30/KA123456/210b1ba7-9184-4840-
alc8-ebf39767c68b/57472a44-0886-475-865a-ca32{c851207",
"extractedDatastreamPath":"extracted/2022/09/30/KA123456
/210bIba7-9184-4840-a1c8-ebf39767c68b/87404c9-0549-4a18-93ff-d1cc55£d8b78",
"extractedDataStreamId":"87404bc9-0549-4a18-93ff-d1cc55fd8b78"
}

ステップごとの抽出プロセス

Data Factory では、オーケストレータープールが抽出用の測定を処理するための 1 つのタスクでジョブをスケジュールします。 Data Factory は、オーケストレータープールに次の情報を渡します。
- 測定 ID
- 抽出する必要がある MDF4、TDMS、または rosbag 型の測定ファイルの場所
- 抽出されたコンテンツの格納場所の宛先パス
- 抽出されたデータストリーム ID
オーケストレータープールは、API を呼び出してデータストリームを更新し、その状態を Processingに設定します。

オーケストレータープールは、測定の一部である各測定ファイルのジョブを作成します。各ジョブには、次のタスクが含まれています。

タスク	目的	手記
検証	測定ファイルからデータを抽出できることを検証します。	他のすべてのタスクは、このタスクに依存します。
プロセスメタデータ	測定ファイルからメタデータを派生させ、API を使用してファイルのメタデータを更新することで、ファイルのメタデータを強化します。
プロセス `StructuredTopics`	特定の測定ファイルから構造化データを抽出します。	構造化データを抽出するトピックの一覧は、構成オブジェクトとして渡されます。
プロセス `CameraTopics`	特定の測定ファイルから画像データを抽出します。	イメージを抽出するトピックの一覧は、構成オブジェクトとして渡されます。
プロセス `LidarTopics`	特定の測定ファイルから nsg データを抽出します。	ドキュメントデータを抽出するトピックの一覧は、構成オブジェクトとして渡されます。
プロセス `CANTopics`	特定の測定ファイルからコントローラーエリアネットワーク (CAN) データを抽出します。	データを抽出するトピックの一覧は、構成オブジェクトとして渡されます。

オーケストレータープールは、各タスクの進行状況を監視します。すべての測定ファイルのすべてのジョブが完了すると、プールは API を呼び出してデータストリームを更新し、その状態を Completedに設定します。
オーケストレーターは正常に終了します。

手記

各タスクは、目的に合わせて適切に定義されたロジックを持つ個別のコンテナーイメージです。タスクは、構成オブジェクトを入力として受け入れます。たとえば、出力を書き込む場所と処理する測定ファイルを入力で指定します。 sensor_msgs/Imageなどのトピックの種類の配列は、入力のもう 1 つの例です。他のすべてのタスクは検証タスクに依存するため、依存タスクが作成されます。他のすべてのタスクは個別に処理でき、並列で実行できます。

考慮事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。詳細については、Microsoft Azure Well-Architected Frameworkのに関するページを参照してください。

確実

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。詳細については、「信頼性の柱の概要」を参照してください。

ソリューションでは、Azure 可用性ゾーンを使用することを検討してください。これは、同じ Azure リージョン内の一意の物理的な場所です。
ディザスターリカバリーとアカウントフェールオーバーを計画します。

安全

セキュリティは、意図的な攻撃や貴重なデータとシステムの悪用に対する保証を提供します。詳細については、「セキュリティの柱の概要」を参照してください。

自動車 OEM と Microsoft の間の責任の分担を理解することが重要です。車両では、OEM はスタック全体を所有していますが、データがクラウドに移行すると、一部の責任は Microsoft に移ります。 Azure サービスとしてのプラットフォーム (PaaS) レイヤーは、オペレーティングシステムを含む物理スタックに組み込みのセキュリティを提供します。既存のインフラストラクチャセキュリティコンポーネントには、次の機能を追加できます。

Microsoft Entra ID を使用し、Microsoft Entra 条件付きアクセスポリシーをする ID とアクセスの管理。
Azure Policyを使用するインフラストラクチャガバナンス。
Microsoft Purviewを使用するデータガバナンス。
ネイティブの Azure Storage とデータベースサービスを使用する保存データの暗号化。詳細については、「データ保護に関する考慮事項」を参照してください。
暗号化キーとシークレットの保護。この目的 Azure Key Vault を使用します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法が見られます。詳細については、「コスト最適化の柱の概要」を参照してください。

自動車両用の DataOps を運用する OEM および Tier 1 サプライヤーにとって重要な懸念事項は、運用コストです。このソリューションでは、次のプラクティスを使用してコストを最適化します。

アプリケーションコードをホストするために Azure が提供するさまざまなオプションを利用します。このソリューションでは、App Service と Batch を使用します。デプロイに適したサービスを選択する方法については、「Azure コンピューティングサービスを選択する」を参照してください。
Azure Storage のインプレースデータ共有を使用する。
ライフサイクル管理を使用してコストを最適化する。
予約インスタンスを使用して App Service のコストを削減します。

貢献

この記事は Microsoft によって管理されています。もともとは次の共同作成者によって作成されました。

主な作成者:

リアン松村 |シニアプログラムマネージャー
jochen Schroeer |リードアーキテクト (サービスラインモビリティ)
Brij Singh |プリンシパルソフトウェアエンジニア
ジネットヴェララ |シニアソフトウェアエンジニアリングリーダー

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

自動運転システム用の ValOps の開発方法の詳細については、以下を参照してください。

自動運転車の運転の検証業務

また、次の関連記事にも関心があります。

次の方法で共有

自律走行車両のデータ操作