特開2022-33712行程分析のための車両イベントデータを処理するシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022033712
(43)【公開日】2022-03-02
(54)【発明の名称】行程分析のための車両イベントデータを処理するシステム及び方法
(51)【国際特許分類】
G06F 16/909 20190101AFI20220222BHJP
G06F 16/28 20190101ALI20220222BHJP
G08G 1/01 20060101ALI20220222BHJP
G08G 1/13 20060101ALI20220222BHJP
【ＦＩ】
G06F16/909
G06F16/28
G08G1/01 A
G08G1/13
【審査請求】未請求
【請求項の数】26
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2021130882
(22)【出願日】2021-08-10
(31)【優先権主張番号】63/063,518
(32)【優先日】2020-08-10
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】521352370
【氏名又は名称】ウィージョ リミテッド
【氏名又は名称原語表記】ＷＥＪＯ ＬＴＤ．
(74)【代理人】
【識別番号】100121728
【弁理士】
【氏名又は名称】井関 勝守
(74)【代理人】
【識別番号】100165803
【弁理士】
【氏名又は名称】金子 修平
(74)【代理人】
【識別番号】100170900
【弁理士】
【氏名又は名称】大西 渉
(72)【発明者】
【氏名】ガウソープ，アラン
(72)【発明者】
【氏名】スラック，マシュー
(57)【要約】 （修正有）
【課題】車両イベントデータを処理するシステム、方法、及びコンピュータプログラム製品を提供する。
【解決手段】ジオロケーションイベント処理及び分析のためのシステム１０において、方法は、位置イベントデータを取り込み、イベントデータから車両の行程を識別する。行程の識別には、所与の車両が行程の目的地まで運転する目的で移動しているかどうかの識別が含まれる。
【選択図】図１
【解決手段】ジオロケーションイベント処理及び分析のためのシステム１０において、方法は、位置イベントデータを取り込み、イベントデータから車両の行程を識別する。行程の識別には、所与の車両が行程の目的地まで運転する目的で移動しているかどうかの識別が含まれる。
【選択図】図１
【特許請求の範囲】
【請求項1】
方法のためのプログラム命令を含むメモリと前記プログラム命令を実行するように構成されているプロセッサとを含むシステムであって、前記方法は、
位置イベントデータをストリーム処理サーバに取り込むことと、
前記ストリーム処理サーバで、前記位置イベントデータから車両の行程を識別することとを含み、
前記行程を識別することは、所与の車両の移動が前記行程の行程セグメントであるかどうかを識別することを含む、システム。
位置イベントデータをストリーム処理サーバに取り込むことと、
前記ストリーム処理サーバで、前記位置イベントデータから車両の行程を識別することとを含み、
前記行程を識別することは、所与の車両の移動が前記行程の行程セグメントであるかどうかを識別することを含む、システム。
【請求項2】
前記位置イベントデータは、関心のある時刻、位置（緯度／軽度）及びイベントを含む、請求項１に記載のシステム。
【請求項3】
前記プロセッサは、前記イベントデータ内の位置データを近接度に応じて符号化することをさらに含む方法のための命令を実行するように構成される、請求項１に記載のシステム。
【請求項4】
前記イベントデータ内の前記位置データを近接度に応じて符号化する方法のための前記命令は、
緯度及び経度を前記近接度が定義される形状にジオハッシュすること、
前記ジオハッシュを州が識別されるように符号化すること、
前記ジオハッシュを郵便番号が識別されるように符号化すること、
前記ジオハッシュを車両が一意に識別される精度に符号化すること、
の少なくとも一つをさらに含む、請求項３に記載のシステム。
緯度及び経度を前記近接度が定義される形状にジオハッシュすること、
前記ジオハッシュを州が識別されるように符号化すること、
前記ジオハッシュを郵便番号が識別されるように符号化すること、
前記ジオハッシュを車両が一意に識別される精度に符号化すること、
の少なくとも一つをさらに含む、請求項３に記載のシステム。
【請求項5】
前記イベントデータ内の前記位置データを近接度に応じて符号化する方法のための前記命令は、
前記ジオハッシュを州が識別されるように５文字に符号化すること、
前記ジオハッシュを郵便番号が識別されるように６文字に符号化することと、
前記ジオハッシュを車両が一意に識別されるように９文字に符号化すること、
の少なくとも一つをさらに含む、請求項４に記載のシステム。
前記ジオハッシュを州が識別されるように５文字に符号化すること、
前記ジオハッシュを郵便番号が識別されるように６文字に符号化することと、
前記ジオハッシュを車両が一意に識別されるように９文字に符号化すること、
の少なくとも一つをさらに含む、請求項４に記載のシステム。
【請求項6】
前記イベントデータ内の前記位置データを近接度が定義される形状に符号化することは、前記緯度及び経度を該文字列の文字に比例する複数の辺を有する矩形にジオハッシュすることを含む、請求項５に記載のシステム。
【請求項7】
前記イベントデータ内の位置データを近接度に応じて符号化することは、
前記ジオハッシュを４～９文字に符号化すること、
を含む、請求項６に記載のシステム。
前記ジオハッシュを４～９文字に符号化すること、
を含む、請求項６に記載のシステム。
【請求項8】
前記方法のための前記命令を実行するように構成されている前記プロセッサは、前記ジオハッシュを地図データベースに写像することをさらに含む、請求項１に記載のシステム。
【請求項9】
前記写像は、前記ジオハッシュを関心のあるデータベースのポイントに写像することをさらに含む、請求項８に記載のシステム。
【請求項10】
前記行程を識別することは、
前記車両のエンジンオン、又は開始動作を識別すること、
前記車両のエンジンオフ、又は停止動作を識別すること、
前記車両の滞留時間を識別すること、
前記車両の最小走行距離を識別すること、
最小走行時間を識別すること、
を含む、請求項１に記載のシステム。
前記車両のエンジンオン、又は開始動作を識別すること、
前記車両のエンジンオフ、又は停止動作を識別すること、
前記車両の滞留時間を識別すること、
前記車両の最小走行距離を識別すること、
最小走行時間を識別すること、
を含む、請求項１に記載のシステム。
【請求項11】
前記プロセッサは、最小走行時間基準で構成され、且つ、前記最小走行時間基準を使用して前記車両の前記最小走行時間を識別するための命令を実行するように構成されている、請求項１０に記載のシステム。
【請求項12】
前記最小走行時間基準は、約６０から約１２０秒である、請求項１１に記載のシステム。
【請求項13】
前記最小走行時間基準は、約６０秒である、請求項１２に記載のシステム。
【請求項14】
前記プロセッサは、最大滞留時間基準で構成され、且つ、前記最大滞留時間基準を使用して前記車両の前記最大滞留時間を識別するための命令を実行するように構成されている、請求項１０に記載のシステム。
【請求項15】
前記最大滞留時間基準は、約２０から約６０秒である、請求項１４に記載のシステム。
【請求項16】
前記最大滞留時間基準は、約３０秒である、請求項１５に記載のシステム。
【請求項17】
前記プロセッサは、最小走行距離基準で構成され、且つ、前記最小走行距離基準を使用して前記車両の前記最小走行距離を識別するための命令を実行するように構成されている、請求項１０に記載のシステム。
【請求項18】
前記最小走行距離基準は、約１００メートルから約３００メートルである、請求項１７に記載のシステム。
【請求項19】
前記最小走行距離基準は、約２００メートルである、請求項１８に記載のシステム。
【請求項20】
前記行程を識別することは、前記行程セグメントが前記行程の一部であるかどうかを識別することを含む、請求項１に記載のシステム。
【請求項21】
前記システムは、能動車両検出を提供するように構成されている、請求項１に記載のシステム。
【請求項22】
前記能動車両検出は、一定期間の複数の前記イベントから車両経路を識別することを含む、請求項１５に記載のシステム。
【請求項23】
前記能動車両検出は、一日の複数の前記イベントから車両経路を識別することを含み、前記識別は、連結成分アルゴリズムを使用することを含み、前記連結成分アルゴリズムは、車両イベントの当該日を含む有向グラフにおける前記車両経路の識別を含み、前記グラフにおいて、ノードは車両であり、ノード間の接続は、前記識別された車両経路である、請求項２１に記載のシステム。
【請求項24】
前記システムは、データウェアハウスを含み、且つ、前記データウェアハウスに前記イベントデータ及び行程決定データを格納する、請求項１に記載のシステム。
【請求項25】
前記格納されているデータに追加される少なくとも一つの時間列をさらに備える、請求項２４に記載のシステム。
【請求項26】
前記時間列は、日付及び時間列を含む、請求項２５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
（関連する出願への相互参照）
この出願は、２０２０年８月１０日出願の米国仮特許出願第６３／０６３５１８号に基づく優先権を主張し、その全体を参照により本明細書に援用する。
この出願は、２０２０年８月１０日出願の米国仮特許出願第６３／０６３５１８号に基づく優先権を主張し、その全体を参照により本明細書に援用する。
【背景技術】
【0002】
（開示の背景）
自動車産業は、これまでに見られたものとは異なり、根本的な変化を遂げている。モビリティエコシステム全体で混乱が起こっている。その結果、より自動化され、接続され、電化され、共有される車両が生まれている。これにより、車で生成されるデータは爆発的に増加している。この豊富な新しいデータ資産の大部分は、未開発のままである。
自動車産業は、これまでに見られたものとは異なり、根本的な変化を遂げている。モビリティエコシステム全体で混乱が起こっている。その結果、より自動化され、接続され、電化され、共有される車両が生まれている。これにより、車で生成されるデータは爆発的に増加している。この豊富な新しいデータ資産の大部分は、未開発のままである。
【0003】
ＧＰＳデータのような車両位置イベントデータは、非常に膨大であり、毎秒２００，０００から６００，０００レコードを含み得る。位置イベントデータの処理は、特に個々の車両についてデータの実質的なリアルタイム分析を提供する従来のシステムにとって、課題を提示する。さらに、個々の車両データは、これらのスケールで分析するために個々の車両データを識別しながら、適切に匿名化するという課題に直面している。必要なものは、大量のデータを分析と再処理に利用できるようにしながら、大量のデータを低遅延で処理且つ保存するように構成されているシステムプラットフォーム、データ処理アルゴリズム、及び処理である。
【0004】
車両追跡のためのシステムがあるけれども、必要なものは、大量の車両データからのリアルタイムに近い、且つ正確な行程データである。必要なものは、車両の動き及び経路分析から行程及び行程の目的地を正確に識別するように構成されているシステムとアルゴリズムである。
【発明の概要】
【0005】
（開示の概要）
以下では、簡単に、本明細書に記載の技術革新のいくつかの態様の基本的な理解を提供するための実施例について記載する。この簡単な説明は、広範な概要を意図したものではない。鍵となる重要な要素を識別したり、範囲を明確にしたり、狭めたりすることを目的としたものでもない。その目的は、単に、後に提示するさらに詳細な説明の前置きとして、いくつかの概念を簡略化された形式で提示することである。
以下では、簡単に、本明細書に記載の技術革新のいくつかの態様の基本的な理解を提供するための実施例について記載する。この簡単な説明は、広範な概要を意図したものではない。鍵となる重要な要素を識別したり、範囲を明確にしたり、狭めたりすることを目的としたものでもない。その目的は、単に、後に提示するさらに詳細な説明の前置きとして、いくつかの概念を簡略化された形式で提示することである。
【0006】
簡潔に記載すると、本明細書は、車両イベントデータを処理するためのシステム、方法、及びコンピュータプログラム製品の様々な実施形態について開示する。
【0007】
少なくとも一実施形態は、方法のためのプログラム命令を含むメモリと前記プログラム命令を実行するように構成されているプロセッサとを含むシステムであって、前記方法は、位置イベントデータをストリーム処理サーバに取り込むことと、
前記ストリーム処理サーバで前記位置イベントデータから車両の行程を識別することとを含み、前記行程を識別することは、所与の車両の移動が前記行程の行程セグメントであるかどうかを識別することを含むものである。
前記ストリーム処理サーバで前記位置イベントデータから車両の行程を識別することとを含み、前記行程を識別することは、所与の車両の移動が前記行程の行程セグメントであるかどうかを識別することを含むものである。
【0008】
一実施形態では、前記位置イベントデータは、関心のある時刻、位置（緯度／軽度）及びイベントを含む。関心のあるイベントには、急ブレーキ、急減速、又は急加速が含まれる。急ブレーキ又は急減速は、所定期間における減速として定義することができる。急加速は、別の所定期間における加速として定義することができる。
【0009】
一実施形態では、前記プロセッサは、前記イベントデータ内の位置データを近接度に応じて符号化することをさらに含む方法のための命令を実行するように構成される。
【0010】
一実施形態では、前記イベントデータ内の前記位置データを近接度に応じて符号化する方法のための前記命令は、緯度及び経度を前記近接度が定義される形状にジオハッシュすること、前記ジオハッシュを州が識別されるように符号化すること、前記ジオハッシュを郵便番号が識別されるように符号化すること、前記ジオハッシュを車両が一意に識別される精度に符号化すること、の少なくとも一つをさらに含むことができる。
【0011】
一実施形態では、前記イベントデータ内の前記位置データを近接度に応じて符号化する方法のための前記命令は、前記ジオハッシュを州が識別されるように５文字に符号化すること、前記ジオハッシュを郵便番号が識別されるように６文字に符号化することと、前記ジオハッシュを車両が一意に識別されるように９文字に符号化すること、の少なくとも一つをさらに含むことができる。一実施形態では、前記イベントデータ内の前記位置データを近接度が定義される形状に符号化することは、前記緯度及び経度を該文字列の文字に比例する複数の辺を有する矩形にジオハッシュすることを含むことができる。
【0012】
一実施形態では、前記イベントデータ内の位置データを近接度に応じて符号化することは、前記ジオハッシュを４から９文字に符号化することを含むことができる。
【0013】
一実施形態では、前記プロセッサは、前記ジオハッシュを地図データベースに写像することをさらに含む方法のための前記命令を実行するように構成されている。前記写像は、前記ジオハッシュを関心のあるデータベースのポイントに写像することをさらに含むことができる。
【0014】
一実施形態では、前記行程を識別することは、前記車両のエンジンオン、又は最初の車両動作を識別すること、前記車両のエンジンオフ、又は停止動作を識別すること、前記車両の滞留時間を識別すること、前記車両の最小走行距離を識別すること、最小走行時間を識別することを含む。
【0015】
一実施形態では、前記プロセッサは、最小走行時間基準で構成され、且つ、前記最小走行時間基準を使用して前記車両の前記最小走行時間を識別するための命令を実行するように構成されている。前記最小走行時間基準は、約６０から約９０秒であり得る。一実施形態では、前記最小走行時間基準は、約６０秒である。
【0016】
一実施形態では、前記プロセッサは、最大滞留時間基準で構成され、且つ、前記最大滞留時間基準を使用して前記車両の前記最大滞留時間を識別するための命令を実行するように構成されている。前記最大滞留時間基準は、約２０から約１２０秒であり得る。一実施形態では、前記最大滞留時間基準は、約３０秒である。
【0017】
一実施形態では、前記プロセッサは、最小走行距離基準で構成され、且つ、前記最小走行距離基準を使用して前記車両の前記最小走行距離を識別するための命令を実行するように構成されている。前記最小走行距離基準は、約１００メートルから約３００メートルであり得る。一実施形態では、前記最小走行距離基準は、約２００メートルである。
【0018】
一実施形態では、前記行程を識別することは、行程セグメントが前記行程の一部を形成しないことを決定することを含む。
【0019】
一実施形態では、前記システムは、能動車両検出を提供するように構成されている。前記能動車両検出は、一定期間の複数の前記イベントから車両経路を識別することを含むことができる。一実施形態では、前記能動車両検出は、一日の複数の前記イベントから車両経路を識別することを含み、前記識別は、連結成分アルゴリズムを使用することを含み、前記連結成分アルゴリズムは、車両イベントの当該日を含む有向グラフにおける前記車両経路の識別を含む。前記グラフにおいて、ノードは車両であり、ノード間の接続は、前記識別された車両経路である。
【0020】
一実施形態では、前記システムは、データウェアハウスを含むことができ、前記データウェアハウスに前記イベントデータ及び行程決定データを格納する。一実施形態では、前記格納されているデータに少なくとも一つの時間列を追加することができる。前記時間列は、日付及び時間列を含むことができる。
【0021】
少なくとも一実施形態では、プロセッサと、上記及び本明細書に記載されている方法を実行するための命令を含むプログラムメモリを含むメモリとを含むコンピュータによって実施される方法について記載されている。
【0022】
少なくとも一実施形態では、上記及び本明細書に記載されている方法をプロセッサによって実行する命令を含むプログラムメモリを含むコンピュータプログラム製品について記載されている。
【0023】
本明細書で使用するように、行程は、目的地への任意の走行、運航、移動を含み得る。
【0024】
１２百万台までの車両に対して毎秒６０万レコードまでの車両イベントデータを取り込み、且つ、処理可能な本開示に関する本明細書に記載したシステム及び方法の典型的な利点は、最適化された低遅延である。
【図面の簡単な説明】
【0025】
非限定的かつ非網羅的な実施形態について、以下の図面を参照して説明する。尚、図面において、同様の参照番号は、特に明記しない限り、様々な図全体を通して同様の部分を指す。
【0026】
理解を深めるために、添付の図面と併せて読むべき以下の詳細な説明を参照する。
【発明を実施するための形態】
【0027】
様々な実施形態について本明細書の一部を形成する添付図面を参照して詳細に説明する。添付図面は、例示によって、本明細書に記載される革新が実施され得る特定の実施形態を示す。しかしながら、実施形態は、多くの異なる形態で具体化することができ、本明細書に記載の実施形態に限定されると解釈されるべきではない。むしろ、これらの実施形態は、本開示が徹底的かつ完全となり、当業者に十分に実施形態の範囲を伝えるように提供されている。とりわけ、様々な実施形態は、方法、システム、媒体、又は装置であり得る。したがって、以下の詳細な説明は、限定的な意味で解釈されるべきではない。
【0028】
本明細書及び特許請求の範囲を通して、以下の用語は、文脈が明確に別段の指示がない限り、本明細書に明示的に関連する意味を取るものとする。「本明細書」という用語は、本出願に関連する明細書、特許請求の範囲、及び図面を指す。本明細書で使用される「一実施形態において」又は「実施形態において」という句は、可能であるものの、必ずしも同じ実施形態又は単一の実施形態を指すとは限らない。さらに、本明細書で使用される「別の実施形態において」という句は、可能ではあるものの、必ずしも異なる実施形態を指すとは限らない。したがって、以下に説明するように、本発明の範囲又は精神から逸脱することなく、様々な実施形態を容易に組み合わせることができる。
【0029】
さらに、文脈で明確に別段の指示がない限り、本明細書で使用されるように、用語「又は」は、包括的な「又は」と、「及び／又は」の用語とに相当する。「に基づく」という用語は排他的ではなく、文脈で明確に別段の指示がない限り、説明されていない追加の要因に基づくことを許容する。さらに、本明細書全体を通して、「一つの」及び「前記」、「上記」の意味は、複数形の参照を含む。「において」の意味には、「の中で」と「の上で」とが含まれる。
【0030】
（例示の論理システムアーキテクチャとシステムフロー）
図１は、少なくとも一実施形態による、ジオロケーションイベント処理及び分析のためのシステム１０の論理アーキテクチャである。様々な実施形態のうちの少なくとも一つでは、入力サーバシステム１００は、ストリーム処理サーバシステム２００及び分析サーバシステム５００と通信するように構成することができる。ストリーム処理サーバシステム２００は、出力サーバシステム４００及び分析サーバシステム５００と通信するように構成することができる。
図１は、少なくとも一実施形態による、ジオロケーションイベント処理及び分析のためのシステム１０の論理アーキテクチャである。様々な実施形態のうちの少なくとも一つでは、入力サーバシステム１００は、ストリーム処理サーバシステム２００及び分析サーバシステム５００と通信するように構成することができる。ストリーム処理サーバシステム２００は、出力サーバシステム４００及び分析サーバシステム５００と通信するように構成することができる。
【0031】
出力サーバシステム４００は、データコンシューマと通信し、データ出力を提供するように構成することができる。出力サーバシステム４００は、また、ストリーム処理サーバ２００と通信するように構成することができる。
【0032】
分析サーバシステム５００は、入力サーバ１００、ストリーム処理サーバシステム２００、及び出力サーバシステム４００と通信し、データを受け入れるように構成されている。分析サーバシステム５００は、ポータルサーバシステム６００と通信し、データを出力するように構成されている。
【0033】
少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、及びポータルサーバシステム６００は、それぞれ、一つ又は複数のコンピュータ又はサーバとすることができる。少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、及びポータルサーバシステム６００のうちの一つ又は複数は、単一のコンピュータ、例えば一つのネットワークサーバコンピュータ上で、又は複数のコンピュータに亘って動作するように構成することができる。例えば、少なくとも一実施形態では、システム１０は、アマゾンウェブサービス（ＡＷＳ）（登録商標）又はマイクロソフト（登録商標）アジュールなどのウェブサービスプラットフォームホスト上で実行するように構成することができる。例示的な実施形態では、システムは、本明細書で説明するデータ処理を実行するように構成することができるスパークストリーミングサーバを採用するＡＷＳ（登録商標）プラットフォーム上に構成されている。一実施形態では、システムは、高スループットメッセージングサーバ、例えば、アパッチカフカを使用するように構成することができる。
【0034】
少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、及びポータルサーバシステム６００は、サービスによって提供されるＡＰＩ又は他の通信インタフェースを用いて、統合及び／又は通信するように構成することができる。
【0035】
少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、及びポータルサーバシステム６００は、ホスティングサーバ上でホストすることができる。
【0036】
少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、及びポータルサーバシステム６００は、ワイドアクセスネットワーク（ＷＡＮ）又はローカルアクセスネットワーク（ＬＡＮ）を含む一つ以上の直接のネットワーク経路を使用して、ネットワーク上で直接又は間接的に、クライアントコンピュータと通信するように構成することができる。
【0037】
当業者は、システム１０のアーキテクチャは、少なくとも一実施形態の一部を例示する非限定的な例であることを理解するであろう。したがって、本明細書に記載の革新の範囲から逸脱することなく、多かれ少なかれコンポーネントを異なる方法で使用及び／又は配置することができる。しかしながら、システム１０は、少なくとも本明細書で主張する革新を開示するのに十分である。
【0038】
図２を参照して、少なくとも一実施形態によるデータ取り込み及びデータスループットのための入力サーバシステム１００の論理アーキテクチャシステムを示す。少なくとも一実施形態では、一つ又は複数のイベントソースからのイベントを決定することができる。一実施形態では、図１に示されるように、イベントソースは、車両センサデータソース１２、ＯＥＭ車両センサデータソース１４、アプリケーションデータソース１６、テレマティクスデータソース２０、無線インフラストラクチャデータソース１７、及びサードパーティデータソース１５などを含むことができる。少なくとも一実施形態では、決定されたイベントは、ストリーム処理サーバシステム２００及び分析サーバシステム５００などのシステムの下流コンポーネントによって管理することができる位置データ、車両センサデータ、様々なユーザインタラクション、表示操作、インプレッションなどに対応することができる。少なくとも一実施形態においては、入力サーバシステム１００は、図１から２に示すよりも多くの又は少ないイベントソースを入力とすることができる。
【0039】
少なくとも一実施形態において、一つ又は複数のイベントソースから受信及び／又は決定することができるイベントには、例えば、ＧＰＳ装置や、ＯＥＭ車両センサデータソース１４などのサードパーティデータソース１５によって提供される位置データ表など、一つ又は複数のデータソースからの車両イベントデータが含まれる。車両イベントデータは、例えば、ＪＳＯＮ、ＣＳＶ、及びＸＭＬのデータベース形式で取り込むことができる。車両イベントデータは、サービス及び／又は入力サーバシステム１００によって提供されるＡＰＩ又は他の通信インタフェースを介して取り込むことができる。例えば、入力サーバシステム１００は、入力サーバシステム１００が車両イベントソース１４によって提供されるデータベースに関連付けることができる様々なイベントを決定することを可能にする入力サーバＡＰＩ１０６が統合されているＡＰＩゲートウェイ１０２インタフェースを提供することができる。例示的なＡＰＩゲートウェイは、例えば、ＡＷＳ（登録商標） ＡＰＩゲートウェイを含むことができる。入力サーバシステムシステム１００のための例示的なホスティングプラットフォームは、クバネティスとドッカーとを含むことができるが、他のプラットフォーム及びネットワークコンピュータ構成を使用することもできる。
【0040】
少なくとも一実施形態では、入力サーバシステム１００は、例えば、Ｓｅｃｕｒｅ ＦＩＬＥ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅｒ（ＳＦＴＰ）などの生データを受け入れるように構成されているサーバ１０４、ＡＰＩを含むか、又は他のデータ入力を構成して車両イベントデータを受け入れるようにすることができる。入力サーバシステム１００は、例えば、分析サーバシステム５００による詳細分析のために、生データをデータストア１０７に格納するように構成することができる。イベントデータには、イグニッションオン、タイムスタンプ（Ｔ１…ＴＮ）、イグニッションオフ、興味のあるイベントデータ、緯度及び経度、並びに車両情報番号（ＶＩＮ）情報を含めることができる。典型的なイベントデータは、当技術分野で知られているソース、例えば、車両自体（例えば、ＧＰＳ、ＡＰＩを介して）から、又はサードパーティデータソース１５から提供される位置データテーブルからいずれの車両移動データも含むことができる。
【0041】
一実施形態では、入力サーバシステム１００は、イベントデータを処理して、例えば、速度、走行時間、及び加速度などの車両移動データを導出するように構成されている。例えば、一実施形態では、ｘ秒（例えば、３秒）毎にイベントデータベース上のスナップショットを取る。次に、緯度／経度データと時間データとを処理して、車両の位置と時間とを使用して、速度や加速度などの車両追跡データを導出することができる。
【0042】
一実施形態において、入力サーバシステム１００は、装置及びサードパーティプラットフォームからのデータを受け入れるように構成されている。入力サーバＡＰＩ１０６は、装置又はサード－パーティプラットフォーム及びプラットフォームホストをシステム１０に対して認証するように構成することができる。
【0043】
そこで、本実施形態では、入力サーバシステム１００は、生データを受信し、生データ及びスキーマ評価のためのデータ品質検査を行うように構成されている。生データの取り込み及び検証は、図７のブロック７０１に示されるような、システムの品質検査のデータ品質パイプラインの開始点である。表１は、システムに受信され得る生データの一例を示す。
【表1】
【0044】
別の実施形態では、入力ソースからの車両イベントデータは、より少ない情報を含むことができる。例えば、表２に示すように、生の車両イベントデータには、位置データ（経度と緯度）や時間データ（タイムスタンプ）など、限られた数の属性を含めることができる。
【表2】
【0045】
本開示の実施形態の典型的な利点は、存在しない情報を本明細書に記載するような革新的なアルゴリズムから導出できることである。例えば、車両イベントデータに行程ＩＤが含まれていない場合や、行程ＩＤが不正確である場合がある。したがって、システムは、最初に入力されたデータが限定された属性を有する場合に、追加の車両イベント属性データを導出するように構成することができる。例えば、システムは、入力される車両イベントデータに対して特定の車両を識別し、車両ＩＤを追加するように構成することができる。システムは、それにより、車両ＩＤに関連付けられている、例えば、場所及びタイムスタンプデータのみを用いて、開始及び停止、速度、方位、加速度、及び他の属性を含む車両の動作を追跡することができる。例えば、一実施形態では、システムは、装置ＩＤを使用して装置ＩＤに関連付けられているフィールドに対する状態変化を識別するように構成することができる。
【0046】
逆に、一実施形態では、入力データは、例えば、燃料レベル、新しいセンサデータ（ドア開／ドア閉）、エアバッグ展開、又はセンサ傾向などの豊富なデータフィールドを含み、これら豊富なデータは、本書に記載するようにアルゴリズムを増強し、又は修正するために使用することができる。
【0047】
一実施形態では、ブロック７０２で、受信されたデータは、外部定義のスキーマ、例えば、アブロ（Ａｖｒｏ）又はジェイソン（ＪＳＯＮ）に適合することができる。データは内部スキーマに変換して検証することができる。一実施形態では、イベントデータは、データ品質パイプラインによる下流ストリーム処理のためのメッセージングシステムに渡される前に、合意されたスキーマ定義に対して検証することができる。例えば、検証済みのデータをアパッチカフカのメッセージングシステムに渡す前に、アパッチアブロのスキーマ定義を使用することができる。別の実施形態では、生の動作及びイベントデータは、クライアントノードクラスタ構成によって処理することもでき、各クライアントは、コンシューマ又はプロデューサであり、且つ、インスタンス内のクラスタは、それらの間でデータを複製することができる。
【0048】
例えば、入力サーバシステム１００は、パルサクラスタのアパッチパルサエンドポイントに接続しているパルサクライアントと一緒に構成することができる。一実施形態では、アパッチパルサエンドポイントは、最後に読み取られたデータを追跡し、アパッチパルサクライアントがいつでも接続して、最後に読み取られたデータからピックアップすることを可能にする。パルサの「標準」コンシューマインタフェースには、トピックをリッスンし、着信メッセージを処理し、メッセージが処理されたときにそれらのメッセージを最終的に確認する「コンシューマ」クライアントを使用することが含まれる。クライアントがトピックに接続するたびに、トピックのカーソルはパルサブローカモジュールによって自動的に管理されるため、クライアントは最初の未確認メッセージから上方に自動的に読み取りを開始する。しかし、クライアントのクライアントリーダーインタフェースを使用すると、クライアントアプリケーションでトピックカーソルを特注で管理することができる。例えば、パルサクライアントリーダーは、トピックに接続したときにリーダーが読み始めるメッセージを指定するように構成することができる。トピックに接続するとき、リーダーインタフェースを使用すると、クライアントはトピック内で利用可能な最も古いメッセージ又はトピック内で利用可能な最新のメッセージから開始することができる。クライアントリーダーは、例えば、永続的なデータストア又はキャッシュからメッセージを取得するメッセージＩＤを使うことによって、最も古いメッセージと最新のメッセージとの間の或る他のメッセージから開始するように構成することもできる。
【0049】
少なくとも一実施形態では、入力サーバシステム１００は、データをクリーンにし、且つ検証するように構成されている。例えば、入力サーバシステム１００は、入力の車両イベント及び位置データを検証し、検証済みデータを、例えば、アパッチカフカサーバキュー１０８に通過させた後、ストリーム処理サーバシステム２００に出力する、入力サーバＡＰＩ１０６を含むように構成することができる。サーバ１０４は、同様に、検証済みの入力位置データをデータストア１０７に出力するように構成することができる。例えば、無効なペイロードをデータストア１０７に格納することができる。無効なデータの例は、不良フィールド、認識されないフィールド、又は同一のイベントを有するデータを含むものであり得る。入力サーバシステム１００は、例えば、システム性能が向上する分析のために、保存された無効データをデータストア１０７から出力する、又は格納されたデータを分析サーバシステム５００に引っ張ることを許可するように構成することができる。例えば、分析サーバシステム５００は、診断機械学習を用いて、認識されないフィールドを有する無効なデータのデータベースに関する分析を実行し、検証処理のためのフィールドを新たに識別し、且つ、標識化するように構成することができる。入力サーバシステム１００は、また、格納されている入力位置データを、例えば、本明細書で記載する行程分析などの分析サーバシステム５００による処理のために渡すように構成することができる。
【0050】
本明細書に記載のように、システム１０は、ストリーミング及びバッチ状況の両方でデータを処理するように構成されている。ストリーミング状況では、完全性よりも低遅延が重要である。つまり、古いデータを処理する必要はない。実際、古いデータを処理すると、他の、より新しいデータの処理が妨げられる可能性があるため、悪影響が生じ得る。バッチ状況では、低遅延よりもデータの完全性が重要である。したがって、これらの二つの状況でデータの処理を容易にするために、一実施形態では、システムは、利用可能になると即座にすべてのデータを入力するが古いデータをスキップするように構成することもできるストリーミング接続をデフォルトにすることができる。バッチプロセッサは、古いデータのためにストリーミングプロセッサによって残された隙間を埋めるように構成することができる。
【0051】
図３は、少なくとも一実施形態による、データスループット及び分析のためのストリーム処理サーバシステム２００の論理アーキテクチャである。本明細書に記載するストリーム処理の結果として、少なくとも毎秒２００Ｋから６００Ｋまでの線形スケーリングにおけるスループット向上を含む、システム処理向上がもたらされている。改善にはさらに、２０秒のエンド・トゥ・エンドのシステム処理が含まれ、システム遅延のさらなる改善が進行中である。少なくとも一実施形態では、システムは、マイクロバッチ処理のためのサーバを使用するように構成することができる。例えば、本明細書で説明するように、少なくとも一実施形態では、ストリーム処理サーバシステム２００は、スパークストリーミングサーバを使用するＡＷＳ（登録商標）及びアパッチカフカなどの高スループットメッセージングサーバなどのウェブサービスプラットフォームホスト上で実行するように構成することができる。一実施形態では、ストリーム処理サーバシステム２００は、例えば、ＡＷＳ（登録商標）イグナイトなどの装置管理サーバ２０７を含むことができ、データ処理サーバからの入力処理データを構成することができる、装置管理サーバ２０７は、外部から提供され又は外部とインタフェースされ得る匿名化されたデータを個々の車両データ分析に使用するように構成することができる。システム１０は、リアルタイムでデータを出力するとともに、将来の分析のためにデータを一つ又は複数のデータストアに格納するように構成することができる。例えば、ストリーム処理サーバシステム２００は、インタフェース、例えば、アパッチカフカを介して、出力サーバシステム４００にリアルタイムデータを出力するように構成することができる。ストリーム処理サーバシステム２００は、リアルタイム及びバッチデータの両方をデータストア１０７内に格納するように構成することもできる。データストア１０７内のデータは、アクセスや、さらなる分析のために洞察サーバシステム５００に提供することができる。
【0052】
少なくとも一実施形態では、イベント情報は、後の処理及び／又は分析のために、一つ又は複数のデータストア１０７に格納することができる。同様に、少なくとも一実施形態では、イベントデータ及び情報は、それを決定又は受信するときに処理することができる。また、イベントペイロード及び処理情報は、履歴情報及び／又は比較情報として使用するため、並びにさらなる処理のため、データストア１０７などのデータストアに格納することができる。
【0053】
少なくとも一実施形態において、ストリーム処理サーバシステム２００は、車両イベントデータ処理を行うように構成されている。
【0054】
図３は、少なくとも一実施形態による、ストリーム処理サーバシステム２００の論理アーキテクチャ及び概略フローチャートを示す。ブロック２０２において、ストリーム処理サーバシステム２００は、入力位置２０１からの位置イベントデータの検証を実行する。適切にフォーマットされていない、重複している、又は認識されないデータを除外する。無効なデータの例には、不良フィールド、認識されないフィールド、もしくは同一のイベント（重複している）を有するデータ、又は同一場所及び時間に発生しているエンジンオン／エンジンオフのデータポイントが含まれ得る。検証には、遅延検査を含めることもできる。これにより、例えば７秒などの所定の期間より古いイベントデータを破棄する。一実施形態では、他の遅延フィルタを、例えば４秒から３０秒の間で使用することができる。
【0055】
一実施形態では、ストリーム処理サーバシステム２００は、エラーを有するフィールドデータのエラー訂正を実行するように構成することができる。例えば、システムは、入力される車両イベントデータをバッファして、車両の一連のデータポイントで、順序のおかしいポイントのセットを識別するように構成することができる。次に、システムは、最も古いデータポイントを検証してその他のデータポイントを破棄するように構成するか、又は車両イベントデータポイントを正しい時系列に再配置することができる。一実施形態では、バッファ時間は、システムの低遅延を最適化するように構成することができる。システム２００は、最少の入力データポイントをバッファして、エラーの識別及び検証を可能にするように構成することができる。例えば、３秒毎に車両イベントデータを提供する入力データストリームに対して、システムは、少なくとも３秒間バッファして、バッファされた車両イベントのエラー識別、エラー検査の実行、及び下流にデータ転送するためのイベントデータの修正を行うように構成することができる。入力ストリームのバッファは、例えば１秒毎など、より頻繁に車両イベントデータを提供する入力ストリームに対してさらに少なくすることができる。
【0056】
一実施形態では、ストリーム処理サーバシステム２００は、ステートフルストリーミングのためのイベントデータをバッファするように構成することができる。車両イベントデータを永続的なイベントログに保存し、且つ、イベント分析ロジックで処理できる。例えば、ストリーム処理サーバシステム２００は、車両イベントデータポイントが新規の行程に対するものか、又は既存の行程に関連付けられるものかを決定するように構成することができる。例えば、ストリーム処理サーバ２００は、車両イベントデータにおいて、信号損失（例えば、トンネル、地下駐車場、衛星／セルの死角領域）によるデータ空隙、イグニッション状態、及び他の走行データなどの状態データを識別するように構成することができる。次に、システムは、以下に説明するように、バッファを使用して、車両イベントデータポイントに対してシステムによって処理されている行程に識別するか、又は新しい行程を開始することができる。
【0057】
例えば、一実装では、バッファは、最初、空データである。与えられた車両の車両イベントデータが到着すると、バッファが検査される。イベントデータが新しい車両に対するものならば、車両イベントデータポイントの内容に関わらず、新規の行程が作成される。車両の新しいデータポイントが到着するたびに、バッファが検査される。データポイントのタイムスタンプが車両に記録されている最後のタイムスタンプより前である場合は、データポイントは無効であるとマーク付けされる。タイムスタンプは、設定可能な期間（例えば、２０分）より後である場合は、新規の行程が開始される。データポイントが現在の行程内にあるとみなされる場合は、バッファが最新の状態に更新され、且つ、データポイントは有効であるとマーク付けされる。イグニッションオン又はオフのようなデータポイントは、行程の開始又は終了の強力な信号として使用される。もっとも、後述するように、一定の位置における滞留時間基準を使用して、例えば、滞留時間により停止が短い停止（例えば、３０秒以下）であることを示す場合に、新規の行程作成を無視することもできる。
【0058】
システムのスケーラビリティを補助するため、データは、車両識別子を使用して分割されている。これにより、別々のノードがストリームデータのサブセットを処理できるが、特定のデータについてのすべてのデータは同じノードで処理されることが保証される。一実施形態では、図７のブロック７０３で示すように、ストリーム処理サーバシステム２００は、属性境界フィルタを実行するように構成されている。属性境界フィルタは、イベントデータ属性が有意なデータについて事前定義される境界内にあることを検査して確認する。例えば、進路属性は円（０→３５９）として定義されている。スキッシュｖｉｎは９から１０文字のＶＩＮである。複数の実施形態では、データプロバイダによって事前定義されているデータ、又は標準によって設定されているデータが含まれる。これらの境界内に存在しないデータ値は、データが属性に対して本質的に障害があることを示す。不適格データは検査して除外することができる。属性境界フィルタの一例を表３－１に示す。
【表3-1】
【0059】
一実施形態では、ブロック７０４でシステムは、属性値フィルタを行うように構成されている。属性値フィルタは、属性値が内部で設定されているか、又は特注で定義された範囲であることを確認する。例えば、１９７０年の日付は、イベントの日付属性の属性境界フィルタ検査に適合し得るが、車両追跡データの適切な値ではない。したがって、属性値フィルタは、事前定義された時間より古いデータ、例えば、６週間以上の古いデータをフィルタするように構成されており、検査及びフィルタすることができる。属性境界フィルタの一例を表３－２に示す。
【表3-2】
【0060】
ブロック７０５で、システムは、レコードデータポイントの属性間の関係が整合することを確認するためのレコードの属性に関する追加検証を行うことができる。例えば、ゼロ以外の走行開始イベントは、本明細書で説明するように、行程決定に対する論理的な意味がない。したがって、表４に示すように、システム１０は、開始イベントの「走行開始」又は行程イグニッションオン開始イベントとしての位置に対する取得タイムスタンプ及び受信タイムスタンプの同一属性について記録されたゼロ以外の速度イベントをフィルタするように構成することができる。
【表4】
【0061】
図２に戻ると、ブロック２０４において、少なくとも一実施形態では、ストリーム処理サーバ２００は、位置イベントデータのジオハッシュを実行する。Ｕｂｅｒ（登録商標）で採用されているＨ３アルゴリズムやＧｏｏｇｌｅ（登録商標）で採用されているＳ２アルゴリズムなど、ジオハッシュの代替手段が利用可能であるものの、ジオハッシュによって、システム１０は、典型的な改善、例えば、システム遅延やスループットの改善が提供されることが判明した。ジオハッシュによって、システム１０の精度及び車両検出におけるデータベースの改善も提供された。例えば、９文字の精度のジオハッシュを使用すると、車両をジオハッシュに一意に関連付けることができる。このような精度は、本明細書に記載するような行程決定アルゴリズムで使用することができる。少なくとも一実施形態では、イベントデータ内の位置データは、近接度に応じて符号化され、符号化は、各イベントの近接度に応じて各イベントの緯度及び経度をジオハッシュすることを含む。イベントデータは、時間、位置（緯度／経度）、及び関心のあるイベントデータを含む。関心のあるイベントデータには、急ブレーキ及び急加速が含まれ得る。例えば、急ブレーキは、所定期間の減速（例えば、ｘ秒で４０－０）として定義することができ、急加速は、所定期間での加速（例えば、ｘ秒で４０－８０ｍｐｈ）として定義することができる。関心のあるイベントデータは、他のアルゴリズムで使用するための相関付け及び処理をすることができる。例えば、場所が時空間クラスタに写像された急ブレーキのクラスタは、渋滞検出アルゴリズムとして使用することができる。
【0062】
ジオハッシュのアルゴリズムは、イベントデータからの緯度及び経度データをｎ文字の短い文字列に符号化する。一実施形態では、ジオハッシュされた緯度／経度データは、形状にジオハッシュされる。例えば、一実施形態では、緯度／経度データは、辺が文字列内の文字に比例する矩形にジオハッシュすることができる。一実施形態では、ジオハッシュは、４から９文字までに符号化することができる。
【0063】
本明細書に記載するように、ジオハッシュされたイベントデータを採用することから多くの利点が得られる。例えば、データベースでは、ジオハッシュによって索引付けされたデータには、連続するスライス内の特定の矩形領域のすべてのポイントが含まれ、スライスの数は、符号化するジオハッシュの精度によって決まる。これにより、単一の索引でクエリを実行することができるように改善されるので、データベースは、複数の索引のクエリよりもはるかに簡単又は高速である。ジオハッシュによる索引構造は、最も近いポイントが最も近いジオハッシュの中にあることが多いため、効率化された近接検索にも有用である。
【0064】
少なくとも一実施形態において、ストリーム処理サーバシステム２００は、ブロック２０６において、位置参照を行う。上記のように、一実施形態では、システムは、ジオハッシュを符号化して、定義された地理的領域、例えば、国、州、又は郵便番号を識別するように構成することができる。システムは、緯度／経度を、辺が文字列の文字に比例する矩形にジオハッシュすることができる。
【0065】
例えば、一実施形態では、ジオハッシュは、５文字までにジオハッシュを符号化するように構成することができ、システムは、５文字のジオハッシュされた位置に対して州を識別するように構成することができる。例えば、５つのスライス又は文字までの精度に符号化されたジオハッシュは、＋／－２．５ｋｍの精度を有し、州を識別するのに十分である。６文字までのジオハッシュは、＋／－０．６１ｋｍの精度を有するため、ジオハッシュされた位置に対して郵便番号を識別するために使用することができる。国を識別するために、４文字のジオハッシュを使用することができる。一実施形態では、システム１０は、ジオハッシュを符号化して、ジオハッシュされた位置に車両を一意に識別するように構成することができる。一実施形態では、システム１０は、ジオハッシュを９文字に符号化して、車両を一意に識別するように構成することができる。
【0066】
一実施形態において、システム１０は、ジオハッシュされたイベントデータを地図データベースに写像するようにさらに構成することができる。地図データベースは、例えば、公共若しくは私有の地図データベースを含む、関心のあるデータベース、又は他の地図データベースであり得る。例示的な地図データベースは、ローカルストリート地図用ジオファブリックなどの現存するストリート地図データ、又は世界地図データベースを含み得る。本明細書に記載のジオハッシュを使用する典型的な利点は、下流で処理するときに、車両イベントデータのはるかに高速で低遅延な拡張が可能になることである。例えば、地理的定義、地図データ、及びその他の拡張は、ジオハッシュされた位置及び車両ＩＤに簡単に写像される。また、供給データを集約されたデータセットに結合し、インタフェースを用いて可視化することもできる。例えば、ＧＩＳ可視化ツール（例えば、Ｍａｐｂｏｘ（登録商標）、ＣＡＲＴＯ（登録商標）、ＡｒｃＧＩＳ（登録商標）、若しくはＧｏｏｇｌｅ（登録商標） Ｍａｐｓ ＡＰＩ）インタフェース、又は他のインタフェースを利用して、例えば、出力サーバシステム４００若しくはポータルサーバシステム６００を介して処理されたデータを使用して分析的洞察を生成するサードパーティ１５に、グラフィックレポートを作成してインタフェースするか、若しくはレポートを出力することができる。
【0067】
少なくとも一実施形態において、ブロック２０８において、ストリーム処理サーバシステム２００は、例えば、イベントデータ内の車両データの車両識別番号（ＶＩＮ）から個人識別情報を削除又は不明瞭化するなどにより、識別情報を削除してデータを匿名化するように構成することができる。様々な実施形態では、イベントデータ又は他のデータは、ＶＩＮ番号を含むことができ、ＶＩＮ番号には、メーカー、モデル、年式等の車両の製品情報を表す数値が含まれ、また、車両を一意に識別する文字を含み、所有者にそれを個人的に識別させるために使用することもできる。システム１０は、例えば、車両データから車両を一意に識別する文字を削除するけれども他の識別シリアル番号（例えば、メーカー、モデル、年式）を残すアルゴリズム、例えば、スキッシュＶｉｎアルゴリズムを含むことができる。一実施形態では、システム１０は、匿名化されたデータに一意の車両タグを追加するように構成することができる。例えば、システム１０は、ＶＩＮに関連する個人識別情報が削除された後、一意の車両のイベントデータを追跡、処理、かつ分析することができるように、一意の番号、文字、又は他の識別情報を匿名化されたデータに追加するように構成することができる。匿名化されたデータの典型的な利点は、匿名化されたデータにより、処理されたイベントデータを外部に提供しながら、例えば、法的に必要とされる場合やユーザが望む場合に、データから個人識別情報を保護できることである。
【0068】
少なくとも一実施形態において、本明細書に記載するように、９文字のジオハッシュは、また、ＶＩＮのデータなどの個人識別情報を取得する、又は必要とすることなく、車両の一意の識別を提供することができる。車両は、データベースイベントデータの処理を介して識別し、且つ、一意の車両を識別する十分な精度である、例えば、９文字にジオハッシュすることができる。そして、車両を識別し、追跡し、そして本明細書に記載するように、それらのデータを処理することができる。
【0069】
上記のように、リアルタイムストリーミングのために、ブロック２０２において、データ検証は、例えば、７秒を超える超過遅延を有するデータを除外する。しかし、バッチデータ処理は、隙間のない完全セットのデータで実行できるため、遅延のためフィルタされないデータを含むことができる。例えば、図５に関して説明したような分析のためのバッチデータ処理は、６週間までの古いデータを受け入れるように構成することができる。それに対して、ストリーム処理サーバシステム２００のストリーミングスタックは、７秒以上古いデータをフィルタするように構成することができ、したがって、ブロック２０２の遅延検証検査を含み、且つ、より大きな遅延を有するイベントを受け入れない。
【0070】
ブロック２０９において、少なくとも一実施形態では、ストリーム処理サーバシステム２００は、行程セグメンテーション分析を行う。一実施形態では、ストリーム処理サーバシステム２００は、所与の車両の経路又は移動が行程の目的地に運転することを目的とするかどうかの識別を含む、イベントデータから車両の行程を識別するように構成されている。行程を識別することには、車両のエンジンオン又は最初の動作を識別すること、車両のエンジンオフ又は停止動作を識別すること、車両の滞留時間を識別すること、最小走行時間を識別することが含まれる。行程セグメンテーション処理２０９は、装置匿名化２０８後に開始するように示されているものの、行程セグメンテーション処理は、データ入力２０１後の任意の時点で開始することができる。
【0071】
少なくとも一実施形態では、行程は、出発点から最終目的地への一つ又は複数の行程セグメントを含むことができる。行程セグメントは、車両のエンジンオン／開始動作とエンジンオフ／停止動作イベントとの間の距離及び移動時間を含む。
【0072】
しかし、実際の運転者は、目的地まで走行する際に一つ又は複数の停止をする可能性がある。行程には、複数の停車地がある走行の場合など、二つ以上の行程セグメントを含めることができる。例えば、運転者は、自宅から職場に移動するとき、又は信号で停止するときに、燃料のために停止する必要があるかも知れない。したがって、車両イベント分析における問題及び課題には、本明細書に記載の実施形態についての正確な車両追跡を開発することが含まれる。例えば、識別された車両の既知の目的地から行程をリバースエンジニアリングするなどの他の行程アルゴリズム又は処理が当技術分野で採用されているが、本開示は、本明細書に説明する技術を使用する、不可知論者の車両追跡のために開発され、且つ有利に実装された実施形態及びアルゴリズムを含み、これらには、データ分析、データベース、インタフェース、データ処理、及び他の技術製品が含まれる。
【0073】
ブロック２１０において、ストリーム処理サーバシステム２００は、イベント情報から行程を修正するための計算を実行するように構成されている。一実施形態では、ストリーム処理サーバシステム２００は、走行時間基準、距離基準、及び滞留時間基準を含む行程検出基準で構成されている。少なくとも一実施形態では、走行時間基準は、最小走行時間基準を含み、システムが行程セグメントを行程に含めるために最小走行持続時間が必要とされる。エンジンオン又は開始動作後の最小走行持続時間は、例えば、約６０秒から約９０秒の走行持続時間を含むことができる。例示的な実施形態では、ストリーム処理サーバシステム２００は、行程セグメントとして含まれるために６０秒を超える車両走行を必要とするように構成することができる。例えば、（１）エンジンオン／イグニッションイベント、（２）既知の最後の動作（例えば、前の走行又は行程から）後の識別車両の最初の動作、又は（３）新しい識別車両の最初の動作、が車両について識別されている場合に、ストリーム処理サーバシステム２００は、イベント後の走行時間が６０秒未満と短いどうかを決定するように構成することができ、そうであれば、この行程セグメントを行程決定から除外するように構成することができる。ストリーム処理サーバシステム２００は、短い走行時間の車両移動は、行程開始又は行先でないと判断するように構成されている。
【0074】
一実施形態では、行程検出基準は、例えば、２００メートルの走行距離基準を含むことができる。ストリーム処理サーバシステム２００は、行程セグメントから２００メートル以下の距離を排除するように構成することができる。最小走行距離基準は、例えば、約１００メートルから約３００メートルまでの、所定の走行距離の持続を含むことができる。最小距離ｘ（例えば、２００メートル）は、最小距離ｘの約５０％の許容誤差を含む索引に定義することができる。
【0075】
一実施形態において、滞留時間基準は、車両の停止時間を含むことができる。例えば、滞留時間の基準は、約３０秒から約９０秒にすることができる。最大滞留時間は、同じ車両のエンジンオフ／停止動作とエンジンオン／始動動作との間の停止時間、例えば、約２０秒から約１２０秒を含むことができる。例えば、ストリーム処理サーバシステム２００は、車両が停止している、又はそのエンジンが３０秒未満停止していると判断する場合、その停止期間を行程の終了又は行程オブジェクト内に含めないように構成することができる。
【0076】
上記のように、一実施形態では、ストリーム処理サーバシステム２００は、車両イベントデータを処理して、一つ又は複数の行程セグメントが車両の行程を構成するかどうかを決定するように構成されている。例えば、エンジンオン又は開始動作のイベント後に、距離基準（例えば、２００メートル超）を超える距離が続くことがある。したがって、システムの走行基準は、行程のこのセグメントを識別する。しかし、車両がその後停止し、エンジンオフのイベントを有し、３０秒以上の静止を続けると、ストリーム処理サーバシステム２００は、それをセグメントとして算入しないように構成することができる。車両がエンジンオフイベントを伴い停止し、３０秒未満静止したままで、その後、エンジンオンイベントを伴い再び移動する場合、滞留時間基準を満たし、ストリーム処理サーバシステム２００は、車両が最終目的地まで走行するための行程内にその行程セグメントを含むように構成されている。一実施形態では、滞留時間基準は、イグニッションオフ後オンするイベントの間に適用するように構成されている。
【0077】
一実施形態では、システムは、所与の車両についての追加データポイントが無い場合を除き、同一行程の部分としてイグニッションイベントが無くても滞在時間を識別するように構成されている。例えば、緯度／経度の変化を伴わない車両イベントデータは、同一行程の部分として識別される。イグニッションイベントを伴わない車両イベントデータの一時停止は、行程が終了したと想定される十分な時間が経過する場合を除き、同一行程の部分として扱われる。イグニッションオフのイベントは、システムによりイグニッションオフが頻繁に発生すると決定し、行程を単一の行程に縫合する追加論理が必要であると決定される場合を除き、行程の終了として識別される。
【0078】
このように、アルゴリズムは、例えば、運転者が自宅で車両に乗り（エンジンオン／開始動作）、１０マイル運転し（走行距離基準）、２９秒間信号で停止し、最終目的地である勤務地に走行する（エンジンオフ／停止動作）ときなど、毎日の目的地へのリアルタイムな運転について、複数の行程セグメントを一行程、又は一行程オブジェクトに結合する。しかし、ストリーム処理サーバシステム２００は、例えば、信号で２９秒間停止すること（滞留時間基準）、又は２００メートル未満（走行距離基準）若しくは６０秒未満（走行時間基準）の移動であることなど、行程の中断を表す可能性が低いイベントを無視するように構成されている。
【0079】
一実施形態では、ストリーム処理サーバシステム２００は、例えば、様々なデータに基づいて、滞留時間基準、走行距離基準、又は走行時間基準のそれぞれについて、複数の基準を含むことができる。したがって、アルゴリズムは、車両及び位置に関する付加的なデータが既知である目的地への一般的なリアルタイム運転の一行程に、複数の行程セグメントを結合することができる。例えば、車両が電気自動車などの道路法定電気自動車として識別される場合、滞留時間基準には、充電ステーションとして識別される場所での最大滞留時間基準２０分を含めることができる。したがって、滞留時間は、例えば、位置に関する他のデータ（例えば、停車地がガソリンスタンド、休憩所、又はレストランなどの関心のある地点であることを示すデータ）に基づいて、２から２０分まで延長することができる。ストリーム処理サーバシステム２００は、電気自動車の運転者が自宅で車両に乗り（エンジンオン又は最初の動作）、充電ステーションまで１００マイル（走行距離基準）運転して充電し（エンジンオフ／停止動作、１２分、滞留時間基準、可変、充電ステーション）、再始動（エンジンオン／開始動作）し、営業会議のある最終目的地まで走行する（エンジンオフ／停止動作）一行程を識別するように構成することができる。別の例では、燃料レベルなどの拡張データが入力ソースによって提供される場合、燃料消費量を基準として使用することができる。例えば、燃料レベルの変化が小さい停止（－００２）は、無視することができる滞留時間基準を識別するために使用することができるであろう。（例えば、６０秒未満の停止は、燃料レベルの小さな低下を伴うのみである）。したがって、理解されるように、上記基準のそれぞれは、とりわけ、イベント車両データポイントについて導出又は取得された知識に応じて可変であるように構成することができる。
【0080】
一実施形態では、ブロック２１１において、ストリーム処理サーバシステム２００は、行程セグメントを行程オブジェクトに集めるよう構成されている。ストリーム処理サーバシステム２００は、上記の基準に従って、所与の装置の行程セグメントの候補チェーンを識別するように構成されている。また、複合行程オブジェクトは、開始がチェーンの始まりであり、終わりがチェーンの最後のセグメントの終わりであるようにインスタンス化することができる。行程オブジェクトの個別テーブルをイベントデータから抽出し、導出される複合行程から追加テーブルを生成することができる。一実施形態では、すべてのエンジンオン／エンジンオフ又は開始動作／停止動作イベントを含む一データセットは、一意の車両ＩＤ又は装置ＩＤに対して識別されている。例えば、車両のエンジンオン／エンジンオフ又は開始動作／停止動作イベントのそれぞれを、候補の行程セグメントを含む単一の行に配置することができる。次に、エンジンオン／エンジンオフ又は開始動作／停止動作イベントの行を、走行距離基準、走行時間基準、及び滞留時間基準のそれぞれで処理して、行程オブジェクトの行程決定に含まれ又はそれから除外され得る行程セグメントを決定する。一実施形態では、ストリーム処理サーバシステム２００は、上記行程基準を満たす車両イベントから決定される行程オブジェクトが入力される追加の行程テーブルを生成することができる。
【0081】
一実施形態では、ブロック２１２において、遅延についてフィルタされた変換位置データと除外された遅延データとの両方が、例えば、アパッチカフカキューのサーバ・キューに入力される。ブロック２１４で、ストリーム処理サーバシステム２００は、データを、完全なデータを含むデータセット（遅延についてフィルタされた変換位置データと除外された遅延データ）２１６と、変換位置データである別のデータセット２２２とに分割する。完全なデータ２１６は、分析サーバシステム５００に対するアクセス又は配信のためにデータストア１０７に格納される一方、フィルタされた変換位置データは、出力サーバシステム４００に配信される。別の実施形態では、完全なデータセット又は除外されたデータを含むその一部をサードパーティ自身による使用及び分析のために、サードパーティプラットフォーム用出力サーバシステム４００に配信することもできる。そのような実施形態では、ブロック２１２で、遅延についてフィルタされた変換位置データと除外された遅延データとを出力サーバシステム４００に直接提供することができる。
【0082】
少なくとも一実施形態において、ストリーム処理サーバ２００は、イベントデータ及び行程決定データをデータウェアハウス１０７内に格納するように構成することができる。データは、データベースフォーマットで格納することができる。一実施形態では、処理されたデータに時間列を追加することができる。別の実施形態では、分析サーバ５００は、ストリーム処理サーバとは独立して行程決定を行うように構成することができるので、ストリーム処理サーバ２００による行程決定は、出力サーバ４００に出力後ストリーム処理サーバから削除することができる。
【0083】
図４は、出力サーバシステム４００の論理アーキテクチャである。少なくとも一実施形態では、出力サーバシステム４００は、レコードを取り込み、スループットし、且つ、イベントデータを出力するように配置されている一つ又は複数のコンピュータとすることができる。出力サーバシステム４００は、プッシュ又はプルベースでデータを提供するように構成することができる。例えば、一実施形態では、システム１０は、アパッチスパーククラスタからのプッシュサーバ４１０を使用するように構成することができる。プッシュサーバは、ストリーム処理サーバシステム２００からの変換位置データを、例えば、遅延フィルタ４１１、ジオフィルタ４１２、イベントフィルタ４１３、変換４１４、送信４１５のために処理することができる。本明細書に記載するように、ジオハッシュは、システム１０のスループット遅延を大幅に改善する。これにより、イベントのすぐ近くで、例えば、数分から数秒以内に処理されたデータに対するタイムリーなプッシュ通知の利点がある。例えば、一実施形態では、システム１０は、６０秒未満の遅延を目標とするように構成されている。上記のように、ストリーム処理サーバシステム２００は、７秒未満の遅延でイベントをフィルタするように構成されていることも、スループットを改善している。一実施形態では、プルデータ用のデータストア４０６を、ＡＰＩゲートウェイ４０４を介して提供することができ、プルＡＰＩ４０５は、サードパーティ１５のどのユーザがデータをプルしているか、且つ、何のデータをユーザが求めているかを追跡することができる。
【0084】
例えば、一実施形態では、出力サーバシステム４００は、システム１０によって提供されるフィルタに基づいてパターンデータを提供することができる。例えば、システムは、所与の場所又は複数の場所のイベントデータをフィルタするためのジオフェンスフィルタ４１２を提供するように構成することができる。理解されるように、ジオフェンスは、多数のパターン及び構成について本明細書で説明するように、行程及びイベントデータの境界付けをし、且つ処理するように構成することができる。例えば、一実施形態では、出力サーバシステム４００は、ユーザにより提供又は選択された経度／緯度内の行程開始及び終了（イグニッション－キーオン／オフイベント）にデータを制限するように構成されている「駐車」フィルタを提供するように構成することができる。このデータに対する追加フィルタ又は除外は、例えば、州（州コード又は緯度／経度）によって構成することができる。システム１０は、また、交通パターンデータを提供する「交通」フィルタを構成することもでき、例えば、フィルタから所与の州及び緯度／経度の境界ボックスを除外することができる。
【0085】
図５は、データ分析及び洞察のための分析サーバシステム５００の論理アーキテクチャを表す。少なくとも一実施形態では、分析サーバシステム５００は、イベントデータを分析するように配置されている一つ又は複数のコンピュータとすることができる。リアルタイムデータとバッチデータとの両方をここで説明する他のコンポーネントから分析サーバシステム５００に渡して処理することができる。一実施形態では、バッチ及びストリーミングデータ処理を組み合わせるアパッチスパーククラスタのようなクラスタコンピューティングフレームワーク及びバッチプロセッサを分析サーバ５００によって使用することができる。分析サーバ５００に提供されるデータには、例えば、入力サーバシステム１００、ストリーム処理サーバシステム２００、及び出力サーバシステム４００からのデータを含めることができる。
【0086】
一実施形態では、分析サーバシステム５００は、データストア１０７のようなデータストアに格納され得る、車両イベントデータ及び処理された情報を受け入れるように構成することができる。図５に示すように、該格納は、出力サーバシステム４００からリアルタイムに出力されるデータ、ストリーム処理サーバシステム２００からの変換位置データ及び除外データ、及び入力サーバシステム１００からのバッチ及びリアルタイムの生データを含むことができる。図２に示すように、データストア１０７に格納された入力位置は、分析サーバシステム５００に出力又はプルされることができる。分析サーバシステム５００は、図２に示すように、ストリーム処理サーバシステム２００と同じ方法で入力位置データを処理するように構成することができる。上記のように、ストリーム処理サーバシステム２００は、完全なデータ（遅延についてフィルタされた変換位置データと除外された遅延データ）を含む完全データセット２１６と、変換位置データのデータセット２２２とに分割するように構成することができる。完全データセット２１６は、分析サーバシステム５００にアクセス又は送信するためにデータストア１０７に格納される一方、フィルタされた変換位置データは、出力サーバシステム４００に送信される。図５に示すように、リアルタイムにフィルタされるデータは、性能５２２、入力対出力５２４、動作監視５２６、及び警告５２８のレポートを含む、ほぼリアルタイムなレポートのために処理することができる。
【0087】
したがって、図５のブロック５０２では、少なくとも一実施形態では、分析処理サーバシステム５００は、必要に応じて、図２のブロック２０２及び図７の７０１から７０５に示すのと同様に、入力位置からの生の位置イベントデータの検証を実行するように構成することができる。一実施形態では、図７のブロック７０６に示すように、システム１０は、レコードのバッチ処理を使用し、多数のイベントレコードに対する属性の詳細な検証を行ってイベントデータポイントの属性間のレコード内関係が有意味であることを確認することができる。例えば、表５に示すように、システム１０は、分析されるデータポイントを分析し、行程イベントの論理順序を確認するように構成することができる（例えば、ある行程に対する行程イベントは、「走行開始－走行終了－走行開始」と交互に変化し、「走行開始－走行開始－走行終了－走行終了」のように繰り返すことはない、など）。
【表5】
【0088】
図５のブロック５０４を参照すると、少なくとも一実施形態では、分析サーバシステム５００は、必要に応じて、図２のブロック２０４に示されるように、位置イベントデータのジオハッシュを実行するように構成することができる。図５のブロック５０６に示すように、分析サーバシステム５００は、必要に応じて、位置参照を実行することができる。図５のブロック５０８では、必要に応じて、分析サーバシステム５００は、図２のブロック２０６及び２０８に示すような装置匿名化を実行するように構成することができる。
【0089】
ブロック５１０では、少なくとも一実施形態では、分析サーバシステム５００は、図２に示すようなイベントデータの行程セグメンテーション解析をするように構成することができる。
【0090】
例示的な実施形態では、システム１０は、車両の事前同定（例えば、ＶＩＮ番号による）を必要とせずに、車両追跡を実行するように構成することもできる。上記のように、ジオハッシュは、イベントデータのデータベースに使用して、データを９文字の精度でジオハッシュすることができる。これは、イベントを車両に一意に関連付けるのに十分な形状に対応する。一実施形態では、能動車両検出は、ある期間にわたる複数のイベントから車両経路を識別することを含む。一実施形態では、能動車両検出は、１日の期間（２４時間）にわたる複数のイベントから車両経路を識別することを含むことができる。識別は、例えば、連結成分アルゴリズムを使用することを含む。一実施形態では、連結成分アルゴリズムを使用して、車両イベントの当該日を含む有向グラフにおける車両経路を識別し、グラフにおいて、ノードは車両であり、ノード間の接続は識別された車両経路である。例えば、行程開始及び終了のグラフが作成され、ノードは開始と終了を表し、辺は車両が取った経路である。それぞれの辺で、開始と終了が時間的にソートされる。辺は、そのノードの終了から次の開始まで時間順に接続するように作成される。ノードは、９桁ジオハッシュのＧＰＳ座標にある。連結成分アルゴリズムは、接続されているノードと辺との組み合わせを検出し、１日の開始時に生成される装置ＩＤが、決定されたサブグラフに沿って渡され、同じ車両によって行われているものとして行程（辺）を一意に識別する。
【0091】
この方法の典型的な利点は、イベントデータに対して車両の事前同定を不要にすることである。本明細書に記載の行程基準を満たす車両経路からの行程セグメントを使用して、上記のように、行程を検出し、不適格な行程イベントを除外することができる。例えば、車両が互いにｘ秒（３０秒）以内に停止動作／エンジンオフして開始動作／エンジンオンするイベントを生じたことを示すイベントデータについての９桁（最高解像度）に符号化されたジオハッシュは、同じ車両と見なすことができる。一連の到着及び出発について、行程は、グラフを通る行程セグメントの最短経路として計算することができる。
【0092】
ブロック５１２において、分析サーバシステム５００は、図２のブロック２１０に示すようなイベント情報から行程を修正する計算を実行するように構成することができる。少なくとも一実施形態では、ブロック５１４で、システム１０は、車両イベントデータのデータベースを分析し、点状の一行程を図２のブロック２１１に記載されている属性を有する一行程オブジェクトに集計することによって、能動車両検出を提供するように構成されている。分析サーバシステムで採用している行程セグメンテーションアルゴリズムの説明については、「行程分析のための車両イベントデータ処理用システム及び方法」と題する米国特許出願第１６／７８７７５５号明細書に記載があり、その全体は本明細書中に援用される。
【0093】
少なくとも一実施形態において、ブロック５１５において、システム１０は、イベントデータ及び行程決定データをデータウェアハウス５１７に格納するように構成することができる。データは、データベース形式で格納することができる。一実施形態では、処理されたデータに時間列を追加することができる。一実施形態では、データベースにはまた、関心のあるポイント（ＰＯＩ）データを含ませることができる。
【0094】
分析サーバシステム５００は、例えば、データウェアハウス５１７に格納されたデータに、例えば、スパーク分析クラスタのようなデータ分析を行う分析サーバコンポーネント５１６を含むことができる。分析サーバシステム５００は、評価５３０、クラスタリング５３１、人口統計分析５３２、及び特注分析５３３を行うように構成することができる。例えば、データウェアハウス５１７に格納され処理された行程データ及び位置データに、日付列及び時間列を追加することができる。これにより、例えば、日付及び時刻によって交差点ｘにある車両の数を決定する、特注分析５３３が使用できる。システム１０はまた、図４に関して説明したように、出力サーバシステム４００で特注分析５３３を提供するように構成することもできる。
【0095】
一実施形態では、データウェアハウス５１７に格納されたデータに地理空間索引列を追加し、例えば、ジオハッシュされたデータについて超局所ターゲティング又はアドホッククエリの高速化を行うことができる。例えば、４桁の数字又は文字による解像度の位置データは、２０メートル以下の解像度に対応できる。
【0096】
分析サーバシステム５００は、診断機械学習５３４を用いて構成して、フィールドが無効なデータのデータベースに関する分析を行い、検証処理のためのフィールドを新たに識別し、且つ、標識化するように構成することができる。
【0097】
一実施形態では、システム１０は、ブロック５１０で説明したように、行程セグメントのバッチ分析を行うように構成することができる。例えば、図７のブロック７０７で、行程セグメンテーション抽出は、一意のＩＤでマークされたすべてのイベントを識別することによる単純な行程抽出を含むことができる。行程セグメンテーション抽出及び数の例を表６に示す。
【表6】
【0098】
システム１０はまた、図７のブロック７０８の行程値フィルタについてブロック５１２で説明したような行程基準を使用してイベント情報から行程を修正する計算を実行するように構成することができる。行程値フィルタの例を表７に示す。
【表7】
【0099】
一実施形態では、バッチデータは、システム性能レポート５３５のために、処理することができる。例えば、一実施形態では、システム１０は、システム遅延のレポートを生成するように構成することができる。取得タイムスタンプデータと受信タイムスタンプデータとの間のパーセンタイル範囲に対するバッチ分析遅延レポートの例を表８に示す。システム１０は、潜在データの間隔分析を実行するように構成することができる。パーセンタイル範囲に対する間隔／取得レートレポートの例を表９に示す。
【表8】
【表9】
【0100】
図６は、ポータルサーバシステム６００の論理アーキテクチャである。少なくとも一実施形態では、ポータルサーバシステム６００は、レコード及びイベントデータを取り込み、スループットするように配置されている一つ又は複数のコンピュータとすることができる。ポータルサーバシステム６００は、ポータルユーザインタフェース６０４及びＡＰＩゲートウェイ６０６を使用して、ポータルＡＰＩ６０８がプラットフォームのサードパーティ１５のユーザからのデータをインタフェースして受け入れるように構成することができる。一実施形態では、ポータルサーバシステム６００は、毎日の静的集約を提供するように構成することができ、分析サーバシステム５００によって提供されるデータにリアルタイムアクセスするための検索エンジン及びアクセスポータルで構成されている。少なくとも一実施形態では、ポータルサーバシステム６００は、例えば、サードパーティ１５のクライアントコンピュータなどのユーザに、ダッシュボードを提供するように構成することができる。少なくとも一実施形態において、分析サーバシステム５００からの情報を、ポータルユーザインタフェース６０４によって提供されるレポートジェネレータに流すことができる。少なくとも一実施形態では、レポートジェネレータは、パフォーマンス情報に基づいて一つ又は複数のレポートを生成するように構成することができる。少なくとも一実施形態では、レポートは、一つ又は複数のレポートテンプレートに基づいて決定し、且つ、フォーマットすることができる。
【0101】
図７は、上記のようなデータ処理のデータパイプラインを示すフローチャートである。図７に示すように、一実施形態では、イベントデータは、データ品質検査の７段階のパイプラインを通過してデータが渡される。さらに、データ処理は、ストリーム処理とバッチ処理との両方を使用して実行される。ストリーミングは、一走行に対して、一度に一レコードに操作し、前のいかなるレコードのコンテキストも保持しないので、属性及びレコードレベルで行う検査のために使用することができる。バッチ処理では、データをより完全に調べることでき、完全な端から端までの処理を網羅することができる。バッチ処理は、ストリーミングと同じ検査に加えて、複数のレコードと行程にわたって実行される検査を実行する。
【0102】
少なくとも一実施形態では、ダッシュボード表示は、システムの他のコンポーネントによって生成された情報の表示をすることができる。少なくとも一実施形態では、ダッシュボード表示は、ネットワークを介してアクセスされるクライアントコンピュータ上に提示することができる。少なくとも一実施形態では、ユーザインタフェースは、請求された主題の精神及び／又は範囲から逸脱することなく使用することができる。このようなユーザインタフェースは、さまざまな方法で配置できる任意の数のユーザインタフェース要素を持つことができる。いくつかの実施形態では、ユーザインタフェースは、ウェブページ、モバイルアプリケーション、ＧＩＳ視覚化ツール、地図作成インタフェース、電子メール、ファイルサーバ、ＰＤＦ文書、テキストメッセージなどを使用して生成することができる。少なくとも一実施形態では、入力サーバシステム１００、ストリーム処理サーバシステム２００、出力サーバシステム４００、分析サーバシステム５００、又はポータルサーバシステム６００は、ユーザインタフェースを生成するための処理及び／又はＡＰＩを含むことができる。
【0103】
本明細書に記載のシステム１０の実施形態のように、処理及びアルゴリズムは、アマゾンウェブサービス（ＡＷＳ）（登録商標）やマイクロソフト（登録商標）アジュール（登録商標）などのウェブサービスプラットフォームホスト上で実行されるように構成することができる。クラウドコンピューティングアーキテクチャは、構成可能なコンピューティング資源（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、及びサービス）の共有プールに、便利な、オンデマンドのネットワークアクセスをするように構成されている。クラウドコンピュータプラットフォームにより、プラットフォームプロバイダは、サービスプロバイダと人間とのインタラクションを必要とすることなく、必要に応じて自動的にサーバ時間及びネットワークストレージなどのコンピューティング能力を一方的に提供できるように構成することができる。さらに、クラウドコンピューティングは、ネットワーク経由で利用可能であり、異種の軽量又は高機能クライアントプラットフォーム（携帯電話、ラップトップ、ＰＤＡなど）による使用を促進する標準メカニズムを介してアクセスされる。クラウドコンピューティングアーキテクチャにおいて、プラットフォームのコンピューティング資源は、複数のコンシューマ、パートナ又は他のサードパーティユーザに、様々な物理及び仮想資源の動的な割り当て及び必要に応じた再割り当てとともにマルチテナントモデルを使用して提供するためにプールすることができる。クラウドコンピューティングアーキテクチャは、また、プラットフォーム資源を迅速かつ柔軟に供給して、場合によっては自動的に、迅速にスケールアウトし、素早く解放して迅速にスケールインできるようにも構成されている。
【0104】
クラウドコンピューティングシステムは、サービスの種類（例えば、記憶装置、処理、帯域幅、及びアクティブなユーザアカウント）に適切な或る抽象化レベルの計量能力を活用することによって資源利用を自動的に制御し、最適化するシステムを用いて構成することができる。資源の使用状況は、監視、制御、及びレポートすることができる。本明細書で記載するように、ある実施形態において、システム１０は、低遅延用に構成されている革新的なアルゴリズム及びデータベース構造を備えるプラットフォームプロバイダによって有利に構成されている。
【0105】
クラウドコンピューティングアーキテクチャは、多数のサービス及びプラットフォーム構成を含んでいる。
【0106】
サービスとしてのソフトウェア（ＳａａＳ）は、プラットフォームプロバイダが、クラウドインフラストラクチャ上で実行するプロバイダアプリケーションを使用できるように構成されている。アプリケーションには、Ｗｅｂブラウザ（Ｗｅｂベースの電子メールなど）などの軽量なクライアントインタフェースを介して、さまざまなクライアント装置からアクセスできる。コンシューマは、通常、限られたユーザ固有のアプリケーション構成設定を除いて、ネットワーク、サーバ、オペレーティングシステム、記憶装置、さらには個々のアプリケーション機能を含む、基盤となるクラウドインフラストラクチャを管理又は制御しない。
【0107】
サービスとしてのプラットフォーム（ＰａａＳ）は、プラットフォームプロバイダが、クラウドインフラストラクチャ上に、プロバイダがサポートしているプログラミング言語及びツールを使用して作成される、コンシューマによって作成又は取得されたアプリケーションを展開できるように構成されている。コンシューマは、ネットワーク、サーバ、オペレーティングシステム、記憶装置などの基盤となるクラウドインフラストラクチャを管理又は制御しないが、展開されたアプリケーションと、場合によってはアプリケーションホスティング環境構成とを制御できる。
【0108】
サービスとしてのインフラストラクチャ（ＩａａＳ）は、プラットフォームプロバイダが、処理、記憶装置、ネットワーク、並びに、コンシューマがオペレーティングシステム及びアプリケーションを含む任意のソフトウェアを展開し且つ実行できる、他の基本的なコンピューティング資源を提供することができるように構成されている。コンシューマは、基盤となるクラウドインフラストラクチャを管理又は制御しないが、オペレーティングシステム、記憶装置、展開されるアプリケーションを制御し、場合によってはネットワークコンポーネント（ホストファイアウォールなど）選択の制御を制限する。
【0109】
クラウドコンピューティングアーキテクチャは、プライベートクラウドコンピューティングアーキテクチャ、コミュニティクラウドコンピューティングアーキテクチャ、又はパブリッククラウドコンピューティングアーキテクチャとして提供することができる。クラウドコンピューティングアーキテクチャは、複合クラウドコンピューティングアーキテクチャとして構成することもでき、二つ又はそれ以上のクラウドプラットフォーム（プライベート、コミュニティ、パブリック）を独自エンティティのまま含み、データ及びアプリケーションの移植を可能とする標準化や独自技術で結合されている（例えば、クラウド間の負荷分散のためのクラウドバースト）。
【0110】
クラウドコンピューティング環境は、無国籍の、低結合な、モジュール性の、且つセマンティックな相互運用性を中心に指向するサービスである。クラウドコンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。
【0111】
図８を参照して、例示的なクラウドコンピューティング環境５０を示す。図示されるように、クラウドコンピューティング環境５０は、パーソナルデジタルアシスタント（ＰＤＡ）又は携帯電話２３、デスクトップコンピュータ２１、ラップトップコンピュータ２２などのローカルコンピューティング装置と一緒にクラウドコンシューマによって使用される一つ又は複数のクラスタコンピューティングノード３０と、例えば、ＯＥＭ車両センサデータソース１４、アプリケーションデータソース１６、テレマティクスデータソース２０、無線インフラストラクチャデータソース１７、及びサードパーティデータソース１５及び／又は車両データソース１２のような自動車コンピュータシステムなどのイベントと、を含む。ノード３０は互いに通信することができる。それらは、本明細書に記載するように、プライベート、コミュニティ、パブリック、若しくは複合クラウド、又はそれらの組み合わせのような一つ又は複数のネットワークに、物理的又は仮想的にグループ化（図示せず）することができる。クラウドコンピューティング環境５０は、クラウドコンシューマがローカルコンピューティング装置上の資源を維持する必要がない、サービスとしてのインフラストラクチャ、プラットフォーム、及び／又はソフトウェアを提供することができる。図９に示すコンピューティング装置の種類は、例示することのみが意図され、且つ、コンピューティングノード３０及びクラウドコンピューティング環境５０は、任意の種類のネットワーク及び／又はネットワークアドレス可能な接続を介して（例えば、ウェブブラウザを使用して）任意の種類のコンピュータ化された装置と通信できることが理解されよう。
【0112】
図９を参照して、クラウドコンピューティング環境５０（図８）によって提供される機能的抽象化層の一式を示す。図９に示すコンポーネント、層、及び機能は例示であり、本明細書に記載の実施形態はそれらに限定されない。図示のように、以下の層及び対応する機能が提供されている。
【0113】
ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェアコンポーネントを含むことができる。ハードウェアコンポーネントの例には、メインフレーム６１、サーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、並びにネットワーク及びネットワークコンポーネント６６が含まれる。いくつかの実施形態では、ソフトウェアコンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７とデータベースソフト６８とが含まれる。
【0114】
仮想化層７０は、仮想エンティティの以下の例を提供する抽象化層を提供する。すなわち、仮想サーバ７１、仮想記憶７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーション及びオペレーティングシステム７４、並びに仮想クライアント７５である。
【0115】
一例では、管理層８０は、以下に説明する機能を提供することができる。資源供給８１は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティング資源及び他の資源の動的な調達を提供する。計量及び価格決定８２は、資源がクラウドコンピューティング環境内で利用されるときの費用追跡、及びこれらの資源の消費に対する請求又は請求書を提供する。一例では、これらの資源は、アプリケーションソフトウェアライセンスを含むことができる。セキュリティは、クラウドコンシューマ及びタスクのＩＤ検証、並びにデータ及び他の資源の保護を提供する。ユーザポータル８３は、コンシューマ及びシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、クラウドコンピューティング資源割り当て及び管理を提供し、要求サービスレベルが満たされるようにする。サービスレベルアグリーメント（ＳＬＡ）の計画及び履行８５は、ＳＬＡに従って将来の要求が予想されるクラウドコンピューティング資源の事前準備と調達とを提供する。
【0116】
ワークロード層９０は、クラウドコンピューティング環境を利用することができる機能の例を提供する。この層から提供できるワークロード及び機能の例には、地図作成とナビゲーション９１、入力処理９２、ストリーム処理９３、ポータルダッシュボード配信９４－同数、データ解析処理９５、及び出力とデータ配信９６が含まれる。
【0117】
本開示では、クラウドコンピューティングプラットフォーム上で実施形態を説明したが、本明細書に記載の実施形態の実装は、クラウドコンピューティング環境に限定されるものではない。
【0118】
図１から９に関連して説明したシステム１０、５０、１００、２００、４００、５００、６００及び７００について記載した実施形態は、単一のネットワークコンピュータによって実装及び／又は実行することができる。他の実施形態では、これらの処理又はこれらの処理の一部は、複数のネットワークコンピュータによって実装及び／又は実行することができる。同様に、少なくとも一実施形態において、システム１０、５０、１００、２００、４００、５００、６００について記載した処理又はその一部は、ネットワークコンピュータの一つ以上の様々な組合せ、クライアントコンピュータ、仮想マシン上で動作することができ、同様のものを利用することができる。さらに、少なくとも一実施形態では、図１から９に関連して記載した処理は、図１から９に関連しても説明したような論理アーキテクチャを備えたシステムで動作することができる。
【0119】
フローチャート図の各ブロック、及びフローチャート図のブロックの組み合わせは、コンピュータプログラム命令によって実装することができることは理解されよう。コンピュータプログラム命令は、プロセッサに供給され、該命令はプロセッサ上で実行され、フローチャートのブロック又は複数のブロックで指定される動作を実現する手段を作成するような機械を生成することができる。コンピュータプログラム命令は、プロセッサに一連の操作ステップを実行させ、プロセッサ上で実行されてフローチャートのブロック又は複数のブロックで指定される動作を実現するステップを提供する命令のように、コンピュータ実装処理を生成させることができる。コンピュータプログラム命令は、フローチャートのブロックに示される操作ステップの少なくともいくつかを並行して実行させることができる。さらに、いくつかのステップは、マルチプロセッサコンピュータシステム又は複数のコンピュータシステムのグループにおいてさえ生じる可能性があるように、一つ以上のプロセッサにわたって実行することもできる。さらに、フローチャート図の一つ若しくは複数のブロック又はブロックの組み合わせは、本開示の範囲又は精神から逸脱することなく、他のブロック若しくはブロックの組み合わせと同時に、又は、図示とは異なる順序でさえも実行することができる。
【0120】
したがって、フローチャート図のブロックは、指定された動作を実行するための組み合わせ、指定された動作を実行するためのステップと指定された動作を実行するためのプログラム命令手段との組み合わせをサポートする。フローチャート図の各ブロック、及びフローチャート図のブロックの組み合わせは、指定された動作又はステップを実行する専用ハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実装することができることも理解されよう。前述の例は、限定的及び／又は網羅的であると解釈されるべきではなく、むしろ、様々な実施形態のうちの少なくとも一実装を示すための例示的な使用例であると解釈されるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【外国語明細書】