JP7540728B2 - 乗り物データを管理するためのシステムおよび方法 - Google Patents

Description

本出願は、２０１８年１１月８日に出願された米国仮特許出願第６２／７５７，５１７号、２０１９年１月３１日に出願された米国仮特許出願第６２／７９９，６９７号、２０１９年５月２４日に出願された米国仮特許出願第６２／８５２，７６９号、および２０１９年７月１８日に出願された米国仮特許出願第６２／８７５，９１９号の優先権を主張し、それらの各々は参照により全体が本明細書に組み込まれる。

自律型の乗り物は、その環境を検知し、ユーザ入力をほとんどまたは全く伴わずにナビゲートすることが可能であり得る乗り物である。自律型の乗り物システムは、レーダー、レーザー画像検出および測距（Ｌｉｄａｒ）、画像センサなどの検知デバイスを使用してその環境を検知することができる。自律型の乗り物システムはさらに、全地球測位システム（ＧＰＳ）技術、ナビゲーションシステム、乗り物間通信、乗り物対基盤技術、および／またはドライブバイワイヤシステムからの情報を使用して乗り物をナビゲートすることができる。

単一の高度に自動化された乗り物または自律型の乗り物は、１時間当たり１～５テラバイト（１～５ＴＢ）の生データを生成することができる。１日当たり１４～１６時間動作することは、１日当たり乗り物当たり５０テラバイト、または１年当たり乗り物当たり２０ペタバイトだけの量を生成することを意味してよい。５，０００台の高度に自動化された乗り物の控えめなフリート（ニューヨーク市だけで１４，０００台のタクシーが存在する）は、年間１００エクサバイトを超える生データを生成する可能性がある。そのようなデータは、たとえば、通信、データ管理、フェイルセーフ、ならびにミドルウェアおよびソフトウェアアプリケーションなどのすべてのサポートタスクを含んでよい自律型の乗り物スタックまたは自動化された乗り物スタックによって生成されてよい。そのようなデータはまた、乗り物間通信または交通基盤から生成されたデータを含んでよい。自律型の乗り物スタックまたは自動化された乗り物スタックは、知覚、データ融合、クラウド／オーバージエア（ＯＴＡ）、位置特定、挙動（別名運転ポリシー）、制御、および安全性などの複数の領域を、エンドツーエンド自動化を処理することができるプラットフォームに統合することができる。たとえば、自律型の乗り物スタックまたは自動化された乗り物スタックは、知覚（たとえば、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、グラフィック処理装置（ＧＰＵ）アクセラレータ、単一命令複数データ（ＳＩＭＤ）メモリ、カメラ、Ｌｉｄａｒ、レーダー、ＧＰＳなどのセンサ／検出器）、位置特定および計画（たとえば、データパス処理、ダブルデータレート（ＤＤＲ）メモリ、位置特定データセット、慣性測定、全地球航法衛星システム（ＧＮＳＳ））、決定または挙動（たとえば、モーションエンジン、エラー訂正コード（ＥＣＣ）メモリ、挙動モジュール、調停、予測子）、制御（たとえば、ロックステッププロセッサ、ＤＤＲメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ）、接続および入出力（Ｉ／Ｏ）（たとえば、無線周波数（ＲＦ）プロセッサ、ネットワークスイッチ、決定論的バス、データ記録）、ならびに様々な他のものなどの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを含んでよい。そのようなデータは、自律型の乗り物スタックまたは自動化された乗り物スタックの一部として、１つもしくは複数のセンサおよび／または様々な他のモジュールによって生成されてよい。

かなりの量の自律型の乗り物データまたは自動化された乗り物データは価値があり得、コスト、タイミング、およびプライバシーの様々な優先順位に対して、乗り物、エッジ基盤、およびクラウドのコンテキストで識別、選択、処理、送信、および格納される必要があり得る。

本明細書では、安全で、確実で、費用効果が高く、拡張可能であり、オープンアプリケーションを促進する方式で自律型の乗り物データまたは自動化された乗り物データを管理するための方法およびシステムに対する必要性が認識されている。

本開示は、乗り物データを管理するためのシステムおよび方法を提供する。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造（たとえば、小規模バッチ製造および自律型の乗り物の製品化）、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。本明細書で使用される「乗り物データ」という用語は、一般に、文脈上別段の示唆がない限り、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物などの任意のタイプの乗り物によって生成されたデータを指す。本明細書で使用される「自律型の乗り物データ」という用語は、一般に、自律型の乗り物によって生成されたデータを指す。本開示の実施形態は自律型の乗り物に関して記載されているが、実施形態は自動化された乗り物に適用可能または適合され得ることが諒解されるべきである。

いくつかの実施形態では、提供されたデータ管理システムは、自律型の乗り物または自動化された乗り物に搭載されたデータオーケストレータを備える場合がある。データオーケストレータは、乗り物データを編成および管理することが可能であり得る。場合によっては、自律型の乗り物データは、自律型の乗り物スタックによって生成されたデータ（たとえば、自律型の乗り物のセンサによって捕捉されたデータ）、ならびに運転者および乗客のデータを含んでよい。データオーケストレータは、どの乗り物データ（のどの部分）がどのデータセンタまたはサードパーティエンティティに通信されるべきか、およびそのようなデータがいつ送信されるかを判断するように構成されてよい。たとえば、自律型の乗り物データの一部は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータは、自律型の乗り物が静止しているとき（次の割当て／タスクを待っている間、または保守されている間）に通信されてよい。

一態様では、乗り物の乗り物データを管理するための方法が提供される。方法は、（ａ）乗り物から乗り物データを収集することであって、乗り物データが少なくとも１テラバイトのサイズを有する、収集することと、（ｂ）乗り物データを処理して乗り物データに対応するメタデータを生成することであって、乗り物データがデータベースに格納される、生成することと、（ｃ）メタデータの少なくとも一部分を使用してデータベースから乗り物データのサブセットを検索することであって、乗り物データのサブセットが乗り物データよりも小さいサイズを有する、検索することと、（ｄ）乗り物データのサブセットを格納または送信することとを含んでよい。

いくつかの実施形態では、方法は、（ｂ）で処理された乗り物データをデータベースに格納することをさらに含む。いくつかの実施形態では、（ｃ）のステップは、メタデータを使用して、予測モデルを訓練するためにデータベースから乗り物データのサブセットを検索することを含み、予測モデルは乗り物データを管理するために使用される。場合によっては、予測モデルは、乗り物からリモートエンティティに乗り物データを送信するために使用可能である。たとえば、方法は、予測モデルを使用して、乗り物からデータオーケストレータによって管理されるデータベースに乗り物データを送信することをさらに含む。

いくつかの実施形態では、方法は、乗り物データにアクセスするユーザからの要求を受信することと、要求に少なくとも部分的に基づいてメタデータの少なくとも一部分を選択することとをさらに含む。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。

別の態様では、乗り物の乗り物データを管理するためのシステムが提供される。システムは、データベースと、データベースに動作可能に結合された１つまたは複数のコンピュータプロセッサとを備え、１つまたは複数のコンピュータプロセッサは、（ｉ）乗り物から乗り物データを収集することであって、乗り物データが少なくとも１テラバイトのサイズを有する、収集することと、（ｉｉ）乗り物データを処理して乗り物データに対応するメタデータを生成することであって、乗り物データがデータベースに格納される、生成することと、（ｉｉｉ）メタデータの少なくとも一部分を使用してデータベースから乗り物データのサブセットを検索することであって、乗り物データのサブセットが乗り物データよりも小さいサイズを有する、検索することと、（ｉｖ）乗り物データのサブセットを格納または送信することとを行うように、個別にまたはまとめてプログラムされる。

いくつかの実施形態では、乗り物データは、少なくとも、１つまたは複数のセンサによって捕捉されたセンサデータと、乗り物に搭載された１つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む。場合によっては、メタデータは、１つもしくは複数のセンサのうちの１つのセンサによって生成された第１のメタデータ、または１つもしくは複数のアプリケーションのうちの１つのアプリケーションによって生成された第２のメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物の１つまたは複数のセンサによって収集されたセンサデータを整列させることによって生成される。いくつかの実施形態では、メタデータは、予測モデルを訓練するためにデータベースから乗り物データのサブセットを検索するために使用され、予測モデルは乗り物データを管理するために使用される。場合によっては、予測モデルは、乗り物からリモートエンティティに乗り物データを送信するために使用可能である。場合によっては、予測モデルは、乗り物からシステムによって管理されるデータベースに乗り物データを送信するために使用可能である。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または自律型の乗り物である。

本開示の別の関連するさらに別個の態様は、乗り物データを管理するためのデータオーケストレータを提供する。データオーケストレータは、自律型の乗り物に搭載される場合がある。データオーケストレータは、（ｉ）乗り物データの１つまたは複数のサブセットを要求する１つまたは複数のリモートエンティティに関連するデータ、および（ｉｉ）乗り物データの１つまたは複数のサブセットを生成する１つまたは複数のアプリケーションに関連するデータを格納するように構成されたデータリポジトリであって、データリポジトリが、乗り物データが収集または生成される乗り物に対してローカルである、データリポジトリと、機械学習ベースの予測モデルおよびデータ送信規則を決定するためのユーザ定義規則を格納するように構成された知識ベースであって、（ｉ）送信されるべき乗り物データの選択された部分、（ｉｉ）乗り物データの選択された部分を送信するとき、および（ｉｉｉ）乗り物データの選択された部分を受信するための１つまたは複数のリモートエンティティのうちの１つのリモートエンティティを備える、知識ベースと、リポジトリに格納されたデータおよび送信規則に基づいて乗り物データの一部分を送信するように構成された送信モジュールとを備えてよい。

いくつかの実施形態では、リポジトリ、知識ベース、および送信モジュールは乗り物に搭載されている。いくつかの実施形態では、１つまたは複数のリモートエンティティは、クラウドアプリケーション、データセンタ、サードパーティサーバ、または別の乗り物を含む。いくつかの実施形態では、データリポジトリは、乗り物データの１つまたは複数のサブセットの可用性、送信タイミング遅延、関連するデータのサブセットのデータタイプ、または送信プロトコルを示すデータを格納する。

いくつかの実施形態では、機械学習ベースの予測モデルは、モデルツリー構造に格納される。場合によっては、モデルツリー構造は、機械学習ベースの予測モデル間の関係を表す。場合によっては、モデルツリー構造のノードは機械学習ベースの予測モデルを表し、ノードはモデルアーキテクチャ、モデルパラメータ、訓練データセット、または試験データセットのうちの少なくとも１つを含む。

いくつかの実施形態では、機械学習ベースの予測モデルは、データセンタに配置されたモデル作成器によって生成される。場合によっては、機械学習ベースの予測モデルは、メタデータおよび乗り物データを使用して訓練および試験される。場合によっては、モデル作成器は、乗り物に使用可能な予測モデルを生成するように構成される。

いくつかの実施形態では、知識ベースは、乗り物に使用可能な予測モデルを格納する。いくつかの実施形態では、乗り物データの選択された部分は、乗り物データのサブセットのうちの１つまたは複数の集約を含む。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。

本開示の別の態様は、乗り物データを管理するための方法を提供する。方法は、（ａ）クラウドにおいて、乗り物から送信された乗り物データを受信することであって、乗り物データが少なくともセンサデータを含む、受信することと、（ｂ）乗り物データを処理して乗り物データに対応するメタデータを生成することであって、メタデータがセンサデータを捕捉するセンサによって生成されたデータを含む、生成することと、（ｄ）メタデータをメタデータデータベースに格納することとを含む。

いくつかの実施形態では、乗り物データはストリームデータおよびバッチデータを含む。いくつかの実施形態では、乗り物データはアプリケーションデータを含む。場合によっては、メタデータは、アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む。

いくつかの実施形態では、乗り物データはパイプラインエンジンによって処理される。場合によっては、パイプラインエンジンは１つまたは複数の機能構成要素を備える。たとえば、１つまたは複数の機能構成要素のうちの少なくとも１つは、ユーザインターフェースを介して一組の機能から選択される。場合によっては、１つまたは複数の機能構成要素のうちの少なくとも１つは、シナリオデータオブジェクトを作成するように構成され、シナリオデータオブジェクトは特定のメタデータが使用されるシナリオを指定するためのものである。

いくつかの実施形態では、（ｂ）で処理された乗り物データは、クラウドの一部としての１つまたは複数のデータベースに格納される。場合によっては、方法は、１つまたは複数のデータベースに格納された乗り物データを使用して予測モデルを訓練することをさらに含む。場合によっては、予測モデルは、乗り物から乗り物データの少なくともサブセットを検索するために使用される。場合によっては、メタデータは、予測モデルを訓練するために１つまたは複数のデータベースから乗り物データのサブセットを検索するために使用される。方法は、予測モデルの目標に従って乗り物データのサブセットに対して適切性分析を実行することと、適切性分析の結果に基づいて乗り物データのサブセットを補正することとをさらに含む。

いくつかの実施形態では、メタデータは、（ｂ）における乗り物データの処理に関連するメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物データの１つまたは複数のサブセットを検索するために使用可能である。いくつかの実施形態では、乗り物データの少なくとも一部分は送信方式に基づいて送信され、送信方式はクラウドからの要求に基づいて決定される。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または自律型の乗り物である。

本開示の別の態様は、乗り物の乗り物データを管理するためのシステムを提供する。システムは、データベースと、データベースに動作可能に結合された１つまたは複数のコンピュータプロセッサとを備え、１つまたは複数のコンピュータプロセッサは、（ｉ）乗り物から送信された乗り物データを受信することであって、乗り物データが少なくともセンサデータを含む、受信することと、（ｉｉ）乗り物データを処理して乗り物データに対応するメタデータを生成することであって、メタデータがセンサデータを捕捉するセンサによって生成されたデータを含む、生成することと、（ｉｉｉ）メタデータをデータベースに格納することとを行うように、個別にまたはまとめてプログラムされる。

いくつかの実施形態では、乗り物データはストリームデータおよびバッチデータを含む。いくつかの実施形態では、乗り物データはアプリケーションデータを含む。場合によっては、メタデータは、アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む。

いくつかの実施形態では、乗り物データはパイプラインエンジンによって処理される。場合によっては、パイプラインエンジンは１つまたは複数の機能構成要素を備える。場合によっては、１つまたは複数の機能構成要素のうちの少なくとも１つは、ユーザインターフェースを介して一組の機能から選択される。場合によっては、１つまたは複数の機能構成要素のうちの少なくとも１つは、シナリオデータオブジェクトを作成するように構成され、シナリオデータオブジェクトは特定のメタデータが使用されるシナリオを指定するためのものである。

いくつかの実施形態では、１つまたは複数のプロセッサは、データベースに格納された乗り物データを使用して予測モデルをさらに訓練するようにプログラムされる。場合によっては、予測モデルは、乗り物から乗り物データの少なくともサブセットを検索するために使用される。いくつかの実施形態では、メタデータは、乗り物データの処理に関連するメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物データの１つまたは複数のサブセットを検索するために使用可能である。いくつかの実施形態では、乗り物データの少なくとも一部分は送信方式に基づいて送信され、送信方式は要求に基づいて決定される。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。

本開示の別の態様は、１つまたは複数のコンピュータプロセッサによる実行時に、本明細書の上記または他の箇所の方法のいずれかを実施する機械実行可能コードを含む、非一時的コンピュータ可読媒体を提供する。

本開示の別の態様は、１つまたは複数のコンピュータプロセッサおよびそれらに結合されたコンピュータメモリを備えるシステムを提供する。コンピュータメモリは、１つまたは複数のコンピュータプロセッサによる実行時に、本明細書の上記または他の箇所の方法のいずれかを実施する機械実行可能コードを含む。

