IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ シナプス・パートナーズ・エルエルシーの特許一覧

特許7540728乗り物データを管理するためのシステムおよび方法
<>
  • 特許-乗り物データを管理するためのシステムおよび方法 図1
  • 特許-乗り物データを管理するためのシステムおよび方法 図2
  • 特許-乗り物データを管理するためのシステムおよび方法 図3
  • 特許-乗り物データを管理するためのシステムおよび方法 図4
  • 特許-乗り物データを管理するためのシステムおよび方法 図5
  • 特許-乗り物データを管理するためのシステムおよび方法 図6
  • 特許-乗り物データを管理するためのシステムおよび方法 図7
  • 特許-乗り物データを管理するためのシステムおよび方法 図8
  • 特許-乗り物データを管理するためのシステムおよび方法 図9
  • 特許-乗り物データを管理するためのシステムおよび方法 図10
  • 特許-乗り物データを管理するためのシステムおよび方法 図11
  • 特許-乗り物データを管理するためのシステムおよび方法 図12
  • 特許-乗り物データを管理するためのシステムおよび方法 図13
  • 特許-乗り物データを管理するためのシステムおよび方法 図14
  • 特許-乗り物データを管理するためのシステムおよび方法 図15
  • 特許-乗り物データを管理するためのシステムおよび方法 図16
  • 特許-乗り物データを管理するためのシステムおよび方法 図17
  • 特許-乗り物データを管理するためのシステムおよび方法 図18
  • 特許-乗り物データを管理するためのシステムおよび方法 図19
  • 特許-乗り物データを管理するためのシステムおよび方法 図20
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-19
(45)【発行日】2024-08-27
(54)【発明の名称】乗り物データを管理するためのシステムおよび方法
(51)【国際特許分類】
   G06F 16/21 20190101AFI20240820BHJP
