Amazon Web Services ブログ
AWS と MongoDB による車両のデジタルツインデータミドルウェア
現在、世界中で推定1億台のコネクテッドカーが道路を走っており、2025年までに4億台に達すると予想されています。コネクテッドカーに対する顧客の購入の意思決定は、ソフトウェアの機能や個人のデジタルライフスタイルへの統合にますます依存するようになるでしょう。これにより、お客様は物理的な運転体験をはるかに超えた、新しいレベルの情報と制御にアクセスできるようになります。
やがて、自動運転などの機能がソフトウェアアプリケーションを通じて必要に応じて有効にできるようになり、移動の計画が完全に自動化され、さまざまな新しい従量課金制のビジネスモデルが開かれるでしょう。自動車メーカーはこれらのトレンドと顧客の期待をよく理解していますが、そこにたどり着くのはかなり困難です。競争力を維持し、車両の販売時以降も収益創出を確保するには、スピードが不可欠です。自動車メーカーはこの問題に対処したいと考えていますが、車両とクラウド間で相互に情報をやりとりする方法の開発など、差別化できないタスクに多くの時間を費やしていることに気づいています。この時間は、このような「技術的な接続」よりも、競合に対する差別化とイノベーションに費やしたほうがよいでしょう。
開発者の効率性は MongoDB の価値の中核であり、ここ数年、MongoDB の機能はよく知られているデータベース製品をはるかに超えて進化してきました。MongoDB は、最も人気のあるデータベーステクノロジープロバイダーの 1 つから、AWS の主要な開発者データプラットフォームの 1 つへと進化しました。このブログ記事では、Realm と Atlas Device Sync で MongoDB Atlas を AWS のクラウドバックエンドとして使用して、車両、クラウド、モバイルアプリ間の統合、すなわち差別化のない「技術的な接続」作業を排除し、次世代のデジタルツインのユースケースやアプリケーションの構築を加速させる方法をご紹介します。
デジタルツインの課題
「デジタルツイン」は、物理装置と仮想装置の間でデータを簡単に双方向に統合すること、と説明できます。デジタルツイン環境を実現することで、リアルタイムの洞察と意思決定が可能になり、装置全体の分析ユースケースがサポートされます。
このブログでは、車両のデジタルツインに焦点を当てています。図 1 に示すように、これは、さまざまな環境で車両のデジタルデータモデルを構築して使用し、車両、AWS クラウド、モバイルデバイスの間で双方向に同期させることを意味し、幅広いユースケースに対応できるようにすることです。
図1:概要
このようなユースケースの簡単な例としては、走行データや気象データを含むステータス情報を活用して EV の航続距離を予測し、充電停止を自動的に計画することが挙げられます。
デジタルツインを実現するには、次の 3 つのコアコンポーネントが必要です。
- 車両のデジタルモデルの作成
- これらのデジタルモデルをモバイルおよびクラウドアプリケーションで実現
- 信頼性の低いネットワークにおける効率的な双方向データ同期メカニズムの確保
こうした一見シンプルに見える作業が、自動車メーカーが現在直面している非常に複雑で時間のかかる作業になります。デジタルモデルの作成自体には、自動車メーカーとそのサプライヤーとの長期にわたる取り組みとコラボレーションが必要です。これに対処するために、大手自動車メーカー、サプライヤー、技術パートナーは、Vehicle Signal Specification (VSS) などの規格の定義を始めています。ただし、このようなツリー状の構造を従来のデータベーステクノロジーと組み合わせると、開発者は構造をリレーショナルデータモデルにマッピングするだけで貴重な時間を無駄にすることになります。
デジタルモデルは、車両、クラウド、モバイル/ウェブアプリケーションなど、さまざまな環境のアプリケーション内にも存在する必要があります。これらの環境はすべて、それぞれ固有の要件を必要とします。その結果、さまざまなテクノロジーとフレームワークが生まれました。
それでもまだ十分ではないと思われるかもしれませんが、これらのデジタルモデルを活用する車両やモバイルアプリケーションは、オフライン時や不安定なネットワーク上でもシームレスに動作することが期待されます。オフラインファーストのアプリケーションとシームレスなデータ同期の組み合わせが目指す未来です。しかし、自動車メーカーがこのような統合機能のメンテナンスだけに膨大な開発時間を浪費し続けると、競合メーカーが次世代のデジタルツインアプリケーションのイノベーションを加速させている動きに、取り残されるリスクがあります。
3 つのコンポーネントについてもう少し詳しく見てみましょう。
車両:コンピュートリソースに制約のある組み込み環境
自動車は、1 日あたり推定25 ギガバイトのデータを生成します。大局的に見ると、25 ギガバイトのデータはNetflixでの 8 時間のストリーミングに相当します!1台当たりのメモリが増えると、車両数百万台分のリソースが必要になるため、依然としてリソース効率に重点が置かれています。したがって、超低フットプリントのテクノロジーを使用できることが重要になります。
MongoDB Realm は、何百万台もの携帯電話で使用されている組み込みデータベーステクノロジーで、モバイルアプリやインフォテインメントのようなシステムの要件を念頭に置いて設計されました。Realm では、リソースの消費を最小限に抑えながらデータを収集、保存、処理するための、使い慣れた軽量なファイルシステム API が利用できます。車両がオフラインのときでも、アプリケーションに必要なすべてのデータを保存して処理できるため、ネットワークへの接続が不安定になっても心配はありません。
さらに、Realm のオブジェクト指向により、オブジェクト・リレーショナル・マッピング・フレームワークのような抽象化レイヤーを追加しなくても、ソフトウェア開発全体が定石的で自然なものになります。
また、モバイルアプリケーションは組み込み機器と多くの共通点を共有しているため、人気の高いモバイルアプリフレームワークやプログラミング言語をサポートする Realm SDK も用意されており、好みの環境で同じ利点を活用できます。
クラウド:AWS のバックエンドパワー
今後、自動車1台あたりで生成されるデータ量が指数関数的に増加するだけでなく、データやデータモデルも進化するでしょう。MongoDB は、ドキュメントモデル上に構築されたマルチモデルデータプラットフォームであり、単一のクエリ言語と API を通じて、進化するさまざまなデータモデルを効率的に処理できます。これにより、複雑さやデータの重複を減らし、コストを節約し、ソフトウェア開発を迅速化できます。
MongoDB の分散型で水平方向にスケーラブルなアーキテクチャを AWS リージョン、アベイラビリティーゾーン、インフラストラクチャサービスと組み合わせることで、データの局所的な配置と高可用性の要件を動的かつ簡単に満たすことができます。
MongoDB と AWS の緊密な連携は、単なるクラウドインフラストラクチャの活用にとどまりません。このコラボレーションにより、AWS のネイティブサービスとの緊密な技術統合が可能になり、さらに AWS のお客様は、既存の AWS アカウントを通じて MongoDB Atlas サービスを利用できるようになります。
AWS 上の MongoDB Atras について詳しく知りたいですか?ここをクリックしてください。
双方向のデータ同期
MongoDB は、クライアントアプリケーションに埋め込まれた Realm データベースと AWS 上のバックエンドデータプラットフォームである MongoDB Atlas の間で、Atlas Device Sync を介した、双方向のデータ同期機能が標準で備わっています。
Atlas Device Sync は、データモデリングと、複数の開発環境にわたるインスタンス化されたデータオブジェクトの同期をシームレスかつリアルタイムで組み合わせるという点でユニークです。ソフトウェア開発者が注意しなければならないのは、アプリケーションコード内のオブジェクトのインスタンスを作成または変更することだけです。
データオブジェクトはアプリケーションコード内でクラス/型として定義されますが、MongoDB Atlas バックエンドは JSON スキーマを使用して属性、データタイプ、および関係を定義します。同じスキーマが、異なるプログラミング環境や Realm SDK のクラス定義に自動的に変換されます。開発者は、プログラミング環境に合わせてデータモデルをコピーして貼り付けるだけで、すぐに使用できます。
フルマネージドの GraphQL API エンドポイントは JSON スキーマも自動的に活用し、通常はウェブやモバイルアプリケーションを通じて、フィールドレベルでロールベースのアクセス制御がされた最新データにすぐにアクセスできます。追加のスキーマのメンテナンスは必要ありません。
車両は常に安定したネットワークのあるエリアで稼働するわけではなく、帯域幅の急激な低下や接続の中断に直面します。このような予測不可能なネットワーク状況に対応するため、Realm はオフラインファーストのパラダイムを採用しています。つまり、データへの変更はまずローカルに保持されます。接続が確立されるとすぐに、変更はクラウドバックエンドを介して他のデバイスとリアルタイムで透過的に同期されます。
また、Realm SDK は突然のネットワークの中断を透過的に自動的に処理し、不安定なネットワーク条件下での接続の再試行によってデバイスのバッテリーが消耗しないようにします。
帯域幅が小さい場合や、データ転送コストが高い場合に対応するため、同期メカニズムはフィールドレベルの変更差分のみをネットワーク経由で送信します。これらのいわゆるチェンジセットは、転送されるデータ量を最小限に抑えるために、転送前にさらに圧縮されます。
分散型アーキテクチャとオフラインファーストのパラダイムは、複数のアプリケーションにわたって同じデータオブジェクトでデータに変更が加えられ、競合が発生する可能性があることも意味します。変更順序などの競合を処理するには、複雑なアプリケーションロジックが必要です。それに対応するため、Atlas Device Sync プロトコルには決定論的な競合解決機能が組み込まれているため、差別化できない複雑なコードを大幅に削減することができ、開発者は機能の開発に時間を割くことができます。
AWS と MongoDB のテレメトリフィードバックループ
車両、クラウドでのデータ管理、およびそれらのデータを同期する方法について説明したので、次は、車両のバッテリーテレメトリを車両内で収集し、クラウドバックエンドに移動して推論し、その結果をドライバー、オーナー、修理工場の担当者とリアルタイムで共有する方法を示すユースケースとアーキテクチャの例を挙げてすべてをまとめてみましょう。
図 2: ハイレベルアーキテクチャ
上記のアーキテクチャを見ると、コネクテッドカーはインフォテイメントシステムなどの車載アプリケーションに Realm SDK を使用しています。このアプリケーションは、車両のテレメトリデータを収集し、車両がオフラインの間は Realm データベースファイルにローカルに保存します。接続が確立されると、HTTPS WebSocket を介してクラウドバックエンドと同期します。バックエンドでは、データは MongoDB データベースに保存されます。トリガーは、収集されたテレメトリデータを AWS EventBridge 経由で Amazon SageMaker にプッシュします。次に、SageMaker によりこのデータを処理します。その後、推論結果が MongoDB に書き戻され、Atlas Device Sync が即座にそれを取得して、携帯電話やインフォテイメントシステムなどのコネクテッドカーの接続アプリケーションすべてと同期します。これにより、車両の状態に関心のあるすべての人が、どこにいても、またそのデータに対して持っている権限に応じて、車両の状態をすぐに知ることができます。
これは、MongoDB AtlasとAWS を活用して、このようなコネクテッドカーのフィードバックループを簡単に構築する方法の簡単な例にすぎません。
あなたの組織が構築できる素晴らしい顧客体験をすべて想像してみてください。例えば、以下のようなアイディアはどうでしょうか。
- 車両のテレメトリデータを収集して気象データと組み合わせ、ルート計画を自動化します
- ロードアシストや遠隔問題解決のためのドライバーとテクニカルサポート間の双方向コミュニケーション
- 保険料を削減するためのドライバープロファイリング
結論
今回のBlog記事は以上です。MongoDB と AWS を使用すると、イノベーションと付加価値のあるユースケースに集中でき、新しい収益源を生み出すことができる、デジタルツイン用の強力なデータミドルウェアを入手できます。差別化により多くの時間を費やし、次世代の自動車顧客体験を生み出す最前線に立ってください。
詳細を知りたい場合は、このブログシリーズのパート2をお楽しみに。そこでは、このブログで取り上げていない技術的な考慮事項 (コードサンプルを含む) を深く掘り下げ、デジタルツインに MongoDB と AWS をどのように活用できるかを紹介するデモプレゼンテーションをお届けします。
この投稿は「Digital Twin Data Middleware with AWS and MongoDB」をAWS Japan SAの岩根 義忠が翻訳しました。