本開示の追加の態様および利点は、以下の発明を実施するための形態から当業者には容易に明らかになり、本開示の例示的な実施形態のみが図示および記載される。実現されるように、本開示は、他の異なる実施形態が可能であり、そのいくつかの詳細は、すべてが本開示から逸脱することなく、様々な明白な点で修正が可能である。したがって、図面および説明は、本質的に例示と見なされるべきであり、限定と見なされるべきではない。
本発明は、例えば、以下を提供する。
（項目１）
乗り物の乗り物データを管理するための方法であって、
（ａ）前記乗り物から前記乗り物データを収集するステップであって、前記乗り物データが少なくとも１テラバイトのサイズを有する、ステップと、
（ｂ）前記乗り物データを処理して前記乗り物データに対応するメタデータを生成するステップであって、前記乗り物データがデータベースに格納される、ステップと、
（ｃ）前記メタデータの少なくとも一部分を使用して前記データベースから前記乗り物データのサブセットを検索するステップであって、前記乗り物データのサブセットが前記乗り物データよりも小さいサイズを有する、ステップと、
（ｄ）前記乗り物データの前記サブセットを格納または送信するステップと
を含む、方法。
（項目２）
前記乗り物データが、少なくとも、１つまたは複数のセンサによって捕捉されたセンサデータと、前記乗り物に搭載された１つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む、項目１に記載の方法。
（項目３）
前記メタデータが、前記１つもしくは複数のセンサのうちの１つのセンサによって生成された第１のメタデータ、または前記１つもしくは複数のアプリケーションのうちの１つのアプリケーションによって生成された第２のメタデータをさらに含む、項目２に記載の方法。
（項目４）
前記乗り物データを処理するステップが、前記乗り物の１つまたは複数のセンサによって収集されたセンサデータを整列させるステップを含む、項目１に記載の方法。
（項目５）
（ｂ）で処理された前記乗り物データを前記データベースに格納するステップをさらに含む、項目１に記載の方法。
（項目６）
（ｃ）が、前記メタデータを使用して、予測モデルを訓練するために前記データベースから前記乗り物データの前記サブセットを検索するステップを含み、前記予測モデルが前記乗り物データを管理するために使用される、項目１に記載の方法。
（項目７）
前記予測モデルが、前記乗り物からリモートエンティティに前記乗り物データを送信するために使用可能である、項目６に記載の方法。
（項目８）
前記予測モデルを使用して、前記乗り物から前記データオーケストレータによって管理されるデータベースに前記乗り物データを送信するステップをさらに含む、項目７に記載の方法。
（項目９）
前記乗り物データにアクセスするユーザからの要求を受信するステップと、前記要求に少なくとも部分的に基づいて前記メタデータの前記少なくとも一部分を選択するステップとをさらに含む、項目１に記載の方法。
（項目１０）
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目１に記載の方法。
（項目１１）
乗り物の乗り物データを管理するためのシステムであって、
データベースと、
前記データベースに動作可能に結合された１つまたは複数のコンピュータプロセッサと
を備え、
前記１つまたは複数のコンピュータプロセッサが、（ｉ）前記乗り物から前記乗り物データを収集することであって、前記乗り物データが少なくとも１テラバイトのサイズを有する、収集することと、（ｉｉ）前記乗り物データを処理して前記乗り物データに対応するメタデータを生成することであって、前記乗り物データが前記データベースに格納される、生成することと、（ｉｉｉ）前記メタデータの少なくとも一部分を使用して前記データベースから前記乗り物データのサブセットを検索することであって、前記乗り物データのサブセットが前記乗り物データよりも小さいサイズを有する、検索することと、（ｉｖ）前記乗り物データの前記サブセットを格納または送信することとを行うように、個別にまたはまとめてプログラムされる、
システム。
（項目１２）
前記乗り物データが、少なくとも、１つまたは複数のセンサによって捕捉されたセンサデータと、前記乗り物に搭載された１つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む、項目１１に記載のシステム。
（項目１３）
前記メタデータが、前記１つもしくは複数のセンサのうちの１つのセンサによって生成された第１のメタデータ、または前記１つもしくは複数のアプリケーションのうちの１つのアプリケーションによって生成された第２のメタデータをさらに含む、項目１２に記載のシステム。
（項目１４）
前記メタデータが、前記乗り物の１つまたは複数のセンサによって収集されたセンサデータを整列させることによって生成される、項目１１に記載のシステム。
（項目１５）
前記メタデータが、予測モデルを訓練するために前記データベースから前記乗り物データの前記サブセットを検索するために使用され、前記予測モデルが前記乗り物データを管理するために使用される、項目１１に記載のシステム。
（項目１６）
前記予測モデルが、前記乗り物からリモートエンティティに前記乗り物データを送信するために使用可能である、項目１５に記載のシステム。
（項目１７）
前記予測モデルが、前記乗り物から前記システムによって管理される前記データベースに前記乗り物データを送信するために使用可能である、項目１６に記載のシステム。
（項目１８）
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目１１に記載のシステム。
（項目１９）
乗り物データを管理するためのデータオーケストレータであって、
（ｉ）前記乗り物データの１つまたは複数のサブセットを要求する１つまたは複数のリモートエンティティに関連するデータ、および（ｉｉ）前記乗り物データの前記１つまたは複数のサブセットを生成する１つまたは複数のアプリケーションに関連するデータを格納するように構成されたデータリポジトリであって、前記データリポジトリが、前記乗り物データが収集または生成される前記乗り物に対してローカルである、データリポジトリと、
機械学習ベースの予測モデルおよびデータ送信規則を決定するためのユーザ定義規則を格納するように構成された知識ベースであって、（ｉ）送信されるべき前記乗り物データの選択された部分、（ｉｉ）前記乗り物データの前記選択された部分を送信するとき、および（ｉｉｉ）前記乗り物データの前記選択された部分を受信するための前記１つまたは複数のリモートエンティティのうちの１つのリモートエンティティを備える、知識ベースと、
前記リポジトリに格納された前記データおよび前記送信規則に基づいて前記乗り物データの一部分を送信するように構成された送信モジュールと
を備える、データオーケストレータ。
（項目２０）
前記リポジトリ、知識ベース、および前記送信モジュールが、前記乗り物に搭載されている、項目１９に記載のデータオーケストレータ。
（項目２１）
前記１つまたは複数のリモートエンティティが、クラウドアプリケーション、データセンタ、サードパーティサーバ、または別の乗り物を含む、項目１９に記載のデータオーケストレータ。
（項目２２）
前記データリポジトリが、前記乗り物データの前記１つまたは複数のサブセットの可用性、送信タイミング遅延、前記関連するデータのサブセットのデータタイプ、または送信プロトコルを示すデータを格納する、項目１９に記載のデータオーケストレータ。
（項目２３）
前記機械学習ベースの予測モデルが、モデルツリー構造に格納される、項目１９に記載のデータオーケストレータ。
（項目２４）
前記モデルツリー構造が、機械学習ベースの予測モデル間の関係を表す、項目２３に記載のデータオーケストレータ。
（項目２５）
前記モデルツリー構造のノードが機械学習ベースの予測モデルを表し、前記ノードがモデルアーキテクチャ、モデルパラメータ、訓練データセット、または試験データセットのうちの少なくとも１つを含む、項目２３に記載のデータオーケストレータ。
（項目２６）
前記機械学習ベースの予測モデルが、データセンタに配置されたモデル作成器によって生成される、項目１９に記載のデータオーケストレータ。
（項目２７）
前記機械学習ベースの予測モデルが、メタデータおよび前記乗り物データを使用して訓練および試験される、項目２６に記載のデータオーケストレータ。
（項目２８）
前記モデル作成器が、前記乗り物に使用可能な予測モデルを生成するように構成される、項目２６に記載のデータオーケストレータ。
（項目２９）
前記知識ベースが、前記乗り物に使用可能な予測モデルを格納する、項目１９に記載のデータオーケストレータ。
（項目３０）
前記乗り物データの前記選択された部分が、乗り物データの前記サブセットのうちの１つまたは複数の集約を含む、項目１９に記載のデータオーケストレータ。
（項目３１）
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目１９に記載のデータオーケストレータ。
（項目３２）
乗り物データを管理するための方法であって、
（ａ）クラウドにおいて、乗り物から送信された乗り物データを受信するステップであって、前記乗り物データが少なくともセンサデータを含む、ステップと、
（ｂ）前記乗り物データを処理して前記乗り物データに対応するメタデータを生成するステップであって、前記メタデータが前記センサデータを捕捉するセンサによって生成されたデータを含む、ステップと、
（ｃ）前記メタデータをメタデータデータベースに格納するステップと
を含む、方法。
（項目３３）
前記乗り物データが、ストリームデータおよびバッチデータを含む、項目３２に記載の方法。
（項目３４）
前記乗り物データが、アプリケーションデータを含む、項目３２に記載の方法。
（項目３５）
前記メタデータが、前記アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む、項目３４に記載の方法。
（項目３６）
前記乗り物データが、パイプラインエンジンによって処理される、項目３２に記載の方法。
（項目３７）
前記パイプラインエンジンが、１つまたは複数の機能構成要素を備える、項目３６に記載の方法。
（項目３８）
前記１つまたは複数の機能構成要素のうちの少なくとも１つが、ユーザインターフェースを介して一組の機能から選択される、項目３７に記載の方法。
（項目３９）
前記１つまたは複数の機能構成要素のうちの少なくとも１つが、シナリオデータオブジェクトを作成するように構成され、前記シナリオデータオブジェクトが特定のメタデータが使用されるシナリオを指定するためのものである、項目３７に記載の方法。
（項目４０）
（ｂ）で処理された前記乗り物データが、前記クラウドの一部としての１つまたは複数のデータベースに格納される、項目３２に記載の方法。
（項目４１）
前記１つまたは複数のデータベースに格納された前記乗り物データを使用して予測モデルを訓練するステップをさらに含む、項目４０に記載の方法。
（項目４２）
前記予測モデルが、前記乗り物から前記乗り物データの少なくともサブセットを検索するために使用される、項目４１に記載の方法。
（項目４３）
前記メタデータが、前記予測モデルを訓練するために前記１つまたは複数のデータベースから前記乗り物データのサブセットを検索するために使用される、項目４１に記載の方法。
（項目４４）
前記予測モデルの目標に従って前記乗り物データの前記サブセットに対して適切性分析を実行するステップをさらに含む、項目４３に記載の方法。
（項目４５）
前記適切性分析の結果に基づいて前記乗り物データの前記サブセットを補正するステップをさらに含む、項目４４に記載の方法。
（項目４６）
前記メタデータが、（ｂ）における前記乗り物データの処理に関連するメタデータをさらに含む、項目３２に記載の方法。
（項目４７）
前記メタデータが、前記乗り物データの１つまたは複数のサブセットを検索するために使用可能である、項目３２に記載の方法。
（項目４８）
前記乗り物データの少なくとも一部分が送信方式に基づいて送信され、前記送信方式が前記クラウドからの要求に基づいて決定される、項目３２に記載の方法。
（項目４９）
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目３２に記載の方法。
（項目５０）
乗り物の乗り物データを管理するためのシステムであって、
データベースと、
前記データベースに動作可能に結合された１つまたは複数のコンピュータプロセッサと
を備え、
前記１つまたは複数のコンピュータプロセッサが、（ｉ）乗り物から送信された乗り物データを受信することであって、前記乗り物データが少なくともセンサデータを含む、受信することと、（ｉｉ）前記乗り物データを処理して前記乗り物データに対応するメタデータを生成することであって、前記メタデータが前記センサデータを捕捉するセンサによって生成されたデータを含む、生成することと、（ｉｉｉ）前記メタデータを前記データベースに格納することとを行うように、個別にまたはまとめてプログラムされる、
システム。
（項目５１）
前記乗り物データが、ストリームデータおよびバッチデータを含む、項目５０に記載のシステム。
（項目５２）
前記乗り物データが、アプリケーションデータを含む、項目５０に記載のシステム。
（項目５３）
前記メタデータが、前記アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む、項目５２に記載のシステム。
（項目５４）
前記乗り物データが、パイプラインエンジンによって処理される、項目５０に記載のシステム。
（項目５５）
前記パイプラインエンジンが、１つまたは複数の機能構成要素を備える、項目５４に記載のシステム。
（項目５６）
前記１つまたは複数の機能構成要素のうちの少なくとも１つが、ユーザインターフェースを介して一組の機能から選択される、項目５５に記載のシステム。
（項目５７）
前記１つまたは複数の機能構成要素のうちの少なくとも１つが、シナリオデータオブジェクトを作成するように構成され、前記シナリオデータオブジェクトが特定のメタデータが使用されるシナリオを指定するためのものである、項目５５に記載のシステム。
（項目５８）
前記１つまたは複数のプロセッサが、前記データベースに格納された前記乗り物データを使用して予測モデルをさらに訓練するようにプログラムされる、項目５０に記載のシステム。
（項目５９）
前記予測モデルが、前記乗り物から前記乗り物データの少なくともサブセットを検索するために使用される、項目５８に記載のシステム。
（項目６０）
前記メタデータが、前記乗り物データの処理に関連するメタデータをさらに含む、項目５０に記載のシステム。
（項目６１）
前記メタデータが、前記乗り物データの１つまたは複数のサブセットを検索するために使用可能である、項目５０に記載のシステム。
（項目６２）
前記乗り物データの少なくとも一部分が送信方式に基づいて送信され、前記送信方式が要求に基づいて決定される、項目５０に記載のシステム。
（項目６３）
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目５０に記載のシステム。

参照による組込み
本明細書で言及されるすべての刊行物、特許、および特許出願は、あたかも個々の刊行物、特許、または特許出願が参照により組み込まれることが具体的かつ個別に示されたかのように、同じ程度まで参照により本明細書に組み込まれる。参照により組み込まれる刊行物および特許または特許出願が明細書に含まれる開示と矛盾する範囲まで、本明細書は、いかなるそのような矛盾する資料にも取って代わり、かつ／または優先するものである。

本発明の新規の特徴は、添付の特許請求の範囲に詳細に記載されている。本発明の特徴および利点のより良い理解は、本発明の原理が利用される例示的な実施形態を記載する以下の発明を実施するための形態、ならびに添付の図面（本明細書では「図（Ｆｉｇｕｒｅ）」および「図（ＦＩＧ）」でもある）を参照して得られる。

データオーケストレータとデータセンタとの間のデータフローを概略的に示す図である。 様々なデータセンタ、自律型の乗り物、およびリモートエンティティにわたるデータフローの例を示す図である。 アプリケーションテーブルの一例を示す図である。 １つまたは複数のリモートエンティティと通信するデータオーケストレータの一例を概略的に示す図である。 予測モデル知識ベースの一例を示す図である。 予測モデルを訓練および開発するためにメタデータデータベースおよびクラウドデータレイクと対話するモデル作成器の一例を示す図である。 予測モデルを作成する方法を示す図である。 データ管理システムの例示的な構成要素を示す図である。 データ取込みパイプラインの一例およびパイプラインエンジンによって実行される機能を示す図である。 例示的なデータ取込みプロセスを示す図である。 整列などのデータ処理によって生成されたメタデータ、アプリケーションおよび／またはセンサによって生成されたメタデータの例を示す図である。 シナリオメタデータの一例を示す図である。 データ管理システムを実装するようにプログラムされるか、そうでなければ構成されたコンピュータシステムを示す図である。 自動化された乗り物および自律型の乗り物のライフサイクルにおける様々なアプリケーションの例を示す図である。 乗り物内の予測モデルを動的に更新する例を示す図である。 本発明のいくつかの実施形態による、ＯＥＭの助けを借りて管理されるデータ送信を概略的に示す図である。 データオーケストレータと１つまたは複数のクラウドアプリケーションとの間のデータ送信プロセスを示す図である。 多層データアーキテクチャを概略的に示す図である。 乗り物層とフォグ層との間、およびフォグ層とクラウド層との間のデータ送信を管理するためのデータオーケストレータの一例を概略的に示す図である。 データオーケストレータが実装され得る環境を示す図である。

本明細書では本発明の様々な実施形態が図示および記載されているが、そのような実施形態が例としてのみ提供されることは当業者には明らかであろう。当業者は、本発明から逸脱することなく、多数の変形、変更、および置換を思いつく場合がある。本明細書に記載された本発明の実施形態に対する様々な代替案が採用されてよいことを理解されたい。

本明細書で使用される、「自律的に制御される」、「自動運転」、「自律型」、および「無人」という用語は、乗り物を記述する際に使用されるとき、一般に、それ自体が少なくとも一部もしくはすべての運転タスクを実行し、かつ／または経路の少なくとも一部分に沿って運転環境を監視することができる乗り物を指す。自律型の乗り物は自動化された乗り物であってよい。そのような自動化された乗り物は、少なくとも部分的または完全に自動化されてよい。自律型の乗り物は、運転者または乗客からの何らかの介入または介入なしで運転するように構成されてよい。自律型の乗り物は、自律型の乗り物に乗っている人間からの介入なしに、ある地点から別の地点に移動することができる。場合によっては、自律型の乗り物は、乗り物の自動化に関する米国運輸省道路交通安全局（ＮＨＴＳＡ）の定義、たとえば、ＮＨＴＳＡ定義のレベル４（Ｌ４）「乗り物上の自動運転システム（ＡＤＳ）は、特定の状況において、それ自体ですべての運転タスクを実行し、運転環境を監視する、基本的には、すべての運転を行うことができる。人間はそのような状況において注意を払う必要はない。」、またはＮＨＴＳＡ定義のレベル５（Ｌ５）「乗り物上の自動運転システム（ＡＤＳ）は、あらゆる状況においてすべての運転を行うことができる。人間の乗員は単なる乗客であり、運転に関与する必要は決してない。」において指定された能力を備えた乗り物を指してよい。提供されたシステムおよび方法は、他の自動化レベルの乗り物に適用できることに留意されたい。たとえば、提供されたシステムまたは方法は、ＮＨＴＳＡ定義のレベル３（Ｌ３）「レベル３の車には運転者は依然として必要であるが、特定の交通条件または環境条件下で安全上重要な機能を乗り物に完全に移行することができる。それは、運転者が依然として存在し、必要な場合に介入するが、前のレベルと同じように状況を監視する必要がないことを意味する。」を満たす乗り物によって生成されたデータを管理するために使用されてよい。場合によっては、自動化された乗り物は、ＮＨＴＳＡ定義のレベル２「乗り物上の高度運転支援システム（ＡＤＡＳ）は、状況によっては、それ自体で実際にステアリングとブレーキ／加速の両方を同時に制御することができる。人間の運転者は、常に十分な注意を払い（「運転環境を監視し」）、残りの運転タスクを実行しなければならない」、またはＮＨＴＳＡ定義のレベル３「乗り物上の自動運転システム（ＡＤＳ）は、状況によっては、それ自体で運転タスクのすべての面を実行することができる。そのような状況では、ＡＤＳが人間の運転者にそうするように要求するときはいつでも、人間の運転者は制御を取り戻す準備ができていなければならない。他のすべての状況では、人間の運転者が運転タスクを実行する。」において指定された能力を備えた乗り物を指してよい。自動化された乗り物は、レベル２のＡＤＡＳを改善するためにＡＩが使用される、レベル２＋の自動運転能力を備えた乗り物を含む場合もあるが、一貫した運転者の制御が依然として必要である。自律型の乗り物データは、自動化された乗り物によって生成されたデータも含んでよい。

自律型の乗り物は、無人乗り物と呼ばれる場合がある。自律型の乗り物は、航空乗り物、陸上乗り物、または水塊を横断する乗り物であり得る。自律型の乗り物は、空中（たとえば、固定翼航空機、回転翼航空機、もしくは固定翼も回転翼ももたない航空機）、水中（たとえば、船舶もしくは潜水艦）、地上（たとえば、自動車、トラック、バス、バン、オートバイ、もしくは列車などの動力車）、地下（たとえば、地下鉄）、宇宙（たとえば、スペースプレーン、衛星、もしくはプローブ）、またはこれらの環境の任意の組合せなどの、任意の適切な環境内を移動するように構成することができる。

「少なくとも」、「より大きい」、または「以上」という用語が一連の２つ以上の数値の最初の数値の前にあるときはいつでも、「少なくとも」、「より大きい」、または「以上」という用語は、その一連の数値の中の各数値に適用される。たとえば、１、２、または３以上は、１以上、２以上、または３以上と同等である。

「しかない」、「未満」、または「以下」という用語が、一連の２つ以上の数値の最初の数値の前にあるときはいつでも、「しかない」、「未満」、または「以下」という用語は、その一連の数値の中の各数値に適用される。たとえば、３、２、または１以下は、３以下、２以下、または１以下と同等である。

本明細書で使用される「リアルタイム」という用語は、一般に、コンピュータプロセッサなどによる、１秒未満、１０分の１秒、１００分の１秒、１ミリ秒、またはそれ未満の応答時間を指す。リアルタイムはまた、第２のイベントの発生に対する第１のイベントの同時発生または実質的な同時発生を指すことができる。

本開示は、データ処理およびデータ格納を含む、データ管理および知識管理のための方法およびシステムを提供する。本開示の方法およびシステムは、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物などの様々なタイプの乗り物に適用することができる。コネクテッド乗り物は、いくつかの異なる通信技術のいずれかを使用して、運転者、道路上の他の乗り物（乗り物間［Ｖ２Ｖ］）、路側基盤（乗り物対基盤［Ｖ２Ｉ］）、および「クラウド」［Ｖ２Ｃ］と通信する乗り物を指してよい。本開示は、乗り物（たとえば、自律型の乗り物）および非乗り物のコンテキストを含む様々なコンテキストで使用され得るデータオーケストレータを提供する。本開示のデータオーケストレータは、様々なソースからのデータを管理するために、またはモノのインターネット（ＩｏＴ）プラットフォーム、サイバー物理ソフトウェアアプリケーションおよびビジネスプロセスなどの様々な用途のために、ならびにエネルギー、製造、航空宇宙、自動車、化学、医薬品、電気通信、小売、保険、医療、金融サービス、公共部門などの組織のために使用されてよい。