【FI】
G06F16/21
【請求項の数】 15
(21)【出願番号】P 2021524162
(86)(22)【出願日】2019-11-06
(65)【公表番号】
(43)【公表日】2022-02-08
(86)【国際出願番号】 US2019060094
(87)【国際公開番号】W WO2020097221
(87)【国際公開日】2020-05-14
【審査請求日】2022-10-14
(31)【優先権主張番号】62/757,517
(32)【優先日】2018-11-08
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/799,697
(32)【優先日】2019-01-31
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/852,769
(32)【優先日】2019-05-24
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/875,919
(32)【優先日】2019-07-18
(33)【優先権主張国・地域又は機関】US
【前置審査】
(73)【特許権者】
【識別番号】521238890
【氏名又は名称】シナプス・パートナーズ・エルエルシー
(74)【代理人】
【識別番号】100078282
【弁理士】
【氏名又は名称】山本 秀策
(74)【代理人】
【識別番号】100113413
【弁理士】
【氏名又は名称】森下 夏樹
(74)【代理人】
【識別番号】100181674
【弁理士】
【氏名又は名称】飯田 貴敏
(74)【代理人】
【識別番号】100181641
【弁理士】
【氏名又は名称】石川 大輔
(74)【代理人】
【識別番号】230113332
【弁護士】
【氏名又は名称】山本 健策
(72)【発明者】
【氏名】シモウディス,エバンゲロス
【審査官】早川 学
(56)【参考文献】
【文献】特開2018-025865(JP,A)
【文献】特表2005-537687(JP,A)
【文献】国際公開第2018/181974(WO,A1)
【文献】中国特許出願公開第107918753(CN,A)
【文献】特開2003-207342(JP,A)
【文献】Manjiang Hu,外4名,"Decision Tree-Based Maneuver Prediction for Driver Rear-End Risk-Avoidance Behaviors in Cut-In Scenarios",Journal of Advanced Transportation,[online],2017年02月15日,Volume 2017,Article ID 7170358,[令和5年6月22日検索], インターネット, <https://doi.org/10.1155/2017/7170358>
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
(57)【特許請求の範囲】
【請求項1】
乗り物データを管理するためのシステムであって、前記乗り物データは、乗り物において生成され、および/または、乗り物において格納され、前記乗り物データのうちの少なくともいくつかは、前記乗り物の動作に関してセンサによって収集された捕捉されたデータであり、前記システムは、
(i)前記乗り物データの1つ以上のサブセットを要求する1つ以上のリモートエンティティに関連するエンティティデータと、(ii)前記乗り物データの前記1つ以上のサブセットを生成する1つ以上のアプリケーションに関連するアプリケーションデータとを格納するように構成されているデータリポジトリであって、前記データリポジトリは、前記乗り物データが収集または生成される前記乗り物に対してローカルである、データリポジトリと、
機械学習ベースの予測モデルとユーザ定義規則とを格納するように構成されている知識ベースであって、前記機械学習ベースの予測モデルおよび前記ユーザ定義規則は、データ送信規則を決定するために前記乗り物において使用され、前記データ送信規則は、(i)送信されるべき前記乗り物データの選択されたサブセット、かつ、(ii)前記乗り物データの前記選択されたサブセットを送信するためのタイミング、かつ、(iii)前記1つ以上のリモートエンティティのうち、前記乗り物データの前記選択されたサブセットを受信するように指定されるリモートエンティティ指定し、前記タイミングは、前記機械学習ベースの予測モデルおよび/または前記ユーザ定義規則に基づいて決定され、前記知識ベースは、少なくとも2つのデータ送信規則を有し、第1のデータ送信規則は、直ちに送信されるべきデータおよび/または前記乗り物が移動している間に送信されるべきデータのためのものであり、第2のデータ送信規則は、前記乗り物が静止している間に送信されなければならないデータのためのものである、知識ベースと、
前記エンティティデータと前記アプリケーションデータと前記データ送信規則とに少なくとも部分的に基づいて、前記乗り物データの前記選択されたサブセットを送信するように構成されている送信モジュールであって、前記乗り物データの前記選択されたサブセットは、前記乗り物データの前記サブセットのメタデータに少なくとも部分的に基づいて、前記データリポジトリから取り出され、前記乗り物データの前記選択されたサブセットは、前記乗り物データの一部である、送信モジュールと
を備える、システム。
【請求項2】
前記データリポジトリおよび前記知識ベースおよび前記送信モジュールは、前記乗り物に搭載されている、請求項1に記載のシステム。
【請求項3】
前記1つ以上のリモートエンティティは、クラウドアプリケーション、データセンタ、サードパーティサーバ、または、別の異なる乗り物を含む、請求項1に記載のシステム。
【請求項4】
前記データリポジトリは、前記乗り物データの前記1つ以上のサブセットの可用性、送信タイミング遅延、データの1つ以上のサブセットのデータタイプ、または、送信プロトコルを示すデータを格納する、請求項1に記載のシステム。
【請求項5】
前記機械学習ベースの予測モデルは、モデルツリー構造で格納されている、請求項1に記載のシステム。
【請求項6】
前記モデルツリー構造は、複数の機械学習ベースの予測モデルの間の関係を表す、請求項5に記載のシステム。
【請求項7】
前記モデルツリー構造のノードは、前記機械学習ベースの予測モデルを表し、前記ノードは、モデルアーキテクチャ、モデルパラメータ、訓練データセット、または、試験データセットのうちの少なくとも1つを含む、請求項5に記載のシステム。
【請求項8】
前記機械学習ベースの予測モデルは、データセンタに配置されているモデル作成器によって生成される、請求項1に記載のシステム。
【請求項9】
前記機械学習ベースの予測モデルは、メタデータおよび前記乗り物データを使用して、訓練され、かつ、試験される、請求項8に記載のシステム。
【請求項10】
前記モデル作成器は、前記乗り物に使用可能な予測モデルを生成するように構成されており、前記予測モデルは、前記知識ベースに格納されている、請求項8に記載のシステム。
【請求項11】
前記乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または、コネクテッド自律型の乗り物である、請求項1に記載のシステム。
【請求項12】
前記乗り物データは、1つ以上の機能構成要素を備えるパイプラインエンジンによって処理され、前記パイプラインエンジンは、前記メタデータのうちの少なくとも一部を生成する、請求項1に記載のシステム。
【請求項13】
前記1つ以上の機能構成要素のうちの少なくとも1つは、ユーザインターフェースを介して一組の機能から選択される、請求項12に記載のシステム。
【請求項14】
前記1つ以上の機能構成要素のうちの少なくとも1つは、シナリオデータオブジェクトを作成するように構成されており、前記シナリオデータオブジェクトは、前記メタデータの使用されるシナリオを指定するために使用可能である、請求項12に記載のシステム。
【請求項15】
前記メタデータは、前記機械学習ベースの予測モデルを訓練するために、前記乗り物データの訓練サブセットを検索するために使用可能である、請求項14に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、2018年11月8日に出願された米国仮特許出願第62/757,517号、2019年1月31日に出願された米国仮特許出願第62/799,697号、2019年5月24日に出願された米国仮特許出願第62/852,769号、および2019年7月18日に出願された米国仮特許出願第62/875,919号の優先権を主張し、それらの各々は参照により全体が本明細書に組み込まれる。
【背景技術】
【0002】
自律型の乗り物は、その環境を検知し、ユーザ入力をほとんどまたは全く伴わずにナビゲートすることが可能であり得る乗り物である。自律型の乗り物システムは、レーダー、レーザー画像検出および測距(Lidar)、画像センサなどの検知デバイスを使用してその環境を検知することができる。自律型の乗り物システムはさらに、全地球測位システム(GPS)技術、ナビゲーションシステム、乗り物間通信、乗り物対基盤技術、および/またはドライブバイワイヤシステムからの情報を使用して乗り物をナビゲートすることができる。
【0003】
単一の高度に自動化された乗り物または自律型の乗り物は、1時間当たり1~5テラバイト(1~5TB)の生データを生成することができる。1日当たり14~16時間動作することは、1日当たり乗り物当たり50テラバイト、または1年当たり乗り物当たり20ペタバイトだけの量を生成することを意味してよい。5,000台の高度に自動化された乗り物の控えめなフリート(ニューヨーク市だけで14,000台のタクシーが存在する)は、年間100エクサバイトを超える生データを生成する可能性がある。そのようなデータは、たとえば、通信、データ管理、フェイルセーフ、ならびにミドルウェアおよびソフトウェアアプリケーションなどのすべてのサポートタスクを含んでよい自律型の乗り物スタックまたは自動化された乗り物スタックによって生成されてよい。そのようなデータはまた、乗り物間通信または交通基盤から生成されたデータを含んでよい。自律型の乗り物スタックまたは自動化された乗り物スタックは、知覚、データ融合、クラウド/オーバージエア(OTA)、位置特定、挙動(別名運転ポリシー)、制御、および安全性などの複数の領域を、エンドツーエンド自動化を処理することができるプラットフォームに統合することができる。たとえば、自律型の乗り物スタックまたは自動化された乗り物スタックは、知覚(たとえば、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、グラフィック処理装置(GPU)アクセラレータ、単一命令複数データ(SIMD)メモリ、カメラ、Lidar、レーダー、GPSなどのセンサ/検出器)、位置特定および計画(たとえば、データパス処理、ダブルデータレート(DDR)メモリ、位置特定データセット、慣性測定、全地球航法衛星システム(GNSS))、決定または挙動(たとえば、モーションエンジン、エラー訂正コード(ECC)メモリ、挙動モジュール、調停、予測子)、制御(たとえば、ロックステッププロセッサ、DDRメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ)、接続および入出力(I/O)(たとえば、無線周波数(RF)プロセッサ、ネットワークスイッチ、決定論的バス、データ記録)、ならびに様々な他のものなどの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを含んでよい。そのようなデータは、自律型の乗り物スタックまたは自動化された乗り物スタックの一部として、1つもしくは複数のセンサおよび/または様々な他のモジュールによって生成されてよい。
【発明の概要】
【発明が解決しようとする課題】
【0004】
かなりの量の自律型の乗り物データまたは自動化された乗り物データは価値があり得、コスト、タイミング、およびプライバシーの様々な優先順位に対して、乗り物、エッジ基盤、およびクラウドのコンテキストで識別、選択、処理、送信、および格納される必要があり得る。
【0005】
本明細書では、安全で、確実で、費用効果が高く、拡張可能であり、オープンアプリケーションを促進する方式で自律型の乗り物データまたは自動化された乗り物データを管理するための方法およびシステムに対する必要性が認識されている。
【課題を解決するための手段】
【0006】
本開示は、乗り物データを管理するためのシステムおよび方法を提供する。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造(たとえば、小規模バッチ製造および自律型の乗り物の製品化)、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。本明細書で使用される「乗り物データ」という用語は、一般に、文脈上別段の示唆がない限り、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物などの任意のタイプの乗り物によって生成されたデータを指す。本明細書で使用される「自律型の乗り物データ」という用語は、一般に、自律型の乗り物によって生成されたデータを指す。本開示の実施形態は自律型の乗り物に関して記載されているが、実施形態は自動化された乗り物に適用可能または適合され得ることが諒解されるべきである。
【0007】
いくつかの実施形態では、提供されたデータ管理システムは、自律型の乗り物または自動化された乗り物に搭載されたデータオーケストレータを備える場合がある。データオーケストレータは、乗り物データを編成および管理することが可能であり得る。場合によっては、自律型の乗り物データは、自律型の乗り物スタックによって生成されたデータ(たとえば、自律型の乗り物のセンサによって捕捉されたデータ)、ならびに運転者および乗客のデータを含んでよい。データオーケストレータは、どの乗り物データ(のどの部分)がどのデータセンタまたはサードパーティエンティティに通信されるべきか、およびそのようなデータがいつ送信されるかを判断するように構成されてよい。たとえば、自律型の乗り物データの一部は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータは、自律型の乗り物が静止しているとき(次の割当て/タスクを待っている間、または保守されている間)に通信されてよい。
【0008】
一態様では、乗り物の乗り物データを管理するための方法が提供される。方法は、(a)乗り物から乗り物データを収集することであって、乗り物データが少なくとも1テラバイトのサイズを有する、収集することと、(b)乗り物データを処理して乗り物データに対応するメタデータを生成することであって、乗り物データがデータベースに格納される、生成することと、(c)メタデータの少なくとも一部分を使用してデータベースから乗り物データのサブセットを検索することであって、乗り物データのサブセットが乗り物データよりも小さいサイズを有する、検索することと、(d)乗り物データのサブセットを格納または送信することとを含んでよい。
【0009】
いくつかの実施形態では、方法は、(b)で処理された乗り物データをデータベースに格納することをさらに含む。いくつかの実施形態では、(c)のステップは、メタデータを使用して、予測モデルを訓練するためにデータベースから乗り物データのサブセットを検索することを含み、予測モデルは乗り物データを管理するために使用される。場合によっては、予測モデルは、乗り物からリモートエンティティに乗り物データを送信するために使用可能である。たとえば、方法は、予測モデルを使用して、乗り物からデータオーケストレータによって管理されるデータベースに乗り物データを送信することをさらに含む。
【0010】
いくつかの実施形態では、方法は、乗り物データにアクセスするユーザからの要求を受信することと、要求に少なくとも部分的に基づいてメタデータの少なくとも一部分を選択することとをさらに含む。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。
【0011】
別の態様では、乗り物の乗り物データを管理するためのシステムが提供される。システムは、データベースと、データベースに動作可能に結合された1つまたは複数のコンピュータプロセッサとを備え、1つまたは複数のコンピュータプロセッサは、(i)乗り物から乗り物データを収集することであって、乗り物データが少なくとも1テラバイトのサイズを有する、収集することと、(ii)乗り物データを処理して乗り物データに対応するメタデータを生成することであって、乗り物データがデータベースに格納される、生成することと、(iii)メタデータの少なくとも一部分を使用してデータベースから乗り物データのサブセットを検索することであって、乗り物データのサブセットが乗り物データよりも小さいサイズを有する、検索することと、(iv)乗り物データのサブセットを格納または送信することとを行うように、個別にまたはまとめてプログラムされる。
【0012】
いくつかの実施形態では、乗り物データは、少なくとも、1つまたは複数のセンサによって捕捉されたセンサデータと、乗り物に搭載された1つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む。場合によっては、メタデータは、1つもしくは複数のセンサのうちの1つのセンサによって生成された第1のメタデータ、または1つもしくは複数のアプリケーションのうちの1つのアプリケーションによって生成された第2のメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物の1つまたは複数のセンサによって収集されたセンサデータを整列させることによって生成される。いくつかの実施形態では、メタデータは、予測モデルを訓練するためにデータベースから乗り物データのサブセットを検索するために使用され、予測モデルは乗り物データを管理するために使用される。場合によっては、予測モデルは、乗り物からリモートエンティティに乗り物データを送信するために使用可能である。場合によっては、予測モデルは、乗り物からシステムによって管理されるデータベースに乗り物データを送信するために使用可能である。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または自律型の乗り物である。
【0013】
本開示の別の関連するさらに別個の態様は、乗り物データを管理するためのデータオーケストレータを提供する。データオーケストレータは、自律型の乗り物に搭載される場合がある。データオーケストレータは、(i)乗り物データの1つまたは複数のサブセットを要求する1つまたは複数のリモートエンティティに関連するデータ、および(ii)乗り物データの1つまたは複数のサブセットを生成する1つまたは複数のアプリケーションに関連するデータを格納するように構成されたデータリポジトリであって、データリポジトリが、乗り物データが収集または生成される乗り物に対してローカルである、データリポジトリと、機械学習ベースの予測モデルおよびデータ送信規則を決定するためのユーザ定義規則を格納するように構成された知識ベースであって、(i)送信されるべき乗り物データの選択された部分、(ii)乗り物データの選択された部分を送信するとき、および(iii)乗り物データの選択された部分を受信するための1つまたは複数のリモートエンティティのうちの1つのリモートエンティティを備える、知識ベースと、リポジトリに格納されたデータおよび送信規則に基づいて乗り物データの一部分を送信するように構成された送信モジュールとを備えてよい。
【0014】
いくつかの実施形態では、リポジトリ、知識ベース、および送信モジュールは乗り物に搭載されている。いくつかの実施形態では、1つまたは複数のリモートエンティティは、クラウドアプリケーション、データセンタ、サードパーティサーバ、または別の乗り物を含む。いくつかの実施形態では、データリポジトリは、乗り物データの1つまたは複数のサブセットの可用性、送信タイミング遅延、関連するデータのサブセットのデータタイプ、または送信プロトコルを示すデータを格納する。
【0015】
いくつかの実施形態では、機械学習ベースの予測モデルは、モデルツリー構造に格納される。場合によっては、モデルツリー構造は、機械学習ベースの予測モデル間の関係を表す。場合によっては、モデルツリー構造のノードは機械学習ベースの予測モデルを表し、ノードはモデルアーキテクチャ、モデルパラメータ、訓練データセット、または試験データセットのうちの少なくとも1つを含む。
【0016】
いくつかの実施形態では、機械学習ベースの予測モデルは、データセンタに配置されたモデル作成器によって生成される。場合によっては、機械学習ベースの予測モデルは、メタデータおよび乗り物データを使用して訓練および試験される。場合によっては、モデル作成器は、乗り物に使用可能な予測モデルを生成するように構成される。
【0017】
いくつかの実施形態では、知識ベースは、乗り物に使用可能な予測モデルを格納する。いくつかの実施形態では、乗り物データの選択された部分は、乗り物データのサブセットのうちの1つまたは複数の集約を含む。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。
【0018】
本開示の別の態様は、乗り物データを管理するための方法を提供する。方法は、(a)クラウドにおいて、乗り物から送信された乗り物データを受信することであって、乗り物データが少なくともセンサデータを含む、受信することと、(b)乗り物データを処理して乗り物データに対応するメタデータを生成することであって、メタデータがセンサデータを捕捉するセンサによって生成されたデータを含む、生成することと、(d)メタデータをメタデータデータベースに格納することとを含む。
【0019】
いくつかの実施形態では、乗り物データはストリームデータおよびバッチデータを含む。いくつかの実施形態では、乗り物データはアプリケーションデータを含む。場合によっては、メタデータは、アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む。
【0020】
いくつかの実施形態では、乗り物データはパイプラインエンジンによって処理される。場合によっては、パイプラインエンジンは1つまたは複数の機能構成要素を備える。たとえば、1つまたは複数の機能構成要素のうちの少なくとも1つは、ユーザインターフェースを介して一組の機能から選択される。場合によっては、1つまたは複数の機能構成要素のうちの少なくとも1つは、シナリオデータオブジェクトを作成するように構成され、シナリオデータオブジェクトは特定のメタデータが使用されるシナリオを指定するためのものである。
【0021】
いくつかの実施形態では、(b)で処理された乗り物データは、クラウドの一部としての1つまたは複数のデータベースに格納される。場合によっては、方法は、1つまたは複数のデータベースに格納された乗り物データを使用して予測モデルを訓練することをさらに含む。場合によっては、予測モデルは、乗り物から乗り物データの少なくともサブセットを検索するために使用される。場合によっては、メタデータは、予測モデルを訓練するために1つまたは複数のデータベースから乗り物データのサブセットを検索するために使用される。方法は、予測モデルの目標に従って乗り物データのサブセットに対して適切性分析を実行することと、適切性分析の結果に基づいて乗り物データのサブセットを補正することとをさらに含む。
【0022】
いくつかの実施形態では、メタデータは、(b)における乗り物データの処理に関連するメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物データの1つまたは複数のサブセットを検索するために使用可能である。いくつかの実施形態では、乗り物データの少なくとも一部分は送信方式に基づいて送信され、送信方式はクラウドからの要求に基づいて決定される。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、または自律型の乗り物である。
【0023】
本開示の別の態様は、乗り物の乗り物データを管理するためのシステムを提供する。システムは、データベースと、データベースに動作可能に結合された1つまたは複数のコンピュータプロセッサとを備え、1つまたは複数のコンピュータプロセッサは、(i)乗り物から送信された乗り物データを受信することであって、乗り物データが少なくともセンサデータを含む、受信することと、(ii)乗り物データを処理して乗り物データに対応するメタデータを生成することであって、メタデータがセンサデータを捕捉するセンサによって生成されたデータを含む、生成することと、(iii)メタデータをデータベースに格納することとを行うように、個別にまたはまとめてプログラムされる。
【0024】
いくつかの実施形態では、乗り物データはストリームデータおよびバッチデータを含む。いくつかの実施形態では、乗り物データはアプリケーションデータを含む。場合によっては、メタデータは、アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む。
【0025】
いくつかの実施形態では、乗り物データはパイプラインエンジンによって処理される。場合によっては、パイプラインエンジンは1つまたは複数の機能構成要素を備える。場合によっては、1つまたは複数の機能構成要素のうちの少なくとも1つは、ユーザインターフェースを介して一組の機能から選択される。場合によっては、1つまたは複数の機能構成要素のうちの少なくとも1つは、シナリオデータオブジェクトを作成するように構成され、シナリオデータオブジェクトは特定のメタデータが使用されるシナリオを指定するためのものである。
【0026】
いくつかの実施形態では、1つまたは複数のプロセッサは、データベースに格納された乗り物データを使用して予測モデルをさらに訓練するようにプログラムされる。場合によっては、予測モデルは、乗り物から乗り物データの少なくともサブセットを検索するために使用される。いくつかの実施形態では、メタデータは、乗り物データの処理に関連するメタデータをさらに含む。いくつかの実施形態では、メタデータは、乗り物データの1つまたは複数のサブセットを検索するために使用可能である。いくつかの実施形態では、乗り物データの少なくとも一部分は送信方式に基づいて送信され、送信方式は要求に基づいて決定される。いくつかの実施形態では、乗り物は、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である。
【0027】
本開示の別の態様は、1つまたは複数のコンピュータプロセッサによる実行時に、本明細書の上記または他の箇所の方法のいずれかを実施する機械実行可能コードを含む、非一時的コンピュータ可読媒体を提供する。
【0028】
本開示の別の態様は、1つまたは複数のコンピュータプロセッサおよびそれらに結合されたコンピュータメモリを備えるシステムを提供する。コンピュータメモリは、1つまたは複数のコンピュータプロセッサによる実行時に、本明細書の上記または他の箇所の方法のいずれかを実施する機械実行可能コードを含む。
【0029】
本開示の追加の態様および利点は、以下の発明を実施するための形態から当業者には容易に明らかになり、本開示の例示的な実施形態のみが図示および記載される。実現されるように、本開示は、他の異なる実施形態が可能であり、そのいくつかの詳細は、すべてが本開示から逸脱することなく、様々な明白な点で修正が可能である。したがって、図面および説明は、本質的に例示と見なされるべきであり、限定と見なされるべきではない。
本発明は、例えば、以下を提供する。
(項目1)
乗り物の乗り物データを管理するための方法であって、
(a)前記乗り物から前記乗り物データを収集するステップであって、前記乗り物データが少なくとも1テラバイトのサイズを有する、ステップと、
(b)前記乗り物データを処理して前記乗り物データに対応するメタデータを生成するステップであって、前記乗り物データがデータベースに格納される、ステップと、
(c)前記メタデータの少なくとも一部分を使用して前記データベースから前記乗り物データのサブセットを検索するステップであって、前記乗り物データのサブセットが前記乗り物データよりも小さいサイズを有する、ステップと、
(d)前記乗り物データの前記サブセットを格納または送信するステップと
を含む、方法。
(項目2)
前記乗り物データが、少なくとも、1つまたは複数のセンサによって捕捉されたセンサデータと、前記乗り物に搭載された1つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む、項目1に記載の方法。
(項目3)
前記メタデータが、前記1つもしくは複数のセンサのうちの1つのセンサによって生成された第1のメタデータ、または前記1つもしくは複数のアプリケーションのうちの1つのアプリケーションによって生成された第2のメタデータをさらに含む、項目2に記載の方法。
(項目4)
前記乗り物データを処理するステップが、前記乗り物の1つまたは複数のセンサによって収集されたセンサデータを整列させるステップを含む、項目1に記載の方法。
(項目5)
(b)で処理された前記乗り物データを前記データベースに格納するステップをさらに含む、項目1に記載の方法。
(項目6)
(c)が、前記メタデータを使用して、予測モデルを訓練するために前記データベースから前記乗り物データの前記サブセットを検索するステップを含み、前記予測モデルが前記乗り物データを管理するために使用される、項目1に記載の方法。
(項目7)
前記予測モデルが、前記乗り物からリモートエンティティに前記乗り物データを送信するために使用可能である、項目6に記載の方法。
(項目8)
前記予測モデルを使用して、前記乗り物から前記データオーケストレータによって管理されるデータベースに前記乗り物データを送信するステップをさらに含む、項目7に記載の方法。
(項目9)
前記乗り物データにアクセスするユーザからの要求を受信するステップと、前記要求に少なくとも部分的に基づいて前記メタデータの前記少なくとも一部分を選択するステップとをさらに含む、項目1に記載の方法。
(項目10)
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目1に記載の方法。
(項目11)
乗り物の乗り物データを管理するためのシステムであって、
データベースと、
前記データベースに動作可能に結合された1つまたは複数のコンピュータプロセッサと
を備え、
前記1つまたは複数のコンピュータプロセッサが、(i)前記乗り物から前記乗り物データを収集することであって、前記乗り物データが少なくとも1テラバイトのサイズを有する、収集することと、(ii)前記乗り物データを処理して前記乗り物データに対応するメタデータを生成することであって、前記乗り物データが前記データベースに格納される、生成することと、(iii)前記メタデータの少なくとも一部分を使用して前記データベースから前記乗り物データのサブセットを検索することであって、前記乗り物データのサブセットが前記乗り物データよりも小さいサイズを有する、検索することと、(iv)前記乗り物データの前記サブセットを格納または送信することとを行うように、個別にまたはまとめてプログラムされる、
システム。
(項目12)
前記乗り物データが、少なくとも、1つまたは複数のセンサによって捕捉されたセンサデータと、前記乗り物に搭載された1つまたは複数のアプリケーションによって生成されたアプリケーションデータとを含む、項目11に記載のシステム。
(項目13)
前記メタデータが、前記1つもしくは複数のセンサのうちの1つのセンサによって生成された第1のメタデータ、または前記1つもしくは複数のアプリケーションのうちの1つのアプリケーションによって生成された第2のメタデータをさらに含む、項目12に記載のシステム。
(項目14)
前記メタデータが、前記乗り物の1つまたは複数のセンサによって収集されたセンサデータを整列させることによって生成される、項目11に記載のシステム。
(項目15)
前記メタデータが、予測モデルを訓練するために前記データベースから前記乗り物データの前記サブセットを検索するために使用され、前記予測モデルが前記乗り物データを管理するために使用される、項目11に記載のシステム。
(項目16)
前記予測モデルが、前記乗り物からリモートエンティティに前記乗り物データを送信するために使用可能である、項目15に記載のシステム。
(項目17)
前記予測モデルが、前記乗り物から前記システムによって管理される前記データベースに前記乗り物データを送信するために使用可能である、項目16に記載のシステム。
(項目18)
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目11に記載のシステム。
(項目19)
乗り物データを管理するためのデータオーケストレータであって、
(i)前記乗り物データの1つまたは複数のサブセットを要求する1つまたは複数のリモートエンティティに関連するデータ、および(ii)前記乗り物データの前記1つまたは複数のサブセットを生成する1つまたは複数のアプリケーションに関連するデータを格納するように構成されたデータリポジトリであって、前記データリポジトリが、前記乗り物データが収集または生成される前記乗り物に対してローカルである、データリポジトリと、
機械学習ベースの予測モデルおよびデータ送信規則を決定するためのユーザ定義規則を格納するように構成された知識ベースであって、(i)送信されるべき前記乗り物データの選択された部分、(ii)前記乗り物データの前記選択された部分を送信するとき、および(iii)前記乗り物データの前記選択された部分を受信するための前記1つまたは複数のリモートエンティティのうちの1つのリモートエンティティを備える、知識ベースと、
前記リポジトリに格納された前記データおよび前記送信規則に基づいて前記乗り物データの一部分を送信するように構成された送信モジュールと
を備える、データオーケストレータ。
(項目20)
前記リポジトリ、知識ベース、および前記送信モジュールが、前記乗り物に搭載されている、項目19に記載のデータオーケストレータ。
(項目21)
前記1つまたは複数のリモートエンティティが、クラウドアプリケーション、データセンタ、サードパーティサーバ、または別の乗り物を含む、項目19に記載のデータオーケストレータ。
(項目22)
前記データリポジトリが、前記乗り物データの前記1つまたは複数のサブセットの可用性、送信タイミング遅延、前記関連するデータのサブセットのデータタイプ、または送信プロトコルを示すデータを格納する、項目19に記載のデータオーケストレータ。
(項目23)
前記機械学習ベースの予測モデルが、モデルツリー構造に格納される、項目19に記載のデータオーケストレータ。
(項目24)
前記モデルツリー構造が、機械学習ベースの予測モデル間の関係を表す、項目23に記載のデータオーケストレータ。
(項目25)
前記モデルツリー構造のノードが機械学習ベースの予測モデルを表し、前記ノードがモデルアーキテクチャ、モデルパラメータ、訓練データセット、または試験データセットのうちの少なくとも1つを含む、項目23に記載のデータオーケストレータ。
(項目26)
前記機械学習ベースの予測モデルが、データセンタに配置されたモデル作成器によって生成される、項目19に記載のデータオーケストレータ。
(項目27)
前記機械学習ベースの予測モデルが、メタデータおよび前記乗り物データを使用して訓練および試験される、項目26に記載のデータオーケストレータ。
(項目28)
前記モデル作成器が、前記乗り物に使用可能な予測モデルを生成するように構成される、項目26に記載のデータオーケストレータ。
(項目29)
前記知識ベースが、前記乗り物に使用可能な予測モデルを格納する、項目19に記載のデータオーケストレータ。
(項目30)
前記乗り物データの前記選択された部分が、乗り物データの前記サブセットのうちの1つまたは複数の集約を含む、項目19に記載のデータオーケストレータ。
(項目31)
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目19に記載のデータオーケストレータ。
(項目32)
乗り物データを管理するための方法であって、
(a)クラウドにおいて、乗り物から送信された乗り物データを受信するステップであって、前記乗り物データが少なくともセンサデータを含む、ステップと、
(b)前記乗り物データを処理して前記乗り物データに対応するメタデータを生成するステップであって、前記メタデータが前記センサデータを捕捉するセンサによって生成されたデータを含む、ステップと、
(c)前記メタデータをメタデータデータベースに格納するステップと
を含む、方法。
(項目33)
前記乗り物データが、ストリームデータおよびバッチデータを含む、項目32に記載の方法。
(項目34)
前記乗り物データが、アプリケーションデータを含む、項目32に記載の方法。
(項目35)
前記メタデータが、前記アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む、項目34に記載の方法。
(項目36)
前記乗り物データが、パイプラインエンジンによって処理される、項目32に記載の方法。
(項目37)
前記パイプラインエンジンが、1つまたは複数の機能構成要素を備える、項目36に記載の方法。
(項目38)
前記1つまたは複数の機能構成要素のうちの少なくとも1つが、ユーザインターフェースを介して一組の機能から選択される、項目37に記載の方法。
(項目39)
前記1つまたは複数の機能構成要素のうちの少なくとも1つが、シナリオデータオブジェクトを作成するように構成され、前記シナリオデータオブジェクトが特定のメタデータが使用されるシナリオを指定するためのものである、項目37に記載の方法。
(項目40)
(b)で処理された前記乗り物データが、前記クラウドの一部としての1つまたは複数のデータベースに格納される、項目32に記載の方法。
(項目41)
前記1つまたは複数のデータベースに格納された前記乗り物データを使用して予測モデルを訓練するステップをさらに含む、項目40に記載の方法。
(項目42)
前記予測モデルが、前記乗り物から前記乗り物データの少なくともサブセットを検索するために使用される、項目41に記載の方法。
(項目43)
前記メタデータが、前記予測モデルを訓練するために前記1つまたは複数のデータベースから前記乗り物データのサブセットを検索するために使用される、項目41に記載の方法。
(項目44)
前記予測モデルの目標に従って前記乗り物データの前記サブセットに対して適切性分析を実行するステップをさらに含む、項目43に記載の方法。
(項目45)
前記適切性分析の結果に基づいて前記乗り物データの前記サブセットを補正するステップをさらに含む、項目44に記載の方法。
(項目46)
前記メタデータが、(b)における前記乗り物データの処理に関連するメタデータをさらに含む、項目32に記載の方法。
(項目47)
前記メタデータが、前記乗り物データの1つまたは複数のサブセットを検索するために使用可能である、項目32に記載の方法。
(項目48)
前記乗り物データの少なくとも一部分が送信方式に基づいて送信され、前記送信方式が前記クラウドからの要求に基づいて決定される、項目32に記載の方法。
(項目49)
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目32に記載の方法。
(項目50)
乗り物の乗り物データを管理するためのシステムであって、
データベースと、
前記データベースに動作可能に結合された1つまたは複数のコンピュータプロセッサと
を備え、
前記1つまたは複数のコンピュータプロセッサが、(i)乗り物から送信された乗り物データを受信することであって、前記乗り物データが少なくともセンサデータを含む、受信することと、(ii)前記乗り物データを処理して前記乗り物データに対応するメタデータを生成することであって、前記メタデータが前記センサデータを捕捉するセンサによって生成されたデータを含む、生成することと、(iii)前記メタデータを前記データベースに格納することとを行うように、個別にまたはまとめてプログラムされる、
システム。
(項目51)
前記乗り物データが、ストリームデータおよびバッチデータを含む、項目50に記載のシステム。
(項目52)
前記乗り物データが、アプリケーションデータを含む、項目50に記載のシステム。
(項目53)
前記メタデータが、前記アプリケーションデータを生成するアプリケーションに関連するメタデータをさらに含む、項目52に記載のシステム。
(項目54)
前記乗り物データが、パイプラインエンジンによって処理される、項目50に記載のシステム。
(項目55)
前記パイプラインエンジンが、1つまたは複数の機能構成要素を備える、項目54に記載のシステム。
(項目56)
前記1つまたは複数の機能構成要素のうちの少なくとも1つが、ユーザインターフェースを介して一組の機能から選択される、項目55に記載のシステム。
(項目57)
前記1つまたは複数の機能構成要素のうちの少なくとも1つが、シナリオデータオブジェクトを作成するように構成され、前記シナリオデータオブジェクトが特定のメタデータが使用されるシナリオを指定するためのものである、項目55に記載のシステム。
(項目58)
前記1つまたは複数のプロセッサが、前記データベースに格納された前記乗り物データを使用して予測モデルをさらに訓練するようにプログラムされる、項目50に記載のシステム。
(項目59)
前記予測モデルが、前記乗り物から前記乗り物データの少なくともサブセットを検索するために使用される、項目58に記載のシステム。
(項目60)
前記メタデータが、前記乗り物データの処理に関連するメタデータをさらに含む、項目50に記載のシステム。
(項目61)
前記メタデータが、前記乗り物データの1つまたは複数のサブセットを検索するために使用可能である、項目50に記載のシステム。
(項目62)
前記乗り物データの少なくとも一部分が送信方式に基づいて送信され、前記送信方式が要求に基づいて決定される、項目50に記載のシステム。
(項目63)
前記乗り物が、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物である、項目50に記載のシステム。
【0030】
参照による組込み
本明細書で言及されるすべての刊行物、特許、および特許出願は、あたかも個々の刊行物、特許、または特許出願が参照により組み込まれることが具体的かつ個別に示されたかのように、同じ程度まで参照により本明細書に組み込まれる。参照により組み込まれる刊行物および特許または特許出願が明細書に含まれる開示と矛盾する範囲まで、本明細書は、いかなるそのような矛盾する資料にも取って代わり、かつ/または優先するものである。
【0031】
本発明の新規の特徴は、添付の特許請求の範囲に詳細に記載されている。本発明の特徴および利点のより良い理解は、本発明の原理が利用される例示的な実施形態を記載する以下の発明を実施するための形態、ならびに添付の図面(本明細書では「図(Figure)」および「図(FIG)」でもある)を参照して得られる。
【図面の簡単な説明】
【0032】
図1】データオーケストレータとデータセンタとの間のデータフローを概略的に示す図である。
図2】様々なデータセンタ、自律型の乗り物、およびリモートエンティティにわたるデータフローの例を示す図である。
図3】アプリケーションテーブルの一例を示す図である。
図4】1つまたは複数のリモートエンティティと通信するデータオーケストレータの一例を概略的に示す図である。
図5】予測モデル知識ベースの一例を示す図である。
図6】予測モデルを訓練および開発するためにメタデータデータベースおよびクラウドデータレイクと対話するモデル作成器の一例を示す図である。
図7】予測モデルを作成する方法を示す図である。
図8】データ管理システムの例示的な構成要素を示す図である。
図9】データ取込みパイプラインの一例およびパイプラインエンジンによって実行される機能を示す図である。
図10】例示的なデータ取込みプロセスを示す図である。
図11】整列などのデータ処理によって生成されたメタデータ、アプリケーションおよび/またはセンサによって生成されたメタデータの例を示す図である。
図12】シナリオメタデータの一例を示す図である。
図13】データ管理システムを実装するようにプログラムされるか、そうでなければ構成されたコンピュータシステムを示す図である。
図14】自動化された乗り物および自律型の乗り物のライフサイクルにおける様々なアプリケーションの例を示す図である。
図15】乗り物内の予測モデルを動的に更新する例を示す図である。
図16】本発明のいくつかの実施形態による、OEMの助けを借りて管理されるデータ送信を概略的に示す図である。
図17】データオーケストレータと1つまたは複数のクラウドアプリケーションとの間のデータ送信プロセスを示す図である。
図18】多層データアーキテクチャを概略的に示す図である。
図19】乗り物層とフォグ層との間、およびフォグ層とクラウド層との間のデータ送信を管理するためのデータオーケストレータの一例を概略的に示す図である。
図20】データオーケストレータが実装され得る環境を示す図である。
【発明を実施するための形態】
【0033】
本明細書では本発明の様々な実施形態が図示および記載されているが、そのような実施形態が例としてのみ提供されることは当業者には明らかであろう。当業者は、本発明から逸脱することなく、多数の変形、変更、および置換を思いつく場合がある。本明細書に記載された本発明の実施形態に対する様々な代替案が採用されてよいことを理解されたい。
【0034】
本明細書で使用される、「自律的に制御される」、「自動運転」、「自律型」、および「無人」という用語は、乗り物を記述する際に使用されるとき、一般に、それ自体が少なくとも一部もしくはすべての運転タスクを実行し、かつ/または経路の少なくとも一部分に沿って運転環境を監視することができる乗り物を指す。自律型の乗り物は自動化された乗り物であってよい。そのような自動化された乗り物は、少なくとも部分的または完全に自動化されてよい。自律型の乗り物は、運転者または乗客からの何らかの介入または介入なしで運転するように構成されてよい。自律型の乗り物は、自律型の乗り物に乗っている人間からの介入なしに、ある地点から別の地点に移動することができる。場合によっては、自律型の乗り物は、乗り物の自動化に関する米国運輸省道路交通安全局(NHTSA)の定義、たとえば、NHTSA定義のレベル4(L4)「乗り物上の自動運転システム(ADS)は、特定の状況において、それ自体ですべての運転タスクを実行し、運転環境を監視する、基本的には、すべての運転を行うことができる。人間はそのような状況において注意を払う必要はない。」、またはNHTSA定義のレベル5(L5)「乗り物上の自動運転システム(ADS)は、あらゆる状況においてすべての運転を行うことができる。人間の乗員は単なる乗客であり、運転に関与する必要は決してない。」において指定された能力を備えた乗り物を指してよい。提供されたシステムおよび方法は、他の自動化レベルの乗り物に適用できることに留意されたい。たとえば、提供されたシステムまたは方法は、NHTSA定義のレベル3(L3)「レベル3の車には運転者は依然として必要であるが、特定の交通条件または環境条件下で安全上重要な機能を乗り物に完全に移行することができる。それは、運転者が依然として存在し、必要な場合に介入するが、前のレベルと同じように状況を監視する必要がないことを意味する。」を満たす乗り物によって生成されたデータを管理するために使用されてよい。場合によっては、自動化された乗り物は、NHTSA定義のレベル2「乗り物上の高度運転支援システム(ADAS)は、状況によっては、それ自体で実際にステアリングとブレーキ/加速の両方を同時に制御することができる。人間の運転者は、常に十分な注意を払い(「運転環境を監視し」)、残りの運転タスクを実行しなければならない」、またはNHTSA定義のレベル3「乗り物上の自動運転システム(ADS)は、状況によっては、それ自体で運転タスクのすべての面を実行することができる。そのような状況では、ADSが人間の運転者にそうするように要求するときはいつでも、人間の運転者は制御を取り戻す準備ができていなければならない。他のすべての状況では、人間の運転者が運転タスクを実行する。」において指定された能力を備えた乗り物を指してよい。自動化された乗り物は、レベル2のADASを改善するためにAIが使用される、レベル2+の自動運転能力を備えた乗り物を含む場合もあるが、一貫した運転者の制御が依然として必要である。自律型の乗り物データは、自動化された乗り物によって生成されたデータも含んでよい。
【0035】
自律型の乗り物は、無人乗り物と呼ばれる場合がある。自律型の乗り物は、航空乗り物、陸上乗り物、または水塊を横断する乗り物であり得る。自律型の乗り物は、空中(たとえば、固定翼航空機、回転翼航空機、もしくは固定翼も回転翼ももたない航空機)、水中(たとえば、船舶もしくは潜水艦)、地上(たとえば、自動車、トラック、バス、バン、オートバイ、もしくは列車などの動力車)、地下(たとえば、地下鉄)、宇宙(たとえば、スペースプレーン、衛星、もしくはプローブ)、またはこれらの環境の任意の組合せなどの、任意の適切な環境内を移動するように構成することができる。
【0036】
「少なくとも」、「より大きい」、または「以上」という用語が一連の2つ以上の数値の最初の数値の前にあるときはいつでも、「少なくとも」、「より大きい」、または「以上」という用語は、その一連の数値の中の各数値に適用される。たとえば、1、2、または3以上は、1以上、2以上、または3以上と同等である。
【0037】
「しかない」、「未満」、または「以下」という用語が、一連の2つ以上の数値の最初の数値の前にあるときはいつでも、「しかない」、「未満」、または「以下」という用語は、その一連の数値の中の各数値に適用される。たとえば、3、2、または1以下は、3以下、2以下、または1以下と同等である。
【0038】
本明細書で使用される「リアルタイム」という用語は、一般に、コンピュータプロセッサなどによる、1秒未満、10分の1秒、100分の1秒、1ミリ秒、またはそれ未満の応答時間を指す。リアルタイムはまた、第2のイベントの発生に対する第1のイベントの同時発生または実質的な同時発生を指すことができる。
【0039】
本開示は、データ処理およびデータ格納を含む、データ管理および知識管理のための方法およびシステムを提供する。本開示の方法およびシステムは、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物などの様々なタイプの乗り物に適用することができる。コネクテッド乗り物は、いくつかの異なる通信技術のいずれかを使用して、運転者、道路上の他の乗り物(乗り物間[V2V])、路側基盤(乗り物対基盤[V2I])、および「クラウド」[V2C]と通信する乗り物を指してよい。本開示は、乗り物(たとえば、自律型の乗り物)および非乗り物のコンテキストを含む様々なコンテキストで使用され得るデータオーケストレータを提供する。本開示のデータオーケストレータは、様々なソースからのデータを管理するために、またはモノのインターネット(IoT)プラットフォーム、サイバー物理ソフトウェアアプリケーションおよびビジネスプロセスなどの様々な用途のために、ならびにエネルギー、製造、航空宇宙、自動車、化学、医薬品、電気通信、小売、保険、医療、金融サービス、公共部門などの組織のために使用されてよい。
【0040】
データ管理システム
本開示は、自律型の乗り物データまたは自動化された乗り物データなどの乗り物データを管理するためのシステムおよび方法を提供する。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造(たとえば、小規模バッチ製造および自律型の乗り物の製品化)、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。データ管理システムは、1時間当たり少なくとも約0.1テラバイト(TB)、0.5TB、1TB、2TB、3TB、4TB、5TB、またはそれ以上の規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。場合によっては、データ管理は、1時間当たり少なくとも約50TB、60TB、70TB、80TB、90TB、100TBの規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。場合によっては、データ管理は、1時間当たり少なくとも1ギガバイト(GB)、2GB、3GB、4GB、5GB、またはそれ以上の規模の生データでフリートによって生成されたデータを管理および編成することが可能であり得る。データ管理システムは、1時間当たり最大0.5TB、1TB、2TB、3TB、4TB、5TB、50TB、60TB、70TB、80TB、90TB、100TB、またはそれ以上のデータの任意のボリュームのデータを管理および編成することが可能であり得る。
【0041】
いくつかの実施形態では、データおよび知識管理システムは、自律型の乗り物または自動化された乗り物に搭載されたデータオーケストレータと通信することができる。データオーケストレータは、乗り物データを管理することが可能であり得る。データオーケストレータはデータルータであってよい。データオーケストレータは、データおよび知識管理システムに乗り物データをインテリジェントにルーティングするように構成されてよい。データオーケストレータは、どの自律型の乗り物データまたは自律型の乗り物データのどの部分が、どのデータセンタまたはサードパーティエンティティのデータおよび知識管理システムに通信されるべきか、ならびに自律型の乗り物データのこの部分がいつ送信されるかを判断するように構成されてよい。たとえば、自律型の乗り物データの一部は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータは、自律型の乗り物が静止しているとき(次の割当て/タスクを待っている間、または保守されている間)に通信されてよい。提供されたデータ管理システムはまた、予測モデルを訓練または開発し、ならびにデータオーケストレータおよび/または自律型の乗り物スタックの構成要素もしくは自動化された乗り物スタックの構成要素にモデルを展開するように構成された予測モデル作成および管理システムを備えてよい。場合によっては、予測モデル作成および管理システムは、リモートエンティティ(たとえば、データセンタ)に存在してよい。提供されたデータ管理システムは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびAPIコールを処理するように構成されたデータおよびメタデータ管理システムをさらに備えてよい。データオーケストレータ、またはデータおよび知識管理システムは、スタンドアロンシステムとして実装または提供することができる。
【0042】
図1は、データオーケストレータ100とデータセンタ120との間のデータフローを概略的に示す。場合によっては、データオーケストレータ100は、たとえば、データ作成、データ洗浄、データ強化、ならびにデータセンタ、システム、およびサードパーティエンティティにわたるデータの配信を含む、データ管理プロセスを自動化するように構成されてよい。自律型の乗り物110から収集されたデータは、自律型の乗り物のセンサによって捕捉されたデータを含んでよい。そのようなセンサは、たとえば、レーザー画像検出および測距(Lidar)、レーダー、ソナー、ディファレンシャル全地球測位システム(DGPS)、慣性測定ユニット(IMU)、ジャイロスコープ、磁力計、加速度計、超音波センサ、画像センサ(たとえば、可視光、赤外線)、熱センサ、音声センサ、振動センサ、導電率センサ、化学センサ、生物学的センサ、放射線センサ、導電率センサ、近接センサ、もしくは任意の他のタイプのセンサなどの乗り物に搭載されたセンサ、ナビゲーションシステム、またはそれらの組合せを含むことができる。自律型の乗り物から収集されたデータは、フリートデータ(たとえば、乗り物オペレーティングシステムからのデータ)、運転者データ(たとえば、運転者の気分、運転者の覚醒度、運転スタイルなど)、乗客データ(たとえば、音楽、ゲームへのアクセス、モバイルアプリケーションなどのユーザデバイスからのデータなどのユーザ体験プラットフォームからのデータ)、および様々な他のデータも含んでよい。乗り物のデータオーケストレータによって送信されたデータは、データセンタに存在するデータおよび知識管理システムによって受信される。データは、1つまたは複数のセンサからのデータストリーム(たとえば、ビデオカメラの出力、センサ融合データ)、バッチデータ、および/または個々の記録(たとえば、輸送中に乗客によって行われた購入取引、乗り物サブシステム、たとえば乗り物のエンジンの健全性を監視するシステム、もしくはタイヤの状態を監視するサブシステムによって生成された個々の記録もしくは一連の記録、乗り物上で動作するアプリケーションの1つとのユーザ対話の結果)を含んでよい。
【0043】
いくつかの実施形態では、データオーケストレータ100は、エッジインテリジェンスプラットフォームであってよい。たとえば、データオーケストレータは、データの処理および編成をエッジ(たとえば、自律型の乗り物)の近くに拡張するフォグコンピューティングまたはエッジコンピューティングの概念に基づくソフトウェアベースのソリューションであってよい。エッジコンピューティングは、サービスがインスタンス化される場所を指してよいが、フォグコンピューティングは、エンドユーザまたはエンドノードの制御におけるデバイスおよびシステム上またはその近傍(たとえば、5メートル以内もしくは1メートル以内)での通信、計算、および格納のリソースおよびサービスの分配を意味してよい。すべてのデータを離れた集中型クラウドに送信するのではなく、エッジデバイス(たとえば、自律型の乗り物、センサ)の近くに維持することにより、待ち時間が最小化され、最大のパフォーマンス、より速い応答時間、ならびにより効果的な保守および運用の戦略が可能になる。それはまた、全体的な帯域幅要件および広く分散されたネットワークを管理するコストを大幅に削減する。提供されたデータ管理システムは、データ処理の少なくとも一部分をエッジで実行することができるエッジインテリジェンスパラダイムを採用することができる。場合によっては、機械学習モデルは、クラウド上で構築および訓練され、エッジデバイスまたはエッジシステム(たとえば、ハードウェアアクセラレータ)上で実行されてよい。本開示のシステムおよび方法は、リアルタイムの現場乗り物データ編成を可能にする効率的で高度に拡張可能なエッジデータ編成プラットフォームを提供することができる。
【0044】
データ管理システムのソフトウェアスタックは、エッジおよびクラウド上で動作するサービスの組合せであり得る。エッジ上で動作するソフトウェアまたはサービスは、データ編成用の予測モデルを採用することができる。クラウド上で動作するソフトウェアまたはサービスは、予測モデルを訓練、開発、および管理するための予測モデル作成および管理システム130を提供することができる。場合によっては、データオーケストレータは、ローカルストレージリポジトリ(たとえば、ローカル時系列データベース)へのセンサデータの取込み、データ洗浄、データ強化(たとえば、サードパーティデータを処理されたデータとマージすること)、データ整列、データ注釈付け、データタグ付け、またはデータ集約をサポートすることができる。生データは、ある時間期間(たとえば、約1、2、3、4、5、6、7、8、9、10秒、約1、2、3、4、5、6、7、8、9、10分、約1、2、3、4、5、6、7、8、9、10時間など)にわたって集約されてよい。代替または追加として、生データは、データタイプまたはソースにわたって集約され、パッケージとしてリモートエンティティに送信されてよい。
【0045】
データオーケストレータは、データセンタ、クラウドアプリケーション、または(たとえば、サードパーティエンティティと関連付けられた)データセンタ内に存在する任意の構成要素にわたってデータを配信することができる。データオーケストレータは、どのデータまたはデータのどの部分がどのデータセンタおよび/またはエンティティに送信されるべきか、ならびにデータのこの部分をいつ送信するかを判断することができる。たとえば、自律型の乗り物データの一部(たとえば、データまたはデータのパッケージの第1の部分)は、直ちに、または自律型の乗り物が動いているときに通信される必要があり得るが、他のデータ(たとえば、データまたはデータのパッケージの第2の部分)は、自律型の乗り物が静止しているとき(次の割当て/タスクを待っている間、または保守されている間)に通信されてよい。さらなる例では、データの第1の部分は、リアルタイムデータに基づいてリアルタイムフィードバックおよび制御を提供するためのフリートマネージャアプリケーションをホストするデータセンタに送信されてよく、データの第2の部分(たとえば、バッチデータ)は、バッチデータに基づいて保険適用範囲を計算するために保険会社サーバに送信されてよい。いくつかの実施形態では、データ配信またはデータ送信は、予測モデルおよび/または手作り規則に少なくとも部分的に基づいて決定されてよい。いくつかの実施形態では、データ送信は、予測モデル、手作り規則、ならびに宛先および送信プロトコルに関するデータを格納するリポジトリに基づいて開始されてよい。一例では、データオーケストレータ100は、データ集約、および集約データをさらなる分析のためにクラウド、異なるデータセンタ、またはエンティティに送信するためのデータ公開のためのサービスをサポートすることができる。データオーケストレータおよび予測モデルに関する詳細は、本明細書で後述される。
【0046】
予測モデル作成および管理システム130は、データオーケストレータ100をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。この環境は、1つもしくは複数のパブリッククラウド(たとえば、Amazon Web Services(AWS)、Azureなど)、および/またはシステムの1つもしくは複数の部分がプライベートクラウドで動作し、他の部分が1つもしくは複数のパブリッククラウドで動作するハイブリッドクラウド構成で動作することができる。たとえば、予測モデル作成および管理システム130は、予測モデルを訓練および開発するように構成されてよい。場合によっては、訓練された予測モデルは、予測モデル更新モジュールを介してデータオーケストレータまたはエッジ基盤に展開されてよい。予測モデル更新モジュールに関する詳細は、図15に関して記載される。場合によっては、予測モデル作成および管理システム130はまた、クラウドで開発された機械学習モデルを、エッジで実行することができるセンサ表現に変換することができてよい。予測モデル作成および管理システム130はまた、自律型の乗り物から送信されたデータを1つまたは複数のデータベースまたはクラウドストレージ123、125、127に取り込むことをサポートすることができる。予測モデル作成および管理システム130は、クラウドまたはプライベートデータセンタにおけるデータの監視または格納を含む、統合された監督および管理を可能にするアプリケーションを含んでよい。いくつかの実施形態では、予測モデル作成および管理システム130は、分析、センサデータ(たとえば、ビデオ)を閲覧するためのユーザインターフェース(UI)モジュールを備えるか、または分析表現を開発および展開し、データ編成アプリケーションをエッジ(たとえば、自律型の乗り物オペレーティングシステム、エッジゲートウェイ、エッジ基盤、データオーケストレータ)に展開し、予測モデル性能を監視し、予測モデルを構成するための管理UIを備えてよい。予測モデル作成および管理システムはデータセンタの構成要素として示されているが、予測モデル作成および管理システムはスタンドアロンシステムであり得ることに留意されたい。
【0047】
提供されたデータ管理システムは、コンテナおよび/またはマイクロサービスなどの任意の適切な技術を採用することができる。たとえば、データオーケストレータのアプリケーションは、コンテナ化されたアプリケーションであり得る。データ管理システムは、コンテナにアプリケーションまたはサービスを実装することなどの、エッジにおけるソフトウェア基盤にマイクロサービスベースのアーキテクチャを展開することができる。別の例では、クラウドアプリケーションならびに/または予測モデル作成および管理システム130は、マイクロサービスによって支援される管理コンソールまたはクラウド分析を提供することができる。
【0048】
コンテナ技術は、(したがって、ハイパーバイザ技術とは異なり)テナントごとにOSカーネル全体の複製を必要とせずに、無視できるオーバーヘッドでオペレーティングシステム(OS)によって管理されるメモリ、中央処理装置(CPU)、およびストレージのようなコンピュータサーバリソースを仮想化する。コンテナは、人気のあるLinuxオープンソースオペレーティングシステムの一部として開発され、DockerおよびCoreOSのような高度管理フレームワークの可用性により、ソフトウェア開発およびデータセンタ運用(「DevOps」)においてかなりのけん引力を得ている。Kubernetesなどの他のコンテナ編成フレームワークも利用されてよい。Kubernetesは、複数のコンテナがホストマシン上で動作し、競合のリスクなしにリソースを共有することを可能にする「ポッド」と呼ばれる高レベル抽象化層を提供する。ポッドは、ディレクトリまたはストレージのような共有サービスを定義し、それをポッド内のすべてのコンテナに紹介するために使用することができる。(工場、倉庫、小売店、および他の施設のような物理的な場所を含む)モノのインターネット(IoT)のユースケースにおける物理センサネットワークに非常に近いニアライン計算基盤を介してセンサデータを処理するためにソフトウェアおよび分析を消費する需要が高まっている。これらの計算ノードは、たとえば、インターネットに接続され、動作中に展開された様々な異種センサデバイスおよび制御システムにアクセスする、中型(たとえば、デュアルコアプロセッサおよび4ギガバイトのメモリ)から小型(たとえば、1ギガバイト未満のメモリを有するシングルコアプロセッサコア)までのサーバを含む。データ管理システムは、これらのエッジ計算基盤設定においてコンテナ技術をインテリジェントに展開および管理するための方法を提供する。
【0049】
データセンタまたはリモートエンティティ120は、自律型の乗り物データおよびメタデータを格納するための1つまたは複数のリポジトリまたはクラウドストレージを備えてよい。たとえば、データセンタ120は、メタデータデータベース123、自律型の乗り物スタックデータを格納するためのクラウドデータレイク125、およびユーザ体験プラットフォームデータ127を格納するためのクラウドデータレイクを備えてよい。本明細書に記載されたユーザ体験プラットフォームは、乗り物の客室の内部で動作しているハードウェアおよび/またはソフトウェアの構成要素を備えてよい。ユーザ体験プラットフォームは、客室の環境および乗員の相互作用、たとえば客室温度、乗員当たりの娯楽の選択肢、各乗員のバイタルサイン、気分、および注意力などを管理するように構成することができる。場合によっては、メタデータデータベース123および/またはクラウドデータレイクは、クラウドストレージオブジェクトであってよい。
【0050】
自律型の乗り物スタックは、知覚、データ融合、クラウド/OTA、位置特定、挙動(別名運転ポリシー)、制御、および安全性などの複数の領域を、エンドツーエンド自動化を処理することができるプラットフォームに統合することができる。たとえば、自律型の乗り物スタックは、知覚(たとえば、ASIC、FPGA、GPUアクセラレータ、SIMDメモリ、カメラ、Lidar、レーダー、GPSなどのセンサ/検出器)、位置特定および計画(たとえば、データパス処理、DDRメモリ、位置特定データセット、慣性測定、GNSS)、決定または挙動(たとえば、モーションエンジン、ECCメモリ、挙動モジュール、調停、予測子)、制御(たとえば、ロックステッププロセッサ、DDRメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ)、接続およびI/O(たとえば、RFプロセッサ、ネットワークスイッチ、決定論的バス、データ記録)などの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを含んでよい。自律型の乗り物スタックデータは、上述された自律型スタックによって生成されたデータを含んでよい。ユーザ体験プラットフォームデータ127は、デジタルサービス(たとえば、音楽、ビデオ、またはゲームへのアクセス)、取引、および乗客商取引またはサービスなどのユーザ体験アプリケーションに関連するデータを含んでよい。たとえば、ユーザ体験プラットフォームデータは、以下に関連するデータを含んでよい。コンテンツにアクセスするサブスクリプション、たとえば、音楽ストリーミングサービス、ニュースサービス、コンシェルジュサービスなどへの年間サブスクリプション、輸送中、ならびに給油ステーション、レストラン、コーヒーショップなどで乗り物が断続的に停止するときの商品、サービス、およびコンテンツの取引ベースの購入(たとえば、エネルギー会社などの充電ステーション事業者は、コーヒーショップチェーンと提携して、乗り物に燃料を補給しながら購入する乗客にコーヒードリンクの割引を提供することができる)、ロイヤルティポイントの償還、たとえば、自動車メーカーおよびフリート事業者は、航空会社またはホテルチェーンによって使用されているのと同様のシステムを使用して自社の顧客のロイヤルティに報いることができ、これらの業界および他の業界がそのようなプログラムを使用するのとほぼ同じ方法でロイヤルティポイントを償還することができる。場合によっては、ユーザ体験プラットフォームデータ127は、ユーザモバイルアプリケーションによって生成されたデータなどのサードパーティパートナーデータも含んでよい。ユーザは、フリート事業者または乗客であり得る。
【0051】
クラウドアプリケーション121、122は、様々なユースケースについて自律型の乗り物から送信されたデータをさらに処理または分析することができる。クラウドアプリケーションは、相手先商標製造会社(OEM)、ホテルおよびホスピタリティ、レストランおよび食事、観光および娯楽、医療、サービス提供、および様々な他の産業などの産業における無人/運転手不要な乗り物についての様々なユースケースを可能にすることができる。特に、提供されたデータ管理のシステムおよび方法は、たとえば、乗り物の設計、試験、ならびに製造(たとえば、小規模バッチ製造および自律型の乗り物の製品化)、乗り物のフリートの構成、注文サービス、資金調達、保険、およびリースを含む乗り物フリートの作成、サービス、個別化、乗車管理、および乗り物管理を含む場合があるフリートの運用、乗り物の保守、修理、燃料補給、およびサービス、ならびにこれらの乗り物またはフリートに発生する事故および他の事象の処理を含む、自動車バリューチェーンの様々な態様に関連するデータに適用することができる。
【0052】
図2は、様々なデータセンタ、自律型の乗り物、およびエンティティにわたるデータフローの例を示す。例に示されたように、自律型の乗り物フリート(AVフリート)201の間に、自律型の乗り物フリートを使用する消費者202によって生成されたデータは、データオーケストレータ220の助けを借りて様々なリモートエンティティに送信されてよい。様々なリモートエンティティには、たとえば、政府211、フリートリース会社209、保険会社207、フリートマネージャ205、フリート事業者203、デジタルサービス217、(たとえば、電車およびシャトル、ライドシェア、タクシー配車サービス、共有トリップまたはプライベートトリップ、徒歩、自転車、eスクータ、タクシーなどの)他の輸送サービス219、プラットフォームプロバイダ215、ならびに相手先商標製造会社(OEM)213が含まれてよい。様々なエンティティに送信されるデータは、同じであってもなくてもよい。たとえば、(たとえば、より多くの消費者関連データまたは乗客関連データを含む)デジタルサービス217に送信されるデータは、(たとえば、より多くのAVフリートデータまたはセンサデータを含む)フリート事業者203に送信されるデータとは異なってよい。データは、異なる時点および/または頻度で様々なエンティティに送信されてよい。たとえば、センサデータストリームは、リアルタイムで、または乗り物が動いている間にフリートマネージャ205またはプラットフォームプロバイダ215に送信されてよいが、バッチデータを含むメッセージパッケージは、乗り物が停止している間またはより低い頻度で政府211またはフリートリース会社209に送信されてよい。いくつかの実施形態では、アプリケーションリポジトリまたはアプリケーションテーブルは、乗り物/乗り物アプリケーションとリモートエンティティ/クラウドアプリケーションとの間のデータ送信に関連する情報を格納するために使用されてよい。アプリケーションテーブルは、本明細書の他の箇所に記載されたデータオーケストレータの構成要素であってよい。場合によっては、クラウドまたはリモートエンティティ上で動作する1つまたは複数のクラウドアプリケーション(たとえば、クラウドアプリケーション121、122またはテナントアプリケーション)は、アプリケーションテーブルに登録することができる。クラウドアプリケーションは、自律型の乗り物または自律型の乗り物のオペレーティングシステム上で動作する1つまたは複数のアプリケーション(たとえば、エッジアプリケーション、ローカルアプリケーション)にリンクされてよい。アプリケーションテーブルは、クラウドアプリケーションが関心をもつ特定の乗り物データ(たとえば、データのタイプ、送信されるデータへのポインタ)、特定の乗り物データを生成するアプリケーション(たとえば、自律型の乗り物上で動作するアプリケーション)、特定のデータが送信されるアプリケーションおよび/またはデータセンタ(たとえば、クラウドアプリケーション121、122、サーバ上のアプリケーションの位置)、データ送信方式またはプロトコル(たとえば、遅延時間または頻度などの送信タイミング、通信プロトコル、送信に使用される圧縮または暗号化の方法)、ならびに様々な他のもの(たとえば、データが送信される前のプライバシーに関する規制規則)に関連するデータを格納することができる。
【0053】
データオーケストレータ220はまた、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物の一部であってよい。図20は、データオーケストレータが実装され得る環境を示す図である。乗り物2001-1、2001-2は、私有であってもよく、フリートの一部であってもよい。乗り物は、乗客輸送、長距離または短距離の物流、ラストマイル配送(たとえば、5マイル、4マイル、3マイル、2マイル、または1マイル以内の配送)に使用されてもよく、混合使用(たとえば、乗客およびパッケージ)を有してもよい。上記のデータは、任意の他の適切なデータ構造として格納できることに留意されたい。場合によっては、アプリケーションテーブルは、ローカルストレージに格納され、データオーケストレータによって管理されてよい。追加または代替として、アプリケーションテーブルは、データオーケストレータと予測モデル作成および管理システムの両方によって管理されてよい。
【0054】
場合によっては、クラウドまたはリモートエンティティ(たとえば、Amazon Web Services(AWS)およびAzureなどのパブリッククラウド、またはプライベートクラウド)上で動作するアプリケーションは、パブリッシュ/サブスクライブ方式を介して特定の乗り物のデータオーケストレータ(または乗り物のフリートのデータオーケストレータ)のアプリケーションテーブルに登録することができる。場合によっては、フォグ/エッジサーバまたはリモートエンティティ上で動作するアプリケーションは、パブリッシュ/サブスクライブ方式を介してアプリケーションテーブルに登録することができる。いくつかの実施形態では、登録アプリケーションは、そこからデータを受信する必要がある乗り物IDおよび/またはそこからデータを受信する必要がある対応する乗り物上で動作する特定の(1つもしくは複数の)乗り物アプリケーションを指定することができる。
【0055】
いくつかの実施形態では、登録アプリケーションによって生成されたデータ要求は、クラウドのサブスクリプションモジュールによって編成および管理されてよく、データ要求は、メッセージを介して1つまたは複数の関連の乗り物にオーバージエア(OTA)で通信されてよい。メッセージは、1つまたは複数の乗り物アプリケーションに対する1つまたは複数の要求を含んでよい。場合によっては、乗り物によって受信されたメッセージに含まれる要求がアプリケーションテーブルに登録されてよい。サブスクリプションモジュールは、データ要求または登録アプリケーションの要求を管理するように構成されてよい。たとえば、サブスクリプションモジュールは、複数の登録アプリケーションの要求を集約することが可能であってよく、それにより、有益なことに通信帯域幅消費が削減される。たとえば、同じ乗り物アプリケーション(たとえば、くぼみ検出器アプリケーション)からのデータを要求することに関する複数の登録アプリケーションの要求が集約されてよい。他の例では、特定の乗り物グループ(たとえば、2010~2015年の間に製造されたすべてのBMW Model 3の乗り物)上で動作する異なる乗り物アプリケーションからのデータを要求することに関する複数の登録アプリケーションの要求が集約され、単一のメッセージにパッケージ化されてよい。
【0056】
図3はアプリケーションテーブル300の一例を示す。アプリケーションテーブル300は、データオーケストレータ(たとえば、図4を参照)の一部であってよい。アプリケーションテーブル300の項目は、上述されたデータを格納することができる。たとえば、アプリケーションテーブルの行は、自律型の乗り物内で動作するアプリケーション(すなわち、乗り物アプリケーション)の名前(たとえば、くぼみ検出器)を含んでよい。アプリケーションは、リモートエンティティ、データセンタ、またはクラウドアプリケーションに通信されるデータを生成することができる。アプリケーションテーブルの行はまた、特定のデータセンタ内で動作する1つまたは複数のアプリケーションへの送信に新しいデータが利用可能であるかどうかを示すフラグ(たとえば、送信フラグ)、データが生成された乗り物の識別子(たとえば、乗り物ID)、クラウドアプリケーション(たとえば、アプリケーション名、クラウド上のアプリケーションの位置)またはこのアプリケーションからのデータを要求するデータセンタおよびデータが送信される場所(たとえば、app_name、loc)、送信されるデータのタイプ(たとえば、ビデオストリーム、CANデータ)、乗り物から送信される実際のデータ(たとえば、Stream1)へのポインタ、送信時間(たとえば、送信タイミング遅延)、圧縮タイプ(たとえば、可逆)、暗号化タイプ(たとえば、RSA)、および規制規則を含んでよい。図示されたアプリケーションテーブルは単なる例であることに留意されたい。データ送信に関連する任意の他のデータをアプリケーションテーブルに含めることができる。
【0057】
場合によっては、1つまたは複数の項目がローカル/乗り物アプリケーションによって設定されてよい。たとえば、要求されたデータが送信に利用可能であるかどうかを示す送信フラグは、ローカル/乗り物アプリケーションによって設定されてよい。場合によっては、1つまたは複数の項目がデータオーケストレータによって設定されてよい。たとえば、乗り物IDまたは規制規則は、データオーケストレータによって設定されてよい。
【0058】
いくつかの実施形態では、クラウドデータレイクは、フリート内の各乗り物のまわりのデータを編成することができる。たとえば、特定のAVスタックおよび特定のユーザ体験プラットフォームからのデータは、対応する乗り物(たとえば、乗り物ID)と関連して編成および格納されてよい。上述されたように、乗り物はクラウドデータレイクに登録することができ、その乗り物ID、それが使用する様々なデータ取得アプリケーション、各データ取得アプリケーションによってアクセスされるセンサ、各センサの能力(たとえば、センサは5秒ごとにデータを捕捉することができるか、またはセンサは720p解像度のビデオを捕捉することができる)、および他のものによって識別されてよい。場合によっては、ユーザ、ネットワーク内のエンティティ、またはシステムに登録された当事者は、乗り物IDを使用して、乗り物、製造元、モデル、および乗り物の製造年などの追加情報を自動的に導出することを許可されてよい。場合によっては、乗り物は、データ管理システムに登録するフリート(たとえば、企業フリート、レンタカー会社のフリート、特定のOEMによって製造された個人所有の乗り物の集合)の一部であり得る。
【0059】
データオーケストレータ
データオーケストレータは、自律型の乗り物に対してローカルであってもよく、自律型の乗り物に搭載されてもよい。いくつかの例では、データオーケストレータは自律型の乗り物上に存在する。上述されたように、データオーケストレータはまた、コネクテッド乗り物、コネクテッド自動化された乗り物、またはコネクテッド自律型の乗り物の一部であってよい。提供されたデータ管理システムは、データ編成がエッジまたはエッジゲートウェイで実行されるエッジインテリジェンスパラダイムを採用することができる。場合によっては、1つまたは複数の機械学習モデルは、クラウド/データセンタ上で構築および訓練され、乗り物またはエッジシステム(たとえば、ハードウェアアクセラレータ)上で実行されてよい。
【0060】
場合によっては、データオーケストレータは、エッジコンピューティングプラットフォームまたはエッジ基盤/システムを部分的に使用して実装されてよい。エッジコンピューティングプラットフォームは、ソフトウェア、ハードウェア、ファームウェア、組込み型ハードウェア、スタンドアロンハードウェア、特定用途向けハードウェア、またはこれらの任意の組合せに実装されてよい。本明細書に記載されたデータオーケストレータおよびその構成要素、エッジコンピューティングプラットフォーム、ならびに技法は、デジタル電子回路、集積回路、特別に設計されたASIC(特定用途向け集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、および/またはそれらの組合せで実現されてよい。これらのシステム、デバイス、および技法は、ストレージシステム、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスからデータおよび命令を受信し、それらにデータおよび命令を送信するように結合された、専用または汎用であり得る少なくとも1つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能および/または解釈可能な1つまたは複数のコンピュータプログラム内の実装形態を含んでよい。(プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られる)これらのコンピュータプログラムは、プログラマブルプロセッサ用の機械命令を含んでよく、高水準手続き型および/もしくはオブジェクト指向のプログラミング言語、ならびに/またはアセンブリ/機械言語で実装されてよい。本明細書で使用される「機械可読媒体」および「コンピュータ可読媒体」という用語は、プログラマブルプロセッサに機械命令および/またはデータを提供するために使用される任意のコンピュータプログラム製品、装置、および/またはデバイス(磁気ディスク、光ディスク、メモリ、もしくはプログラマブルロジックデバイス(PLD)など)を指す。
【0061】
いくつかの実施形態では、提供されたデータオーケストレータは、どの自律型の乗り物データまたは自律型の乗り物データのどの部分が、どのデータセンタまたはサードパーティエンティティに通信されるべきか、およびデータのこの部分がいつ送信されるかを判断することが可能であってよい。データ送信またはデータ配信は、アプリケーションテーブル、規則、および予測モデルを使用して決定されてよい。予測モデルは機械学習ベースのモデルであってよい。
【0062】
機械学習は、データ内のパターンの発見を自動化し、構築されたモデルを使用して様々なアプリケーションでインテリジェント予測を行う際の重要な計算構成モデルとして進化している。機械学習アルゴリズムなどの人工知能は、データ編成のための予測モデルを訓練するために使用されてよい。機械学習アルゴリズムは、たとえばニューラルネットワークであってよい。ニューラルネットワークの例には、深層ニューラルネットワーク、畳み込みニューラルネットワーク(CNN)、および再帰型ニューラルネットワーク(RNN)が含まれる。機械学習アルゴリズムは、サポートベクトルマシン(SVM)、単純ベイズ分類、線形回帰、分位回帰、ロジスティック回帰、ランダムフォレスト、ニューラルネットワーク、CNN、RNN、勾配ブースト分類器もしくはリプレッサ、または別の教師付きもしくは教師なしの機械学習アルゴリズムのうちの1つまたは複数を含んでよい。
【0063】
図4は、1つまたは複数のリモートエンティティ420、430と通信するデータオーケストレータ410の一例を概略的に示す。いくつかの実施形態では、データオーケストレータ410は、決定エンジン413およびデータ通信モジュール415を備えてよい。場合によっては、データオーケストレータ410は、データ処理モジュール411を備えていてもよい。場合によっては、データ処理モジュール411は、ストリームデータおよびバッチデータの前処理を実現することができる。代替の実施形態では、データ処理モジュール411は、データおよびメタデータ管理モジュール425の構成要素など、クラウド420上に存在してよい。データオーケストレータ410は、アプリケーションリポジトリ405および/または予測モデル知識ベース407などの1つまたは複数のローカルデータベースに結合されてもよく、それらを有してもよい。アプリケーションリポジトリ405は、上述されたアプリケーションテーブルを格納することができる。予測モデル知識ベース405は、データ送信(方式)を決定するための機械学習モデルおよび/または手作り規則を格納するように構成されてよい。データ送信方式は、どの自律型の乗り物データがどのデータセンタまたはサードパーティエンティティに通信されるべきか、およびそのようなデータがいつ送信されるかを指定することができる。予測モデル知識ベース405は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。たとえば、予測モデル知識ベース405は、乗り物の自律移動に使用されるモデル、乗り物の(1つもしくは複数の)客室の個別化および(1つもしくは複数の)客室内部で実行される他の機能に使用されるモデル、ならびに/またはフリートの安全で最適化された動作に使用されるモデルを格納することができる。
【0064】
データオーケストレータ410は、予測モデル管理モジュール421と通信することができる。予測モデル管理モジュール421は、図1に記載された予測モデル作成および管理システム130と同じであり得る。予測モデル管理モジュール421は、データセンタ、クラウド、サーバなどのリモートエンティティ420上に存在してよい。場合によっては、予測モデル管理モジュール421は、ネットワークを介してデータオーケストレータ410をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。場合によっては、予測モデル管理モジュール421はスタンドアロンシステムである。場合によっては、予測モデル管理モジュール421はデータセンタの構成要素であってよく、データセンタは、自律型の乗り物データを利用する1つまたは複数のアプリケーション423をホストすることができる。
【0065】
前述のアプリケーションリポジトリ405は、上述されたアプリケーションテーブルと同じであり得るか、またはアプリケーションテーブルを含むことができる。
【0066】
予測モデル知識ベース407は、機械学習モデルおよび/または手作り規則を格納することができる。知識ベースの環境では、関連する人間の専門知識と結合された情報の可用性および活用は、プロセス、実装、および利用効率を改善するための重要な構成要素である。知識ベースは、インターネットアクセスまたは他の関連技術を用いて広範囲の場所からアクセスすることができる複数のデータソース内の特定の主題に関する大量の情報を提供する。
【0067】
システムのアプリケーションリポジトリ405、予測モデル知識ベース407、1つまたは複数のローカルデータベース、メタデータデータベース427、およびクラウドデータベース429は、任意の適切なデータベース技法を利用することができる。たとえば、構造化照会言語(SQL)または「NoSQL」データベースは、フリートデータ、乗客データ、履歴データ、予測モデルまたはアルゴリズムを格納するために利用されてよい。データベースのうちのいくつかは、配列、ハッシュ、(リンク)リスト、構造体、構造化テキストファイル(たとえば、XML)、テーブル、JavaScript Object Notation(JSON)、NOSQLなどの様々な標準データ構造を使用して実装することができる。そのようなデータ構造は、メモリおよび/または(構造化)ファイルに記憶されてよい。別の代替案では、オブジェクト指向データベースが使用されてよい。オブジェクトデータベースは、共通の属性によって一緒にグループ化および/またはリンクされたいくつかのオブジェクト集合を含むことができ、それらは、いくつかの共通の属性によって他のオブジェクト集合に関連する場合がある。オブジェクト指向データベースは、オブジェクトが単なるデータではなく、所与のオブジェクト内にカプセル化された他のタイプの機能を有することができることを除いて、リレーショナルデータベースと同様に機能する。いくつかの実施形態では、データベースは、ノード、エッジ、およびプロパティを有するセマンティッククエリのためのグラフ構造を使用して、データを表現および格納するグラフデータベースを含んでよい。本発明のデータベースがデータ構造として実装される場合、本発明のデータベースの使用は、本発明の構成要素などの別の構成要素に統合されてよい。また、データベースは、データ構造、オブジェクト、およびリレーショナル構造の混合物として実装されてよい。データベースは、標準的なデータ処理技法を介して、様々な形態で統合および/または分散されてよい。データベースの一部、たとえば、テーブルは、エクスポートおよび/またはインポートされ、したがって、分散化および/または統合されてよい。
【0068】
いくつかの実施形態では、データ管理システムは、高速かつ効率的なデータ検索、クエリ、および配信のためのデータベースを構築することができる。たとえば、データ管理システムは、データを抽出、変換、およびロード(ETL)するようにカスタマイズされたアルゴリズムを提供することができる。いくつかの実施形態では、データ管理システムは、他のデータ構造を使用することと比較して、大規模データベースに適合し、容易に拡張可能であり、クエリおよびデータ検索において効率的であるか、またはメモリ要件を削減した効率的なデータベースモデルを提供するために、独自のデータベースアーキテクチャまたはデータ構造を使用してデータベースを構築することができる。たとえば、モデルツリーは、モデルの異なるバージョンを提示するノードと、モデルの目標、性能特性、および様々な他のものを表すノードパラメータとを有するツリーデータ構造を使用して格納されてよい。
【0069】
いくつかの実施形態では、データオーケストレータは、多層データアーキテクチャに適用されてよい。図18は多層データアーキテクチャ1800を概略的に示す。図示された例では、データオーケストレータは、上述されたフォグコンピューティングまたはエッジコンピューティングの概念に基づくソフトウェアベースのソリューションであってよい。場合によっては、多層データアーキテクチャは、乗り物層(たとえば、乗り物内データ1810)、フォグ層(たとえば、フォグ/エッジデータ1820)、およびクラウド層(たとえば、クラウドデータ1830)を備えてよい。多層データアーキテクチャは任意の数の層を備えてよい。たとえば、フォグ層は1つまたは複数の層を備えてよい。乗り物層にあるデータは、ユーザ体験プラットフォーム401および/または乗り物スタック403、乗り物に搭載されたセンサ、ならびに本明細書の他の箇所に記載された様々な他のソースによって生成された乗り物内データ1810を含んでよい。乗り物層にあるデータは上述された自律型の乗り物データと同じであってよい。フォグ層にあるデータ(たとえば、フォグ/エッジデータ1820)は、データオーケストレータによって生成、管理、および直接アクセスされてよい。フォグ/エッジデータ1820は、データ処理モジュール411によって処理された後のデータを含んでよい。データ処理モジュール411は、ローカルストレージリポジトリ(たとえば、ローカル時系列データベース)へのセンサデータの取込み、データ洗浄、データ強化(たとえば、メタデータでデータを装飾すること)、データ整列、データ注釈付け、データタグ付け、データ集約、および様々な他のデータ処理をサポートすることができる。フォグ/エッジデータ1820はまた、送信方式に従ってクラウドに送信される中間データを含んでよい。
【0070】
データオーケストレータは、どの乗り物データまたは乗り物データのどの部分が乗り物内データベース内に留まるか、フォグ層データベース(たとえば、フォグ/エッジデータベース)に移動/送信されるべきか、およびどのフォグ/エッジデータまたはフォグ/エッジデータのどの部分がどのデータセンタまたはサードパーティエンティティに通信されるべきか、データのこの部分がいつどの頻度で送信されるかを判断するように構成されるか、または判断することが可能であってよい。場合によっては、エッジ/フォグデータベースにオフロードまたは移動したデータは、格納効率を向上させるために、乗り物内データベースから削除されてよい。あるいは、乗り物内データベース内のデータは、エッジ/フォグデータベースにオフロードされた後、所定の時間期間の間保存されてよい。
【0071】
図19は、乗り物層とフォグ層との間、およびフォグ層とクラウド層との間のデータ送信を管理するためのデータオーケストレータ1910の一例を概略的に示す。複数の層間のデータ送信またはデータ配信は、アプリケーションテーブル、規則、および予測モデルを使用して決定されてよい。予測モデルは、上述された機械学習ベースのモデルであってよい。
【0072】
データオーケストレータ1910は、上述されたデータオーケストレータ410と同じであり得る。たとえば、データオーケストレータ1910は、決定エンジン1913およびデータ通信モジュール1915を備えてよい。場合によっては、データオーケストレータ1910は、データ処理モジュール(図示せず)を備えていてもよい。場合によっては、データ処理モジュールは、乗り物内データベース1920から送信されたストリームデータおよびバッチデータの前処理を実現することができる。乗り物内データベース1920は、乗り物に搭載され、乗り物データ(たとえば、乗り物内データ1810)を格納することができる。データオーケストレータは、乗り物内データベース1920とフォグ/エッジデータベース1930との間、およびフォグ/エッジデータベース1930とクラウドデータベースとの間のデータ送信を管理することができる。
【0073】
データオーケストレータ1910は、上述されたアプリケーションリポジトリ405および/または予測モデル知識ベース407などの1つまたは複数のローカルデータベースに結合されてもよく、それらを有してもよい。アプリケーションリポジトリ405は、上述されたアプリケーションテーブルを格納することができる。予測モデル知識ベース405は、データ送信(方式)を決定するための機械学習モデルおよび/または手作り規則を格納するように構成されてよい。データ送信方式は、どの乗り物データまたは乗り物データのどの部分が乗り物内データベース1920に留まるか、フォグ層データベース(たとえば、フォグ/エッジデータベース1930)に移動/送信されるべきか、ならびにそのようなデータがいつおよび/またはどの頻度で送信されるかを指定することができる。データ送信方式はまた、どのフォグ/エッジデータまたはフォグ/エッジデータのどの部分がどのデータセンタまたはサードパーティエンティティに通信されるべきか、データのこの部分がいつどの頻度で送信されるかを指定することができる。予測モデル知識ベース405は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。場合によっては、予測モデル知識ベース405は、乗り物の自律移動に使用されるモデル、乗り物の(1つもしくは複数の)客室の個別化および(1つもしくは複数の)客室内部で実行される他の機能に使用されるモデル、ならびに/またはフリートの安全で最適化された動作に使用されるモデルを格納することができるシステムの知識ベースと同じでなくてもよく、同じである必要もない。
【0074】
図5は予測モデル知識ベース500の一例を示す。いくつかの実施形態では、予測モデル知識ベース500は、自動車オントロジー501および1つまたは複数のモデルツリー503を含んでよい。いくつかの実施形態では、予測モデル知識ベースは、手作り規則と機械学習ベースの予測モデルの両方を含んでよい。手作り規則および機械学習ベースの予測モデルは、データ送信を規制する規則またはプロトコルを個別にまたはまとめて決定することができる。たとえば、規則は、所与のデータの集約(たとえば、Message_package)が送信されるべきアプリケーションおよび/またはデータセンタ、送信されるべきデータの集約、データ送信方式(たとえば、遅延時間または頻度などの送信タイミング、通信プロトコル、送信に使用される圧縮または暗号化の方法)、および様々な他のもの(たとえば、データが送信される前のプライバシーに関する規制規則)を指定することができる。
【0075】
手作り規則は、外部ソースからインポートされるか、または1人もしくは複数のユーザによって定義されてよい(たとえば、作り規則はユーザ定義規則であってよい)。場合によっては、手作り規則は、乗り物からのデータを要求するリモートアプリケーションによって提供されてよい。場合によっては、データ送信方式は、リモートアプリケーションからの要求に基づいて決定されてよい。場合によっては、要求は、リモートサードパーティアプリケーション(たとえば、アプリケーション423、430)から中間構成要素(たとえば、相手先商標製造会社(OEM))に送信される要求であってよい。たとえば、保険アプリケーションは、運転者が支払っている保険料と比較して運転者が過度に運転している可能性があるかどうかを理解し、新しい保険商品を作成し、安全機能のために運転者に割引を提供し、リスクを評価し、事故現場管理、最初の紛失通知、請求プロセスの強化などの目的で、所定の頻度(たとえば、1週間、2週間、1ヶ月、2ヶ月など)で乗り物に関連付けられたOEMシステムからの特定のタイプのデータ(たとえば、OEM組込みデバイスによって収集されたデータ)を要求することができる。
【0076】
要求は、アプリケーションによって必要とされるデータのタイプ、データが必要とされる頻度、そのようなタイプのデータが送信される時間期間に関する情報、または他の情報を含んでよい。状況によっては、データ送信がまれであるか、または送信されるデータ量が比較的少ないとき、データ送信方式は、機械学習モデルを使用して作成され得る送信方式などのインテリジェント送信方式を使用せずに、前述の要求に基づいて生成されてよい。たとえば、要求アプリケーション(たとえば、保険アプリケーション)は、対象乗り物(または乗り物のグループ)に関連付けられたOEMシステムに、対象乗り物から必要とされるデータのタイプおよびそのようなデータの頻度を示す要求を送信することができる。場合によっては、要求は乗り物のグループを指定することができる。たとえば、要求は、特定のモデル(たとえば、Audi A8)、年式(たとえば、2017年)、特定の運転自動化機能を有するモデル(たとえば、車線変更モニタ付きのA8)などを指定することができる。OEMシステムは、それぞれの対象乗り物のデータオーケストレータに要求を渡す(たとえば、要求メッセージを送信して要求を中継する)ことができる。要求を受信すると、データオーケストレータは、要求をキューにプッシュし、要求の受信を確認応答するためにOEMシステムに応答メッセージを送り返すことができる。次いで、OEMシステムは、要求が記録されたことを示すメッセージを要求アプリケーションに送信することができる。
【0077】
次に、データオーケストレータは、要求に含まれる情報に基づいて要求されたデータを送信することができる。データオーケストレータは、要求されたデータを要求アプリケーションに直接送信することができる。そのような場合、データオーケストレータからリモートアプリケーション(たとえば、要求アプリケーション)に送信されるデータに関連する情報は、中間エンティティ(たとえば、OEMシステム)を介して通信されてよい。たとえば、要求/応答メッセージを渡すことに加えて、OEMシステム/アプリケーションは、送信周期が完了したときに(たとえば、データオーケストレータから完了メッセージを受信すると)、キューから送信要求を削除するようにデータオーケストレータに指示するメッセージをデータオーケストレータに送信することができる。次いで、データオーケストレータは、キューから項目を削除し、項目が削除されたことを示すメッセージをOEMシステムに送信することができる。OEMシステムは、要求が完了したことを示すメッセージを要求アプリケーションに送信することができる。
【0078】
予測モデル知識ベース500は、データオーケストレータによって使用される機械学習モデルに加えて、他のモデルを格納することができる。たとえば、予測モデル知識ベース500は、乗り物の自律移動に使用されるモデル、(1つもしくは複数の)客室の個別化ならびに乗り物および/もしくは乗り物の(1つもしくは複数の)客室内部で実行される他の機能に使用されるモデル、ならびに/またはフリートの安全で最適化された動作に使用されるモデルを格納することができる。予測モデル知識ベース500に格納されたモデルは、データオーケストレータによって使用される予測モデル、自律型の乗り物スタックによって使用されている予測モデル、ユーザ体験プラットフォームまたはフリート管理システムによって使用されるモデルを含んでよい。あるいは、自律型の乗り物スタックによって使用されている予測モデル、およびユーザ体験プラットフォームによって使用されるモデルは、それぞれの自律型の乗り物スタックまたはユーザ体験プラットフォームによって別々に管理される予測モデル知識ベースに格納されてよい。
【0079】
自動車オントロジー501は、一人もしくは複数の個人、組織によって手動で開発することができるか、外部のシステムもしくはリソースからインポートすることができるか、またはユーザと協働する機械学習システムを使用して部分的に学習する(たとえば、自然言語テキストから自動車用語を抽出する)ことができる。場合によっては、自動車オントロジーの一部分はモデルツリーからのデータに基づいてよい。たとえば、モデルの目標および/または洞察の記述はモデルツリーのノードに格納されてよいが、目標および/または洞察の記述は自動車オントロジーの一部であってもよい。
【0080】
予測モデル知識ベース500は、他のオントロジーまたはモデルを格納することができる。場合によっては、シナリオメタデータは、次いでデータベースから適切な乗り物データを検索するために使用される特定のメタデータを使用してシナリオの特性を指定するために作成されてよい。予測モデル知識ベースは、新しいシナリオを作成するために、ならびに様々なレベルの詳細でシナリオを作成するために使用することができる階層シナリオオントロジーを含んでよい。たとえば、より高いレベルの詳細(すなわち、シナリオに関するより高いレベルの情報)で記述されたシナリオは、低忠実度シミュレーションまたは予測モデルを作成するために使用されてよいが、より低いレベルの詳細(すなわち、シナリオに関するより詳細な下位レベルの情報)で記述された同じシナリオは、高忠実度シミュレーションまたは予測モデルを作成するために使用されてよい。
【0081】
1つまたは複数のモデルツリー503はツリー構造の集合であってよい。ツリー構造は1つまたは複数のノード507を含んでよく、各ノードは予測モデルの特性および予測モデルを生成するために使用されるデータ(たとえば、訓練データ、試験データ)へのポインタを含む。実際のデータ(たとえば、訓練データ、試験データ)は、クラウドデータベース429に格納されてよい。クラウドデータベース429は、クラウドデータレイク125、127と同じであり得るか、またはクラウドデータレイク125、127のいずれかまたは両方を含むことができる。所与のモデルツリー内のノードの階層は、特定の予測モデルのバージョンおよびモデル間の関係を表すことができる。予測モデルの特性には、たとえば、予測モデルの目標/機能、モデル性能特性、および様々な他の特性が含まれてよい。ノード507はまた、モデルパラメータ(たとえば、重み、ハイパーパラメータなど)、モデルパラメータに関するメタデータ、モデルの性能統計、またはモデルアーキテクチャ(たとえば、層の数、層内のノードの数、CNN、RNN)を格納することができる。場合によっては、ノード507は、モデルを実行するために必要な(1つまたは複数の)計算リソース(たとえば、1つのグラフィック処理装置(GPU)、2つのGPU、3つのCPUなど)に関する情報をさらに含んでよい。ノードは、上述されたデータのすべてまたは任意の組合せを含んでよい。
【0082】
場合によっては、様々な予測モデルは異なるモデルツリー構造を使用して格納されてよい。知識ベースは、たとえば、予測モデルが使用されている場所に応じて異なるモデルツリー構造を有してよい。たとえば、ユーザ体験プラットフォームによって使用される予測モデルを格納するためのモデルツリー構造は、データオーケストレータによって使用される予測モデルを格納するモデルツリー構造とは異なってよい。
【0083】
モデルツリーは動的であってよい。たとえば、新しいノードは、モデルの元のアーキテクチャに対する変更、モデルの性能特性に対する変更、または訓練データもしくは試験データに対する変更に応答して作成されてよい。
【0084】
場合によっては、予測モデル知識ベースは手作り規則を格納してもよい。手作り規則は、1人もしくは複数の個人、組織によって手動で開発することができるか、または外部のシステムもしくはリソースからインポートすることができる。手作り規則および予測モデルは、別々に、順番に、または同時に適用されてよい。
【0085】
下記は、図3に記載されたアプリケーションテーブルによるデータ送信に関する規則の一例を示す。
【0086】
Pothole_Detector_AppのTransmission_Flagがセットされている場合、
データが送信されなければならないときを決定し、
Transmission_Flag=SETを有するVehicle_IDごとに、
乗り物からビデオストリームを受信し、
すべての適用可能な規制規則を適用し、
適用可能な規制規則を適用した後に生じるデータセットを暗号化してEnrypted_Data_Fileを作成し、
Enrypted_Data_Fileを圧縮してCompressed_Data_Fileを作成し、
[Compressed_Data_File,File_Size,Transmission_Delay,Data_Center_Address_List]から構成されるMessage_Packageを作成し、
Communication-ModuleキューにMessage_Packageを送信する
いくつかの実施形態では、データ送信方式は、データがどのように送信されるかを指定することもできる。たとえば、データ送信方式は、送信に使用される圧縮方法(たとえば、可逆圧縮アルゴリズム、非可逆圧縮アルゴリズム、符号化など)、または暗号化方法(たとえば、RSA、トリプルDES、Blowfish、Twofish、AESなど)を指定することができる。場合によっては、データ圧縮方法および/または暗号化方法は、規則に基づいて送信のために決定されてよい。たとえば、規則は、所与のタイプのデータ、データを使用するアプリケーション、データの宛先などに従って圧縮方法および/または暗号化方法を決定することができる。データ圧縮方法および/または暗号化方法を決定するための規則は、上述された予測モデル知識ベースなどのデータオーケストレータがアクセス可能なデータベースに格納されてよい。場合によっては、データ圧縮方法および/または暗号化方法を決定するための規則は、データ送信を決定するための規則の一部であってよい。たとえば、暗号化方法または圧縮方法を決定するためのルールセットは、データの送信方式を決定するために(たとえば、ルールセット識別子によって)呼び出されてよい。
【0087】
圧縮方法および/または暗号化方法を決定するための規則は、手作り規則であってよい。たとえば、データのタイプ、アプリケーションに関連するデータ、データの宛先などを指定する送信要求を受信すると、圧縮方法および/または暗号化方法に関する所定の規則または手作り規則が適用されてよい。そのような手作り規則は、上述された予測モデル知識ベースなどのデータオーケストレータがアクセス可能なデータベースに格納されてよい。場合によっては、圧縮方法および/または暗号化方法は、機械学習アルゴリズムで訓練されたモデルによって決定されてよい。たとえば、データ圧縮または暗号化のための所定のルールセットが利用できない(たとえば、ルールセット識別子が利用できない、データセットのタイプが今までにないなどの)とき、訓練されたモデルは、送信されるべきデータのセットに適用され、データのセットを圧縮または暗号化するための規則を生成することができる。場合によっては、訓練されたモデルによって生成されたルールセットは、将来のデータ送信(方式)のために予測モデル知識ベースに格納されてよい。
【0088】
再び図4を参照すると、データ処理モジュール411は、ローカルストレージリポジトリ(たとえば、ローカル時系列データベース)へのセンサデータの取込み、データ洗浄、データ強化(たとえば、メタデータでデータを装飾すること)、データ整列、データ注釈付け、データタグ付け、データ集約、および様々な他のデータ処理をサポートすることができる。ユーザ体験プラットフォーム401および/または乗り物スタック403、乗り物に搭載されたセンサ、ならびに本明細書の他の箇所に記載された様々な他のソースからのデータは、データ処理モジュールによって取り込まれ、処理されてよい。たとえば、データ処理モジュールは、1つまたは複数のプロトコル(たとえば、MQ Telemetry Transport、OPC Unified Architecture、Modbus、およびDDS)を介してセンサからデータを収集するか、または取り込むことができる。センサによって提供または出力されるデータは、バイナリデータストリームであってよい。センサからデータ処理モジュールへのこのデータの送信または配信は、プッシュ方法またはプル方法であり得る。場合によっては、データ処理モジュールは、生のバイナリデータを(JavaScript Object Notationなどの)消費可能なデータフォーマットに復号するか、または追加の必要かつ有用なメタデータとマージすることにより、センサからの入力データを強化することができる。いくつかの実施形態では、メタデータは、センサデータを捕捉するセンサ(たとえば、GPS、Lidar、カメラなど)、データに対する前処理(たとえば、時系列の整列および作成)、ならびに特定のユースケースまたはアプリケーション(たとえば、歩行者の回避、パターン認識、障害物の回避など)用のデータに対して動作する様々なアプリケーションおよび/または予測モデルに関連してよい。あるいは、そのようなデータ処理は、クラウド上のアプリケーションによって実行されてよい。たとえば、データ処理モジュール411は、データオーケストレータではなくクラウド420上に存在してよい。データ処理方法およびメタデータ作成に関する詳細は、本明細書において後述される。
【0089】
決定エンジン413は、予測モデル知識ベース407内の規則を実行するように構成されてよい。たとえば、決定エンジンは、実行の資格があるかまたは実行の準備ができている予測モデル知識ベース407内の規則を常に調べ、次いで、適格な規則に関連付けられたアクションを実行し、データ通信モジュール415を呼び出して、結果(たとえば、集約データ、Message_Package)を宛先(たとえば、要求されたデータセンタ420、アプリケーション431、リモートエンティティ、サードパーティエンティティ431など)に送信することができる。
【0090】
データ通信モジュール415は、規則に従って、処理されたデータまたは自律型の乗り物データの選択された部分を宛先に送信することができる。下記は、データ通信モジュールによって実行される手順の一例を示す。
【0091】
ステップ1 Queue_Statusをチェックする
ステップ2 Queue_Status=1の場合、
Message_Packageごとに、
File_SizeおよびTransmission_Delayを調査して、Transmission_Channel_Typeを決定し、
Transmission_Channel_TypeのTransmission_Channelを選択し、
選択されたTransmission_Channelを介してData_Center_Address_List内の各アドレスにCompressed_Data_Fileを送信し、
Transmission_Succeess=1の場合、QueueからMessage_Packageを削除し、そうでない場合、送信に進む
ステップ3 ステップ1に進む
データオーケストレータとクラウドまたはリモートエンティティとの間の通信を容易にするために、様々な通信プロトコルが使用されてよい。これらの通信プロトコルには、VLAN、MPLS、TCP/IP、トンネリング、HTTPプロトコル、ワイヤレスアプリケーションプロトコル(WAP)、ベンダ固有プロトコル、カスタマイズされたプロトコルなどが含まれてよい。一実施形態では、通信ネットワークはインターネットであるが、他の実施形態では、通信ネットワークは、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、ワイヤレスネットワーク、イントラネット、プライベートネットワーク、パブリックネットワーク、交換ネットワーク、およびこれらの組合せなどを含む、任意の適切な通信ネットワークであってよい。ネットワークは、ワイヤレスおよび/または有線の通信システムの両方を使用するローカルエリアネットワークおよび/またはワイドエリアネットワークの任意の組合せを含んでよい。たとえば、ネットワークは、インターネットならびに携帯電話ネットワークを含んでよい。一実施形態では、ネットワークは、標準的な通信技術および/またはプロトコルを使用する。したがって、ネットワークは、イーサネット、802.11、マイクロ波アクセス用世界的相互運用性(WiMAX)、2G/3G/4Gもしくはロングタームエボリューション(LTE)のモバイル通信プロトコル、赤外線(IR)通信技術、および/またはWi-Fiなどの技術を使用するリンクを含んでよく、ワイヤレス、有線、非同期転送モード(ATM)、インフィニバンド、PCIエクスプレス高度スイッチング、またはそれらの組合せであってよい。ネットワークで使用される他のネットワーキングプロトコルには、マルチプロトコルラベルスイッチング(MPLS)、伝送制御プロトコル/インターネットプロトコル(TCP/IP)、ユーザデータグラムプロトコル(UDP)、ハイパーテキスト転送プロトコル(HTTP)、シンプルメール転送プロトコル(SMTP)、ファイル転送プロトコル(FTP)などが含まれ得る。ネットワークを介して交換されるデータは、バイナリ形式の画像データ(たとえば、ポータブルネットワークグラフィックス(PNG)など)、ハイパーテキストマークアップ言語(HTML)、拡張可能マークアップ言語(XML)などを含む技術および/またはフォーマットを使用して表すことができる。さらに、リンクのすべてまたはいくつかは、セキュアソケットレイヤ(SSL)、転送レイヤセキュリティ(TLS)、インターネットプロトコルセキュリティ(IPsec)などの従来の暗号化技術を使用して暗号化することができる。別の実施形態では、ネットワーク上のエンティティは、上述されたものの代わりに、またはそれらに加えて、カスタムおよび/または専用のデータ通信技術を使用することができる。ネットワークは、ワイヤレス、有線、またはそれらの組合せであってよい。
【0092】
予測モデル作成および管理システム
予測モデル管理モジュール421は、図1に記載された予測モデル作成および管理システムと同じであり得る。予測モデル管理モジュール421は、データオーケストレータ410またはデータオーケストレータの1つもしくは複数の構成要素(たとえば、予測モデル知識ベース)をリモートで構成および管理するために、クラウドまたは業務用環境で動作するサービスまたはアプリケーションを含んでよい。
【0093】
いくつかの実施形態では、予測モデル管理モジュール421は、モデル作成器およびモデルマネージャを備えてよい。場合によっては、モデル作成器は、クラウドデータレイクおよびメタデータデータベースからのデータを使用して予測モデルを訓練、開発、または試験するように構成されてよい。モデルマネージャは、様々な構成要素(たとえば、クラウドデータレイク、メタデータデータベース、データオーケストレータ、モデル作成器)間のデータフローを管理し、正確で複雑かつ高速なクエリ(たとえば、モデルクエリ、メタデータクエリ)、モデル展開、保守、監視、モデル更新、モデルバージョン管理、モデル共有、および様々な他のものを提供するように構成されてよい。たとえば、展開コンテキストはエッジ基盤に応じて異なってよく、モデルマネージャは、エッジハードウェア仕様、展開場所、互換性のあるシステムに関する情報、セキュリティおよびプライバシーのためのデータアクセスマニフェスト、モデルの展開および保守中に所与の展開およびバージョン管理で利用できないデータフィールドをモデル化するためのエミュレータなどのアプリケーションマニフェストを考慮に入れることができる。
【0094】
予測モデル管理モジュールによって提供されるデータ管理は、自動化された乗り物および自律型の乗り物のライフサイクル全体にわたって適用することができる。たとえば、データ管理は、乗り物設計段階、乗り物/フリート検証段階、または乗り物/フリート展開段階における様々なアプリケーションにわたって適用されてよい。図14は、自動化された乗り物および自律型の乗り物のライフサイクルにおける様々なアプリケーションの例を示す図である。たとえば、データ管理は、乗り物設計段階、乗り物/フリート検証段階、または乗り物/フリート展開段階において、新しいモデルの作成または既存のモデルの更新に使用することができる。
【0095】
図6は、予測モデルを訓練および開発するためにメタデータデータベース427およびクラウドデータレイク429と対話するモデル作成器600の一例を示す図である。訓練された予測モデルは、性能について試験されてよく、次いで、性能要件を満たす予測モデルは、予測モデル知識ベース407に挿入されてよい。いくつかの実施形態では、クラウドデータベース429は、図1に記載された両方のクラウドデータレイク125、127を含んでよい。
【0096】
モデル作成器は、データオーケストレータによって使用される予測モデル、自律型の乗り物スタックによって使用されている予測モデル、ユーザ体験プラットフォーム、フリート管理システム、および様々な他のものによって使用される予測モデルを開発するように構成されてよい。モデル作成器は、データ管理およびデータ編成に加えて、乗り物の自律移動、(1つもしくは複数の)乗り物客室の個別化ならびに乗り物および/もしくは(1つもしくは複数の)乗り物客室内部で実行される他の機能、フリートの安全で最適化された動作、ならびに/または様々な他のアプリケーションに使用される予測モデルを訓練および開発することができる。
【0097】
図7は予測モデルを作成する方法700を示す。方法またはプロセスは、上述されたモデル作成器によって実行されてよい。予測モデルを生成するために、モデル目標および性能特性(たとえば、精度)が決定されてよい(動作701)。さらに、所望のデータ特性(たとえば、完全性、有効性、精度、一貫性、可用性、および適時性)が決定されてよい(動作702)。次に、モデルを訓練するために、データベース(たとえば、クラウドデータレイク)からラベル付きデータまたはデータセットが選択されてよい(動作703)。場合によっては、データベースからデータを検索することは、データ特性を有するメタデータデータベース内のメタデータを照会し、次いでメタデータ照会結果に基づいてクラウドデータレイクからデータを検索することを含んでよい。クラウドデータレイクからデータが返されない場合、データ特性が調整されてよい(すなわち、動作702を繰り返す)。場合によっては、返されたデータまたはデータセットは、次のステップの前にサンプリングされてよい。
【0098】
場合によっては、ラベル付きデータまたはデータセットは、モデル目標を考慮して適切性について分析されてよい(動作704)。たとえば、ラベル付きデータセットは、たとえば、自律型の乗り物が自動的に右折を行うことを可能にする予測モデルを開発することなどの、予測目標に十分であるかどうかが判定されてよい。様々な適切な方法は、ラベル付きデータセットの適切性を判定するために利用されてよい。たとえば、統計的検出力が計算され、分析に使用されてよい。統計的検出力は、検出される効果があるときに研究が効果を検出する可能性である。統計的検出力が高い場合、実際に1つの効果があるとき、タイプIIエラーを起こす確率、または効果がないと結論付ける確率は低下する。統計的検出力は、主に効果の大きさおよびそれを検出するために使用されるサンプルの大きさによって影響を受ける。大きい効果は小さい効果よりも検出が容易であるが、大きいサンプルは小さいサンプルよりも高い試験感度を提示する。
【0099】
動作704で生成された分析結果は、データセットが補正される必要があるかどうかを判定することができる。適切性分析の結果は、データセットが適切な要件を満たすかどうか、適切性のレベル、または補正される必要があるかどうかを示すことができる。たとえば、ラベル付きデータセットの適切性が計算され、所定のしきい値を下回るとき、データセットは適切性要件を満たさないと判定され、補正を必要とする可能性がある。データセットが補正を必要としないと判定すると、データセットは、予測モデルを訓練するために使用されてよい(動作706)。場合によっては、モデルを訓練することは、モデルタイプ(たとえば、CNN、RNN、勾配ブーストされた分類器またはリプレッサなど)を選択すること、モデルのアーキテクチャ(たとえば、層の数、ノード、ReLU層など)を選択すること、パラメータを設定すること、訓練データを作成すること(たとえば、データのペアリング、入力データベクトルの生成)、およびモデルを作成するために訓練データを処理することを含んでよい。場合によっては、データセットが分析され、データ補正を必要とすると判定された場合、補正が実行されてよい(動作705)。データセットを補正することができない場合、データベースから新しいまたは異なるデータセットが選択されてよい(すなわち、動作703を繰り返す)。
【0100】
訓練されたモデルは、予測モデル知識ベース407から検索された試験データを使用して試験および最適化されてよい(動作707)。次に、試験結果が性能特性と比較されて、予測モデルが性能要件を満たすかどうかが判定されてよい(動作708)。性能が良好である、すなわち性能要件を満たす場合、モデルが予測モデル知識ベース407に挿入されてよい(動作709)。
【0101】
場合によっては、新しいモデルを予測モデル知識ベースに挿入することは、新しいモデルがモデルツリーのどこに挿入されるか(たとえば、新しいノードとして既存のモデルツリーに追加されるか、または新しいモデルツリーに追加されるか)を判定することを含んでよい。新しいモデルとともに、モデル目標、モデルアーキテクチャ、モデルパラメータ、訓練データ、試験データ、モデル性能統計値などの他のデータも、モデルツリー構造にアーカイブされてよい。次に、モデル作成器またはモデルマネージャによって予測モデル性能が絶えず監視されてよい(動作710)。訓練されたモデルが性能試験を通過しない場合、プロセスは、不十分な性能がデータ特性またはモデル特性によって引き起こされたかどうかを判定することに進んでよい。決定に続いて、動作701(たとえば、性能特性の調整)および/または動作702(たとえば、データ特性の調整)が繰り返されてよい。
【0102】
場合によっては、新しい予測モデルの作成時、または既存の予測モデルに対して行われた更新/変更時に、予測モデルは選択された乗り物に利用可能であってよい。たとえば、予測モデルが更新され、予測モデル知識ベースに格納されると、予測モデルはフリート内の1つまたは複数の乗り物にダウンロードされてよい。利用可能な予測モデルは、動的に選択された1つまたは複数の乗り物にダウンロードされるか、またはそれらの中で更新されてよい。図15は、乗り物内の予測モデルを動的に更新する例を示す図である。
【0103】
上述されたように、予測モデルは、データ管理およびデータ編成に加えて、乗り物の自律移動、(1つもしくは複数の)乗り物客室の個別化ならびに乗り物および/もしくは(1つもしくは複数の)乗り物客室内部で実行される他の機能、フリートの安全で最適化された動作、ならびに/または様々な他のアプリケーションに使用されるモデルを含んでよい。乗り物が新しい状況に対処することを可能にするために、新しいモデルが作成されてよい。クラウドデータレイクに収集および格納された新しいデータに基づいて全体的な性能を改善するために、モデルが更新されてよい。場合によっては、システムによってアクセス可能なフリート内の特定の乗り物または一組の乗り物によって使用される予測モデルのリストが乗り物データベース内で維持される。
【0104】
場合によっては、そのような更新、変更、または新しいモデルの作成は、予測モデル管理モジュールの構成要素によって自動的に検出されてよい。たとえば、図15を参照すると、予測モデル更新モジュール1501は、新しいモデルが作成されたとき、または既存のモデルが更新されたときに、予測モデル知識ベース1503によって通知されてよい。次いで、予測モデル更新モジュール1501は、更新されたモデルのコピーを受信するために1つまたは複数の乗り物を選択することができる。1つまたは複数の乗り物は、サブスクリプション、モデルの利用、または他の基準に基づいて選択または決定されてよい。予測モデル更新構成要素はまた、選択された乗り物内でいつモデルが更新されるかを判断することができる。たとえば、予測モデル更新構成要素は、乗り物が停止しているとき(たとえば、保守、洗浄、修理などの間)に、または必要に応じて、モデルが直ちに更新される必要があると判断することができる。たとえば、タクシー配車フリートの一部である乗り物の場合、サンフランシスコの野球場で行われているゲームがある夜間に右折を行うための予測モデルは、(たとえば、乗客をピックアップするため、乗客を降車させるため、または乗客をどこか他の場所でピックアップもしくは降車させる過程でその領域を通過するために)影響を受ける領域を通過することを伴う乗車を完了するように乗り物が割り当てられている場合にのみ必要とされてよい。予測モデル更新モジュール1501は、上述されたクラウドのサブスクリプションモジュールの一部であってよい。
【0105】
再び図4を参照すると、クラウドもしくはデータセンタ420または提供された乗り物データ管理システムは、データおよびメタデータ管理モジュール425も備えてよい。データおよびメタデータ管理モジュール425は、データ処理モジュール411によって行われるデータ処理、ならびにメタデータの作成および管理を含む様々な機能を実行することができる。データおよびメタデータ管理モジュールは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびAPIコールを処理するように構成されてよい。データおよびメタデータ管理モジュールに関する詳細は、たとえば、図8図12に関連して説明される。
【0106】
クラウドまたはデータセンタ420は、クラウドアプリケーション423と、分析、センサデータ(たとえば、ビデオ)、および/または処理されたデータを閲覧するためのユーザインターフェース(UI)モジュール425とをさらに備えてよい。UIは、分析表現を開発および展開し、データ編成アプリケーションをエッジ(たとえば、自律型の乗り物オペレーティングシステム、エッジゲートウェイ、エッジ基盤、データオーケストレータ)に展開し、データ編成を構成および監視するための管理UIも含んでよい。
【0107】
図8は、乗り物データ管理システム800の例示的な構成要素、特にリモートエンティティ(たとえば、データセンタ)上に存在する乗り物データ管理システムの構成要素を示す。いくつかの実施形態では、乗り物データ管理システム800は、データおよびメタデータ管理システムと、予測モデル作成および管理システムとを備えてよい。データおよびメタデータ管理システムは、上述されたデータおよびメタデータ管理モジュールと同じであり得る。データおよびメタデータ管理システムは、自律型の乗り物によって生成されたデータおよび関連するメタデータを格納および管理し、データおよびメタデータに対して発行されたクエリおよびAPIコールを処理するように構成されてよい。いくつかの実施形態では、乗り物データ管理システム800は、少なくともパイプラインエンジン801と、予測モデル作成および管理システム803とを含むデータおよびメタデータ管理システムを備えてよい。いくつかの実施形態では、データおよびメタデータ管理システムは、データベースクエリエンジン805、メタデータクエリエンジン807、データシステム管理815、データシステムアーカイブ規則817、データシステムセキュリティ819、データベースAPI821、規制規則823、およびクラウド間通信825などの他の機能構成要素を備えてよい。たとえば、メタデータデータベース809は、データベースクエリエンジン805を介してメタデータクエリ言語を使用してアクセスすることができる。別の例では、データレイク811、813内のデータは、メタデータクエリの結果としてアクセスされ得るか、またはデータベースクエリエンジン805を使用して直接アクセスされ得る。クラウド間通信825は、VLAN、MPLS、TCP/IP、トンネリング、HTTPプロトコル、ワイヤレスアプリケーションプロトコル(WAP)、ベンダ固有プロトコル、カスタマイズされたプロトコルなどの様々な通信プロトコルを含んでよい。クラウド間通信は、システム(たとえば、クラウドベースのシステム)および/またはデバイスによって使用されてよく、様々なAPI(たとえば、RESTアーキテクチャ、SOAP、Webサービス、エンタープライズサービスバスプロトコル、またはシステム間通信および/もしくはプロセス間通信用の手法を提供するように設計された任意のデータ交換プロトコルを使用するAPI)を利用することができるインターフェースを備えてよい。いくつかの実施形態では、乗り物データ管理システム800は、メタデータデータベース809、自律型の乗り物スタックデータを格納するためのクラウドデータレイク811、およびユーザ体験プラットフォームデータを格納するためのクラウドデータレイク813をさらに備えてよい。
【0108】
いくつかの実施形態では、上述された構成要素のうちの1つまたは複数は、1つまたは複数のクラウドアプリケーションまたは企業アプリケーション(たとえば、フリート保守831、フリート管理833、マップ更新835、フリート構成837)と対話することができる。クラウドアプリケーションは、リモートエンティティ上でホストされてもよく、データ管理システムによって管理される乗り物データを利用してもよい。場合によっては、クラウドアプリケーションは、予測モデル作成および管理システム803によって作成されるデータベースまたは知識ベース832、834、836、838を有してよい。場合によっては、クラウドアプリケーションは、自律型の乗り物スタックデータを格納するためのクラウドデータレイク811、ユーザ体験プラットフォームデータを格納するためのクラウドデータレイク813に格納されたデータ、またはメタデータデータベース809に格納されたメタデータにアクセスし、それらを操作する許可を有してよい。場合によっては、データはクラウドアプリケーションにディスパッチされてよく、(メタデータまたはアプリケーションテーブル内で識別された)対応するクラウドアプリケーションにデータをディスパッチするために、予測モデル作成および管理システムは、迅速な検索のためにテーブルにローカルにリストされたクラウド上のすべてのリソース(すなわち、アプリケーション)のアドレスを有してよい。
【0109】
パイプラインエンジン801は、データオーケストレータから送信された生データまたはバッチデータの連続ストリームを前処理するように構成されてよい。たとえば、データは、機械学習分析に供給することができるように処理されてよい。データ処理には、たとえば、データの正規化、メタデータによるデータのラベル付け、タグ付け、データの整列、データの分割などが含まれてよい。場合によっては、処理方法は、機械学習分析を構築する開発者によるAPIを介してプログラム可能である。
【0110】
図9は、データ取込みパイプライン900の一例およびパイプラインエンジンによって実行される機能を示す。パイプライン900は、ストリームまたはバッチに取り込まれているデータを処理するための複数の機能を含んでよい。データには、たとえば、シミュレーションデータ、フリートデータなどの乗り物からのデータ、動作環境データ、輸送データ、乗り物遠隔測定、AVスタックおよびユーザ体験プラットフォームによって生成されたデータ、サードパーティパートナーデータ(たとえば、ユーザモバイルアプリケーションからのデータ)、センサデータ(たとえば、GPS、IMU、カメラ、Lidar、赤外線センサ、熱センサ、超音波センサなど)、地理位置データ、ならびに本明細書の他の箇所に記載された様々な他のデータが含まれてよい。ストリームデータは、限定はしないが、環境の時空間点測定値などの時系列データ、レーダー、Lidar、衛星、ソナーからのグリッド化測定値、および/またはアレイ指向データフォーマットもしくは多次元データを表すのに適した任意の他のデータフォーマットで形成されたシミュレーションプロセスの出力などの多次元データ、マップタイルなどの視覚化データ、メタデータ、センサからの生入力データなどの生データ、文書、デジタルサービス、データ収集、統合、処理分析のソースコード、ならびに様々な他のデータを含む、様々なタイプのデータを含んでよい。バッチは、テナント固有、アプリケーション固有であってもよく、並列処理用のコンテキスト認識サブグループにグループ化されてもよい。バッチは、本明細書の他の箇所に記載されたデータオーケストレータから生成および送信されてよい。
【0111】
パイプライン900はカスタマイズ可能であってよい。たとえば、パイプライン900の1つまたは複数の機能は、ユーザによって作成されてよい。代替または追加として、1つまたは複数の機能は、管理システムによって作成されてもよく、他のシステムもしくはサードパーティソースからインポートされてもよい。場合によっては、ユーザは、関数セット(たとえば、利用可能な機能920)から選択し、選択された関数をパイプラインに追加することを許可されてよい。場合によっては、パイプラインの作成または修正は、ユーザインターフェースモジュール(たとえば、図4のユーザインターフェースモジュール425)によって提供されるグラフィカルユーザインターフェース(GUI)を介して実行されてよい。たとえば、一組の利用可能な関数がGUI内に表示されてよい。ユーザは、GUI内で、関数をクリックすることによってCREATE SCENARIOS関数を表すグラフィカル要素を選択するか、またはドラッグアンドドロップによって現在のパイプラインに関数を追加することができる。
【0112】
場合によっては、グラフィカルユーザインターフェース(GUI)またはユーザインターフェースは、ディスプレイ上に提供されてよい。ディスプレイは、タッチスクリーンであってもなくてもよい。ディスプレイは、発光ダイオード(LED)スクリーン、有機発光ダイオード(OLED)スクリーン、液晶ディスプレイ(LCD)スクリーン、プラズマスクリーン、または任意の他のタイプのスクリーンであってよい。ディスプレイは、アプリケーションを介して(たとえば、ユーザデバイス上で、クラウド上で、またはデータオーケストレータ上で実行されるアプリケーションプログラミングインターフェース(API)を介して)レンダリングされたユーザインターフェース(UI)またはグラフィカルユーザインターフェース(GUI)を表示するように構成されてよい。
【0113】
いくつかの実施形態では、複数の機能は、取込み901、フィルタリング905、クリーニング907、タグ付け909、拡大911、注釈付け913、匿名化915、および様々な他の機能(たとえば、シミュレート)などのサードパーティ機能を含んでよい。たとえば、データクリーニング907は、データからノイズを除去すること(たとえば、画像処理におけるノイズ削減)、誤ったデータを補正すること(たとえば、1つのカメラが故障しており、光を示さないが、日中である)、共通データフォーマットを確立すること(たとえば、メトリックシステムを使用する、すべての数を小数点第3位までなど)、または、意図されたデータ消費者もしくはアプリケーションによってAPIを介して迅速かつ容易にアクセスされ得るようにデータを準備することを含んでよい。別の例では、データ拡大911は、自律型の乗り物モデルを試験するためにより完全なデータセットのために実際のデータと合成を組み合わせること、特定のタイプの予測を可能にするためにパートナーからのデータで捕捉されたデータを増強すること、移動時間を予測するために交通渋滞データを気象データと組み合わせること、情報量の多いデータを作成するためにいくつかのデータセットを組み合わせること(たとえば、1日の特定の時間帯における乗り物到着時間を予測するために乗り物動作データを都市交通基盤データおよび渋滞データと組み合わせること)を含んでよい。さらなる例では、データのタグ付け909または注釈付け913は、あらゆるレベルで行われるマルチメディアデータ(たとえば、画像、Lidar、オーディオ)の注釈付けおよびメタデータの作成を含んでよい。メタデータは、データ管理環境内のデータの移動中に作成されてよい。たとえば、画像は、(おそらく何らかの手動介入で)検索され、注釈付けされ、次いで再インデックス付けされる必要があり得る。作成されたメタデータは、メタデータカタログに組み込まれてよい。手動または自動で生成された様々なタイプのメタデータなどの他のメタデータも、メタデータカタログに挿入されてよい。複数の機能は、データ整列903およびシナリオ作成921などの独自の機能も備えてよい。
【0114】
図10は例示的なデータ取込みプロセス1000を示す。場合によっては、ストリームデータおよび/またはバッチデータは、パイプラインエンジンに取り込まれてよい。場合によっては、取り込まれたストリームデータはストリーム処理システム1001に配信されてよく、取り込まれたバッチデータは抽出-変換-ロード(ETL)システム1003に配信されてよい。ETLシステム1003は、従来のETL機能またはカスタマイズされた機能を実行することができる。たとえば、ETLシステムは、取り込まれたバッチデータをユーザにより有用なフォーマットに変換することができる。たとえば、データ変換は、特定の列のみを選択してフォーマットにロードすることと、コード化された値を変換することと、新しい計算値を導出することと、データをソートすることと、データを集計することと、データを輸送または回転させることと、列を複数の列に分割することと、他の処理とを含んでよい。
【0115】
本明細書ではストリーム処理システム1001およびETLシステム1003が説明されるが、本明細書に記載された機能を実装するために追加のモジュールまたは代替のモジュールが使用されてよい。ストリーム処理システムおよびETLシステムは、実装され得る多くの実行可能モジュールの単に例示的なものである。
【0116】
場合によっては、データ整列は、ETLシステムまたはストリーム処理システムによって実行されてよい。場合によっては、異なるセンサ(たとえば、センサは、異なる頻度でデータを捕捉することができる)により、または異なるソース(たとえば、サードパーティアプリケーションデータ)から捕捉されたデータが整列されてよい。たとえば、カメラ、Lidar、および遠隔測定データ(たとえば、温度、乗り物の状態、バッテリ充電など)によって捕捉されたデータは、時間に対して整列されてよい。場合によっては、データ整列は自動的に実行されてよい。代替または追加として、ユーザは、どのセンサまたはソースから収集されたデータが整列されるべきか、および/またはデータが整列されるべき時間ウィンドウを指定することができる。一例では、結果データは、時間に対して整列された時系列データであってよい。データは、アプリケーション、データ構造などの他の次元に沿って整列させることができることに留意されたい。
【0117】
メタデータ
乗り物データ管理システムはメタデータ管理を実現することができる。場合によっては、メタデータの作成および管理は、上述されたデータおよびメタデータ管理システムによって実現されてよい。場合によっては、メタデータは、メタデータに基づくデータのサブセットまたは自律型の乗り物データの一部分の選択を可能にすることができる。いくつかの実施形態では、メタデータは、センサデータ(たとえば、GPS、Lidar、カメラなど)を捕捉するセンサ、データに対する前処理(たとえば、時系列の整列および作成)、ならびに特定のユースケースまたはアプリケーション(たとえば、歩行者の回避、パターン認識、障害物の回避など)用のデータに対して動作する様々なアプリケーションおよび/または予測モデルに関する情報を提供することができる。メタデータは乗り物上で作成されてよい。たとえば、メタデータは、乗り物上で動作するセンサまたはアプリケーションによって生成されてよい。別の例では、メタデータは、乗り物に搭載されたデータオーケストレータによって生成されてよい。メタデータは、乗り物から離れて、またはリモートエンティティによって生成されてよい。たとえば、データ処理(たとえば、整列)に関するメタデータは、データセンタ内で、またはクラウドアプリケーションによって生成されてよい。場合によっては、メタデータの少なくとも一部分は、乗り物上で生成され、リモートエンティティに送信される。場合によっては、メタデータの少なくとも一部分は、リモートエンティティに設けられた構成要素(たとえば、クラウドアプリケーションまたはパイプラインエンジン)によって生成される。作成されたメタデータは、データ管理システムによって管理されるメタデータデータベースに格納されてよい。代替または追加として、メタデータは、メタデータを生成するために使用されるデータの少なくとも一部または全部を有するデータベースに格納されてよい。
【0118】
図11は、整列、アプリケーション、およびセンサによって生成されたメタデータの一例を示す。たとえば、異なるセンサデータ1111、1113が整列されると、整列情報(たとえば、構造パディング、頻度、時間ウィンドウなど)を提供するためにメタデータ(たとえば、整列作成メタデータ1103)が作成されてよい。場合によっては、データを生成するセンサまたはソースに関するメタデータ(たとえば、センサ作成メタデータ1105)が作成されてよい。たとえば、センサ作成メタデータは、センサに関する情報、センサの識別子、データタイプなどを含んでよい。場合によっては、アプリケーションに関するメタデータ(たとえば、アプリケーション作成メタデータ1101)は、データを処理および/または生成するアプリケーションによって作成されてよい。たとえば、アプリケーション作成メタデータ1101は、アプリケーションの名前、アプリケーションの開発者、アプリケーションのバージョン、および様々な他のものに関する情報を提供することができる。
【0119】
いくつかの実施形態では、データ管理システムは、データベースからデータを高速検索または照会するためのメタデータのメタデータを生成することができる。たとえば、シナリオメタデータは、次いでデータベースから適切な乗り物データを検索するために使用される特定のメタデータを使用してシナリオの特性を指定するために作成されてよい。図12はシナリオメタデータ1200の一例を示す。以下の例では、曇天の朝に乗り物が街路から高速道路に合流するために右折を行うシナリオを記述するシナリオデータオブジェクトは、以下のように定義されてよい。
【0120】
Scenario_Name:たとえば、右側合流
Scenario_Type:たとえば、高速道路への右側合流
Static_Objects:たとえば、木
Dynamic_Objects:たとえば、動作乗り物
Environment:たとえば、曇天の朝
Scene_Description:たとえば、都市一般道路から高速道路に進入する乗り物
Trigger_Rules:たとえば、乗り物が交差点に近づく10秒前に選択を始め、合流が完了した20秒後に止める
Data:たとえば、時系列セグメント1
下記は、新しいシナリオオブジェクトを作成する例示的なプロセスである。
【0121】
ステップ1 Scenario_Typeを指定する
ステップ2 MetadataCatalog内のメタデータを使用して、各Static_Object、各Dynamic_Object、およびScene_Descriptionを指定する
ステップ3 選択されたメタデータを使用してメタデータクエリ言語を使用してクエリを発行して、ResultSetを作成する
ステップ4 ResultSetが空である場合、NewTimeSeriesDataが物理的に収集またはシミュレートされ得るかどうかを判定し、そうでない場合、ステップ7に進む。
【0122】
ステップ5 NewTimeSeriesDataがシミュレートされる必要がある場合、データセット全体がシミュレートされる必要があるかどうか、またはデータセットの一部のみがシミュレートされ、次いで物理的に収集されたデータとマージされる必要があるかどうかを判定する。ステップ6に進む
ステップ6 Data_Ingestion_Pipelineを使用して(収集されるか、シミュレートされるか、またはそれらの組合せの)NewTimeSeriesDataを処理する
ステップ7 NewTimeSeriesDataSet内のTimeSeriesごとに、
a.Triger_Rulesを使用してステップ2の指定されたメタデータを満たすTimeSeriesセグメントを選択して、TimeSeriesSegmentを作成する。
【0123】
b.新しいScenarioObjectを作成する
c.選択されたセグメントと名前を関連付ける
d.ステップ2からのメタデータを入力する
ed.TimeSeriesSegmentをScenarioObjectに挿入する
コンピュータシステム
本明細書に記載された乗り物データ管理システム、データオーケストレータ、またはプロセスは、1つまたは複数のプロセッサによって実施することができる。いくつかの実施形態では、1つまたは複数のプロセッサは、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、および/または1つもしくは複数のアドバンストRISCマシン(ARM)プロセッサなどのきめ細かい空間アーキテクチャの形態のプログラマブルプロセッサ(たとえば、中央処理装置(CPU)、グラフィック処理装置(GPU)、汎用処理装置、またはマイクロコントローラ)であってよい。いくつかの実施形態では、プロセッサはコンピュータシステムの処理ユニットであってよい。図13は、データ管理システムを実装するようにプログラムされるか、そうでなければ構成されたコンピュータシステム1301を示す。コンピュータシステム1301は、本開示の様々な態様を調整することができる。
【0124】
コンピュータシステム1301は、中央処理装置(CPU、本明細書では「プロセッサ」および「コンピュータプロセッサ」でもある)1305を含み、それは、シングルコアもしくはマルチコアのプロセッサ、または並列処理のための複数のプロセッサであり得る。コンピュータシステム1301はまた、メモリまたは記憶場所1310(たとえば、ランダムアクセスメモリ、読取り専用メモリ、フラッシュメモリ)、電子記憶ユニット1315(たとえば、ハードディスク)、1つまたは複数の他のシステムと通信するための通信インターフェース1320(たとえば、ネットワークアダプタ)、ならびにキャッシュ、他のメモリ、データストレージ、および/または電子ディスプレイアダプタなどの周辺デバイス1325を含む。メモリ1310、記憶ユニット1315、インターフェース1320、および周辺デバイス1125は、マザーボードなどの通信バス(実線)を介してCPU1305と通信している。記憶ユニット1315は、データを記憶するためのデータ記憶ユニット(またはデータリポジトリ)であり得る。コンピュータシステム1301は、通信インターフェース1320の助けを借りて、コンピュータネットワーク(「ネットワーク」)1030に動作可能に結合することができる。ネットワーク1030は、インターネット、インターネットおよび/もしくはエクストラネット、またはインターネットと通信しているイントラネットおよび/もしくはエクストラネットであり得る。ネットワーク1030は、場合によっては、電気通信ネットワークおよび/またはデータネットワークである。ネットワーク1030は、クラウドコンピューティングなどの分散コンピューティングを可能にすることができる1つまたは複数のコンピュータサーバを含むことができる。ネットワーク1030は、場合によっては、コンピュータシステム1301の助けを借りてピアツーピアネットワークを実装することができ、それにより、コンピュータシステム1301に結合されたデバイスがクライアントまたはサーバとして振る舞うことが可能になってよい。
【0125】
CPU1305は、プログラムまたはソフトウェアで具現化することができる一連の機械可読命令を実行することができる。命令は、メモリ1310などの記憶場所に記憶されてよい。命令は、CPU1305を対象とすることができ、CPU1305は、その後、本開示の方法を実施するようにCPU1305をプログラムするか、そうでなければ構成することができる。CPU1305によって実行される動作の例には、フェッチ、復号、実行、およびライトバックが含まれ得る。
【0126】
CPU1305は、集積回路などの回路の一部であり得る。システム1301の1つまたは複数の他の構成要素を回路に含めることができる。場合によっては、回路は特定用途向け集積回路(ASIC)である。
【0127】
記憶ユニット1315は、ドライバ、ライブラリ、および保存されたプログラムなどのファイルを記憶することができる。記憶ユニット1315は、ユーザデータ、たとえば、ユーザの嗜好およびユーザプログラムを記憶することができる。コンピュータシステム1301は、場合によっては、イントラネットまたはインターネットを介してコンピュータシステム1301と通信しているリモートサーバ上に配置されるなどの、コンピュータシステム1301の外部にある1つまたは複数の追加のデータ記憶ユニットを含むことができる。
【0128】
コンピュータシステム1301は、ネットワーク1030を介して1つまたは複数のリモートコンピュータシステムと通信することができる。たとえば、コンピュータシステム1301は、ユーザのリモートコンピュータシステム(たとえば、ユーザデバイス)と通信することができる。リモートコンピュータシステムの例には、パーソナルコンピュータ(たとえば、ポータブルPC)、スレートもしくはタブレットPC(たとえば、Apple(登録商標)iPad、Samsung(登録商標)GalaxyTab)、電話、スマートフォン(たとえば、Apple(登録商標)iPhone、Android対応デバイス、Blackberry(登録商標))、または携帯情報端末が含まれる。ユーザは、ネットワーク1030を介してコンピュータシステム1301にアクセスすることができる。
【0129】
本明細書に記載された方法は、たとえば、メモリ1310または電子記憶ユニット1315などのコンピュータシステム1301の電子記憶場所に記憶された機械(たとえば、コンピュータプロセッサ)実行可能コードによって実施することができる。機械実行可能コードまたは機械可読コードは、ソフトウェアの形態で提供することができる。使用中、コードはプロセッサ1305によって実行することができる。場合によっては、コードは、記憶ユニット1315から検索し、プロセッサ1305による容易なアクセスのためにメモリ1310に記憶することができる。状況によっては、電子記憶ユニット1315を排除することができ、機械実行可能命令はメモリ1310に格納される。
【0130】
コードは、事前にコンパイルされ、コードを実行するように適合されたプロセッサを有する機械で使用するように構成することもでき、実行時の間にコンパイルすることもできる。コードは、事前コンパイル方式か、またはコンパイル時方式でコードを実行することを可能にするように選択することができるプログラミング言語で供給することができる。
【0131】
コンピュータシステム1301などの、本明細書において提供されたシステムおよび方法の態様は、プログラミングで具現化することができる。技術の様々な態様は、通常、機械(もしくはプロセッサ)実行可能コードおよび/またはあるタイプの機械可読媒体内で搬送もしくは具現化された関連データの形態の「製品」または「製造品」と考えられてよい。機械実行可能コードは、メモリ(たとえば、読取り専用メモリ、ランダムアクセスメモリ、フラッシュメモリ)またはハードディスクなどの電子記憶ユニットに記憶することができる。「記憶」タイプの媒体は、コンピュータ、プロセッサなどの有形メモリ、または様々な半導体メモリ、テープドライブ、ディスクドライブなどのそれらの関連モジュールのいずれかまたはすべてを含むことができ、それらは、ソフトウェアプログラミングのためにいつでも非一時的なストレージを提供することができる。ソフトウェアのすべてまたは部分は、時々、インターネットまたは様々な他の電気通信ネットワークを介して通信されてよい。そのような通信は、たとえば、あるコンピュータまたはプロセッサから別のコンピュータまたはプロセッサへの、たとえば、管理サーバまたはホストコンピュータからアプリケーションサーバのコンピュータプラットフォームへのソフトウェアのローディングを可能にすることができる。したがって、ソフトウェア要素を運ぶことができる別のタイプの媒体には、有線および光の地上回線ネットワークを介して、かつ様々なエアリンク上で、ローカルデバイス間の物理インターフェースにわたって使用されるような、光、電気、および電磁波が含まれる。有線リンクまたはワイヤレスリンク、光リンクなどの波を搬送する物理的要素も、ソフトウェアを運ぶ媒体と見なされてよい。本明細書で使用される場合、非一時的で有形の「記憶」媒体に限定されない限り、コンピュータまたは機械の「可読媒体」などの用語は、実行のためにプロセッサに命令を提供することに関与する任意の媒体を指す。
【0132】
したがって、コンピュータ実行可能コードなどの機械可読媒体は、有形記憶媒体、搬送波媒体、または物理伝送媒体を含むが、それらに限定されない多くの形態をとることができる。不揮発性記憶媒体には、たとえば、図面に示されたデータベースなどを実装するために使用され得るものなどの、任意の(1つまたは複数の)コンピュータ内などの任意のストレージデバイスなどの、光ディスクまたは磁気ディスクが含まれる。揮発性記憶媒体には、そのようなコンピュータプラットフォームのメインメモリなどの動的メモリが含まれる。有形伝送媒体には、コンピュータシステム内のバスを備えるワイヤを含む、同軸ケーブル、銅線、および光ファイバが含まれる。搬送波伝送媒体は、電気信号もしくは電磁信号、または無線周波数(RF)および赤外線(IR)データ通信中に生成されるものなどの音響波もしくは光波の形態をとることができる。したがって、コンピュータ可読媒体の一般的な形態には、たとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、CD-ROM、DVDもしくはDVD-ROM、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンをもつ任意の他の物理記憶媒体、RAM、ROM、PROMおよびEPROM、FLASH-EPROM、任意の他のメモリチップもしくはカートリッジ、データもしくは命令を転送する搬送波、そのような搬送波を転送するケーブルもしくはリンク、またはコンピュータがプログラミングコードおよび/もしくはデータを読み取ることができる任意の他の媒体が含まれる。これらの形態のコンピュータ可読媒体の多くは、実行のためにプロセッサに1つまたは複数の命令の1つまたは複数のシーケンスを搬送することに関与する場合がある。
【0133】
コンピュータシステム1301は、たとえば、本明細書の他の箇所に記載されたグラフィカルユーザインターフェースを提供するためのユーザインターフェース(UI)1340を備える電子ディスプレイ1335を含むか、またはそれと通信することができる。UIの例には、限定なしに、グラフィカルユーザインターフェース(GUI)およびウェブベースのユーザインターフェースが含まれる。
【0134】
本開示の方法およびシステムは、1つまたは複数のアルゴリズムによって実装することができる。アルゴリズムは、中央処理装置1305による実行時にソフトウェアによって実施することができる。アルゴリズムは、たとえば、予測モデルなどの訓練されたモデルであり得る。
【0135】
いくつかの実施形態では、乗り物データの少なくとも一部分は、AIアルゴリズムを使用して生成されない所定のデータ送信方式に従って、リモートエンティティ(たとえば、クラウドアプリケーション)に送信されてよい。たとえば、状況によっては、データ送信がまれであるか、または送信されるデータ量が比較的少ないとき、データ送信方式は、機械学習モデルを使用せずにクラウドアプリケーションからの要求に基づいて生成されてよい。そのような状況では、データ送信は、リモートエンティティと対象乗り物に存在するデータオーケストレータとの間の要求および応答を処理する/渡す中間エンティティ(たとえば、相手先商標製造会社(OEM))によって管理されてよい。中間エンティティは、リモートエンティティとデータオーケストレータとの間の修正されていないかまたは処理されたデータ送信要求/応答を渡すためにプロキシとして機能することができる。場合によっては、中間エンティティは、要求に基づいて乗り物データを送信する1台または複数の対象乗り物を決定することができる。場合によっては、中間エンティティはさらに、乗り物データの少なくとも一部分を集約するかまたは組み立て、それを要求アプリケーションに送信することができる。場合によっては、中間エンティティは、乗り物データおよび/または送信に関する情報(たとえば、データソース、データ処理方法など)を記述するメタデータを生成し、メタデータを要求アプリケーションに送信することができる。図16は、本発明のいくつかの実施形態による、OEM1630の助けを借りて管理されるデータ送信を概略的に示す。
【0136】
OEM1630は、基本的な乗り物データおよび機能を管理することができる。OEM1630は、本明細書の他の箇所に記載された1つもしくは複数のクラウドアプリケーション、企業クラウド、または他のサードパーティエンティティ1640-1、1640-2などのリモートエンティティと直接通信することができる。OEMは、知覚(たとえば、ASIC、FPGA、GPUアクセラレータ、SIMDメモリ、カメラ、Lidar、レーダー、GPSなどのセンサ/検出器)、位置特定および計画(たとえば、データパス処理、DDRメモリ、位置特定データセット、慣性測定、GNSS)、決定または挙動(たとえば、モーションエンジン、ECCメモリ、挙動モジュール、調停、予測子)、制御(たとえば、ロックステッププロセッサ、DDRメモリ、安全性モニタ、フェイルセーフフォールバック、バイワイヤコントローラ)、接続およびI/O(たとえば、RFプロセッサ、ネットワークスイッチ、決定論的バス、データ記録)などの、様々な実行時ソフトウェア構成要素または基本ソフトウェアサービスを提供することができる。OEMは、前述のソフトウェアサービスまたはセンサによって生成されたテレマティクスデータを収集または管理することができる。テレマティクスデータには、たとえば、速度関連データ(たとえば、急加速、速度違反、頻繁な加速)、停止関連データ(たとえば、急ブレーキ、頻繁な停止、頻繁なブレーキ)、方向転換関連データ(たとえば、急な方向転換、方向転換前の加速、出口前の過制動、進路逸脱)、通常運転する経路に関連するデータ(たとえば、高速道路対地方道路、既知の交通渋滞があるエリア、事故率が高い/低いエリア)、または他のデータ(たとえば、疲労した方向転換、いつも高速車線を走行すること、方向指示器の使用)が含まれてよい。OEM1630は、1つもしくは複数の乗り物1610-1、1610-2、および/または1つもしくは複数のデータオーケストレータ1620-1、1620-2と通信することができる。
【0137】
いくつかの実施形態では、OEMなどの中間エンティティは、予測モデル管理モジュールからのどの(1つまたは複数の)予測モデルを選択された乗り物または乗り物のフリートに送信するか、およびどの(1つまたは複数の)構成要素がこれらのモデルを受信することができるかを判断するように構成されたデータおよび知識管理システムを管理することができる。場合によっては、(1つまたは複数の)モデルは、クラウドサブスクリプションモジュールを介して(1つまたは複数の)関連の乗り物にOTAで送信されてよい。場合によっては、リモートアプリケーションは、OEMに要求を送信することによって1つまたは複数の乗り物からのデータを要求することができる。たとえば、保険アプリケーションは、不正を検出し、新しい保険商品を作成し、安全機能のために運転者に割引を提供し、リスクを評価し、事故現場管理、最初の紛失通知、請求処理の強化などの目的で、所定の頻度(たとえば、1週間、2週間、1ヶ月、2ヶ月など)で対象乗り物に関連付けられたOEMシステムからの特定のタイプのデータ(たとえば、OEM組込みデバイスによって収集されたデータ)を要求することができる。次いで、OEMは、データ送信を調整するために、対象乗り物に関連付けられたデータオーケストレータに要求を渡すことができる。要求されたタイプのデータは、データオーケストレータから要求アプリケーション1640-1、1640-2に直接送信されてよい。
【0138】
図17は、データオーケストレータ1720と1つまたは複数のクラウドアプリケーションとの間のデータ送信プロセスを示す。場合によっては、1つまたは複数のデータオーケストレータと1つまたは複数のクラウドアプリケーションとの間のデータ送信は、乗り物OEM1730などの中間エンティティの助けを借りて調整および管理されてよい。データオーケストレータは、本明細書の他の箇所に記載された乗り物と共にローカルに存在してよい。
【0139】
いくつかの実施形態では、1つまたは複数のクラウドアプリケーションは、特定のタイプの乗り物データを要求する要求1710を乗り物OEM1730に送信することができる。たとえば、要求1710は、アプリケーション(たとえば、App1)によって必要とされるデータのタイプ、データが必要とされる頻度、そのようなタイプのデータが送信される時間期間に関する情報、または対象乗り物の識別番号などの他の情報を含んでよい。たとえば、要求アプリケーションApp1(たとえば、保険アプリケーション)は、対象乗り物に関連付けられた乗り物OEM1730に、対象乗り物から必要とされるデータのタイプおよびそのようなデータの頻度を示す要求を送信することができる。
【0140】
乗り物OEM1730は、対象乗り物のデータオーケストレータに要求1711を渡す(たとえば、要求メッセージを送信して要求を中継する)ことができる。データオーケストレータに渡される要求1711は、元の要求1710と同じ修正されていない要求であってよい。代替または追加として、乗り物OEM1730は、クラウドアプリケーションApp1から受信された要求1710を処理し、どの乗り物/データオーケストレータが要求1711を受信する対象乗り物/データオーケストレータであるかを判断することができる。たとえば、元の要求1710は、(たとえば、乗り物IDを知らない)対象乗り物を指定することなく、請求プロセスを強化するためにあるタイプの乗り物からテレマティクスデータを要求することができ、次いで、乗り物OEM1730は、乗り物タイプの要件を満たす対象乗り物を識別し、識別された対象乗り物/データオーケストレータに要求1711を送信することができる。場合によっては、要求は乗り物のグループを指定することができる。たとえば、要求は、特定のモデル(たとえば、Audi A8)、年式(たとえば、2017年)、特定の運転自動化機能を有するモデル(たとえば、車線変更モニタ付きのA8)などを指定することができる。OEMシステムは、それぞれの対象乗り物のデータオーケストレータに要求を渡す(たとえば、要求メッセージを送信して要求を中継する)ことができる。上述されたように、乗り物OEMは、データオーケストレータと要求アプリケーションとの間で要求および応答を渡すためにプロキシとして機能することができる。これは、乗り物IDまたは他の乗り物情報がサードパーティ(たとえば、クラウドアプリケーション)に公開されない場合があるので、有利なことに、セキュリティの層を追加することができる。
【0141】
要求1711を受信すると、データオーケストレータは、要求をキューにプッシュし、要求の受信を確認応答するために乗り物OEM1730にメッセージを送り返すことができる。次いで、乗り物OEM1730は、要求が記録されたことを示すメッセージ(すなわち、応答)を要求アプリケーションに送信することができる。
【0142】
対象乗り物に関連付けられた1つまたは複数のデータオーケストレータは、要求1711に含まれる情報に基づいて、要求された乗り物データを要求アプリケーションに送信することができる。たとえば、1つまたは複数のデータオーケストレータは、要求されたデータ(たとえば、データパケット)を要求アプリケーションに直接送信することができる。
【0143】
場合によっては、要求/応答メッセージの受け渡しおよび中継に加えて、乗り物OEMは、データ送信を調整するための指示を送信することができる。たとえば、乗り物OEMは、送信周期が完了したときに(たとえば、データオーケストレータから完了メッセージを受信すると)、キューから送信要求を削除するようにデータオーケストレータに指示するメッセージをデータオーケストレータに送信することができる。次いで、データオーケストレータは、キューから項目を削除し、項目が削除されたことを示すメッセージを乗り物OEMに送信することができる。OEMシステムは、要求が完了したことを示すメッセージを要求アプリケーションに送信することができる。
【0144】
本発明の好ましい実施形態が本明細書に図示および記載されているが、そのような実施形態が例としてのみ提供されていることが当業者には明らかであろう。本発明が本明細書内に提供された特定の例によって限定されることは意図されていない。本発明は前述の明細書を参照して記載されているが、本明細書の実施形態の説明および図示は、限定的な意味で解釈されることを意図していない。当業者は次に、本発明から逸脱することなく、多数の変形、変更、および置換を思いつくであろう。さらに、本発明のすべての態様は、様々な条件および変数に依存する本明細書に記載された特定の描写、構成、または相対的比率に限定されないことを理解されたい。本明細書に記載された本発明の実施形態に対する様々な代替案が、本発明を実践する際に利用されてよいことが理解されるべきである。したがって、本発明は、そのような代替、修正、変形、または均等物もカバーすることが考えられる。以下の特許請求の範囲が本発明の範囲を定義し、これらの特許請求の範囲内の方法および構造ならびにそれらの均等物がそれらによってカバーされることが意図されている。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20