AWS 上での BMW Group による自動運転のためのデータ処理とデータ管理のスケーリング

このブログは、Scaling Automated Driving data processing and data management with BMW Group on AWS を翻訳したものです。

自動運転 (Autonomous driving、AD) や先進運転支援は自動車産業における主要な技術です。完全に実現されれば、快適性と安全性の向上、および、自動車メーカーの新しいビジネスモデルを通じて、自動車およびモビリティ産業を根本から変革する可能性があります。BMW Group は自動車業界の主要な OEM の一つです。今年、BMW Group は 7 シリーズにおいて、高度な自動運転システムのローンチを予定しています。 2020 年の AWS re:Invent セッションでは、世界中のコネクテッドのお客様の車両フリートから、BMW Group がどのように十億 km を超える匿名化された認識データを収集し、より安全で、かつ、高度な自動運転システムを開発するのに役立てているかを学びました。BMW Group では、一般に、データ処理が法的に必要でない限り、お客様の同意なしに車両データを処理することはありません。お客様から同意を得るには処理対象のデータや処理の目的についての透明性が要求されます。このブログでは、BMW Group が AWS 上でどのようにお客様の車両データを収集・分析・可視化を行っているかを説明します。

お客様の車両データの利用目的

一般に、AD に関する車両データには 2 種類あります。つまり、テスト車両からのデータとお客様の車両データです。テスト車両は自動車メーカーによって使用される社内での開発用車両で、追加のセンサーやロギング用システムなど、お客様向けの通常の車両にはないものを搭載しています。この追加の設備によって、自動車メーカーはより詳細な車両データを収集することが可能です。このブログでは、お客様の車両データに焦点を当てます。お客様の車両のデータはすべて実世界のデータであり、実際の車両の挙動です。お客様の車両データは、お客様の直接的な行動に基づいている可能性があり、自動車メーカーが車両の AD 機能をどのようにより良く設計、改善、検証、妥当性の確認、承認するべきかを理解するうえで重要です。例えば、お客様の車両データによって、いつどこである特定の AD 機能がお客様によって最も使われているか、その機能のどこを改善する必要があるか、といったことを明らかにすることができます。これは自動車メーカーの AD 機能の開発者が、お客様にとってインパクトや価値が大きい領域に戦略的に注力するうえで有用です。お客様の車両データは AD 機能の妥当性の確認や検証にも利用することができます。たとえば、ある運転シナリオが発生する頻度を計算したり、そのシナリオにおいてある機能が効かない場合の重大度を見積もるために利用できる可能性があります。

お客様の車両データの収集

お客様のデータに関しては、お客様がその収集や使用に関して積極的な同意をした場合のみ、自動車メーカーは収集と利用が可能です。もし BMW Group に対する同意がある場合、BMW Group のお客様データ収集用プラットフォームを通じて、車両の AD 機能に関するデータが収集されます。次の２種類のデータが収集されます。

どちらの種類の車両データも、 BMW Group によって無線でその AWS 上のデータストレージに転送されます。収集されるデータには以下のものが含まれます。

データ収集の次のステップは、 BMW Group が生のセンサーデータを特定の状況において収集することです。BMW Group では EMEA、US、および、中国において、様々な運用設計ドメイン (operational design domains、ODD) において、お客様の同意に基づいてデータを収集しています。各地域で毎年、10 億 km 以上のデータが収集されており、これは 50 TB 以上に相当しています。

収集されたデータは、次に、AWS 上で稼働している、 BMW Group によって構築されたビッグデータツールチェーンを使って処理されます。このツールチェーンは BMW Group の AD 機能の開発者やデータ分析者が、そのようなデータを使ってより効率良く作業をし、お客様のニーズをよりよく反映した AD 機能を構築するうえで役に立つように設計されています。お客様の車両フリートが増加し、より多くのデータが転送されるようになるにつれて、収集されるデータ量も指数関数的に増大します。以下では、BMW Group による、そのような車両データの増大に対処するのに役に立つ、 AWS 上のソリューションの説明をします。

データプライバシーとガバナンス

お客様データの保護は BMW Group におけるデータ保護プログラムの主要な目的の一つです。それゆえ、お客様データを収集するための必須プロセスが既に導入されています。法律で必須でない場合、データ収集にはお客様の明示的な同意が必要です。個人特定ができないようにするために、多層的なオンボード (車両内) とオフボード (クラウド内) での匿名化のステップがあり、BMW Group が AD 機能開発に必要なデータのみが、適切な保持ポリシーに従って、収集・保存されます。

データ処理とデータ管理のためのソリューションの概要

図 1: データ処理とデータ管理のためのソリューションの概要

図１で提案されている BMW Group のソリューションには、6 つの主要なコンポーネントがあります。