データ管理システム
本開示は、自律型の乗り物データまたは自動化された乗り物データなどの乗り物データを管理するためのシステムおよび方法を提供する。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造（たとえば、小規模バッチ製造および自律型の乗り物の製品化）、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。データ管理システムは、１時間当たり少なくとも約０．１テラバイト（ＴＢ）、０．５ＴＢ、１ＴＢ、２ＴＢ、３ＴＢ、４ＴＢ、５ＴＢ、またはそれ以上の規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。場合によっては、データ管理は、１時間当たり少なくとも約５０ＴＢ、６０ＴＢ、７０ＴＢ、８０ＴＢ、９０ＴＢ、１００ＴＢの規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。場合によっては、データ管理は、１時間当たり少なくとも１ギガバイト（ＧＢ）、２ＧＢ、３ＧＢ、４ＧＢ、５ＧＢ、またはそれ以上の規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。データ管理システムは、１時間当たり最大０．５ＴＢ、１ＴＢ、２ＴＢ、３ＴＢ、４ＴＢ、５ＴＢ、５０ＴＢ、６０ＴＢ、７０ＴＢ、８０ＴＢ、９０ＴＢ、１００ＴＢ、またはそれ以上のデータの任意のボリュームのデータを管理および編成することが可能であり得る。

いくつかの実施形態では、データおよび知識管理システムは、自律型の乗り物または自動化された乗り物に搭載されたデータオーケストレータと通信することができる。データオーケストレータは、乗り物データを管理することが可能であり得る。データオーケストレータはデータルータであってよい。データオーケストレータは、データおよび知識管理システムに乗り物データをインテリジェントにルーティングするように構成されてよい。データオーケストレータは、どの自律型の乗り物データまたは自律型の乗り物データのどの部分が、どのデータセンタまたはサードパーティエンティティのデータおよび知識管理システムに通信されるべきか、ならびに自律型の乗り物データのこの部分がいつ送信されるかを判断するように構成されてよい。たとえば、自律型の乗り物データの一部は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータは、自律型の乗り物が静止しているとき（次の割当て／タスクを待っている間、または保守されている間）に通信されてよい。提供されたデータ管理システムはまた、予測モデルを訓練または開発し、ならびにデータオーケストレータおよび／または自律型の乗り物スタックの構成要素もしくは自動化された乗り物スタックの構成要素にモデルを展開するように構成された予測モデル作成および管理システムを備えてよい。場合によっては、予測モデル作成および管理システムは、リモートエンティティ（たとえば、データセンタ）に存在してよい。提供されたデータ管理システムは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびＡＰＩコールを処理するように構成されたデータおよびメタデータ管理システムをさらに備えてよい。データオーケストレータ、またはデータおよび知識管理システムは、スタンドアロンシステムとして実装または提供することができる。

図１は、データオーケストレータ１００とデータセンタ１２０との間のデータフローを概略的に示す。場合によっては、データオーケストレータ１００は、たとえば、データ作成、データ洗浄、データ強化、ならびにデータセンタ、システム、およびサードパーティエンティティにわたるデータの配信を含む、データ管理プロセスを自動化するように構成されてよい。自律型の乗り物１１０から収集されたデータは、自律型の乗り物のセンサによって捕捉されたデータを含んでよい。そのようなセンサは、たとえば、レーザー画像検出および測距（Ｌｉｄａｒ）、レーダー、ソナー、ディファレンシャル全地球測位システム（ＤＧＰＳ）、慣性測定ユニット（ＩＭＵ）、ジャイロスコープ、磁力計、加速度計、超音波センサ、画像センサ（たとえば、可視光、赤外線）、熱センサ、音声センサ、振動センサ、導電率センサ、化学センサ、生物学的センサ、放射線センサ、導電率センサ、近接センサ、もしくは任意の他のタイプのセンサなどの乗り物に搭載されたセンサ、ナビゲーションシステム、またはそれらの組合せを含むことができる。自律型の乗り物から収集されたデータは、フリートデータ（たとえば、乗り物オペレーティングシステムからのデータ）、運転者データ（たとえば、運転者の気分、運転者の覚醒度、運転スタイルなど）、乗客データ（たとえば、音楽、ゲームへのアクセス、モバイルアプリケーションなどのユーザデバイスからのデータなどのユーザ体験プラットフォームからのデータ）、および様々な他のデータも含んでよい。乗り物のデータオーケストレータによって送信されたデータは、データセンタに存在するデータおよび知識管理システムによって受信される。データは、１つまたは複数のセンサからのデータストリーム（たとえば、ビデオカメラの出力、センサ融合データ）、バッチデータ、および／または個々の記録（たとえば、輸送中に乗客によって行われた購入取引、乗り物サブシステム、たとえば乗り物のエンジンの健全性を監視するシステム、もしくはタイヤの状態を監視するサブシステムによって生成された個々の記録もしくは一連の記録、乗り物上で動作するアプリケーションの１つとのユーザ対話の結果）を含んでよい。

いくつかの実施形態では、データオーケストレータ１００は、エッジインテリジェンスプラットフォームであってよい。たとえば、データオーケストレータは、データの処理および編成をエッジ（たとえば、自律型の乗り物）の近くに拡張するフォグコンピューティングまたはエッジコンピューティングの概念に基づくソフトウェアベースのソリューションであってよい。エッジコンピューティングは、サービスがインスタンス化される場所を指してよいが、フォグコンピューティングは、エンドユーザまたはエンドノードの制御におけるデバイスおよびシステム上またはその近傍（たとえば、５メートル以内もしくは１メートル以内）での通信、計算、および格納のリソースおよびサービスの分配を意味してよい。すべてのデータを離れた集中型クラウドに送信するのではなく、エッジデバイス（たとえば、自律型の乗り物、センサ）の近くに維持することにより、待ち時間が最小化され、最大のパフォーマンス、より速い応答時間、ならびにより効果的な保守および運用の戦略が可能になる。それはまた、全体的な帯域幅要件および広く分散されたネットワークを管理するコストを大幅に削減する。提供されたデータ管理システムは、データ処理の少なくとも一部分をエッジで実行することができるエッジインテリジェンスパラダイムを採用することができる。場合によっては、機械学習モデルは、クラウド上で構築および訓練され、エッジデバイスまたはエッジシステム（たとえば、ハードウェアアクセラレータ）上で実行されてよい。本開示のシステムおよび方法は、リアルタイムの現場乗り物データ編成を可能にする効率的で高度に拡張可能なエッジデータ編成プラットフォームを提供することができる。

データ管理システムのソフトウェアスタックは、エッジおよびクラウド上で動作するサービスの組合せであり得る。エッジ上で動作するソフトウェアまたはサービスは、データ編成用の予測モデルを採用することができる。クラウド上で動作するソフトウェアまたはサービスは、予測モデルを訓練、開発、および管理するための予測モデル作成および管理システム１３０を提供することができる。場合によっては、データオーケストレータは、ローカルストレージリポジトリ（たとえば、ローカル時系列データベース）へのセンサデータの取込み、データ洗浄、データ強化（たとえば、サードパーティデータを処理されたデータとマージすること）、データ整列、データ注釈付け、データタグ付け、またはデータ集約をサポートすることができる。生データは、ある時間期間（たとえば、約１、２、３、４、５、６、７、８、９、１０秒、約１、２、３、４、５、６、７、８、９、１０分、約１、２、３、４、５、６、７、８、９、１０時間など）にわたって集約されてよい。代替または追加として、生データは、データタイプまたはソースにわたって集約され、パッケージとしてリモートエンティティに送信されてよい。

データオーケストレータは、データセンタ、クラウドアプリケーション、または（たとえば、サードパーティエンティティと関連付けられた）データセンタ内に存在する任意の構成要素にわたってデータを配信することができる。データオーケストレータは、どのデータまたはデータのどの部分がどのデータセンタおよび／またはエンティティに送信されるべきか、ならびにデータのこの部分をいつ送信するかを判断することができる。たとえば、自律型の乗り物データの一部（たとえば、データまたはデータのパッケージの第１の部分）は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータ（たとえば、データまたはデータのパッケージの第２の部分）は、自律型の乗り物が静止しているとき（次の割当て／タスクを待っている間、または保守されている間）に通信されてよい。さらなる例では、データの第１の部分は、リアルタイムデータに基づいてリアルタイムフィードバックおよび制御を提供するためのフリートマネージャアプリケーションをホストするデータセンタに送信されてよく、データの第２の部分（たとえば、バッチデータ）は、バッチデータに基づいて保険適用範囲を計算するために保険会社サーバに送信されてよい。いくつかの実施形態では、データ配信またはデータ送信は、予測モデルおよび／または手作り規則に少なくとも部分的に基づいて決定されてよい。いくつかの実施形態では、データ送信は、予測モデル、手作り規則、ならびに宛先および送信プロトコルに関するデータを格納するリポジトリに基づいて開始されてよい。一例では、データオーケストレータ１００は、データ集約、および集約データをさらなる分析のためにクラウド、異なるデータセンタ、またはエンティティに送信するためのデータ公開のためのサービスをサポートすることができる。データオーケストレータおよび予測モデルに関する詳細は、本明細書で後述される。

予測モデル作成および管理システム１３０は、データオーケストレータ１００をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。この環境は、１つもしくは複数のパブリッククラウド（たとえば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）、Ａｚｕｒｅなど）、および／またはシステムの１つもしくは複数の部分がプライベートクラウドで動作し、他の部分が１つもしくは複数のパブリッククラウドで動作するハイブリッドクラウド構成で動作することができる。たとえば、予測モデル作成および管理システム１３０は、予測モデルを訓練および開発するように構成されてよい。場合によっては、訓練された予測モデルは、予測モデル更新モジュールを介してデータオーケストレータまたはエッジ基盤に展開されてよい。予測モデル更新モジュールに関する詳細は、図１５に関して記載される。場合によっては、予測モデル作成および管理システム１３０はまた、クラウドで開発された機械学習モデルを、エッジで実行することができるセンサ表現に変換することができてよい。予測モデル作成および管理システム１３０はまた、自律型の乗り物から送信されたデータを１つまたは複数のデータベースまたはクラウドストレージ１２３、１２５、１２７に取り込むことをサポートすることができる。予測モデル作成および管理システム１３０は、クラウドまたはプライベートデータセンタにおけるデータの監視または格納を含む、統合された監督および管理を可能にするアプリケーションを含んでよい。いくつかの実施形態では、予測モデル作成および管理システム１３０は、分析、センサデータ（たとえば、ビデオ）を閲覧するためのユーザインターフェース（ＵＩ）モジュールを備えるか、または分析表現を開発および展開し、データ編成アプリケーションをエッジ（たとえば、自律型の乗り物オペレーティングシステム、エッジゲートウェイ、エッジ基盤、データオーケストレータ）に展開し、予測モデル性能を監視し、予測モデルを構成するための管理ＵＩを備えてよい。予測モデル作成および管理システムはデータセンタの構成要素として示されているが、予測モデル作成および管理システムはスタンドアロンシステムであり得ることに留意されたい。

提供されたデータ管理システムは、コンテナおよび／またはマイクロサービスなどの任意の適切な技術を採用することができる。たとえば、データオーケストレータのアプリケーションは、コンテナ化されたアプリケーションであり得る。データ管理システムは、コンテナにアプリケーションまたはサービスを実装することなどの、エッジにおけるソフトウェア基盤にマイクロサービスベースのアーキテクチャを展開することができる。別の例では、クラウドアプリケーションならびに／または予測モデル作成および管理システム１３０は、マイクロサービスによって支援される管理コンソールまたはクラウド分析を提供することができる。

コンテナ技術は、（したがって、ハイパーバイザ技術とは異なり）テナントごとにＯＳカーネル全体の複製を必要とせずに、無視できるオーバーヘッドでオペレーティングシステム（ＯＳ）によって管理されるメモリ、中央処理装置（ＣＰＵ）、およびストレージのようなコンピュータサーバリソースを仮想化する。コンテナは、人気のあるＬｉｎｕｘオープンソースオペレーティングシステムの一部として開発され、ＤｏｃｋｅｒおよびＣｏｒｅＯＳのような高度管理フレームワークの可用性により、ソフトウェア開発およびデータセンタ運用（「ＤｅｖＯｐｓ」）においてかなりのけん引力を得ている。Ｋｕｂｅｒｎｅｔｅｓなどの他のコンテナ編成フレームワークも利用されてよい。Ｋｕｂｅｒｎｅｔｅｓは、複数のコンテナがホストマシン上で動作し、競合のリスクなしにリソースを共有することを可能にする「ポッド」と呼ばれる高レベル抽象化層を提供する。ポッドは、ディレクトリまたはストレージのような共有サービスを定義し、それをポッド内のすべてのコンテナに紹介するために使用することができる。（工場、倉庫、小売店、および他の施設のような物理的な場所を含む）モノのインターネット（ＩｏＴ）のユースケースにおける物理センサネットワークに非常に近いニアライン計算基盤を介してセンサデータを処理するためにソフトウェアおよび分析を消費する需要が高まっている。これらの計算ノードは、たとえば、インターネットに接続され、動作中に展開された様々な異種センサデバイスおよび制御システムにアクセスする、中型（たとえば、デュアルコアプロセッサおよび４ギガバイトのメモリ）から小型（たとえば、１ギガバイト未満のメモリを有するシングルコアプロセッサコア）までのサーバを含む。データ管理システムは、これらのエッジ計算基盤設定においてコンテナ技術をインテリジェントに展開および管理するための方法を提供する。

データセンタまたはリモートエンティティ１２０は、自律型の乗り物データおよびメタデータを格納するための１つまたは複数のリポジトリまたはクラウドストレージを備えてよい。たとえば、データセンタ１２０は、メタデータデータベース１２３、自律型の乗り物スタックデータを格納するためのクラウドデータレイク１２５、およびユーザ体験プラットフォームデータ１２７を格納するためのクラウドデータレイクを備えてよい。本明細書に記載されたユーザ体験プラットフォームは、乗り物の客室の内部で動作しているハードウェアおよび／またはソフトウェアの構成要素を備えてよい。ユーザ体験プラットフォームは、客室の環境および乗員の相互作用、たとえば客室温度、乗員当たりの娯楽の選択肢、各乗員のバイタルサイン、気分、および注意力などを管理するように構成することができる。場合によっては、メタデータデータベース１２３および／またはクラウドデータレイクは、クラウドストレージオブジェクトであってよい。

自律型の乗り物スタックは、知覚、データ融合、クラウド／ＯＴＡ、位置特定、挙動（別名運転ポリシー）、制御、および安全性などの複数の領域を、エンドツーエンド自動化を処理することができるプラットフォームに統合することができる。たとえば、自律型の乗り物スタックは、知覚（たとえば、ＡＳＩＣ、ＦＰＧＡ、ＧＰＵアクセラレータ、ＳＩＭＤメモリ、カメラ、Ｌｉｄａｒ、レーダー、ＧＰＳなどのセンサ／検出器）、位置特定および計画（たとえば、データパス処理、ＤＤＲメモリ、位置特定データセット、慣性測定、ＧＮＳＳ）、決定または挙動（たとえば、モーションエンジン、ＥＣＣメモリ、挙動モジュール、調停、予測子）、制御（たとえば、ロックステッププロセッサ、ＤＤＲメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ）、接続およびＩ／Ｏ（たとえば、ＲＦプロセッサ、ネットワークスイッチ、決定論的バス、データ記録）などの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを含んでよい。自律型の乗り物スタックデータは、上述された自律型スタックによって生成されたデータを含んでよい。ユーザ体験プラットフォームデータ１２７は、デジタルサービス（たとえば、音楽、ビデオ、またはゲームへのアクセス）、取引、および乗客商取引またはサービスなどのユーザ体験アプリケーションに関連するデータを含んでよい。たとえば、ユーザ体験プラットフォームデータは、以下に関連するデータを含んでよい。コンテンツにアクセスするサブスクリプション、たとえば、音楽ストリーミングサービス、ニュースサービス、コンシェルジュサービスなどへの年間サブスクリプション、輸送中、ならびに給油ステーション、レストラン、コーヒーショップなどで乗り物が断続的に停止するときの商品、サービス、およびコンテンツの取引ベースの購入（たとえば、エネルギー会社などの充電ステーション事業者は、コーヒーショップチェーンと提携して、乗り物に燃料を補給しながら購入する乗客にコーヒードリンクの割引を提供することができる）、ロイヤルティポイントの償還、たとえば、自動車メーカーおよびフリート事業者は、航空会社またはホテルチェーンによって使用されているのと同様のシステムを使用して自社の顧客のロイヤルティに報いることができ、これらの業界および他の業界がそのようなプログラムを使用するのとほぼ同じ方法でロイヤルティポイントを償還することができる。場合によっては、ユーザ体験プラットフォームデータ１２７は、ユーザモバイルアプリケーションによって生成されたデータなどのサードパーティパートナーデータも含んでよい。ユーザは、フリート事業者または乗客であり得る。

クラウドアプリケーション１２１、１２２は、様々なユースケースについて自律型の乗り物から送信されたデータをさらに処理または分析することができる。クラウドアプリケーションは、相手先商標製造会社（ＯＥＭ）、ホテルおよびホスピタリティ、レストランおよび食事、観光および娯楽、医療、サービス提供、および様々な他の産業などの産業における無人／運転手不要な乗り物についての様々なユースケースを可能にすることができる。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造（たとえば、小規模バッチ製造および自律型の乗り物の製品化）、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。

図２は、様々なデータセンタ、自律型の乗り物、およびエンティティにわたるデータフローの例を示す。例に示されたように、自律型の乗り物フリート（ＡＶフリート）２０１の間に、自律型の乗り物フリートを使用する消費者２０２によって生成されたデータは、データオーケストレータ２２０の助けを借りて様々なリモートエンティティに送信されてよい。様々なリモートエンティティには、たとえば、政府２１１、フリートリース会社２０９、保険会社２０７、フリートマネージャ２０５、フリート事業者２０３、デジタルサービス２１７、（たとえば、電車およびシャトル、ライドシェア、タクシー配車サービス、共有トリップまたはプライベートトリップ、徒歩、自転車、ｅスクータ、タクシーなどの）他の輸送サービス２１９、プラットフォームプロバイダ２１５、ならびに相手先商標製造会社（ＯＥＭ）２１３が含まれてよい。様々なエンティティに送信されるデータは、同じであってもなくてもよい。たとえば、（たとえば、より多くの消費者関連データまたは乗客関連データを含む）デジタルサービス２１７に送信されるデータは、（たとえば、より多くのＡＶフリートデータまたはセンサデータを含む）フリート事業者２０３に送信されるデータとは異なってよい。データは、異なる時点および／または頻度で様々なエンティティに送信されてよい。たとえば、センサデータストリームは、リアルタイムで、または乗り物が動いている間にフリートマネージャ２０５またはプラットフォームプロバイダ２１５に送信されてよいが、バッチデータを含むメッセージパッケージは、乗り物が停止している間またはより低い頻度で政府２１１またはフリートリース会社２０９に送信されてよい。いくつかの実施形態では、アプリケーションリポジトリまたはアプリケーションテーブルは、乗り物／乗り物アプリケーションとリモートエンティティ／クラウドアプリケーションとの間のデータ送信に関連する情報を格納するために使用されてよい。アプリケーションテーブルは、本明細書の他の箇所に記載されたデータオーケストレータの構成要素であってよい。場合によっては、クラウドまたはリモートエンティティ上で動作する１つまたは複数のクラウドアプリケーション（たとえば、クラウドアプリケーション１２１、１２２またはテナントアプリケーション）は、アプリケーションテーブルに登録することができる。クラウドアプリケーションは、自律型の乗り物または自律型の乗り物のオペレーティングシステム上で動作する１つまたは複数のアプリケーション（たとえば、エッジアプリケーション、ローカルアプリケーション）にリンクされてよい。アプリケーションテーブルは、クラウドアプリケーションが関心をもつ特定の乗り物データ（たとえば、データのタイプ、送信されるデータへのポインタ）、特定の乗り物データを生成するアプリケーション（たとえば、自律型の乗り物上で動作するアプリケーション）、特定のデータが送信されるアプリケーションおよび／またはデータセンタ（たとえば、クラウドアプリケーション１２１、１２２、サーバ上のアプリケーションの位置）、データ送信方式またはプロトコル（たとえば、遅延時間または頻度などの送信タイミング、通信プロトコル、送信に使用される圧縮または暗号化の方法）、ならびに様々な他のもの（たとえば、データが送信される前のプライバシーに関する規制規則）に関連するデータを格納することができる。

データオーケストレータ２２０はまた、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物の一部であってよい。図２０は、データオーケストレータが実装され得る環境を示す図である。乗り物２００１－１、２００１－２は、私有であってもよく、フリートの一部であってもよい。乗り物は、乗客輸送、長距離または短距離の物流、ラストマイル配送（たとえば、５マイル、４マイル、３マイル、２マイル、または１マイル以内の配送）に使用されてもよく、混合使用（たとえば、乗客およびパッケージ）を有してもよい。上記のデータは、任意の他の適切なデータ構造として格納できることに留意されたい。場合によっては、アプリケーションテーブルは、ローカルストレージに格納され、データオーケストレータによって管理されてよい。追加または代替として、アプリケーションテーブルは、データオーケストレータと予測モデル作成および管理システムの両方によって管理されてよい。

場合によっては、クラウドまたはリモートエンティティ（たとえば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）およびＡｚｕｒｅなどのパブリッククラウド、またはプライベートクラウド）上で動作するアプリケーションは、パブリッシュ／サブスクライブ方式を介して特定の乗り物のデータオーケストレータ（または乗り物のフリートのデータオーケストレータ）のアプリケーションテーブルに登録することができる。場合によっては、フォグ／エッジサーバまたはリモートエンティティ上で動作するアプリケーションは、パブリッシュ／サブスクライブ方式を介してアプリケーションテーブルに登録することができる。いくつかの実施形態では、登録アプリケーションは、そこからデータを受信する必要がある乗り物ＩＤおよび／またはそこからデータを受信する必要がある対応する乗り物上で動作する特定の（１つもしくは複数の）乗り物アプリケーションを指定することができる。

いくつかの実施形態では、登録アプリケーションによって生成されたデータ要求は、クラウドのサブスクリプションモジュールによって編成および管理されてよく、データ要求は、メッセージを介して１つまたは複数の関連の乗り物にオーバージエア（ＯＴＡ）で通信されてよい。メッセージは、１つまたは複数の乗り物アプリケーションに対する１つまたは複数の要求を含んでよい。場合によっては、乗り物によって受信されたメッセージに含まれる要求がアプリケーションテーブルに登録されてよい。サブスクリプションモジュールは、データ要求または登録アプリケーションの要求を管理するように構成されてよい。たとえば、サブスクリプションモジュールは、複数の登録アプリケーションの要求を集約することが可能であってよく、それにより、有益なことに通信帯域幅消費が削減される。たとえば、同じ乗り物アプリケーション（たとえば、くぼみ検出器アプリケーション）からのデータを要求することに関する複数の登録アプリケーションの要求が集約されてよい。他の例では、特定の乗り物グループ（たとえば、２０１０～２０１５年の間に製造されたすべてのＢＭＷ Ｍｏｄｅｌ ３の乗り物）上で動作する異なる乗り物アプリケーションからのデータを要求することに関する複数の登録アプリケーションの要求が集約され、単一のメッセージにパッケージ化されてよい。

図３はアプリケーションテーブル３００の一例を示す。アプリケーションテーブル３００は、データオーケストレータ（たとえば、図４を参照）の一部であってよい。アプリケーションテーブル３００の項目は、上述されたデータを格納することができる。たとえば、アプリケーションテーブルの行は、自律型の乗り物内で動作するアプリケーション（すなわち、乗り物アプリケーション）の名前（たとえば、くぼみ検出器）を含んでよい。アプリケーションは、リモートエンティティ、データセンタ、またはクラウドアプリケーションに通信されるデータを生成することができる。アプリケーションテーブルの行はまた、特定のデータセンタ内で動作する１つまたは複数のアプリケーションへの送信に新しいデータが利用可能であるかどうかを示すフラグ（たとえば、送信フラグ）、データが生成された乗り物の識別子（たとえば、乗り物ＩＤ）、クラウドアプリケーション（たとえば、アプリケーション名、クラウド上のアプリケーションの位置）またはこのアプリケーションからのデータを要求するデータセンタおよびデータが送信される場所（たとえば、ａｐｐ＿ｎａｍｅ、ｌｏｃ）、送信されるデータのタイプ（たとえば、ビデオストリーム、ＣＡＮデータ）、乗り物から送信される実際のデータ（たとえば、Ｓｔｒｅａｍ１）へのポインタ、送信時間（たとえば、送信タイミング遅延）、圧縮タイプ（たとえば、可逆）、暗号化タイプ（たとえば、ＲＳＡ）、および規制規則を含んでよい。図示されたアプリケーションテーブルは単なる例であることに留意されたい。データ送信に関連する任意の他のデータをアプリケーションテーブルに含めることができる。

場合によっては、１つまたは複数の項目がローカル／乗り物アプリケーションによって設定されてよい。たとえば、要求されたデータが送信に利用可能であるかどうかを示す送信フラグは、ローカル／乗り物アプリケーションによって設定されてよい。場合によっては、１つまたは複数の項目がデータオーケストレータによって設定されてよい。たとえば、乗り物ＩＤまたは規制規則は、データオーケストレータによって設定されてよい。

いくつかの実施形態では、クラウドデータレイクは、フリート内の各乗り物のまわりのデータを編成することができる。たとえば、特定のＡＶスタックおよび特定のユーザ体験プラットフォームからのデータは、対応する乗り物（たとえば、乗り物ＩＤ）と関連して編成および格納されてよい。上述されたように、乗り物はクラウドデータレイクに登録することができ、その乗り物ＩＤ、それが使用する様々なデータ取得アプリケーション、各データ取得アプリケーションによってアクセスされるセンサ、各センサの能力（たとえば、センサは５秒ごとにデータを捕捉することができるか、またはセンサは７２０ｐ解像度のビデオを捕捉することができる）、および他のものによって識別されてよい。場合によっては、ユーザ、ネットワーク内のエンティティ、またはシステムに登録された当事者は、乗り物ＩＤを使用して、乗り物、製造元、モデル、および乗り物の製造年などの追加情報を自動的に導出することを許可されてよい。場合によっては、乗り物は、データ管理システムに登録するフリート（たとえば、企業フリート、レンタカー会社のフリート、特定のＯＥＭによって製造された個人所有の乗り物の集合）の一部であり得る。

データオーケストレータ
データオーケストレータは、自律型の乗り物に対してローカルであってもよく、自律型の乗り物に搭載されてもよい。いくつかの例では、データオーケストレータは自律型の乗り物上に存在する。上述されたように、データオーケストレータはまた、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物の一部であってよい。提供されたデータ管理システムは、データ編成がエッジまたはエッジゲートウェイで実行されるエッジインテリジェンスパラダイムを採用することができる。場合によっては、１つまたは複数の機械学習モデルは、クラウド／データセンタ上で構築および訓練され、乗り物またはエッジシステム（たとえば、ハードウェアアクセラレータ）上で実行されてよい。

場合によっては、データオーケストレータは、エッジコンピューティングプラットフォームまたはエッジ基盤／システムを部分的に使用して実装されてよい。エッジコンピューティングプラットフォームは、ソフトウェア、ハードウェア、ファームウェア、組込み型ハードウェア、スタンドアロンハードウェア、特定用途向けハードウェア、またはこれらの任意の組合せに実装されてよい。本明細書に記載されたデータオーケストレータおよびその構成要素、エッジコンピューティングプラットフォーム、ならびに技法は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組合せで実現されてよい。これらのシステム、デバイス、および技法は、ストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータおよび命令を受信し、それらにデータおよび命令を送信するように結合された、専用または汎用であり得る少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能および／または解釈可能な１つまたは複数のコンピュータプログラム内の実装形態を含んでよい。（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られる）これらのコンピュータプログラムは、プログラマブルプロセッサ用の機械命令を含んでよく、高水準手続き型および／もしくはオブジェクト指向のプログラミング言語、ならびに／またはアセンブリ／機械言語で実装されてよい。本明細書で使用される「機械可読媒体」および「コンピュータ可読媒体」という用語は、プログラマブルプロセッサに機械命令および／またはデータを提供するために使用される任意のコンピュータプログラム製品、装置、および／またはデバイス（磁気ディスク、光ディスク、メモリ、もしくはプログラマブルロジックデバイス（ＰＬＤ）など）を指す。

いくつかの実施形態では、提供されたデータオーケストレータは、どの自律型の乗り物データまたは自律型の乗り物データのどの部分が、どのデータセンタまたはサードパーティエンティティに通信されるべきか、およびデータのこの部分がいつ送信されるかを判断することが可能であってよい。データ送信またはデータ配信は、アプリケーションテーブル、規則、および予測モデルを使用して決定されてよい。予測モデルは機械学習ベースのモデルであってよい。

機械学習は、データ内のパターンの発見を自動化し、構築されたモデルを使用して様々なアプリケーションでインテリジェント予測を行う際の重要な計算構成モデルとして進化している。機械学習アルゴリズムなどの人工知能は、データ編成のための予測モデルを訓練するために使用されてよい。機械学習アルゴリズムは、たとえばニューラルネットワークであってよい。ニューラルネットワークの例には、深層ニューラルネットワーク、畳み込みニューラルネットワーク（ＣＮＮ）、および再帰型ニューラルネットワーク（ＲＮＮ）が含まれる。機械学習アルゴリズムは、サポートベクトルマシン（ＳＶＭ）、単純ベイズ分類、線形回帰、分位回帰、ロジスティック回帰、ランダムフォレスト、ニューラルネットワーク、ＣＮＮ、ＲＮＮ、勾配ブースト分類器もしくはリプレッサ、または別の教師付きもしくは教師なしの機械学習アルゴリズムのうちの１つまたは複数を含んでよい。

図４は、１つまたは複数のリモートエンティティ４２０、４３０と通信するデータオーケストレータ４１０の一例を概略的に示す。いくつかの実施形態では、データオーケストレータ４１０は、決定エンジン４１３およびデータ通信モジュール４１５を備えてよい。場合によっては、データオーケストレータ４１０は、データ処理モジュール４１１を備えていてもよい。場合によっては、データ処理モジュール４１１は、ストリームデータおよびバッチデータの前処理を実現することができる。代替の実施形態では、データ処理モジュール４１１は、データおよびメタデータ管理モジュール４２５の構成要素など、クラウド４２０上に存在してよい。データオーケストレータ４１０は、アプリケーションリポジトリ４０５および／または予測モデル知識ベース４０７などの１つまたは複数のローカルデータベースに結合されてもよく、それらを有してもよい。アプリケーションリポジトリ４０５は、上述されたアプリケーションテーブルを格納することができる。予測モデル知識ベース４０５は、データ送信（方式）を決定するための機械学習モデルおよび／または手作り規則を格納するように構成されてよい。データ送信方式は、どの自律型の乗り物データがどのデータセンタまたはサードパーティエンティティに通信されるべきか、およびそのようなデータがいつ送信されるかを指定することができる。予測モデル知識ベース４０５は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。たとえば、予測モデル知識ベース４０５は、乗り物の自律移動に使用されるモデル、乗り物の（１つもしくは複数の）客室の個別化および（１つもしくは複数の）客室内部で実行される他の機能に使用されるモデル、ならびに／またはフリートの安全で最適化された動作に使用されるモデルを格納することができる。

データオーケストレータ４１０は、予測モデル管理モジュール４２１と通信することができる。予測モデル管理モジュール４２１は、図１に記載された予測モデル作成および管理システム１３０と同じであり得る。予測モデル管理モジュール４２１は、データセンタ、クラウド、サーバなどのリモートエンティティ４２０上に存在してよい。場合によっては、予測モデル管理モジュール４２１は、ネットワークを介してデータオーケストレータ４１０をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。場合によっては、予測モデル管理モジュール４２１はスタンドアロンシステムである。場合によっては、予測モデル管理モジュール４２１はデータセンタの構成要素であってよく、データセンタは、自律型の乗り物データを利用する１つまたは複数のアプリケーション４２３をホストすることができる。

前述のアプリケーションリポジトリ４０５は、上述されたアプリケーションテーブルと同じであり得るか、またはアプリケーションテーブルを含むことができる。

予測モデル知識ベース４０７は、機械学習モデルおよび／または手作り規則を格納することができる。知識ベースの環境では、関連する人間の専門知識と結合された情報の可用性および活用は、プロセス、実装、および利用効率を改善するための重要な構成要素である。知識ベースは、インターネットアクセスまたは他の関連技術を用いて広範囲の場所からアクセスすることができる複数のデータソース内の特定の主題に関する大量の情報を提供する。

システムのアプリケーションリポジトリ４０５、予測モデル知識ベース４０７、１つまたは複数のローカルデータベース、メタデータデータベース４２７、およびクラウドデータベース４２９は、任意の適切なデータベース技法を利用することができる。たとえば、構造化照会言語（ＳＱＬ）または「ＮｏＳＱＬ」データベースは、フリートデータ、乗客データ、履歴データ、予測モデルまたはアルゴリズムを格納するために利用されてよい。データベースのうちのいくつかは、配列、ハッシュ、（リンク）リスト、構造体、構造化テキストファイル（たとえば、ＸＭＬ）、テーブル、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、ＮＯＳＱＬなどの様々な標準データ構造を使用して実装することができる。そのようなデータ構造は、メモリおよび／または（構造化）ファイルに記憶されてよい。別の代替案では、オブジェクト指向データベースが使用されてよい。オブジェクトデータベースは、共通の属性によって一緒にグループ化および／またはリンクされたいくつかのオブジェクト集合を含むことができ、それらは、いくつかの共通の属性によって他のオブジェクト集合に関連する場合がある。オブジェクト指向データベースは、オブジェクトが単なるデータではなく、所与のオブジェクト内にカプセル化された他のタイプの機能を有することができることを除いて、リレーショナルデータベースと同様に機能する。いくつかの実施形態では、データベースは、ノード、エッジ、およびプロパティを有するセマンティッククエリのためのグラフ構造を使用して、データを表現および格納するグラフデータベースを含んでよい。本発明のデータベースがデータ構造として実装される場合、本発明のデータベースの使用は、本発明の構成要素などの別の構成要素に統合されてよい。また、データベースは、データ構造、オブジェクト、およびリレーショナル構造の混合物として実装されてよい。データベースは、標準的なデータ処理技法を介して、様々な形態で統合および／または分散されてよい。データベースの一部、たとえば、テーブルは、エクスポートおよび／またはインポートされ、したがって、分散化および／または統合されてよい。

いくつかの実施形態では、データ管理システムは、高速かつ効率的なデータ検索、クエリ、および配信のためのデータベースを構築することができる。たとえば、データ管理システムは、データを抽出、変換、およびロード（ＥＴＬ）するようにカスタマイズされたアルゴリズムを提供することができる。いくつかの実施形態では、データ管理システムは、他のデータ構造を使用することと比較して、大規模データベースに適合し、容易に拡張可能であり、クエリおよびデータ検索において効率的であるか、またはメモリ要件を削減した効率的なデータベースモデルを提供するために、独自のデータベースアーキテクチャまたはデータ構造を使用してデータベースを構築することができる。たとえば、モデルツリーは、モデルの異なるバージョンを提示するノードと、モデルの目標、性能特性、および様々な他のものを表すノードパラメータとを有するツリーデータ構造を使用して格納されてよい。

いくつかの実施形態では、データオーケストレータは、多層データアーキテクチャに適用されてよい。図１８は多層データアーキテクチャ１８００を概略的に示す。図示された例では、データオーケストレータは、上述されたフォグコンピューティングまたはエッジコンピューティングの概念に基づくソフトウェアベースのソリューションであってよい。場合によっては、多層データアーキテクチャは、乗り物層（たとえば、乗り物内データ１８１０）、フォグ層（たとえば、フォグ／エッジデータ１８２０）、およびクラウド層（たとえば、クラウドデータ１８３０）を備えてよい。多層データアーキテクチャは任意の数の層を備えてよい。たとえば、フォグ層は１つまたは複数の層を備えてよい。乗り物層にあるデータは、ユーザ体験プラットフォーム４０１および／または乗り物スタック４０３、乗り物に搭載されたセンサ、ならびに本明細書の他の箇所に記載された様々な他のソースによって生成された乗り物内データ１８１０を含んでよい。乗り物層にあるデータは上述された自律型の乗り物データと同じであってよい。フォグ層にあるデータ（たとえば、フォグ／エッジデータ１８２０）は、データオーケストレータによって生成、管理、および直接アクセスされてよい。フォグ／エッジデータ１８２０は、データ処理モジュール４１１によって処理された後のデータを含んでよい。データ処理モジュール４１１は、ローカルストレージリポジトリ（たとえば、ローカル時系列データベース）へのセンサデータの取込み、データ洗浄、データ強化（たとえば、メタデータでデータを装飾すること）、データ整列、データ注釈付け、データタグ付け、データ集約、および様々な他のデータ処理をサポートすることができる。フォグ／エッジデータ１８２０はまた、送信方式に従ってクラウドに送信される中間データを含んでよい。

データオーケストレータは、どの乗り物データまたは乗り物データのどの部分が乗り物内データベース内に留まるか、フォグ層データベース（たとえば、フォグ／エッジデータベース）に移動／送信されるべきか、およびどのフォグ／エッジデータまたはフォグ／エッジデータのどの部分がどのデータセンタまたはサードパーティエンティティに通信されるべきか、データのこの部分がいつどの頻度で送信されるかを判断するように構成されるか、または判断することが可能であってよい。場合によっては、エッジ／フォグデータベースにオフロードまたは移動したデータは、格納効率を向上させるために、乗り物内データベースから削除されてよい。あるいは、乗り物内データベース内のデータは、エッジ／フォグデータベースにオフロードされた後、所定の時間期間の間保存されてよい。

図１９は、乗り物層とフォグ層との間、およびフォグ層とクラウド層との間のデータ送信を管理するためのデータオーケストレータ１９１０の一例を概略的に示す。複数の層間のデータ送信またはデータ配信は、アプリケーションテーブル、規則、および予測モデルを使用して決定されてよい。予測モデルは、上述された機械学習ベースのモデルであってよい。