1. お客様の車両から BMW Cloud Data Hub (CDH) へのデータの無線での取り込み。このデータをより良く管理するうえで、BMW Group では、ソフトウェアエンジニアリングチームの自律性と機敏性の両方を向上するために、「データ提供者 (data providers)」と「データ利用者 (data consumers)」という概念を導入しました。この場合では、前述のデータ収集用プラットフォームはデータ提供者として振る舞い、データの取り込み、変換、Parquet ファイル (自動車から取得したソートされていないイベント) での CDH へのデータ保存をするように設計されています。
2. AWS Step Functions を用いたデータパイプライン。このデータパイプラインには 5 つの主要な Amazon EMR ジョブがあります。すべての結果は Amazon Simple Storage Service (Amazon S3) バケットに保存されます。
   1. 各ドライブの完全性 (各ドライブの始まりと終わり) を確認。ドライブに対する匿名化を実行。分析スタック (ステップ 4) を介してより詳細な分析をするために、Apache Parquet フォーマットに最適化されたデータのパーティショニングとソートを実行。Apache Parquet はオープンソースの列指向のデータファイルフォーマットで、効率良いデータの保存と取得を目的として設計されています。Apache Parquet は、複雑なデータを一括処理するための、効率良いデータ圧縮とパフォーマンスが強化されたエンコーディングスキームを提供しています。
   2. フラット化されたテーブル (非正規化したデータベーステーブルの方が分析者にとってずっと使いやすい) を生成するための、入力データの抽出とエンリッチメント。
   3. ダッシュボード/レポートとデータの検索のために、メタデータを抽出。
   4. サンプリングレートが異なる入力シグナルに対して、同期や内挿を実行 (分析者にとってより使いやすい)。様々な車載センサーが異なる周波数を持っているため、例えばセンサーごとに 100ms というように、均一の周波数へと同期を行います。
   5. より迅速な検索や統計のために、カスタムのラベリングツールを用いてドライブ区間の自動ラベリングを実施。例として、急ブレーキや高速道路での割り込みイベントなどが挙げられます。

   Spark ジョブのランタイムとして Amazon EMR を選ぶのにはいくつかの主要な理由があります。まず、アプリケーションコードをローカルシステムにおいて検証可能であることです。同じコードベースをオンプレミスのシステムに共有可能です。また、Amazon EMR は幅広い種類の Amazon EC2 インスタンスタイプをサポートしており、その中にはコスト最適化に役立つ AWS Gravition3 や Amazon EC2 スポットインスタンスも含まれています。

3. データの保存とアクセス管理。生のセンサーデータを除くすべてのデータは、 BMW によって Amazon S3 内に Apache Parquet フォーマットで保存されています。Amazon S3 Intelligent-Tiering ストレージクラスが有効になっています。AWS Glue データカタログはテーブルの定義を与えており、AWS Glue を用いた抽出・変換・ロード (extract、transform、load、ETL) ジョブのソースおよびターゲットとして使用されるデータへの参照が含まれています。AWS Lake Formation は、行レベル、または、列レベルでのきめの細かいアクセスコントロールを AD 機能開発者やデータ分析者に提供しています。
4. Amazon EMR ベースの分析スタック。BMW のデータ分析者は自分自身のクラスターをオンデマンドで立ち上げることができます。Spark、Amazon Athena、 または、 AWS Glue を用いたビッグデータ解析をするうえで、JupyterLab か Zeppelin を使用しています。
5. 運転シーンの可視化。運転シーンは Foxglove やカスタムメイドのアニメーションジェネレータを用いて可視化できます。Foxglove と NiceDCV を用いたリモートアクセスを使った同様の実装が、 Autonomous Driving Data Framework (ADDF) というオープンソースプロジェクトの モジュール の一つとして実装されています。
6. Amazon QuickSight を用いた KPI ダッシュボード。AD 機能のためのダッシュボードには、いつどこで Active Cruise Control のような特定の AD 機能が使われているかが表示されており、これを使って BMW Group は AD 機能の開発の優先度を決めることができます。プラットフォームのためのダッシュボードを使うことで、BMW Group のプラットフォーム管理者はある AWS サービスの費用と利用状況を管理することができます。

ベストプラクティス 1: 大きなチームにおける並列での開発環境の利用。

大きなチームの AD 開発者はそれぞれ、同じ AWS アカウントを使用している他の同僚と干渉することなく、スタック全体のデプロイとテストを実施したいと思っています。Terraform Workspaces を使うことで、同じ AWS アカウント内のすべての AWS リソースの分離とスタック全体に関連する複数のインスタンス上での開発が可能となります。

ベストプラクティス 2: Spark のパフォーマンス最適化。

BMW Group のチームではカスタムの Spark partitioners と catalyst strategy を用いて、メモリ使用量を削減したり、パフォーマンスの向上を行っています。Amazon EMR の全てのインスタンスタイプを利用できるように、BMW のチームではカスタムの re-partition strategy を導入することにより、メモリの最適化を行いました。これは我々のユースケースにおいて、メモリ使用量を最大 50 % 削減するのに役立つように設計されています。この re-partition strategy は catalyst strategy と直接統合されています。catalyst 内で行のシリアル化や逆シリアル化をする必要はなく、処理時間を 30% 削減できます。

ベストプラクティス 3: テストの自動化。

BMW Group の開発チームはコードとデータ品質に関して高いハードルを課しており、単体テストから、統合テスト、エンドツーエンドのテストまで、あらゆるレベルのテストケースを定義しています。標準の Apache Spark API を使うことで、追加の Amazon EMR クラスターを立ち上げることなく、ローカルでテストすることが可能です。

まとめ

このブログでは、BMW Group がどのように AWS 上で車両データを収集・分析・可視化し、AD 機能の開発者やデータ分析者が AD 機能を開発したり、改善するのに役立てているかを紹介しました。Amazon EMR、Amazon S3、Amazon Athena、Amazon Glue、AWS CodeBuild や Amazon Quicksight を含む、幅広い AWS のサービスを活用することによって、クラウド上でどのようにデータを準備・前処理しているかを説明しました。これは、BMW Group のお客様のプライバシーを考慮しつつ、急激に増える車両データに応じてスケールさせるうえで役に立っています。

BMW の Cloud Data Hub に関してさらに知りたい方はこのブログを、ADDF についてはこのブログを参照してください。AWS が提供する内容については、 AWS for automotive のページを参照するか、AWS チームにコンタクトしてください。

このブログはソリューションアーキテクトの渡邊翼と畔栁竜生、スペシャリストの橘幸彦が翻訳を担当しました。

参考文献