データオーケストレータ１９１０は、上述されたデータオーケストレータ４１０と同じであり得る。たとえば、データオーケストレータ１９１０は、決定エンジン１９１３およびデータ通信モジュール１９１５を備えてよい。場合によっては、データオーケストレータ１９１０は、データ処理モジュール（図示せず）を備えていてもよい。場合によっては、データ処理モジュールは、乗り物内データベース１９２０から送信されたストリームデータおよびバッチデータの前処理を実現することができる。乗り物内データベース１９２０は、乗り物に搭載され、乗り物データ（たとえば、乗り物内データ１８１０）を格納することができる。データオーケストレータは、乗り物内データベース１９２０とフォグ／エッジデータベース１９３０との間、およびフォグ／エッジデータベース１９３０とクラウドデータベースとの間のデータ送信を管理することができる。

データオーケストレータ１９１０は、上述されたアプリケーションリポジトリ４０５および／または予測モデル知識ベース４０７などの１つまたは複数のローカルデータベースに結合されてもよく、それらを有してもよい。アプリケーションリポジトリ４０５は、上述されたアプリケーションテーブルを格納することができる。予測モデル知識ベース４０５は、データ送信（方式）を決定するための機械学習モデルおよび／または手作り規則を格納するように構成されてよい。データ送信方式は、どの乗り物データまたは乗り物データのどの部分が乗り物内データベース１９２０に留まるか、フォグ層データベース（たとえば、フォグ／エッジデータベース１９３０）に移動／送信されるべきか、ならびにそのようなデータがいつおよび／またはどの頻度で送信されるかを指定することができる。データ送信方式はまた、どのフォグ／エッジデータまたはフォグ／エッジデータのどの部分がどのデータセンタまたはサードパーティエンティティに通信されるべきか、データのこの部分がいつどの頻度で送信されるかを指定することができる。予測モデル知識ベース４０５は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。場合によっては、予測モデル知識ベース４０５は、乗り物の自律移動に使用されるモデル、乗り物の（１つもしくは複数の）客室の個別化および（１つもしくは複数の）客室内部で実行される他の機能に使用されるモデル、ならびに／またはフリートの安全で最適化された動作に使用されるモデルを格納することができるシステムの知識ベースと同じでなくてもよく、同じである必要もない。

図５は予測モデル知識ベース５００の一例を示す。いくつかの実施形態では、予測モデル知識ベース５００は、自動車オントロジー５０１および１つまたは複数のモデルツリー５０３を含んでよい。いくつかの実施形態では、予測モデル知識ベースは、手作り規則と機械学習ベースの予測モデルの両方を含んでよい。手作り規則および機械学習ベースの予測モデルは、データ送信を規制する規則またはプロトコルを個別にまたはまとめて決定することができる。たとえば、規則は、所与のデータの集約（たとえば、Ｍｅｓｓａｇｅ＿ｐａｃｋａｇｅ）が送信されるべきアプリケーションおよび／またはデータセンタ、送信されるべきデータの集約、データ送信方式（たとえば、遅延時間または頻度などの送信タイミング、通信プロトコル、送信に使用される圧縮または暗号化の方法）、および様々な他のもの（たとえば、データが送信される前のプライバシーに関する規制規則）を指定することができる。

手作り規則は、外部ソースからインポートされるか、または１人もしくは複数のユーザによって定義されてよい（たとえば、作り規則はユーザ定義規則であってよい）。場合によっては、手作り規則は、乗り物からのデータを要求するリモートアプリケーションによって提供されてよい。場合によっては、データ送信方式は、リモートアプリケーションからの要求に基づいて決定されてよい。場合によっては、要求は、リモートサードパーティアプリケーション（たとえば、アプリケーション４２３、４３０）から中間構成要素（たとえば、相手先商標製造会社（ＯＥＭ））に送信される要求であってよい。たとえば、保険アプリケーションは、運転者が支払っている保険料と比較して運転者が過度に運転している可能性があるかどうかを理解し、新しい保険商品を作成し、安全機能のために運転者に割引を提供し、リスクを評価し、事故現場管理、最初の紛失通知、請求プロセスの強化などの目的で、所定の頻度（たとえば、１週間、２週間、１ヶ月、２ヶ月など）で乗り物に関連付けられたＯＥＭシステムからの特定のタイプのデータ（たとえば、ＯＥＭ組込みデバイスによって収集されたデータ）を要求することができる。

要求は、アプリケーションによって必要とされるデータのタイプ、データが必要とされる頻度、そのようなタイプのデータが送信される時間期間に関する情報、または他の情報を含んでよい。状況によっては、データ送信がまれであるか、または送信されるデータ量が比較的少ないとき、データ送信方式は、機械学習モデルを使用して作成され得る送信方式などのインテリジェント送信方式を使用せずに、前述の要求に基づいて生成されてよい。たとえば、要求アプリケーション（たとえば、保険アプリケーション）は、対象乗り物（または乗り物のグループ）に関連付けられたＯＥＭシステムに、対象乗り物から必要とされるデータのタイプおよびそのようなデータの頻度を示す要求を送信することができる。場合によっては、要求は乗り物のグループを指定することができる。たとえば、要求は、特定のモデル（たとえば、Ａｕｄｉ Ａ８）、年式（たとえば、２０１７年）、特定の運転自動化機能を有するモデル（たとえば、車線変更モニタ付きのＡ８）などを指定することができる。ＯＥＭシステムは、それぞれの対象乗り物のデータオーケストレータに要求を渡す（たとえば、要求メッセージを送信して要求を中継する）ことができる。要求を受信すると、データオーケストレータは、要求をキューにプッシュし、要求の受信を確認応答するためにＯＥＭシステムに応答メッセージを送り返すことができる。次いで、ＯＥＭシステムは、要求が記録されたことを示すメッセージを要求アプリケーションに送信することができる。

次に、データオーケストレータは、要求に含まれる情報に基づいて要求されたデータを送信することができる。データオーケストレータは、要求されたデータを要求アプリケーションに直接送信することができる。そのような場合、データオーケストレータからリモートアプリケーション（たとえば、要求アプリケーション）に送信されるデータに関連する情報は、中間エンティティ（たとえば、ＯＥＭシステム）を介して通信されてよい。たとえば、要求／応答メッセージを渡すことに加えて、ＯＥＭシステム／アプリケーションは、送信周期が完了したときに（たとえば、データオーケストレータから完了メッセージを受信すると）、キューから送信要求を削除するようにデータオーケストレータに指示するメッセージをデータオーケストレータに送信することができる。次いで、データオーケストレータは、キューから項目を削除し、項目が削除されたことを示すメッセージをＯＥＭシステムに送信することができる。ＯＥＭシステムは、要求が完了したことを示すメッセージを要求アプリケーションに送信することができる。

予測モデル知識ベース５００は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。たとえば、予測モデル知識ベース５００は、乗り物の自律移動に使用されるモデル、（１つもしくは複数の）客室の個別化ならびに乗り物および／もしくは乗り物の（１つもしくは複数の）客室内部で実行される他の機能に使用されるモデル、ならびに／またはフリートの安全で最適化された動作に使用されるモデルを格納することができる。予測モデル知識ベース５００に格納されたモデルは、データオーケストレータによって使用される予測モデル、自律型の乗り物スタックによって使用されている予測モデル、ユーザ体験プラットフォームまたはフリート管理システムによって使用されるモデルを含んでよい。あるいは、自律型の乗り物スタックによって使用されている予測モデル、およびユーザ体験プラットフォームによって使用されるモデルは、それぞれの自律型の乗り物スタックまたはユーザ体験プラットフォームによって別々に管理される予測モデル知識ベースに格納されてよい。

自動車オントロジー５０１は、一人もしくは複数の個人、組織によって手動で開発することができるか、外部のシステムもしくはリソースからインポートすることができるか、またはユーザと協働する機械学習システムを使用して部分的に学習する（たとえば、自然言語テキストから自動車用語を抽出する）ことができる。場合によっては、自動車オントロジーの一部分はモデルツリーからのデータに基づいてよい。たとえば、モデルの目標および／または洞察の記述はモデルツリーのノードに格納されてよいが、目標および／または洞察の記述は自動車オントロジーの一部であってもよい。

予測モデル知識ベース５００は、他のオントロジーまたはモデルを格納することができる。場合によっては、シナリオメタデータは、次いでデータベースから適切な乗り物データを検索するために使用される特定のメタデータを使用してシナリオの特性を指定するために作成されてよい。予測モデル知識ベースは、新しいシナリオを作成するために、ならびに様々なレベルの詳細でシナリオを作成するために使用することができる階層シナリオオントロジーを含んでよい。たとえば、より高いレベルの詳細（すなわち、シナリオに関するより高いレベルの情報）で記述されたシナリオは、低忠実度シミュレーションまたは予測モデルを作成するために使用されてよいが、より低いレベルの詳細（すなわち、シナリオに関するより詳細な下位レベルの情報）で記述された同じシナリオは、高忠実度シミュレーションまたは予測モデルを作成するために使用されてよい。

１つまたは複数のモデルツリー５０３はツリー構造の集合であってよい。ツリー構造は１つまたは複数のノード５０７を含んでよく、各ノードは予測モデルの特性および予測モデルを生成するために使用されるデータ（たとえば、訓練データ、試験データ）へのポインタを含む。実際のデータ（たとえば、訓練データ、試験データ）は、クラウドデータベース４２９に格納されてよい。クラウドデータベース４２９は、クラウドデータレイク１２５、１２７と同じであり得るか、またはクラウドデータレイク１２５、１２７のいずれかまたは両方を含むことができる。所与のモデルツリー内のノードの階層は、特定の予測モデルのバージョンおよびモデル間の関係を表すことができる。予測モデルの特性には、たとえば、予測モデルの目標／機能、モデル性能特性、および様々な他の特性が含まれてよい。ノード５０７はまた、モデルパラメータ（たとえば、重み、ハイパーパラメータなど）、モデルパラメータに関するメタデータ、モデルの性能統計、またはモデルアーキテクチャ（たとえば、層の数、層内のノードの数、ＣＮＮ、ＲＮＮ）を格納することができる。場合によっては、ノード５０７は、モデルを実行するために必要な（１つまたは複数の）計算リソース（たとえば、１つのグラフィック処理装置（ＧＰＵ）、２つのＧＰＵ、３つのＣＰＵなど）に関する情報をさらに含んでよい。ノードは、上述されたデータのすべてまたは任意の組合せを含んでよい。

場合によっては、様々な予測モデルは異なるモデルツリー構造を使用して格納されてよい。知識ベースは、たとえば、予測モデルが使用されている場所に応じて異なるモデルツリー構造を有してよい。たとえば、ユーザ体験プラットフォームによって使用される予測モデルを格納するためのモデルツリー構造は、データオーケストレータによって使用される予測モデルを格納するモデルツリー構造とは異なってよい。

モデルツリーは動的であってよい。たとえば、新しいノードは、モデルの元のアーキテクチャに対する変更、モデルの性能特性に対する変更、または訓練データもしくは試験データに対する変更に応答して作成されてよい。

場合によっては、予測モデル知識ベースは手作り規則を格納してもよい。手作り規則は、１人もしくは複数の個人、組織によって手動で開発することができるか、または外部のシステムもしくはリソースからインポートすることができる。手作り規則および予測モデルは、別々に、順番に、または同時に適用されてよい。

下記は、図３に記載されたアプリケーションテーブルによるデータ送信に関する規則の一例を示す。

Ｐｏｔｈｏｌｅ＿Ｄｅｔｅｃｔｏｒ＿ＡｐｐのＴｒａｎｓｍｉｓｓｉｏｎ＿Ｆｌａｇがセットされている場合、
データが送信されなければならないときを決定し、
Ｔｒａｎｓｍｉｓｓｉｏｎ＿Ｆｌａｇ＝ＳＥＴを有するＶｅｈｉｃｌｅ＿ＩＤごとに、
乗り物からビデオストリームを受信し、
すべての適用可能な規制規則を適用し、
適用可能な規制規則を適用した後に生じるデータセットを暗号化してＥｎｒｙｐｔｅｄ＿Ｄａｔａ＿Ｆｉｌｅを作成し、
Ｅｎｒｙｐｔｅｄ＿Ｄａｔａ＿Ｆｉｌｅを圧縮してＣｏｍｐｒｅｓｓｅｄ＿Ｄａｔａ＿Ｆｉｌｅを作成し、
［Ｃｏｍｐｒｅｓｓｅｄ＿Ｄａｔａ＿Ｆｉｌｅ，Ｆｉｌｅ＿Ｓｉｚｅ，Ｔｒａｎｓｍｉｓｓｉｏｎ＿Ｄｅｌａｙ，Ｄａｔａ＿Ｃｅｎｔｅｒ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ］から構成されるＭｅｓｓａｇｅ＿Ｐａｃｋａｇｅを作成し、
Ｃｏｍｍｕｎｉｃａｔｉｏｎ－ＭｏｄｕｌｅキューにＭｅｓｓａｇｅ＿Ｐａｃｋａｇｅを送信する
いくつかの実施形態では、データ送信方式は、データがどのように送信されるかを指定することもできる。たとえば、データ送信方式は、送信に使用される圧縮方法（たとえば、可逆圧縮アルゴリズム、非可逆圧縮アルゴリズム、符号化など）、または暗号化方法（たとえば、ＲＳＡ、トリプルＤＥＳ、Ｂｌｏｗｆｉｓｈ、Ｔｗｏｆｉｓｈ、ＡＥＳなど）を指定することができる。場合によっては、データ圧縮方法および／または暗号化方法は、規則に基づいて送信のために決定されてよい。たとえば、規則は、所与のタイプのデータ、データを使用するアプリケーション、データの宛先などに従って圧縮方法および／または暗号化方法を決定することができる。データ圧縮方法および／または暗号化方法を決定するための規則は、上述された予測モデル知識ベースなどのデータオーケストレータがアクセス可能なデータベースに格納されてよい。場合によっては、データ圧縮方法および／または暗号化方法を決定するための規則は、データ送信を決定するための規則の一部であってよい。たとえば、暗号化方法または圧縮方法を決定するためのルールセットは、データの送信方式を決定するために（たとえば、ルールセット識別子によって）呼び出されてよい。

圧縮方法および／または暗号化方法を決定するための規則は、手作り規則であってよい。たとえば、データのタイプ、アプリケーションに関連するデータ、データの宛先などを指定する送信要求を受信すると、圧縮方法および／または暗号化方法に関する所定の規則または手作り規則が適用されてよい。そのような手作り規則は、上述された予測モデル知識ベースなどのデータオーケストレータがアクセス可能なデータベースに格納されてよい。場合によっては、圧縮方法および／または暗号化方法は、機械学習アルゴリズムで訓練されたモデルによって決定されてよい。たとえば、データ圧縮または暗号化のための所定のルールセットが利用できない（たとえば、ルールセット識別子が利用できない、データセットのタイプが今までにないなどの）とき、訓練されたモデルは、送信されるべきデータのセットに適用され、データのセットを圧縮または暗号化するための規則を生成することができる。場合によっては、訓練されたモデルによって生成されたルールセットは、将来のデータ送信（方式）のために予測モデル知識ベースに格納されてよい。

再び図４を参照すると、データ処理モジュール４１１は、ローカルストレージリポジトリ（たとえば、ローカル時系列データベース）へのセンサデータの取込み、データ洗浄、データ強化（たとえば、メタデータでデータを装飾すること）、データ整列、データ注釈付け、データタグ付け、データ集約、および様々な他のデータ処理をサポートすることができる。ユーザ体験プラットフォーム４０１および／または乗り物スタック４０３、乗り物に搭載されたセンサ、ならびに本明細書の他の箇所に記載された様々な他のソースからのデータは、データ処理モジュールによって取り込まれ、処理されてよい。たとえば、データ処理モジュールは、１つまたは複数のプロトコル（たとえば、ＭＱ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ、ＯＰＣ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ、Ｍｏｄｂｕｓ、およびＤＤＳ）を介してセンサからデータを収集するか、または取り込むことができる。センサによって提供または出力されるデータは、バイナリデータストリームであってよい。センサからデータ処理モジュールへのこのデータの送信または配信は、プッシュ方法またはプル方法であり得る。場合によっては、データ処理モジュールは、生のバイナリデータを（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎなどの）消費可能なデータフォーマットに復号するか、または追加の必要かつ有用なメタデータとマージすることにより、センサからの入力データを強化することができる。いくつかの実施形態では、メタデータは、センサデータを捕捉するセンサ（たとえば、ＧＰＳ、Ｌｉｄａｒ、カメラなど）、データに対する前処理（たとえば、時系列の整列および作成）、ならびに特定のユースケースまたはアプリケーション（たとえば、歩行者の回避、パターン認識、障害物の回避など）用のデータに対して動作する様々なアプリケーションおよび／または予測モデルに関連してよい。あるいは、そのようなデータ処理は、クラウド上のアプリケーションによって実行されてよい。たとえば、データ処理モジュール４１１は、データオーケストレータではなくクラウド４２０上に存在してよい。データ処理方法およびメタデータ作成に関する詳細は、本明細書において後述される。

決定エンジン４１３は、予測モデル知識ベース４０７内の規則を実行するように構成されてよい。たとえば、決定エンジンは、実行の資格があるかまたは実行の準備ができている予測モデル知識ベース４０７内の規則を常に調べ、次いで、適格な規則に関連付けられたアクションを実行し、データ通信モジュール４１５を呼び出して、結果（たとえば、集約データ、Ｍｅｓｓａｇｅ＿Ｐａｃｋａｇｅ）を宛先（たとえば、要求されたデータセンタ４２０、アプリケーション４３１、リモートエンティティ、サードパーティエンティティ４３１など）に送信することができる。

データ通信モジュール４１５は、規則に従って、処理されたデータまたは自律型の乗り物データの選択された部分を宛先に送信することができる。下記は、データ通信モジュールによって実行される手順の一例を示す。

ステップ１ Ｑｕｅｕｅ＿Ｓｔａｔｕｓをチェックする
ステップ２ Ｑｕｅｕｅ＿Ｓｔａｔｕｓ＝１の場合、
Ｍｅｓｓａｇｅ＿Ｐａｃｋａｇｅごとに、
Ｆｉｌｅ＿ＳｉｚｅおよびＴｒａｎｓｍｉｓｓｉｏｎ＿Ｄｅｌａｙを調査して、Ｔｒａｎｓｍｉｓｓｉｏｎ＿Ｃｈａｎｎｅｌ＿Ｔｙｐｅを決定し、
Ｔｒａｎｓｍｉｓｓｉｏｎ＿Ｃｈａｎｎｅｌ＿ＴｙｐｅのＴｒａｎｓｍｉｓｓｉｏｎ＿Ｃｈａｎｎｅｌを選択し、
選択されたＴｒａｎｓｍｉｓｓｉｏｎ＿Ｃｈａｎｎｅｌを介してＤａｔａ＿Ｃｅｎｔｅｒ＿Ａｄｄｒｅｓｓ＿Ｌｉｓｔ内の各アドレスにＣｏｍｐｒｅｓｓｅｄ＿Ｄａｔａ＿Ｆｉｌｅを送信し、
Ｔｒａｎｓｍｉｓｓｉｏｎ＿Ｓｕｃｃｅｅｓｓ＝１の場合、ＱｕｅｕｅからＭｅｓｓａｇｅ＿Ｐａｃｋａｇｅを削除し、そうでない場合、送信に進む
ステップ３ ステップ１に進む
データオーケストレータとクラウドまたはリモートエンティティとの間の通信を容易にするために、様々な通信プロトコルが使用されてよい。これらの通信プロトコルには、ＶＬＡＮ、ＭＰＬＳ、ＴＣＰ／ＩＰ、トンネリング、ＨＴＴＰプロトコル、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ベンダ固有プロトコル、カスタマイズされたプロトコルなどが含まれてよい。一実施形態では、通信ネットワークはインターネットであるが、他の実施形態では、通信ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ワイヤレスネットワーク、イントラネット、プライベートネットワーク、パブリックネットワーク、交換ネットワーク、およびこれらの組合せなどを含む、任意の適切な通信ネットワークであってよい。ネットワークは、ワイヤレスおよび／または有線の通信システムの両方を使用するローカルエリアネットワークおよび／またはワイドエリアネットワークの任意の組合せを含んでよい。たとえば、ネットワークは、インターネットならびに携帯電話ネットワークを含んでよい。一実施形態では、ネットワークは、標準的な通信技術および／またはプロトコルを使用する。したがって、ネットワークは、イーサネット、８０２．１１、マイクロ波アクセス用世界的相互運用性（ＷｉＭＡＸ）、２Ｇ／３Ｇ／４Ｇもしくはロングタームエボリューション（ＬＴＥ）のモバイル通信プロトコル、赤外線（ＩＲ）通信技術、および／またはＷｉ－Ｆｉなどの技術を使用するリンクを含んでよく、ワイヤレス、有線、非同期転送モード（ＡＴＭ）、インフィニバンド、ＰＣＩエクスプレス高度スイッチング、またはそれらの組合せであってよい。ネットワークで使用される他のネットワーキングプロトコルには、マルチプロトコルラベルスイッチング（ＭＰＬＳ）、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、シンプルメール転送プロトコル（ＳＭＴＰ）、ファイル転送プロトコル（ＦＴＰ）などが含まれ得る。ネットワークを介して交換されるデータは、バイナリ形式の画像データ（たとえば、ポータブルネットワークグラフィックス（ＰＮＧ）など）、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張可能マークアップ言語（ＸＭＬ）などを含む技術および／またはフォーマットを使用して表すことができる。さらに、リンクのすべてまたはいくつかは、セキュアソケットレイヤ（ＳＳＬ）、転送レイヤセキュリティ（ＴＬＳ）、インターネットプロトコルセキュリティ（ＩＰｓｅｃ）などの従来の暗号化技術を使用して暗号化することができる。別の実施形態では、ネットワーク上のエンティティは、上述されたものの代わりに、またはそれらに加えて、カスタムおよび／または専用のデータ通信技術を使用することができる。ネットワークは、ワイヤレス、有線、またはそれらの組合せであってよい。

予測モデル作成および管理システム
予測モデル管理モジュール４２１は、図１に記載された予測モデル作成および管理システムと同じであり得る。予測モデル管理モジュール４２１は、データオーケストレータ４１０またはデータオーケストレータの１つもしくは複数の構成要素（たとえば、予測モデル知識ベース）をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。

いくつかの実施形態では、予測モデル管理モジュール４２１は、モデル作成器およびモデルマネージャを備えてよい。場合によっては、モデル作成器は、クラウドデータレイクおよびメタデータデータベースからのデータを使用して予測モデルを訓練、開発、または試験するように構成されてよい。モデルマネージャは、様々な構成要素（たとえば、クラウドデータレイク、メタデータデータベース、データオーケストレータ、モデル作成器）間のデータフローを管理し、正確で複雑かつ高速なクエリ（たとえば、モデルクエリ、メタデータクエリ）、モデル展開、保守、監視、モデル更新、モデルバージョン管理、モデル共有、および様々な他のものを提供するように構成されてよい。たとえば、展開コンテキストはエッジ基盤に応じて異なってよく、モデルマネージャは、エッジハードウェア仕様、展開場所、互換性のあるシステムに関する情報、セキュリティおよびプライバシーのためのデータアクセスマニフェスト、モデルの展開および保守中に所与の展開およびバージョン管理で利用できないデータフィールドをモデル化するためのエミュレータなどのアプリケーションマニフェストを考慮に入れることができる。

予測モデル管理モジュールによって提供されるデータ管理は、自動化された乗り物および自律型の乗り物のライフサイクル全体にわたって適用することができる。たとえば、データ管理は、乗り物設計段階、乗り物／フリート検証段階、または乗り物／フリート展開段階における様々なアプリケーションにわたって適用されてよい。図１４は、自動化された乗り物および自律型の乗り物のライフサイクルにおける様々なアプリケーションの例を示す図である。たとえば、データ管理は、乗り物設計段階、乗り物／フリート検証段階、または乗り物／フリート展開段階において、新しいモデルの作成または既存のモデルの更新に使用することができる。

図６は、予測モデルを訓練および開発するためにメタデータデータベース４２７およびクラウドデータレイク４２９と対話するモデル作成器６００の一例を示す図である。訓練された予測モデルは、性能について試験されてよく、次いで、性能要件を満たす予測モデルは、予測モデル知識ベース４０７に挿入されてよい。いくつかの実施形態では、クラウドデータベース４２９は、図１に記載された両方のクラウドデータレイク１２５、１２７を含んでよい。

モデル作成器は、データオーケストレータによって使用される予測モデル、自律型の乗り物スタックによって使用されている予測モデル、ユーザ体験プラットフォーム、フリート管理システム、および様々な他のものによって使用される予測モデルを開発するように構成されてよい。モデル作成器は、データ管理およびデータ編成に加えて、乗り物の自律移動、（１つもしくは複数の）乗り物客室の個別化ならびに乗り物および／もしくは（１つもしくは複数の）乗り物客室内部で実行される他の機能、フリートの安全で最適化された動作、ならびに／または様々な他のアプリケーションに使用される予測モデルを訓練および開発することができる。

図７は予測モデルを作成する方法７００を示す。方法またはプロセスは、上述されたモデル作成器によって実行されてよい。予測モデルを生成するために、モデル目標および性能特性（たとえば、精度）が決定されてよい（動作７０１）。さらに、所望のデータ特性（たとえば、完全性、有効性、精度、一貫性、可用性、および適時性）が決定されてよい（動作７０２）。次に、モデルを訓練するために、データベース（たとえば、クラウドデータレイク）からラベル付きデータまたはデータセットが選択されてよい（動作７０３）。場合によっては、データベースからデータを検索することは、データ特性を有するメタデータデータベース内のメタデータを照会し、次いでメタデータ照会結果に基づいてクラウドデータレイクからデータを検索することを含んでよい。クラウドデータレイクからデータが返されない場合、データ特性が調整されてよい（すなわち、動作７０２を繰り返す）。場合によっては、返されたデータまたはデータセットは、次のステップの前にサンプリングされてよい。

場合によっては、ラベル付きデータまたはデータセットは、モデル目標を考慮して適切性について分析されてよい（動作７０４）。たとえば、ラベル付きデータセットは、たとえば、自律型の乗り物が自動的に右折を行うことを可能にする予測モデルを開発することなどの、予測目標に十分であるかどうかが判定されてよい。様々な適切な方法は、ラベル付きデータセットの適切性を判定するために利用されてよい。たとえば、統計的検出力が計算され、分析に使用されてよい。統計的検出力は、検出される効果があるときに研究が効果を検出する可能性である。統計的検出力が高い場合、実際に１つの効果があるとき、タイプＩＩエラーを起こす確率、または効果がないと結論付ける確率は低下する。統計的検出力は、主に効果の大きさおよびそれを検出するために使用されるサンプルの大きさによって影響を受ける。大きい効果は小さい効果よりも検出が容易であるが、大きいサンプルは小さいサンプルよりも高い試験感度を提示する。

動作７０４で生成された分析結果は、データセットが補正される必要があるかどうかを判定することができる。適切性分析の結果は、データセットが適切な要件を満たすかどうか、適切性のレベル、または補正される必要があるかどうかを示すことができる。たとえば、ラベル付きデータセットの適切性が計算され、所定のしきい値を下回るとき、データセットは適切性要件を満たさないと判定され、補正を必要とする可能性がある。データセットが補正を必要としないと判定すると、データセットは、予測モデルを訓練するために使用されてよい（動作７０６）。場合によっては、モデルを訓練することは、モデルタイプ（たとえば、ＣＮＮ、ＲＮＮ、勾配ブーストされた分類器またはリプレッサなど）を選択すること、モデルのアーキテクチャ（たとえば、層の数、ノード、ＲｅＬＵ層など）を選択すること、パラメータを設定すること、訓練データを作成すること（たとえば、データのペアリング、入力データベクトルの生成）、およびモデルを作成するために訓練データを処理することを含んでよい。場合によっては、データセットが分析され、データ補正を必要とすると判定された場合、補正が実行されてよい（動作７０５）。データセットを補正することができない場合、データベースから新しいまたは異なるデータセットが選択されてよい（すなわち、動作７０３を繰り返す）。

訓練されたモデルは、予測モデル知識ベース４０７から検索された試験データを使用して試験および最適化されてよい（動作７０７）。次に、試験結果が性能特性と比較されて、予測モデルが性能要件を満たすかどうかが判定されてよい（動作７０８）。性能が良好である、すなわち性能要件を満たす場合、モデルが予測モデル知識ベース４０７に挿入されてよい（動作７０９）。

場合によっては、新しいモデルを予測モデル知識ベースに挿入することは、新しいモデルがモデルツリーのどこに挿入されるか（たとえば、新しいノードとして既存のモデルツリーに追加されるか、または新しいモデルツリーに追加されるか）を判定することを含んでよい。新しいモデルとともに、モデル目標、モデルアーキテクチャ、モデルパラメータ、訓練データ、試験データ、モデル性能統計値などの他のデータも、モデルツリー構造にアーカイブされてよい。次に、モデル作成器またはモデルマネージャによって予測モデル性能が絶えず監視されてよい（動作７１０）。訓練されたモデルが性能試験を通過しない場合、プロセスは、不十分な性能がデータ特性またはモデル特性によって引き起こされたかどうかを判定することに進んでよい。決定に続いて、動作７０１（たとえば、性能特性の調整）および／または動作７０２（たとえば、データ特性の調整）が繰り返されてよい。

場合によっては、新しい予測モデルの作成時、または既存の予測モデルに対して行われた更新／変更時に、予測モデルは選択された乗り物に利用可能であってよい。たとえば、予測モデルが更新され、予測モデル知識ベースに格納されると、予測モデルはフリート内の１つまたは複数の乗り物にダウンロードされてよい。利用可能な予測モデルは、動的に選択された１つまたは複数の乗り物にダウンロードされるか、またはそれらの中で更新されてよい。図１５は、乗り物内の予測モデルを動的に更新する例を示す図である。

上述されたように、予測モデルは、データ管理およびデータ編成に加えて、乗り物の自律移動、（１つもしくは複数の）乗り物客室の個別化ならびに乗り物および／もしくは（１つもしくは複数の）乗り物客室内部で実行される他の機能、フリートの安全で最適化された動作、ならびに／または様々な他のアプリケーションに使用されるモデルを含んでよい。乗り物が新しい状況に対処することを可能にするために、新しいモデルが作成されてよい。クラウドデータレイクに収集および格納された新しいデータに基づいて全体的な性能を改善するために、モデルが更新されてよい。場合によっては、システムによってアクセス可能なフリート内の特定の乗り物または一組の乗り物によって使用される予測モデルのリストが乗り物データベース内で維持される。

場合によっては、そのような更新、変更、または新しいモデルの作成は、予測モデル管理モジュールの構成要素によって自動的に検出されてよい。たとえば、図１５を参照すると、予測モデル更新モジュール１５０１は、新しいモデルが作成されたとき、または既存のモデルが更新されたときに、予測モデル知識ベース１５０３によって通知されてよい。次いで、予測モデル更新モジュール１５０１は、更新されたモデルのコピーを受信するために１つまたは複数の乗り物を選択することができる。１つまたは複数の乗り物は、サブスクリプション、モデルの利用、または他の基準に基づいて選択または決定されてよい。予測モデル更新構成要素はまた、選択された乗り物内でいつモデルが更新されるかを判断することができる。たとえば、予測モデル更新構成要素は、乗り物が停止しているとき（たとえば、保守、洗浄、修理などの間）に、または必要に応じて、モデルが直ちに更新される必要があると判断することができる。たとえば、タクシー配車フリートの一部である乗り物の場合、サンフランシスコの野球場で行われているゲームがある夜間に右折を行うための予測モデルは、（たとえば、乗客をピックアップするため、乗客を降車させるため、または乗客をどこか他の場所でピックアップもしくは降車させる過程でその領域を通過するために）影響を受ける領域を通過することを伴う乗車を完了するように乗り物が割り当てられている場合にのみ必要とされてよい。予測モデル更新モジュール１５０１は、上述されたクラウドのサブスクリプションモジュールの一部であってよい。

再び図４を参照すると、クラウドもしくはデータセンタ４２０または提供された乗り物データ管理システムは、データおよびメタデータ管理モジュール４２５も備えてよい。データおよびメタデータ管理モジュール４２５は、データ処理モジュール４１１によって行われるデータ処理、ならびにメタデータの作成および管理を含む様々な機能を実行することができる。データおよびメタデータ管理モジュールは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびＡＰＩコールを処理するように構成されてよい。データおよびメタデータ管理モジュールに関する詳細は、たとえば、図８～図１２に関連して説明される。

クラウドまたはデータセンタ４２０は、クラウドアプリケーション４２３と、分析、センサデータ（たとえば、ビデオ）、および／または処理されたデータを閲覧するためのユーザインターフェース（ＵＩ）モジュール４２５とをさらに備えてよい。ＵＩは、分析表現を開発および展開し、データ編成アプリケーションをエッジ（たとえば、自律型の乗り物オペレーティングシステム、エッジゲートウェイ、エッジ基盤、データオーケストレータ）に展開し、データ編成を構成および監視するための管理ＵＩも含んでよい。

図８は、乗り物データ管理システム８００の例示的な構成要素、特にリモートエンティティ（たとえば、データセンタ）上に存在する乗り物データ管理システムの構成要素を示す。いくつかの実施形態では、乗り物データ管理システム８００は、データおよびメタデータ管理システムと、予測モデル作成および管理システムとを備えてよい。データおよびメタデータ管理システムは、上述されたデータおよびメタデータ管理モジュールと同じであり得る。データおよびメタデータ管理システムは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびＡＰＩコールを処理するように構成されてよい。いくつかの実施形態では、乗り物データ管理システム８００は、少なくともパイプラインエンジン８０１と、予測モデル作成および管理システム８０３とを含むデータおよびメタデータ管理システムを備えてよい。いくつかの実施形態では、データおよびメタデータ管理システムは、データベースクエリエンジン８０５、メタデータクエリエンジン８０７、データシステム管理８１５、データシステムアーカイブ規則８１７、データシステムセキュリティ８１９、データベースＡＰＩ８２１、規制規則８２３、およびクラウド間通信８２５などの他の機能構成要素を備えてよい。たとえば、メタデータデータベース８０９は、データベースクエリエンジン８０５を介してメタデータクエリ言語を使用してアクセスすることができる。別の例では、データレイク８１１、８１３内のデータは、メタデータクエリの結果としてアクセスされ得るか、またはデータベースクエリエンジン８０５を使用して直接アクセスされ得る。クラウド間通信８２５は、ＶＬＡＮ、ＭＰＬＳ、ＴＣＰ／ＩＰ、トンネリング、ＨＴＴＰプロトコル、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ベンダ固有プロトコル、カスタマイズされたプロトコルなどの様々な通信プロトコルを含んでよい。クラウド間通信は、システム（たとえば、クラウドベースのシステム）および／またはデバイスによって使用されてよく、様々なＡＰＩ（たとえば、ＲＥＳＴアーキテクチャ、ＳＯＡＰ、Ｗｅｂサービス、エンタープライズサービスバスプロトコル、またはシステム間通信および／もしくはプロセス間通信用の手法を提供するように設計された任意のデータ交換プロトコルを使用するＡＰＩ）を利用することができるインターフェースを備えてよい。いくつかの実施形態では、乗り物データ管理システム８００は、メタデータデータベース８０９、自律型の乗り物スタックデータを格納するためのクラウドデータレイク８１１、およびユーザ体験プラットフォームデータを格納するためのクラウドデータレイク８１３をさらに備えてよい。

いくつかの実施形態では、上述された構成要素のうちの１つまたは複数は、１つまたは複数のクラウドアプリケーションまたは企業アプリケーション（たとえば、フリート保守８３１、フリート管理８３３、マップ更新８３５、フリート構成８３７）と対話することができる。クラウドアプリケーションは、リモートエンティティ上でホストされてもよく、データ管理システムによって管理される乗り物データを利用してもよい。場合によっては、クラウドアプリケーションは、予測モデル作成および管理システム８０３によって作成されるデータベースまたは知識ベース８３２、８３４、８３６、８３８を有してよい。場合によっては、クラウドアプリケーションは、自律型の乗り物スタックデータを格納するためのクラウドデータレイク８１１、ユーザ体験プラットフォームデータを格納するためのクラウドデータレイク８１３に格納されたデータ、またはメタデータデータベース８０９に格納されたメタデータにアクセスし、それらを操作する許可を有してよい。場合によっては、データはクラウドアプリケーションにディスパッチされてよく、（メタデータまたはアプリケーションテーブル内で識別された）対応するクラウドアプリケーションにデータをディスパッチするために、予測モデル作成および管理システムは、迅速な検索のためにテーブルにローカルにリストされたクラウド上のすべてのリソース（すなわち、アプリケーション）のアドレスを有してよい。

パイプラインエンジン８０１は、データオーケストレータから送信された生データまたはバッチデータの連続ストリームを前処理するように構成されてよい。たとえば、データは、機械学習分析に供給することができるように処理されてよい。データ処理には、たとえば、データの正規化、メタデータによるデータのラベル付け、タグ付け、データの整列、データの分割などが含まれてよい。場合によっては、処理方法は、機械学習分析を構築する開発者によるＡＰＩを介してプログラム可能である。

図９は、データ取込みパイプライン９００の一例およびパイプラインエンジンによって実行される機能を示す。パイプライン９００は、ストリームまたはバッチに取り込まれているデータを処理するための複数の機能を含んでよい。データには、たとえば、シミュレーションデータ、フリートデータなどの乗り物からのデータ、動作環境データ、輸送データ、乗り物遠隔測定、ＡＶスタックおよびユーザ体験プラットフォームによって生成されたデータ、サードパーティパートナーデータ（たとえば、ユーザモバイルアプリケーションからのデータ）、センサデータ（たとえば、ＧＰＳ、ＩＭＵ、カメラ、Ｌｉｄａｒ、赤外線センサ、熱センサ、超音波センサなど）、地理位置データ、ならびに本明細書の他の箇所に記載された様々な他のデータが含まれてよい。ストリームデータは、限定はしないが、環境の時空間点測定値などの時系列データ、レーダー、Ｌｉｄａｒ、衛星、ソナーからのグリッド化測定値、および／またはアレイ指向データフォーマットもしくは多次元データを表すのに適した任意の他のデータフォーマットで形成されたシミュレーションプロセスの出力などの多次元データ、マップタイルなどの視覚化データ、メタデータ、センサからの生入力データなどの生データ、文書、デジタルサービス、データ収集、統合、処理分析のソースコード、ならびに様々な他のデータを含む、様々なタイプのデータを含んでよい。バッチは、テナント固有、アプリケーション固有であってもよく、並列処理用のコンテキスト認識サブグループにグループ化されてもよい。バッチは、本明細書の他の箇所に記載されたデータオーケストレータから生成および送信されてよい。

パイプライン９００はカスタマイズ可能であってよい。たとえば、パイプライン９００の１つまたは複数の機能は、ユーザによって作成されてよい。代替または追加として、１つまたは複数の機能は、管理システムによって作成されてもよく、他のシステムもしくはサードパーティソースからインポートされてもよい。場合によっては、ユーザは、関数セット（たとえば、利用可能な機能９２０）から選択し、選択された関数をパイプラインに追加することを許可されてよい。場合によっては、パイプラインの作成または修正は、ユーザインターフェースモジュール（たとえば、図４のユーザインターフェースモジュール４２５）によって提供されるグラフィカルユーザインターフェース（ＧＵＩ）を介して実行されてよい。たとえば、一組の利用可能な関数がＧＵＩ内に表示されてよい。ユーザは、ＧＵＩ内で、関数をクリックすることによってＣＲＥＡＴＥ ＳＣＥＮＡＲＩＯＳ関数を表すグラフィカル要素を選択するか、またはドラッグアンドドロップによって現在のパイプラインに関数を追加することができる。

場合によっては、グラフィカルユーザインターフェース（ＧＵＩ）またはユーザインターフェースは、ディスプレイ上に提供されてよい。ディスプレイは、タッチスクリーンであってもなくてもよい。ディスプレイは、発光ダイオード（ＬＥＤ）スクリーン、有機発光ダイオード（ＯＬＥＤ）スクリーン、液晶ディスプレイ（ＬＣＤ）スクリーン、プラズマスクリーン、または任意の他のタイプのスクリーンであってよい。ディスプレイは、アプリケーションを介して（たとえば、ユーザデバイス上で、クラウド上で、またはデータオーケストレータ上で実行されるアプリケーションプログラミングインターフェース（ＡＰＩ）を介して）レンダリングされたユーザインターフェース（ＵＩ）またはグラフィカルユーザインターフェース（ＧＵＩ）を表示するように構成されてよい。

いくつかの実施形態では、複数の機能は、取込み９０１、フィルタリング９０５、クリーニング９０７、タグ付け９０９、拡大９１１、注釈付け９１３、匿名化９１５、および様々な他の機能（たとえば、シミュレート）などのサードパーティ機能を含んでよい。たとえば、データクリーニング９０７は、データからノイズを除去すること（たとえば、画像処理におけるノイズ削減）、誤ったデータを補正すること（たとえば、１つのカメラが故障しており、光を示さないが、日中である）、共通データフォーマットを確立すること（たとえば、メトリックシステムを使用する、すべての数を小数点第３位までなど）、または、意図されたデータ消費者もしくはアプリケーションによってＡＰＩを介して迅速かつ容易にアクセスされ得るようにデータを準備することを含んでよい。別の例では、データ拡大９１１は、自律型の乗り物モデルを試験するためにより完全なデータセットのために実際のデータと合成を組み合わせること、特定のタイプの予測を可能にするためにパートナーからのデータで捕捉されたデータを増強すること、移動時間を予測するために交通渋滞データを気象データと組み合わせること、情報量の多いデータを作成するためにいくつかのデータセットを組み合わせること（たとえば、１日の特定の時間帯における乗り物到着時間を予測するために乗り物動作データを都市交通基盤データおよび渋滞データと組み合わせること）を含んでよい。さらなる例では、データのタグ付け９０９または注釈付け９１３は、あらゆるレベルで行われるマルチメディアデータ（たとえば、画像、Ｌｉｄａｒ、オーディオ）の注釈付けおよびメタデータの作成を含んでよい。メタデータは、データ管理環境内のデータの移動中に作成されてよい。たとえば、画像は、（おそらく何らかの手動介入で）検索され、注釈付けされ、次いで再インデックス付けされる必要があり得る。作成されたメタデータは、メタデータカタログに組み込まれてよい。手動または自動で生成された様々なタイプのメタデータなどの他のメタデータも、メタデータカタログに挿入されてよい。複数の機能は、データ整列９０３およびシナリオ作成９２１などの独自の機能も備えてよい。

図１０は例示的なデータ取込みプロセス１０００を示す。場合によっては、ストリームデータおよび／またはバッチデータは、パイプラインエンジンに取り込まれてよい。場合によっては、取り込まれたストリームデータはストリーム処理システム１００１に配信されてよく、取り込まれたバッチデータは抽出－変換－ロード（ＥＴＬ）システム１００３に配信されてよい。ＥＴＬシステム１００３は、従来のＥＴＬ機能またはカスタマイズされた機能を実行することができる。たとえば、ＥＴＬシステムは、取り込まれたバッチデータをユーザにより有用なフォーマットに変換することができる。たとえば、データ変換は、特定の列のみを選択してフォーマットにロードすることと、コード化された値を変換することと、新しい計算値を導出することと、データをソートすることと、データを集計することと、データを輸送または回転させることと、列を複数の列に分割することと、他の処理とを含んでよい。

本明細書ではストリーム処理システム１００１およびＥＴＬシステム１００３が説明されるが、本明細書に記載された機能を実装するために追加のモジュールまたは代替のモジュールが使用されてよい。ストリーム処理システムおよびＥＴＬシステムは、実装され得る多くの実行可能モジュールの単に例示的なものである。

場合によっては、データ整列は、ＥＴＬシステムまたはストリーム処理システムによって実行されてよい。場合によっては、異なるセンサ（たとえば、センサは、異なる頻度でデータを捕捉することができる）により、または異なるソース（たとえば、サードパーティアプリケーションデータ）から捕捉されたデータが整列されてよい。たとえば、カメラ、Ｌｉｄａｒ、および遠隔測定データ（たとえば、温度、乗り物の状態、バッテリ充電など）によって捕捉されたデータは、時間に対して整列されてよい。場合によっては、データ整列は自動的に実行されてよい。代替または追加として、ユーザは、どのセンサまたはソースから収集されたデータが整列されるべきか、および／またはデータが整列されるべき時間ウィンドウを指定することができる。一例では、結果データは、時間に対して整列された時系列データであってよい。データは、アプリケーション、データ構造などの他の次元に沿って整列させることができることに留意されたい。

メタデータ
乗り物データ管理システムはメタデータ管理を実現することができる。場合によっては、メタデータの作成および管理は、上述されたデータおよびメタデータ管理システムによって実現されてよい。場合によっては、メタデータは、メタデータに基づくデータのサブセットまたは自律型の乗り物データの一部分の選択を可能にすることができる。いくつかの実施形態では、メタデータは、センサデータ（たとえば、ＧＰＳ、Ｌｉｄａｒ、カメラなど）を捕捉するセンサ、データに対する前処理（たとえば、時系列の整列および作成）、ならびに特定のユースケースまたはアプリケーション（たとえば、歩行者の回避、パターン認識、障害物の回避など）用のデータに対して動作する様々なアプリケーションおよび／または予測モデルに関する情報を提供することができる。メタデータは乗り物上で作成されてよい。たとえば、メタデータは、乗り物上で動作するセンサまたはアプリケーションによって生成されてよい。別の例では、メタデータは、乗り物に搭載されたデータオーケストレータによって生成されてよい。メタデータは、乗り物から離れて、またはリモートエンティティによって生成されてよい。たとえば、データ処理（たとえば、整列）に関するメタデータは、データセンタ内で、またはクラウドアプリケーションによって生成されてよい。場合によっては、メタデータの少なくとも一部分は、乗り物上で生成され、リモートエンティティに送信される。場合によっては、メタデータの少なくとも一部分は、リモートエンティティに設けられた構成要素（たとえば、クラウドアプリケーションまたはパイプラインエンジン）によって生成される。作成されたメタデータは、データ管理システムによって管理されるメタデータデータベースに格納されてよい。代替または追加として、メタデータは、メタデータを生成するために使用されるデータの少なくとも一部または全部を有するデータベースに格納されてよい。

図１１は、整列、アプリケーション、およびセンサによって生成されたメタデータの一例を示す。たとえば、異なるセンサデータ１１１１、１１１３が整列されると、整列情報（たとえば、構造パディング、頻度、時間ウィンドウなど）を提供するためにメタデータ（たとえば、整列作成メタデータ１１０３）が作成されてよい。場合によっては、データを生成するセンサまたはソースに関するメタデータ（たとえば、センサ作成メタデータ１１０５）が作成されてよい。たとえば、センサ作成メタデータは、センサに関する情報、センサの識別子、データタイプなどを含んでよい。場合によっては、アプリケーションに関するメタデータ（たとえば、アプリケーション作成メタデータ１１０１）は、データを処理および／または生成するアプリケーションによって作成されてよい。たとえば、アプリケーション作成メタデータ１１０１は、アプリケーションの名前、アプリケーションの開発者、アプリケーションのバージョン、および様々な他のものに関する情報を提供することができる。

いくつかの実施形態では、データ管理システムは、データベースからデータを高速検索または照会するためのメタデータのメタデータを生成することができる。たとえば、シナリオメタデータは、次いでデータベースから適切な乗り物データを検索するために使用される特定のメタデータを使用してシナリオの特性を指定するために作成されてよい。図１２はシナリオメタデータ１２００の一例を示す。以下の例では、曇天の朝に乗り物が街路から高速道路に合流するために右折を行うシナリオを記述するシナリオデータオブジェクトは、以下のように定義されてよい。

Ｓｃｅｎａｒｉｏ＿Ｎａｍｅ：たとえば、右側合流
Ｓｃｅｎａｒｉｏ＿Ｔｙｐｅ：たとえば、高速道路への右側合流
Ｓｔａｔｉｃ＿Ｏｂｊｅｃｔｓ：たとえば、木
Ｄｙｎａｍｉｃ＿Ｏｂｊｅｃｔｓ：たとえば、動作乗り物
Ｅｎｖｉｒｏｎｍｅｎｔ：たとえば、曇天の朝
Ｓｃｅｎｅ＿Ｄｅｓｃｒｉｐｔｉｏｎ：たとえば、都市一般道路から高速道路に進入する乗り物
Ｔｒｉｇｇｅｒ＿Ｒｕｌｅｓ：たとえば、乗り物が交差点に近づく１０秒前に選択を始め、合流が完了した２０秒後に止める
Ｄａｔａ：たとえば、時系列セグメント１
下記は、新しいシナリオオブジェクトを作成する例示的なプロセスである。

ステップ１ Ｓｃｅｎａｒｉｏ＿Ｔｙｐｅを指定する
ステップ２ ＭｅｔａｄａｔａＣａｔａｌｏｇ内のメタデータを使用して、各Ｓｔａｔｉｃ＿Ｏｂｊｅｃｔ、各Ｄｙｎａｍｉｃ＿Ｏｂｊｅｃｔ、およびＳｃｅｎｅ＿Ｄｅｓｃｒｉｐｔｉｏｎを指定する
ステップ３ 選択されたメタデータを使用してメタデータクエリ言語を使用してクエリを発行して、ＲｅｓｕｌｔＳｅｔを作成する
ステップ４ ＲｅｓｕｌｔＳｅｔが空である場合、ＮｅｗＴｉｍｅＳｅｒｉｅｓＤａｔａが物理的に収集またはシミュレートされ得るかどうかを判定し、そうでない場合、ステップ７に進む。

ステップ５ ＮｅｗＴｉｍｅＳｅｒｉｅｓＤａｔａがシミュレートされる必要がある場合、データセット全体がシミュレートされる必要があるかどうか、またはデータセットの一部のみがシミュレートされ、次いで物理的に収集されたデータとマージされる必要があるかどうかを判定する。ステップ６に進む
ステップ６ Ｄａｔａ＿Ｉｎｇｅｓｔｉｏｎ＿Ｐｉｐｅｌｉｎｅを使用して（収集されるか、シミュレートされるか、またはそれらの組合せの）ＮｅｗＴｉｍｅＳｅｒｉｅｓＤａｔａを処理する
ステップ７ ＮｅｗＴｉｍｅＳｅｒｉｅｓＤａｔａＳｅｔ内のＴｉｍｅＳｅｒｉｅｓごとに、
ａ．Ｔｒｉｇｅｒ＿Ｒｕｌｅｓを使用してステップ２の指定されたメタデータを満たすＴｉｍｅＳｅｒｉｅｓセグメントを選択して、ＴｉｍｅＳｅｒｉｅｓＳｅｇｍｅｎｔを作成する。

ｂ．新しいＳｃｅｎａｒｉｏＯｂｊｅｃｔを作成する
ｃ．選択されたセグメントと名前を関連付ける
ｄ．ステップ２からのメタデータを入力する
ｅｄ．ＴｉｍｅＳｅｒｉｅｓＳｅｇｍｅｎｔをＳｃｅｎａｒｉｏＯｂｊｅｃｔに挿入する
コンピュータシステム
本明細書に記載された乗り物データ管理システム、データオーケストレータ、またはプロセスは、１つまたは複数のプロセッサによって実施することができる。いくつかの実施形態では、１つまたは複数のプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、および／または１つもしくは複数のアドバンストＲＩＳＣマシン（ＡＲＭ）プロセッサなどのきめ細かい空間アーキテクチャの形態のプログラマブルプロセッサ（たとえば、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、汎用処理装置、またはマイクロコントローラ）であってよい。いくつかの実施形態では、プロセッサはコンピュータシステムの処理ユニットであってよい。図１３は、データ管理システムを実装するようにプログラムされるか、そうでなければ構成されたコンピュータシステム１３０１を示す。コンピュータシステム１３０１は、本開示の様々な態様を調整することができる。

コンピュータシステム１３０１は、中央処理装置（ＣＰＵ、本明細書では「プロセッサ」および「コンピュータプロセッサ」でもある）１３０５を含み、それは、シングルコアもしくはマルチコアのプロセッサ、または並列処理のための複数のプロセッサであり得る。コンピュータシステム１３０１はまた、メモリまたは記憶場所１３１０（たとえば、ランダムアクセスメモリ、読取り専用メモリ、フラッシュメモリ）、電子記憶ユニット１３１５（たとえば、ハードディスク）、１つまたは複数の他のシステムと通信するための通信インターフェース１３２０（たとえば、ネットワークアダプタ）、ならびにキャッシュ、他のメモリ、データストレージ、および／または電子ディスプレイアダプタなどの周辺デバイス１３２５を含む。メモリ１３１０、記憶ユニット１３１５、インターフェース１３２０、および周辺デバイス１１２５は、マザーボードなどの通信バス（実線）を介してＣＰＵ１３０５と通信している。記憶ユニット１３１５は、データを記憶するためのデータ記憶ユニット（またはデータリポジトリ）であり得る。コンピュータシステム１３０１は、通信インターフェース１３２０の助けを借りて、コンピュータネットワーク（「ネットワーク」）１０３０に動作可能に結合することができる。ネットワーク１０３０は、インターネット、インターネットおよび／もしくはエクストラネット、またはインターネットと通信しているイントラネットおよび／もしくはエクストラネットであり得る。ネットワーク１０３０は、場合によっては、電気通信ネットワークおよび／またはデータネットワークである。ネットワーク１０３０は、クラウドコンピューティングなどの分散コンピューティングを可能にすることができる１つまたは複数のコンピュータサーバを含むことができる。ネットワーク１０３０は、場合によっては、コンピュータシステム１３０１の助けを借りてピアツーピアネットワークを実装することができ、それにより、コンピュータシステム１３０１に結合されたデバイスがクライアントまたはサーバとして振る舞うことが可能になってよい。

ＣＰＵ１３０５は、プログラムまたはソフトウェアで具現化することができる一連の機械可読命令を実行することができる。命令は、メモリ１３１０などの記憶場所に記憶されてよい。命令は、ＣＰＵ１３０５を対象とすることができ、ＣＰＵ１３０５は、その後、本開示の方法を実施するようにＣＰＵ１３０５をプログラムするか、そうでなければ構成することができる。ＣＰＵ１３０５によって実行される動作の例には、フェッチ、復号、実行、およびライトバックが含まれ得る。

ＣＰＵ１３０５は、集積回路などの回路の一部であり得る。システム１３０１の１つまたは複数の他の構成要素を回路に含めることができる。場合によっては、回路は特定用途向け集積回路（ＡＳＩＣ）である。

記憶ユニット１３１５は、ドライバ、ライブラリ、および保存されたプログラムなどのファイルを記憶することができる。記憶ユニット１３１５は、ユーザデータ、たとえば、ユーザの嗜好およびユーザプログラムを記憶することができる。コンピュータシステム１３０１は、場合によっては、イントラネットまたはインターネットを介してコンピュータシステム１３０１と通信しているリモートサーバ上に配置されるなどの、コンピュータシステム１３０１の外部にある１つまたは複数の追加のデータ記憶ユニットを含むことができる。

コンピュータシステム１３０１は、ネットワーク１０３０を介して１つまたは複数のリモートコンピュータシステムと通信することができる。たとえば、コンピュータシステム１３０１は、ユーザのリモートコンピュータシステム（たとえば、ユーザデバイス）と通信することができる。リモートコンピュータシステムの例には、パーソナルコンピュータ（たとえば、ポータブルＰＣ）、スレートもしくはタブレットＰＣ（たとえば、Ａｐｐｌｅ（登録商標）ｉＰａｄ、Ｓａｍｓｕｎｇ（登録商標）ＧａｌａｘｙＴａｂ）、電話、スマートフォン（たとえば、Ａｐｐｌｅ（登録商標）ｉＰｈｏｎｅ、Ａｎｄｒｏｉｄ対応デバイス、Ｂｌａｃｋｂｅｒｒｙ（登録商標））、または携帯情報端末が含まれる。ユーザは、ネットワーク１０３０を介してコンピュータシステム１３０１にアクセスすることができる。

本明細書に記載された方法は、たとえば、メモリ１３１０または電子記憶ユニット１３１５などのコンピュータシステム１３０１の電子記憶場所に記憶された機械（たとえば、コンピュータプロセッサ）実行可能コードによって実施することができる。機械実行可能コードまたは機械可読コードは、ソフトウェアの形態で提供することができる。使用中、コードはプロセッサ１３０５によって実行することができる。場合によっては、コードは、記憶ユニット１３１５から検索し、プロセッサ１３０５による容易なアクセスのためにメモリ１３１０に記憶することができる。状況によっては、電子記憶ユニット１３１５を排除することができ、機械実行可能命令はメモリ１３１０に格納される。

コードは、事前にコンパイルされ、コードを実行するように適合されたプロセッサを有する機械で使用するように構成することもでき、実行時の間にコンパイルすることもできる。コードは、事前コンパイル方式か、またはコンパイル時方式でコードを実行することを可能にするように選択することができるプログラミング言語で供給することができる。

コンピュータシステム１３０１などの、本明細書において提供されたシステムおよび方法の態様は、プログラミングで具現化することができる。技術の様々な態様は、通常、機械（もしくはプロセッサ）実行可能コードおよび／またはあるタイプの機械可読媒体内で搬送もしくは具現化された関連データの形態の「製品」または「製造品」と考えられてよい。機械実行可能コードは、メモリ（たとえば、読取り専用メモリ、ランダムアクセスメモリ、フラッシュメモリ）またはハードディスクなどの電子記憶ユニットに記憶することができる。「記憶」タイプの媒体は、コンピュータ、プロセッサなどの有形メモリ、または様々な半導体メモリ、テープドライブ、ディスクドライブなどのそれらの関連モジュールのいずれかまたはすべてを含むことができ、それらは、ソフトウェアプログラミングのためにいつでも非一時的なストレージを提供することができる。ソフトウェアのすべてまたは部分は、時々、インターネットまたは様々な他の電気通信ネットワークを介して通信されてよい。そのような通信は、たとえば、あるコンピュータまたはプロセッサから別のコンピュータまたはプロセッサへの、たとえば、管理サーバまたはホストコンピュータからアプリケーションサーバのコンピュータプラットフォームへのソフトウェアのローディングを可能にすることができる。したがって、ソフトウェア要素を運ぶことができる別のタイプの媒体には、有線および光の地上回線ネットワークを介して、かつ様々なエアリンク上で、ローカルデバイス間の物理インターフェースにわたって使用されるような、光、電気、および電磁波が含まれる。有線リンクまたはワイヤレスリンク、光リンクなどの波を搬送する物理的要素も、ソフトウェアを運ぶ媒体と見なされてよい。本明細書で使用される場合、非一時的で有形の「記憶」媒体に限定されない限り、コンピュータまたは機械の「可読媒体」などの用語は、実行のためにプロセッサに命令を提供することに関与する任意の媒体を指す。

したがって、コンピュータ実行可能コードなどの機械可読媒体は、有形記憶媒体、搬送波媒体、または物理伝送媒体を含むが、それらに限定されない多くの形態をとることができる。不揮発性記憶媒体には、たとえば、図面に示されたデータベースなどを実装するために使用され得るものなどの、任意の（１つまたは複数の）コンピュータ内などの任意のストレージデバイスなどの、光ディスクまたは磁気ディスクが含まれる。揮発性記憶媒体には、そのようなコンピュータプラットフォームのメインメモリなどの動的メモリが含まれる。有形伝送媒体には、コンピュータシステム内のバスを備えるワイヤを含む、同軸ケーブル、銅線、および光ファイバが含まれる。搬送波伝送媒体は、電気信号もしくは電磁信号、または無線周波数（ＲＦ）および赤外線（ＩＲ）データ通信中に生成されるものなどの音響波もしくは光波の形態をとることができる。したがって、コンピュータ可読媒体の一般的な形態には、たとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤもしくはＤＶＤ－ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンをもつ任意の他の物理記憶媒体、ＲＡＭ、ＲＯＭ、ＰＲＯＭおよびＥＰＲＯＭ、ＦＬＡＳＨ－ＥＰＲＯＭ、任意の他のメモリチップもしくはカートリッジ、データもしくは命令を転送する搬送波、そのような搬送波を転送するケーブルもしくはリンク、またはコンピュータがプログラミングコードおよび／もしくはデータを読み取ることができる任意の他の媒体が含まれる。これらの形態のコンピュータ可読媒体の多くは、実行のためにプロセッサに１つまたは複数の命令の１つまたは複数のシーケンスを搬送することに関与する場合がある。

コンピュータシステム１３０１は、たとえば、本明細書の他の箇所に記載されたグラフィカルユーザインターフェースを提供するためのユーザインターフェース（ＵＩ）１３４０を備える電子ディスプレイ１３３５を含むか、またはそれと通信することができる。ＵＩの例には、限定なしに、グラフィカルユーザインターフェース（ＧＵＩ）およびウェブベースのユーザインターフェースが含まれる。

本開示の方法およびシステムは、１つまたは複数のアルゴリズムによって実装することができる。アルゴリズムは、中央処理装置１３０５による実行時にソフトウェアによって実施することができる。アルゴリズムは、たとえば、予測モデルなどの訓練されたモデルであり得る。

いくつかの実施形態では、乗り物データの少なくとも一部分は、ＡＩアルゴリズムを使用して生成されない所定のデータ送信方式に従って、リモートエンティティ（たとえば、クラウドアプリケーション）に送信されてよい。たとえば、状況によっては、データ送信がまれであるか、または送信されるデータ量が比較的少ないとき、データ送信方式は、機械学習モデルを使用せずにクラウドアプリケーションからの要求に基づいて生成されてよい。そのような状況では、データ送信は、リモートエンティティと対象乗り物に存在するデータオーケストレータとの間の要求および応答を処理する／渡す中間エンティティ（たとえば、相手先商標製造会社（ＯＥＭ））によって管理されてよい。中間エンティティは、リモートエンティティとデータオーケストレータとの間の修正されていないかまたは処理されたデータ送信要求／応答を渡すためにプロキシとして機能することができる。場合によっては、中間エンティティは、要求に基づいて乗り物データを送信する１台または複数の対象乗り物を決定することができる。場合によっては、中間エンティティはさらに、乗り物データの少なくとも一部分を集約するかまたは組み立て、それを要求アプリケーションに送信することができる。場合によっては、中間エンティティは、乗り物データおよび／または送信に関する情報（たとえば、データソース、データ処理方法など）を記述するメタデータを生成し、メタデータを要求アプリケーションに送信することができる。図１６は、本発明のいくつかの実施形態による、ＯＥＭ１６３０の助けを借りて管理されるデータ送信を概略的に示す。

ＯＥＭ１６３０は、基本的な乗り物データおよび機能を管理することができる。ＯＥＭ１６３０は、本明細書の他の箇所に記載された１つもしくは複数のクラウドアプリケーション、企業クラウド、または他のサードパーティエンティティ１６４０－１、１６４０－２などのリモートエンティティと直接通信することができる。ＯＥＭは、知覚（たとえば、ＡＳＩＣ、ＦＰＧＡ、ＧＰＵアクセラレータ、ＳＩＭＤメモリ、カメラ、Ｌｉｄａｒ、レーダー、ＧＰＳなどのセンサ／検出器）、位置特定および計画（たとえば、データパス処理、ＤＤＲメモリ、位置特定データセット、慣性測定、ＧＮＳＳ）、決定または挙動（たとえば、モーションエンジン、ＥＣＣメモリ、挙動モジュール、調停、予測子）、制御（たとえば、ロックステッププロセッサ、ＤＤＲメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ）、接続およびＩ／Ｏ（たとえば、ＲＦプロセッサ、ネットワークスイッチ、決定論的バス、データ記録）などの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを提供することができる。ＯＥＭは、前述のソフトウェアサービスまたはセンサによって生成されたテレマティクスデータを収集または管理することができる。テレマティクスデータには、たとえば、速度関連データ（たとえば、急加速、速度違反、頻繁な加速）、停止関連データ（たとえば、急ブレーキ、頻繁な停止、頻繁なブレーキ）、方向転換関連データ（たとえば、急な方向転換、方向転換前の加速、出口前の過制動、進路逸脱）、通常運転する経路に関連するデータ（たとえば、高速道路対地方道路、既知の交通渋滞があるエリア、事故率が高い／低いエリア）、または他のデータ（たとえば、疲労した方向転換、いつも高速車線を走行すること、方向指示器の使用）が含まれてよい。ＯＥＭ１６３０は、１つもしくは複数の乗り物１６１０－１、１６１０－２、および／または１つもしくは複数のデータオーケストレータ１６２０－１、１６２０－２と通信することができる。

いくつかの実施形態では、ＯＥＭなどの中間エンティティは、予測モデル管理モジュールからのどの（１つまたは複数の）予測モデルを選択された乗り物または乗り物のフリートに送信するか、およびどの（１つまたは複数の）構成要素がこれらのモデルを受信することができるかを判断するように構成されたデータおよび知識管理システムを管理することができる。場合によっては、（１つまたは複数の）モデルは、クラウドサブスクリプションモジュールを介して（１つまたは複数の）関連の乗り物にＯＴＡで送信されてよい。場合によっては、リモートアプリケーションは、ＯＥＭに要求を送信することによって１つまたは複数の乗り物からのデータを要求することができる。たとえば、保険アプリケーションは、不正を検出し、新しい保険商品を作成し、安全機能のために運転者に割引を提供し、リスクを評価し、事故現場管理、最初の紛失通知、請求処理の強化などの目的で、所定の頻度（たとえば、１週間、２週間、１ヶ月、２ヶ月など）で対象乗り物に関連付けられたＯＥＭシステムからの特定のタイプのデータ（たとえば、ＯＥＭ組込みデバイスによって収集されたデータ）を要求することができる。次いで、ＯＥＭは、データ送信を調整するために、対象乗り物に関連付けられたデータオーケストレータに要求を渡すことができる。要求されたタイプのデータは、データオーケストレータから要求アプリケーション１６４０－１、１６４０－２に直接送信されてよい。

図１７は、データオーケストレータ１７２０と１つまたは複数のクラウドアプリケーションとの間のデータ送信プロセスを示す。場合によっては、１つまたは複数のデータオーケストレータと１つまたは複数のクラウドアプリケーションとの間のデータ送信は、乗り物ＯＥＭ１７３０などの中間エンティティの助けを借りて調整および管理されてよい。データオーケストレータは、本明細書の他の箇所に記載された乗り物と共にローカルに存在してよい。

いくつかの実施形態では、１つまたは複数のクラウドアプリケーションは、特定のタイプの乗り物データを要求する要求１７１０を乗り物ＯＥＭ１７３０に送信することができる。たとえば、要求１７１０は、アプリケーション（たとえば、Ａｐｐ１）によって必要とされるデータのタイプ、データが必要とされる頻度、そのようなタイプのデータが送信される時間期間に関する情報、または対象乗り物の識別番号などの他の情報を含んでよい。たとえば、要求アプリケーションＡｐｐ１（たとえば、保険アプリケーション）は、対象乗り物に関連付けられた乗り物ＯＥＭ１７３０に、対象乗り物から必要とされるデータのタイプおよびそのようなデータの頻度を示す要求を送信することができる。

乗り物ＯＥＭ１７３０は、対象乗り物のデータオーケストレータに要求１７１１を渡す（たとえば、要求メッセージを送信して要求を中継する）ことができる。データオーケストレータに渡される要求１７１１は、元の要求１７１０と同じ修正されていない要求であってよい。代替または追加として、乗り物ＯＥＭ１７３０は、クラウドアプリケーションＡｐｐ１から受信された要求１７１０を処理し、どの乗り物／データオーケストレータが要求１７１１を受信する対象乗り物／データオーケストレータであるかを判断することができる。たとえば、元の要求１７１０は、（たとえば、乗り物ＩＤを知らない）対象乗り物を指定することなく、請求プロセスを強化するためにあるタイプの乗り物からテレマティクスデータを要求することができ、次いで、乗り物ＯＥＭ１７３０は、乗り物タイプの要件を満たす対象乗り物を識別し、識別された対象乗り物／データオーケストレータに要求１７１１を送信することができる。場合によっては、要求は乗り物のグループを指定することができる。たとえば、要求は、特定のモデル（たとえば、Ａｕｄｉ Ａ８）、年式（たとえば、２０１７年）、特定の運転自動化機能を有するモデル（たとえば、車線変更モニタ付きのＡ８）などを指定することができる。ＯＥＭシステムは、それぞれの対象乗り物のデータオーケストレータに要求を渡す（たとえば、要求メッセージを送信して要求を中継する）ことができる。上述されたように、乗り物ＯＥＭは、データオーケストレータと要求アプリケーションとの間で要求および応答を渡すためにプロキシとして機能することができる。これは、乗り物ＩＤまたは他の乗り物情報がサードパーティ（たとえば、クラウドアプリケーション）に公開されない場合があるので、有利なことに、セキュリティの層を追加することができる。

要求１７１１を受信すると、データオーケストレータは、要求をキューにプッシュし、要求の受信を確認応答するために乗り物ＯＥＭ１７３０にメッセージを送り返すことができる。次いで、乗り物ＯＥＭ１７３０は、要求が記録されたことを示すメッセージ（すなわち、応答）を要求アプリケーションに送信することができる。

対象乗り物に関連付けられた１つまたは複数のデータオーケストレータは、要求１７１１に含まれる情報に基づいて、要求された乗り物データを要求アプリケーションに送信することができる。たとえば、１つまたは複数のデータオーケストレータは、要求されたデータ（たとえば、データパケット）を要求アプリケーションに直接送信することができる。

場合によっては、要求／応答メッセージの受け渡しおよび中継に加えて、乗り物ＯＥＭは、データ送信を調整するための指示を送信することができる。たとえば、乗り物ＯＥＭは、送信周期が完了したときに（たとえば、データオーケストレータから完了メッセージを受信すると）、キューから送信要求を削除するようにデータオーケストレータに指示するメッセージをデータオーケストレータに送信することができる。次いで、データオーケストレータは、キューから項目を削除し、項目が削除されたことを示すメッセージを乗り物ＯＥＭに送信することができる。ＯＥＭシステムは、要求が完了したことを示すメッセージを要求アプリケーションに送信することができる。

本発明の好ましい実施形態が本明細書に図示および記載されているが、そのような実施形態が例としてのみ提供されていることが当業者には明らかであろう。本発明が本明細書内に提供された特定の例によって限定されることは意図されていない。本発明は前述の明細書を参照して記載されているが、本明細書の実施形態の説明および図示は、限定的な意味で解釈されることを意図していない。当業者は次に、本発明から逸脱することなく、多数の変形、変更、および置換を思いつくであろう。さらに、本発明のすべての態様は、様々な条件および変数に依存する本明細書に記載された特定の描写、構成、または相対的比率に限定されないことを理解されたい。本明細書に記載された本発明の実施形態に対する様々な代替案が、本発明を実践する際に利用されてよいことが理解されるべきである。したがって、本発明は、そのような代替、修正、変形、または均等物もカバーすることが考えられる。以下の特許請求の範囲が本発明の範囲を定義し、これらの特許請求の範囲内の方法および構造ならびにそれらの均等物がそれらによってカバーされることが意図されている。

Claims (15)

1. 乗り物データを管理するためのシステムであって、前記乗り物データは、乗り物において生成され、および／または、乗り物において格納され、前記乗り物データのうちの少なくともいくつかは、前記乗り物の動作に関してセンサによって収集された捕捉されたデータであり、前記システムは、
   （ｉ）前記乗り物データの１つ以上のサブセットを要求する１つ以上のリモートエンティティに関連するエンティティデータと、（ｉｉ）前記乗り物データの前記１つ以上のサブセットを生成する１つ以上のアプリケーションに関連するアプリケーションデータとを格納するように構成されているデータリポジトリであって、前記データリポジトリは、前記乗り物データが収集または生成される前記乗り物に対してローカルである、データリポジトリと、
   機械学習ベースの予測モデルとユーザ定義規則とを格納するように構成されている知識ベースであって、前記機械学習ベースの予測モデルおよび前記ユーザ定義規則は、データ送信規則を決定するために前記乗り物において使用され、前記データ送信規則は、（ｉ）送信されるべき前記乗り物データの選択されたサブセット、かつ、（ｉｉ）前記乗り物データの前記選択されたサブセットを送信するためのタイミング、かつ、（ｉｉｉ）前記１つ以上のリモートエンティティのうち、前記乗り物データの前記選択されたサブセットを受信するように指定されるリモートエンティティを指定し、前記タイミングは、前記機械学習ベースの予測モデルおよび／または前記ユーザ定義規則に基づいて決定され、前記知識ベースは、少なくとも２つのデータ送信規則を有し、第１のデータ送信規則は、直ちに送信されるべきデータおよび／または前記乗り物が移動している間に送信されるべきデータのためのものであり、第２のデータ送信規則は、前記乗り物が静止している間に送信されなければならないデータのためのものである、知識ベースと、
   前記エンティティデータと前記アプリケーションデータと前記データ送信規則とに少なくとも部分的に基づいて、前記乗り物データの前記選択されたサブセットを送信するように構成されている送信モジュールであって、前記乗り物データの前記選択されたサブセットは、前記乗り物データの前記サブセットのメタデータに少なくとも部分的に基づいて、前記データリポジトリから取り出され、前記乗り物データの前記選択されたサブセットは、前記乗り物データの一部である、送信モジュールと
   を備える、システム。
2. 前記データリポジトリおよび前記知識ベースおよび前記送信モジュールは、前記乗り物に搭載されている、請求項１に記載のシステム。
3. 前記１つ以上のリモートエンティティは、クラウドアプリケーション、データセンタ、サードパーティサーバ、または、別の異なる乗り物を含む、請求項１に記載のシステム。
4. 前記データリポジトリは、前記乗り物データの前記１つ以上のサブセットの可用性、送信タイミング遅延、データの１つ以上のサブセットのデータタイプ、または、送信プロトコルを示すデータを格納する、請求項１に記載のシステム。
5. 前記機械学習ベースの予測モデルは、モデルツリー構造で格納されている、請求項１に記載のシステム。
6. 前記モデルツリー構造は、複数の機械学習ベースの予測モデルの間の関係を表す、請求項５に記載のシステム。
7. 前記モデルツリー構造のノードは、前記機械学習ベースの予測モデルを表し、前記ノードは、モデルアーキテクチャ、モデルパラメータ、訓練データセット、または、試験データセットのうちの少なくとも１つを含む、請求項５に記載のシステム。
8. 前記機械学習ベースの予測モデルは、データセンタに配置されているモデル作成器によって生成される、請求項１に記載のシステム。
9. 前記機械学習ベースの予測モデルは、メタデータおよび前記乗り物データを使用して、訓練され、かつ、試験される、請求項８に記載のシステム。
10. 前記モデル作成器は、前記乗り物に使用可能な予測モデルを生成するように構成されており、前記予測モデルは、前記知識ベースに格納されている、請求項８に記載のシステム。
11. 前記乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または、コネクテッド自律型の乗り物である、請求項１に記載のシステム。
12. 前記乗り物データは、１つ以上の機能構成要素を備えるパイプラインエンジンによって処理され、前記パイプラインエンジンは、前記メタデータのうちの少なくとも一部を生成する、請求項１に記載のシステム。
13. 前記１つ以上の機能構成要素のうちの少なくとも１つは、ユーザインターフェースを介して一組の機能から選択される、請求項１２に記載のシステム。
14. 前記１つ以上の機能構成要素のうちの少なくとも１つは、シナリオデータオブジェクトを作成するように構成されており、前記シナリオデータオブジェクトは、前記メタデータの使用されるシナリオを指定するために使用可能である、請求項１２に記載のシステム。
15. 前記メタデータは、前記機械学習ベースの予測モデルを訓練するために、前記乗り物データの訓練サブセットを検索するために使用可能である、請求項１４に記載のシステム。

Images