JP2022549453A - 行程分析のために車両イベントデータを処理するためのシステムおよび方法 - Google Patents

Abstract

実施形態は、ロケーションイベントデータを取り込みイベントデータから車両の行程を特定し関心イベント分析を実行するための、システムおよび方法に向けられている。次に、関心イベント分析を、コネクテッド車両行程から導き出されるインサイトおよび正確なマッピングのために、可視化インターフェイスに提供する。

Description

開示の背景
自動車産業はこれまでに見たことのない激変の最中にある。混乱がモビリティエコシステム全体に生じている。結果として、車両は、一層自動化、接続、電化、および共有されるようになった。そのため、自動車から発生するデータは爆発的に増加している。この豊富な新たなデータ資産はほとんどが未活用のままである。

ＧＰＳデータ等の車両ロケーションイベントデータは、極めて膨大なものであり、毎秒２００，０００～６００，０００のレコードを含み得る。実質的にリアルタイムのデータ分析を提供する従来のシステムにとって、とりわけ個々の車両についてロケーションイベントデータを処理することが課題となっている。さらに、個々の車両データについての課題は、個々の車両データを匿名化しつつ分析のためにこれらのスケールで特定することである。大量のデータを遅延を少なくして処理および保存しつつもこの大量のデータを分析および再処理のために利用できるようにするように構成された、システムプラットフォームならびにデータ処理アルゴリズムおよびプロセスが必要である。

車両を追跡するためのシステムは存在するが、必要なのは、大量の車両データからの、リアルタイムに近い正確な行程データである。車両の移動およびルートの分析から行程および行程の目的地を正確に特定するように構成されたシステムとアルゴリズムが必要である。

開示の概要
以下、本明細書に記載のイノベーションのいくつかの側面の基本的理解が得られるよう、実施形態を簡単に説明する。この簡単な説明は、広範囲にわたる概要を意図しているのではない。重要または不可欠な要素を特定することを意図している訳でも、範囲を明確にするかそうでなければ狭くすることを意図している訳でもない。その目的は、後に示すより詳細な説明の前置きとしていくつかの概念を簡単な形で示すことにすぎない。

簡単に説明すると、車両イベントデータを処理するためのシステム、方法、およびコンピュータプログラムプロダクトの各種実施形態が本明細書に開示される。

少なくとも１つの実施形態は、プログラム命令を含むメモリと、以下の方法のための上記命令を実行するように構成されたプロセッサとを備えるシステムであり、この方法は、ロケーションイベントデータを取り込むステップと、このイベントデータから車両の行程を特定するステップとを含み、上記行程を特定するステップは、所与の車両の移動が上記行程の行程セグメントであるか否かを特定することを含む。

ある実施形態において、システムプロセッサは、以下の方法のための命令を実行するように構成され、この方法は、車両についてのロケーションイベントデータをストリーム処理サーバまたは分析プロセッササーバに取り込むステップを含み、ロケーションイベントデータは車両についての時間および位置（緯度／経度）を含み、上記方法はさらに、ストリーム処理サーバまたは分析プロセッササーバのいずれかにおいて、ロケーションイベントデータから複数の車両行程を特定するステップと、ある期間にわたるジオフェンスされた領域についてのロケーションイベントデータに対して関心イベントアルゴリズムを実行するステップとを含み、関心イベントは、急ブレーキイベント、急減速イベント、急加速イベント、およびスピード違反イベントからなる群より選択され、上記方法はさらに、関心イベントアルゴリズムからの関心イベント出力を可視化するように構成されたマッピング可視化インターフェイスにフィードを提供するステップを含む。急ブレーキまたは急減速は、予め定められた時間内の減速であると定義されてもよい。急加速は、別の予め定められた時間内の加速であると定義される。

ある実施形態において、プロセッサは、イベントデータにおけるロケーションデータを近接度に符号化することをさらに含む上記方法のための命令を実行するように構成されている。

ある実施形態において、上記イベントデータにおけるロケーションデータを近接度に符号化することはさらに、緯度および経度を、近接度を定める形状にジオハッシュすること、ジオハッシュを符号化して州を特定すること、ジオハッシュを符号化してジップコードを特定すること、およびジオハッシュを精度に符号化して車両を一意に特定すること、のうちの少なくとも１つを含み得る。

ある実施形態において、上記イベントデータにおけるロケーションデータを近接度に符号化することはさらに、ジオハッシュを５文字に符号化して州を特定すること、ジオハッシュを６文字に符号化してジップコードを特定すること、およびジオハッシュを９文字に符号化して車両を一意に特定すること、のうちの少なくとも１つを含み得る。ある実施形態において、イベントデータにおけるロケーションデータを近接度を定める形状に符号化することは、緯度および経度を、そのエッジがストリング内の文字に比例する多角形または矩形に、ジオハッシュすることを含む。

ある実施形態において、イベントデータにおけるロケーションデータを近接度に符号化することは、ジオハッシュを４～９文字に符号化することをさらに含む。

ある実施形態において、プロセッサは、ジオハッシュをマップデータベースにマッピングすることをさらに含む上記方法のための命令を実行するように構成されている。マッピングすることは、ジオハッシュを関心ポイントデータベースにマッピングすることをさらに含み得る。

ある実施形態において、上記行程を特定するステップは、車両のエンジンオンまたは最初の車両移動を特定することと、車両のエンジンオフまたは移動停止を特定することと、車両の滞留時間を特定することと、車両の最短走行距離を特定することと、最短走行継続時間を特定することとを含む。

ある実施形態において、プロセッサは最短走行継続時間基準で構成され、プロセッサは最短走行継続時間基準を用いて車両の最短走行継続時間を特定するための命令を実行するように構成されている。最短走行継続時間基準は、約６０～約９０秒であってもよい。ある実施形態において、最短走行継続時間基準は約６０秒である。

ある実施形態において、プロセッサは最長滞留時間基準で構成され、プロセッサは最長滞留時間基準を用いて車両の最長滞留時間を特定するための命令を実行するように構成されている。最長滞留時間基準は、約２０～約１２０秒であってもよい。ある実施形態において、最長滞留時間基準は約３０秒である。

ある実施形態において、プロセッサは最短走行距離基準で構成され、プロセッサは最短走行距離基準を用いて車両の最短走行距離を特定するための命令を実行するように構成されている。最短走行距離基準は約１００メートル～約３００メートルであってもよい。ある実施形態において、最短走行距離基準は約２００メートルである。

ある実施形態において、上記行程を特定するステップは、行程セグメントがこの行程の一部を形成しないと判断することを含む。

ある実施形態において、上記システムは能動的車両検出を提供するように構成されている。能動的車両検出は、ある期間にわたる複数のイベントから車両経路を特定することを含み得る。ある実施形態において、能動的車両検出は、ある１日の上記期間にわたる複数のイベントから車両経路を特定することを含み、特定することはコネクテッドコンポーネントアルゴリズムを使用することを含み、コネクテッドコンポーネントアルゴリズムは、車両イベントの上記日を含む有向グラフ内で車両経路を特定することを含む。このグラフにおいて、ノードが車両であり、ノード間の接続が特定された車両経路である。

ある実施形態において、上記システムはデータウェアハウスを含み得る。このシステムは、イベントデータおよび行程決定データをデータウェアハウスに格納する。ある実施形態において、少なくとも１つのタイムカラムを格納されたデータに追加してもよい。このタイムカラムは日付（date）カラムおよび時間（hour）カラムを含み得る。

ある実施形態において、上記システムは、上記期間のジオフェンスされた領域における関心イベントのイベントをクラスタリングするためのクラスタリングアルゴリズムを含む。クラスタリングアルゴリズムは、急ブレーキイベント、急減速イベント、急加速、およびスピード違反イベントからなる群より選択された関心イベントをクラスタリングするように構成されている。このシステムは、関心イベントクラスタリングアルゴリズムを含む混雑検出アルゴリズムを含み得る。

ある実施形態において、マッピング可視化インターフェイスは、上記期間におけるジオフェンスされた領域についての異なる関心イベントアルゴリズム出力のオーバーレイをマッピング可視化インターフェイス上に表示するように、構成されてもよい。このシステムは、マッピング可視化インターフェイス上に、上記期間におけるジオフェンスされた領域についての異なる関心イベントクラスタのオーバーレイを表示するように構成されてもよい。このシステムは、マッピング可視化インターフェイス上に、上記期間におけるジオフェンスされた領域についての関心イベントアルゴリズム出力とともに行程のオーバーレイを表示するように構成されてもよい。

少なくとも１つの実施形態は、コンピュータによって実現される方法を説明し、このコンピュータは、プロセッサと、上記のおよび本明細書に記載される方法を実行するための命令を含むプログラムメモリを含むメモリとを備える。

少なくとも１つの実施形態は、プロセッサによって実行されると上記のおよび本明細書に記載される方法を実行するための命令を含むプログラムメモリを含む、コンピュータプログラムプロダクトを説明する。

本明細書で使用される行程は、ある目的地への任意のトリップ、走路、または走行を含み得る。

本明細書に記載のシステムおよび方法の、ある具体例としての利点は、本開示の時点で最大１２００万台の車両について毎秒最大６００，０００のレコードに対し車両イベントデータを取り込み処理することが可能な、最適化された低レイテンシである。

非限定的でありかつ非網羅的な実施形態について図面を参照しながら説明する。図面において、特に明記しない限り、各種図面の同様の参照番号は同様の部分を示す。

一層の理解のために、添付の図面と関連付けて読まれるべき以下の詳細な説明を参照する。

各種実施形態のうちの少なくとも１つを実現することができる環境のシステム図である。 各種実施形態のうちの少なくとも１つに係るクラウドコンピューティングアーキテクチャを示す図である。 各種実施形態のうちの少なくとも１つに係るクラウドコンピューティングプラットフォームの論理アーキテクチャを示す図である。 本開示の各種実施形態のうちの少なくとも１つに係るイングレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るストリーム処理サーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るエグレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係る分析サーバシステムの論理アーキテクチャおよびプロセスのフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るポータルサーバシステムの論理アーキテクチャおよびプロセスのフローチャートを示す図である。 システムのデータ処理チェックのデータ品質パイプラインを示すフローチャートの図である。 システムのデータパイプラインおよびデータ処理を示すフローチャートの図である。 可視化インターフェイスに提供されるアグリゲートされたデータセットと組み合わされるフィードデータを示すフローチャートの図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 ルートを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両のルートおよび行程を可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両のルートおよび行程を可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両のルートおよび行程を可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両のルートおよび行程を可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示する、具体例としてのビデオインターフェイスの一連のスクリーンショットのうちの１つを示す図である。 コネクテッド車両の行程データを可視化したものを表示する、具体例としてのビデオインターフェイスの一連のスクリーンショットのうちの１つを示す図である。 コネクテッド車両の行程データを可視化したものを表示する、具体例としてのビデオインターフェイスの一連のスクリーンショットのうちの１つを示す図である。 コネクテッド車両の行程データを可視化したものを表示する、具体例としてのビデオインターフェイスの一連のスクリーンショットのうちの１つを示す図である。 コネクテッド車両の行程データを可視化したものを表示する、具体例としてのビデオインターフェイスの一連のスクリーンショットのうちの１つを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 ルートを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。 コネクテッド車両の行程データおよび関心イベントを可視化したものを表示するインターフェイスを示す図である。

実施形態の詳細な説明
以下、添付の図面を参照しながら各種実施形態についてより十分に説明するが、これらの図面は、実施形態の一部を形成し、説明のために、本明細書に記載のイノベーションを実施できる特定の実施形態を示す。しかしながら、実施形態は、多数の異なる形態で実施可能であり、本明細書に記載の実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本開示が詳細で完璧となるように、かつ、実施形態の範囲を当業者に十分に伝えるように、提供される。とりわけ、各種実施形態は、方法、システム、媒体、またはデバイスであってもよい。そのため、以下の詳細な説明は限定的な意味で解釈されてはならない。

本明細書および請求項を通して、以下の用語は、文脈が明らかにそれを否定しない限り、本明細書において明示的に関連付けられている意味を持つ。「本明細書において」という用語は、本願に関連付けられた明細書、請求項、および図面のことである。本明細書で使用される「一実施形態において」または「ある実施形態において」という表現は、同一の実施形態または単一の実施形態を指す可能性はあるが、必ずしも異なる実施形態を指す訳ではない。したがって、以下で説明するように、各種実施形態を、本発明の範囲または精神から逸脱することなく、容易に組み合わせることができる。

加えて、本明細書で使用される「または」という用語は、包含的な「または」であり、文脈が明らかにそれを否定しない限り、「および／または」という用語と等価である。「基づいて」という用語は排他的なものではなく、文脈が明らかにそれを否定しない限り、記載されていないその他の要素に基づくことを認める。加えて、本明細書を通して、「ａ」、「ａｎ」および「ｔｈｅ」の意味は、複数を含む。「中に／内（ｉｎ）」の意味は、「中に」および「上に（ｏｎ）」を含む。

図１Ａは、少なくとも１つの実施形態に係るジオロケーションイベント処理および分析のためのシステム１０の論理アーキテクチャである。各種実施形態のうちの少なくとも１つにおいて、イングレスサーバシステム１００は、ストリーム処理サーバシステム２００および分析サーバシステム５００と通信するように配置することができる。ストリーム処理サーバシステム２００は、エグレスサーバシステム４００および分析サーバシステム５００と通信するように配置することができる。

エグレスサーバシステム４００は、データ消費者と通信し、データ出力をデータ消費者に提供するように構成することができる。エグレスサーバシステム４００はまた、ストリーム処理サーバシステム２００と通信するように構成することができる。

分析サーバシステム５００は、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、およびエグレスサーバシステム４００と通信し、これらのシステムからのデータを受け入れるように構成される。分析サーバシステム５００は、ポータルサーバシステム６００と通信し、データをポータルサーバシステム６００に出力するように構成される。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００の各々は、１つ以上のコンピュータまたはサーバとすることができる。少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００のうちの１つ以上を、単一のコンピュータ上で、たとえばネットワークサーバコンピュータ上で、または、複数のコンピュータにまたがって動作するように構成することができる。たとえば、少なくとも１つの実施形態において、システム１０を、アマゾンウェブサービス（登録商標）（ＡＷＳ：Amazon Web Services）またはマイクロソフト（登録商標）アジュール（Microsoft Azure）等のウェブサービスプラットフォームホスト上で実行するように構成することができる。ある具体例としての実施形態において、このシステムは、本明細書に記載のデータ処理を実行するように構成することができるスパークストリーミングサーバを使用するＡＷＳプラットフォーム上に構成される。ある実施形態において、このシステムを、高スループットメッセージングサーバ、たとえばＡｐａｃｈｅ Ｋａｆｋａ（アパッチカフカ）を使用するように構成することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００を、サービスが提供するＡＰＩのまたは他の通信インターフェイスを使用して統合および／または通信するように構成することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００は、ホスティングサーバ上でホストすることができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００を、ワイドアクセスネットワーク（ＷＡＮ：Wide Access Networks）またはローカルアクセスネットワーク（ＬＡＮ：Local Access Networks）を含む１つ以上の直接ネットワーク経路を用い、ネットワークを介して、クライアントコンピュータと直接的または間接的に通信するように構成することができる。

本明細書に記載されている、システム１０、プロセスおよびアルゴリズムの実施形態は、アマゾンウェブサービス（ＡＷＳ）（登録商標）またはマイクロソフトアジュール（登録商標）等のウェブサービスプラットフォームホスト上で実行されるように構成することができる。クラウドコンピューティングアーキテクチャが、設定可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドネットワークアクセスのために構成される。クラウドコンピュータプラットフォームを、プラットフォームプロバイダが、サービスのプロバイダと人間とのやり取りを必要とすることなく、必要に応じて自動的に、サーバ時間およびネットワークストレージ等のコンピューティング機能を単方向にプロビジョニングできるように、構成することができる。さらに、クラウドコンピューティングは、ネットワーク上で利用可能であり、異種の薄いまたは厚いクライアントプラットフォーム（たとえば携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準メカニズムを通じてアクセスされる。クラウドコンピューティングアーキテクチャにおいて、プラットフォームのコンピューティングリソースをプールすることにより、需要に応じて異なる物理および仮想リソースが動的に割り当てられ、再度割り当てられるマルチテナントモデルを使用して、複数の消費者、パートナー、または他の第三者ユーザにサービスすることができる。また、クラウドコンピューティングアーキテクチャは、プラットフォームリソースを迅速かつ弾性的に、場合によっては自動的にプロビジョニングして迅速にスケールアウトし、迅速にリリースして迅速にスケールインするように、構成される。

クラウドコンピューティングシステムを、サービスのタイプ（たとえばストレージ、処理、帯域幅、およびアクティブユーザアカウント）に適した何らかのアブストラクションレベルのメータリング機能を強化することによってリソースの使用を自動的に制御し最適化するシステムで、構成することができる。リソースの使用が、監視、制御、および報告されてもよい。本明細書に記載されるように、実施形態において、システム１０は、低レイテンシのために構成された革新的なアルゴリズムおよびデータベース構造を備えるプラットフォームプロバイダによって有利に構成される。

クラウドコンピューティングアーキテクチャは、いくつかのサービスおよびプラットフォーム構成を含む。

サービスとしてのソフトウェア（ＳａａＳ）は、プラットフォームプロバイダが、クラウドインフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することを可能にするように構成される。アプリケーションは、ウェブブラウザ（たとえばウェブベースの電子メール）等のシンクライアントインターフェイスを介して各種のクライアントデバイスからアクセス可能である。典型的に、消費者は、限定されたユーザ固有のアプリケーション構成設定を場合によっては例外として、ネットワーク、サーバ、オペレーティングシステム、ストレージ、または個々のアプリケーション機能さえ含む基礎となるクラウドインフラストラクチャを、管理または制御しない。

サービスとしてのプラットフォーム（ＰａａＳ）は、プラットフォームプロバイダが、プロバイダがサポートするプログラミング言語およびツールを使用して作成されたクラウドインフラストラクチャ上に、消費者によって作成または取得されたアプリケーションをデプロイすることを可能にするように、構成される。消費者は、ネットワーク、サーバ、オペレーティングシステム、またはストレージを含む基礎となるクラウドインフラストラクチャを管理または制御しないが、デプロイされたアプリケーションおよび場合によってはアプリケーションホスティング環境構成を制御することができる。

サービス（ＩａａＳ）としてのインフラストラクチャは、プラットフォームプロバイダが、処理、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースをプロビジョニングすることを可能にするように構成され、この場合、消費者は、オペレーティングシステムおよびアプリケーションを含み得る任意のソフトウェアをデプロイし実行することが可能である。消費者は、基礎となるクラウドインフラストラクチャを管理または制御しないが、オペレーティングシステム、ストレージ、デプロイされたアプリケーションを制御し、場合によっては選択ネットワーキング構成要素（たとえばホストファイアウォール）に対する制限された制御を行う。

クラウドコンピューティングアーキテクチャは、プライベートクラウドコンピューティングアーキテクチャ、コミュニティクラウドコンピューティングアーキテクチャ、またはパブリッククラウドコンピューティングアーキテクチャとして提供することができる。また、クラウドコンピューティングアーキテクチャを、ハイブリッドクラウドコンピューティングアーキテクチャとして構成することもでき、これは、固有のエンティティのままであるがデータおよびアプリケーション可搬性（たとえばクラウド間の負荷バランスのためのクラウドバースト化）を可能にする標準化されたまたはプロプライエタリ技術によって一緒に結合される、２つ以上のクラウドプラットフォーム（プライベート、コミュニティ、またはパブリック）を含む。

クラウドコンピューティング環境は、ステートレス性、低結合性、モジュール性、およびセマンティック相互運用性に焦点を当てたサービス指向のものである。クラウドコンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

次に図１Ｂを参照すると、説明のためのクラウドコンピューティング環境５０が示されている。図示のように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード３０を含み、たとえば、携帯情報端末（ＰＤＡ）または携帯電話２３、デスクトップコンピュータ２１、ラップトップコンピュータ２２等のクラウド消費者が使用するローカルコンピューティングデバイス、ならびに、ＯＥＭ車両センサデータソース１４、アプリケーションデータソース１６、テレマティクスデータソース２０、ワイヤレスインフラストラクチャデータソース１７、第三者データソース１５等のイベント、および／または車両データソース１２等の自動車コンピュータシステムを備える。ノード３０は相互に通信することができる。これらは、本明細書に記載のプライベート、コミュニティ、パブリック、もしくはハイブリッドクラウド、またはそれらの組み合わせ等の、１つ以上のネットワークにおいて、物理的または仮想的にグループ化することができる（図示せず）。クラウドコンピューティング環境５０は、クラウド消費者がローカルコンピューティングデバイス上でリソースを維持する必要がないサービスとして、インフラストラクチャ、プラットフォーム、および／またはソフトウェアを提供するように構成される。図１Ｂに示されるタイプのコンピューティングデバイスは、専ら例示を意図しており、コンピューティングノード３０およびクラウドコンピューティング環境５０は、任意のタイプのネットワークおよび／またはネットワークアドレス指定可能接続を介して（たとえばウェブブラウザを使用して）任意のタイプのコンピュータ化されたデバイスと通信できることが、理解される。

次に図１Ｃを参照すると、クラウドコンピューティング環境５０（図１Ｂ）が提供する一組の機能的抽象化層が示されている。図１Ｃに示したコンポーネント、層、および機能は例示であって、本明細書に記載の実施形態はこれらに限定されるものではない。図示のように、以下の層および対応する機能が提供される。

ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェアコンポーネントを含み得る。ハードウェアコンポーネントの例は、たとえば、メインフレーム６１、サーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワーキングコンポーネント６６を含む。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含む。

仮想化層７０は抽象化層を提供し、仮想化層から、仮想エンティティの例として、仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、ならびに仮想クライアント７５を、提供することができる。

一例において、管理層８０は、以下で説明する機能を提供することができる。リソースプロビジョニング８１は、クラウドコンピューティング環境内でタスクを実行するために使用されるコンピューティングリソースおよび他のリソースの動的調達を提供する。メータリングおよび価格設定８２は、リソースがクラウドコンピューティング環境内で利用される際にコストトラッキングを提供し、これらのリソースの消費に対する課金および請求を提供する。一例において、これらのリソースはアプリケーションソフトウェアライセンスを含み得る。セキュリティは、クラウド消費者およびタスクのアイデンティティ検証、ならびにデータおよび他のリソースの保護を提供する。ユーザポータル８３は、消費者およびシステム管理者のためにクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、必要なサービスレベルが満たされるようにクラウドコンピューティングリソースの割り当ておよび管理を提供する。サービスレベル合意（ＳＬＡ：Service Level Agreement）計画および履行８５は、ＳＬＡに従って将来の要求が予想されるクラウドコンピューティングリソースの事前配置および調達を提供する。

ワークロード層９０は、クラウドコンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロードおよび機能の例は、マッピングおよびナビゲーション９１、イングレス処理９２、ストリーム処理９３、ポータルダッシュボード配信９４－同一番号、データ分析処理９５、ならびにエグレスおよびデータ配信９６を含む。

本開示はクラウドコンピューティングプラットフォーム上での実施形態を説明するが、本明細書に記載の実施形態の実装は、クラウドコンピューティング環境に限定されない。システム１０のアーキテクチャはある実施形態の少なくとも一部を例示する非限定的な例であることを、当業者は理解するであろう。そのため、より多くのまたは少ない構成要素を、本明細書に記載のイノベーションの範囲から逸脱することなく、異なる方法で採用および／または配置することができる。しかしながら、システム１０は、少なくとも本明細書でクレームされる発明を開示するのに十分である。

図２を参照すると、少なくとも１つの実施形態に従う、データおよびデータスループットを取り込むためのイングレスサーバシステム１００の論理アーキテクチャが示されている。少なくとも１つの実施形態において、１つ以上のイベントソースからのイベントを決定することができる。ある実施形態において、図１Ａに示されるように、イベントソースは、車両センサデータソース１２、ＯＥＭ車両センサデータソース１４、アプリケーションデータソースｌ６、テレマティクスデータソース２０、ワイヤレスインフラストラクチャデータソース１７、および第三者データソース１５などを含み得る。少なくとも１つの実施形態において、決定したイベントは、ストリーム処理サーバシステム２００および分析サーバシステム５００等のシステムの下流コンポーネントが管理することができる、ロケーションデータ、車両センサデータ、さまざまなユーザとの対話、表示操作、印象などに対応し得る。少なくとも１つの実施形態において、イングレスサーバシステム１００は、図１Ａ～図２に示されるイベントソースよりも多いまたは少ないイベントソースをイングレスすることが可能である。

少なくとも１つの実施形態において、１つ以上のイベントソースから受信および／または決定することができるイベントは、１つ以上のデータソースからの、たとえばＧＰＳデバイスからの車両イベントデータ、または、ＯＥＭ車両センサデータソース１４等の第三者データソース１５から提供されるロケーションデータテーブルを含む。車両イベントデータは、データベースフォーマットで、たとえばＪＳＯＮ、ＣＳＶ、およびＸＭＬで取り込むことができる。車両イベントデータは、サービスおよび／またはイングレスサーバシステム１００から提供されるＡＰＩまたは他の通信インターフェイスを介して取り込むことができる。たとえば、イングレスサーバシステム１００はイングレスサーバＡＰＩ１０６と統合されたＡＰＩゲートウェイ１０２インターフェイスを提供することができ、これは、車両イベントソース１４から提供されるデータベースに関連付けることができる各種イベントをイングレスサーバシステム１００が決定できるようにする。ある具体例としてのＡＰＩゲートウェイは、たとえばＡＷＳ ＡＰＩゲートウェイを含み得る。イングレスサーバシステム１００システムのための具体例としてのホスティングプラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＤｏｃｋｅｒを含み得るが、他のプラットフォームおよびネットワークコンピュータ構成も同様に採用することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００は、生データを受け入れるように構成されたサーバ１０４、たとえば、セキュアファイル転送プロトコルサーバ（ＳＦＴＰ：Secure File Transfer Protocol Server）を含み、ＡＰＩまたは他のデータ入力を、車両イベントデータを受け入れるように構成することができる。イングレスサーバシステム１００を、たとえば分析サーバシステム５００によるさらなる分析のために生データをデータストア１０７に格納するように構成することができる。イベントデータは、イグニッションオン、タイムスタンプ（Ｔ１…ＴＮ）、イグニッションオフ、関心イベントデータ、緯度および経度、ならびに車両情報番号（ＶＩＮ：Vehicle Information Number）情報を含み得る。具体例としてのイベントデータは、当技術において周知のソースからの、たとえば車両自体からの（たとえばＧＰＳ、ＡＰＩを介した）、または、第三者データソース１５から提供されたロケーションデータのテーブルからの、車両移動データを含み得る。

ある実施形態において、システムは、車両位置をより高い精度で検出しマッピングするように構成される。道路網に関して有用な総計を収集する、たとえば１日／１週間周期の予想交通量および速度を収集するために、システムを、所与の道路網を通して車両がどのように移動しているかを判断するように構成してもよい。

ある実施形態において、システムを、道路セグメントに対する線分の集合体として与えられたベースマップを含むように構成してもよい。このシステムは、各線分ごとに、この線分の、この線分から最も近い線分に対する関係に関する幾何学的情報を含む。各線分ごとに、予想交通量および速度に関する統計学的情報が、プロセスの最初の繰り返しから生成される。先に示したように、車両移動イベントデータは、経度、緯度、進行方向、速度、および時刻を含む。

ある実施形態において、システムは、道路セグメントに対応する線分の集まりを取り込み、線分の集まりに対するＲツリーインデックスを作成するように構成される。Ｒツリーは、空間アクセス方法に対して使用されるツリーデータ構造である、すなわち、地理座標、矩形または多角形等の多次元情報をインデックスするためのものである。Ｒツリーは、特に道路セグメントを表すために、空間オブジェクトをバウンディングボックス多角形として記憶するように構成される。Ｒツリーは、先ず、データポイントをスナップするために座標の所定距離以内にある道路セグメント候補を発見するために使用される。次に、これらの候補が、進行方向等のイベントデータを考慮する改良されたメトリックを用いてさらに調べられ、すべての既知情報に基づいて、可能性が最も高い道路セグメントを選択する。速度および／または時刻等のイベントデータを用いて道路セグメントを選択することもできる。システムは、たとえば上記Ｒツリーを用いてバウンディングボックス道路セグメント間の距離を予め規定するように構成される。道路セグメントについて予め計算された距離に対し、システムは、最も近い距離に対して最も近くにあるものを選択するように構成されてもよい。特に、システムは、ポイント（緯度／経度）と道路セグメント（線分）との間の距離を特定するように構成される。アイテム距離幹線の実装により、任意の２つのポイントの距離を道路セグメントとして特定してもよい。システムは、緯度／経度データポイントから最も近いポイントの単純なまたはデフォルト選択に基づいて道路セグメントを選ぶように構成されてもよい。上記のように、道路セグメントはバウンディングボックスまたは線分として規定されてもよい。

ある実施形態において、イングレスサーバシステム１００は、イベントデータを処理して車両移動データを導き出す、たとえば、速度、継続時間、および加速度を導き出すように構成される。たとえば、ある実施形態において、ｘ秒（たとえば３秒）ごとにイベントデータベース上でスナップショットが撮影される。次に、緯度／経度データおよび時間データを処理し、車両の位置および時間を使用して、速度および加速度等の車両追跡データを導き出すことができる。

ある実施形態において、イングレスサーバシステム１００は、デバイスおよび第三者プラットフォームからのデータを受け入れるように構成される。イングレスサーバＡＰＩ１０６を、システム１０に対し、デバイスまたは第三者プラットフォームおよびプラットフォームホストを認証するように構成することができる。

したがって、ある実施形態において、イングレスサーバシステム１００は、生データを受信し、生データのデータ品質チェックおよびスキーマ評価を実行するように構成される。生データを取り込んで検証することは、図７のブロック７０１に示される、システムの品質チェックのデータ品質パイプラインのスタートである。表１は、システムが受信できる生データの一例を示す。

別の実施形態において、イングレスソースからの車両イベントデータに含まれる情報は、より少なくてもよい。たとえば、表２に示されるように、生の車両イベントデータは、限られた数の属性を、たとえばロケーションデータ（経度および緯度）と時間データ（タイムスタンプ）とを含み得る。

本開示の実施形態の具体例としてのある利点は、存在しない情報を、本明細書に記載の革新的なアルゴリズムから導き出すことができる点である。たとえば、車両イベントデータは、行程の特定を含まない場合がある、または不正確な行程の特定を有する場合がある。したがって、システムを、最初にイングレスされたデータが限定された属性を有する場合は追加の車両イベント属性データを導き出すように構成することができる。たとえば、システムを、イングレスされた車両イベントデータについて特定の車両を識別して車両ＩＤを追加するように構成することができる。そうすることで、システムは、たとえば、車両ＩＤに関連付けられたロケーションおよびタイムスタンプデータのみを使用し、発進と停止、速度、進行方向、加速度、および他の属性を含めて、車両の移動を追跡することができる。たとえば、ある実施形態において、システムは、デバイスＩＤを使用しデバイスＩＤに対応付けられたフィールドの状態変更を識別するように構成されてもよい。

逆に、ある実施形態において、イングレスされたデータが、燃料レベル、新たなセンサデータ（ドア開放／ドア閉鎖）、エアバッグ展開、またはセンサ傾向等の強化されたデータフィールドを含む場合、強化されたデータを採用することにより、本明細書に記載のアルゴリズムを拡大または修正することができる。

ある実施形態では、ブロック７０２において、受信したデータは、外部から定義されたスキーマ、たとえばＡｖｒｏまたはＪＳＯＮに準拠していてもよい。このデータは内部スキーマに変換して検証することができる。ある実施形態において、イベントデータを、データ品質パイプラインによるダウンストリーム処理のためにメッセージングシステムに渡される前に、合意されたスキーマ定義と照らし合わせて検証することができる。たとえば、Ａｐａｃｈｅ Ｋａｆｋａメッセージングシステムに検証済みデータを渡す前に、Ａｐａｃｈｅ Ａｖｒｏスキーマ定義を使用することができる。別の実施形態において、生の移動およびイベントデータは、クライアントノードクラスタ構成によって処理することもでき、この場合、各クライアントは消費者または生産者であり、インスタンス内のクラスタはそれらの間でデータを複製することができる。

たとえば、イングレスサーバシステム１００を、パルサークラスタのＡｐａｃｈｅパルサーエンドポイントに接続されたパルサークライアントで構成することができる。ある実施形態において、Ａｐａｃｈｅパルサーエンドポイントは、読み出された最後のデータ読み出しを追跡し、Ａｐａｃｈｅパルサークライアントを、読み出された最後のデータからピックアップするためにいつでも接続できるようにする。パルサーにおいて、「標準」消費者インターフェイスは、「消費者」クライアントを使用して、トピックをリッスンし、着信メッセージを処理し、メッセージが処理されたときにそれらのメッセージを最後に確認応答することを含む。トピックのカーソルはパルサーブローカーモジュールによって自動管理されるので、クライアントは、トピックに接続するときは常に、最も早い確認応答されていないメッセージ以降の読み取りを自動的に開始する。しかしながら、このクライアントのためのクライアントリーダーインタフェースは、クライアントアプリケーションがトピックカーソルをビスポーク方式で管理できるようにする。たとえば、パルサークライアントリーダーを、トピックに接続し、トピックに接続したときからリーダーが読み取りを開始したのはどのメッセージかを指定するように、構成することができる。トピックに接続するとき、リーダーインターフェイスは、クライアントが、トピック内の最も早い利用可能メッセージから、または、トピック内の最新の利用可能メッセージから開始することを可能にする。クライアントリーダーを、たとえばメッセージＩＤを使用して永続データストアまたはキャッシュからメッセージをフェッチすることにより、最も早いメッセージと最新のメッセージとの間の何らかの他のメッセージから開始するように構成することもできる。

少なくとも１つの実施形態において、イングレスサーバシステム１００は、データをクリーンにし検証するように構成される。たとえば、イングレスサーバシステム１００を、取り込まれた車両イベントおよびロケーションデータを検証し、検証したロケーションデータをサーバキュー１０８に、たとえばＡｐａｃｈｅ Ｋａｆｋａキュー１０８に渡すように構成されたイングレスサーバＡＰＩ１０６を含むように構成することができ、上記データはストリーム処理サーバシステム２００に出力される。サーバ１０４を、検証された、イングレスされたロケーションデータを、データストア１０７に出力するように構成することもできる。また、イングレスサーバシステム１００を、無効データをデータストア１０７に渡すように構成することができる。たとえば、無効ペイロードをデータストア１０７に格納することができる。具体例としての無効データは、たとえば、不良フィールドもしくは認識されないフィールド、または同一のイベントを有するデータを含み得る。

イングレスサーバシステム１００を、たとえばシステム性能を改善するために、格納された無効データを出力するように、または格納されたデータを分析のためにデータストア１０７から分析サーバシステム５００に引き出すことができるように構成することができる。たとえば、分析サーバシステム５００を、認識されていないフィールドを有する無効データのデータベースを分析し検証済み処理のためにフィールドを新たに識別しラベル付けするように構成された診断機械学習を用いて構成することができる。イングレスサーバシステム１００を、分析サーバシステム５００による処理のために、たとえば本明細書に記載の行程分析のために、格納された、イングレスされたロケーションデータを渡すように構成することもできる。

本明細書に記載されるように、システム１０は、ストリーミングコンテキストおよびバッチコンテキストの両方でデータを処理するように構成される。ストリーミングコンテキストでは、低レイテンシが完全性よりも重要である、すなわち古いデータを処理する必要はなく、実際、古いデータを処理することは、より最近のデータの処理を遅らせる可能性があるため、有害な影響を与える可能性がある。バッチコンテキストでは、データの完全性が低レイテンシよりも重要である。したがって、これらの２つのコンテキストにおけるデータの処理を容易にするために、ある実施形態において、システムは、すべてのデータを利用可能になると直ちにイングレスするストリーミング接続にデフォルトすることができるが、古いデータをスキップするように構成することもできる。バッチプロセッサを、古いデータを原因とする、ストリーミングプロセッサが残した何らかのギャップを埋めるように構成してもよい。

図３は、少なくとも１つの実施形態に係る、データスループットおよび分析のためのストリーム処理サーバシステム２００の論理アーキテクチャである。本明細書に記載のストリーム処理は、毎秒少なくとも２００ｋ～６００ｋレコードの線形スケーリングにおけるスループットの改善を含むシステム処理の改善をもたらす。改善はさらに、２０秒のエンドツーエンドシステム処理を含み、システムレイテンシのさらなる改善が進行中である。少なくとも１つの実施形態において、システムを、マイクロバッチ処理のためのサーバを使用するように構成することができる。たとえば、本明細書に記載のように、少なくとも１つの実施形態において、ストリーム処理サーバシステム２００を、Ａｐａｃｈｅ Ｋａｆｋａ等の高スループットメッセージングサーバおよびスパークストリーミングサーバを使用するＡＷＳ等のウェブサービスプラットフォームホスト上で実行されるように構成することができる。ある実施形態において、ストリーム処理サーバシステム２００は、データ処理サーバからの処理済みデータを入力するように構成することができる、デバイス管理サーバ２０７、たとえばＡＷＳイグナイトを含み得る。デバイス管理サーバ２０７を、外部に提供またはインターフェイスできる、個々の車両データ分析のために匿名化されたデータを使用するように構成することができる。システム１０を、リアルタイムでデータを出力するように、かつ、将来の分析のために１つ以上のデータストアにデータを格納するように、構成することができる。たとえば、ストリーム処理サーバシステム２００を、インターフェイスを介して、たとえばＡｐａｃｈｅ Ｋａｆｋａを介してリアルタイムデータをエグレスサーバシステム４００に出力するように構成することができる。ストリーム処理サーバシステム２００を、リアルタイムデータおよびバッチデータの両方をデータストア１０７に格納するように構成することもできる。さらなる分析のために、データストア１０７内のデータにアクセスする、またはこのデータをインサイト（insight）サーバシステム５００に与えることができる。

少なくとも１つの実施形態において、イベント情報は、後の処理および／または分析のために、１つ以上のデータストア１０７に格納することができる。同様に、少なくとも１つの実施形態において、イベントデータおよび情報は、決定または受信されると処理されてもよい。また、イベントペイロードおよびプロセス情報を、履歴情報および／または比較情報としての使用のため、ならびにさらなる処理のために、データストア１０７等のデータストアに格納することができる。

少なくとも１つの実施形態において、ストリーム処理サーバシステム２００は、車両イベントデータ処理を実行するように構成される。

図３は、少なくとも１つの実施形態に係る、ストリーム処理サーバシステム２００の論理アーキテクチャと関連するフローチャート概要を示す。ブロック２０２において、ストリーム処理サーバシステム２００は、イングレスされたロケーション２０１からのロケーションイベントデータの検証を実行する。適切にフォーマットされていない、重複する、または認識されないデータは、フィルタリングによって取り除かれる。具体例としての無効データは、たとえば、不良フィールド、認識されないフィールドを有するデータ、または同一イベント（重複）、または同じ場所および時間において発生するエンジンオン／エンジンオフデータポイントを含み得る。また、検証は、予め定められた期間、たとえば７秒より古いイベントデータを破棄するレイテンシチェックを含む。ある実施形態において、たとえば、４秒と１５秒の間の他のレイテンシフィルタを使用することができる。

ある実施形態において、ストリーム処理サーバシステム２００は、誤りがあるフィールドデータに対して誤り訂正を実行するように構成されてもよい。たとえば、システムは、イングレスされた車両イベントデータをバッファリングすることにより、車両の一連のデータポイントにおいて、不具合のあるポイントのセットを特定するように構成されてもよい。そうすると、システムは、最も早いデータポイントを検証しその他のポイントを破棄するように構成されてもよく、または、システムは、車両イベントデータポイントを並べ変えて正しい時系列にしてもよい。ある実施形態において、バッファリング時間を、システムの低レイテンシを最適化するように設定してもよい。システム２００は、最小数のイングレスされたデータポイントをバッファリングすることにより、誤りの特定および検証を可能にするように構成されてもよい。たとえば、車両イベントデータを３秒ごとに提供するイングレスデータストリームに対して、システムは、少なくとも３秒間バッファリングして誤りを特定し、バッファリングした車両イベントデータに対して誤り検査を実行し、イベントデータを下流に転送するために訂正するように構成されてもよい。イングレスストリームに対するバッファリングをより少なくして車両イベントデータをより高頻度で、たとえば１秒ごとに提供してもよい。

ある実施形態において、図７のブロック７０３に示されるように、ストリーム処理サーバシステム２００は、属性範囲フィルタリングを実行するように構成される。属性範囲フィルタリングは、イベントデータ属性が、このデータにとって重要な、データの予め定められた範囲に含まれることを保証するために、チェックする。たとえば、進行方向属性を、円（０→３５９）と定める。ｓｑｕｉｓｈ－ｖｉｎは９～１０文字のＶＩＮである。例は、データプロバイダによって予め定義されたまたは標準によって設定されたデータを含む。これらの範囲にないデータ値は、データが属性について本質的に不良であることを示す。非適合データをチェックし、フィルタリングして取り除くことができる。属性範囲フィルタリングの一例を表３に示す。

ある実施形態において、ブロック７０４において、システムは、属性値フィルタリングを実行するように構成される。属性値フィルタリングは、属性値が内部で設定されたことまたはビスポーク規定範囲であることを保証するために、チェックする。たとえば、１９７０という日付は、イベントの日付属性に対する属性範囲フィルタチェックに合格することができるが、その日付は車両追跡データにとっては妥当なデータではない。したがって、属性値フィルタリングは、チェックしフィルタリングすることができる、予め定められた時間よりも古い、たとえば６週間以上前のデータをフィルタリングするように構成される。属性範囲フィルタリングの一例を表３に示す。

ブロック７０５において、システムは、レコード内の属性についてさらに検証を行い、レコードデータポイントの属性間の関係がコヒーレントであることを確認することができる。たとえば、非ゼロトリップ開始イベントは、本明細書に記載の行程決定にとっては論理的な意味をなさない。したがって、表４に示されるように、システム１０を、「トリップ開始」または行程のイグニッションオンもしくは開始イベントとしての、ロケーションの捕捉タイムスタンプおよび受信タイムスタンプの同一属性に対して記録された、非ゼロ速度イベントをフィルタリングするように構成することができる。

図３に戻ると、ブロック２０４において、少なくとも１つの実施形態において、ストリーム処理サーバ２００は、ロケーションイベントデータのジオハッシュを実行する。Ｕｂｅｒ（商標）が使用するＨ３アルゴリズムまたはＧｏｏｇｌｅ（商標）が使用するＳ２アルゴリズム等の、ジオハッシュに代わるものを利用できるが、ジオハッシュは、システム１０に、具体例としての改善、たとえばシステムレイテンシおよびスループットの改善をもたらすことが見出された。また、ジオハッシュは、システム１０の精度および車両検出におけるデータベースの改善をもたらした。たとえば、９文字の精度のジオハッシュを使用することにより、車両をジオハッシュに一意に関連付けることができる。そのような精度は、本明細書に記載の行程決定アルゴリズムに用いることができる。少なくとも１つの実施形態において、イベントデータ内のロケーションデータは近接度に符号化され、符号化は、各イベントの緯度および経度を各イベントの近接度にジオハッシュすることを含む。イベントデータは、時間、位置（緯度／経度）、および関心イベントを決定するためのデータを含む。関心イベントデータは、急ブレーキおよび急な加速を含み得る。たとえば、急ブレーキは、予め定められた時間内の減速（たとえばｘ秒間で４０－０）であると定義することができ、急な加速は、予め定められた時間内の加速（たとえばｘ秒間で４０－８０ｍｐｈ）であると定義される。関心イベントデータは、他のアルゴリズムにおける使用のために相関させて処理することができる。たとえば、時空間クラスタにロケーションマッピングされた急ブレーキのクラスタを、混雑検出アルゴリズムとして用いることができる。したがって、急加速は、車両加速の値（ｍ／ｓ２）が規定されたしきい値（メートル毎秒毎秒）を上回る場合の運転挙動であると定義することができる。たとえば、ある実施形態において、SPEED_RATE_OF_CHANGE >= ２．６３８ｍ／ｓ２ ・SPEED_RATE_OF_CHANGE_POSITIVE = TRUEの値は、決められた旅行または行程における急加速イベントの数を与える。

関心イベントデータは、他のアルゴリズムにおける使用のために相関させて処理することができる。たとえば、時空間クラスタにロケーションマッピングされた急ブレーキのクラスタを、混雑検出アルゴリズムとして用いることができる。フィードデータを提供するまたは他のデータと組み合わせて集約されたデータセットにし、インターフェイスを用いて、たとえばＧＩＳ可視化ツール（たとえばＭａｐｂｏｘ、ＣＡＲＴＯ、ＡｒｃＧＩＳ、もしくはＧｏｏｇｌｅ（登録商標） Ｍａｐｓ ＡＰＩ）または本明細書に記載の他のインターフェイスを用いて、可視化してもよい。

ジオハッシュアルゴリズムは、イベントデータからの緯度および経度（緯度／経度）データをｎ文字の短いストリングに符号化する。ある実施形態において、ジオハッシュされた緯度／経度データは、ある形状にジオハッシュされる。たとえば、ある実施形態において、緯度／経度データは、そのエッジがストリング内の文字に比例する矩形にジオハッシュすることができる。ある実施形態において、ジオハッシュは、４～９文字に符号化することができる。

いくつかの利点が、本明細書に記載のジオハッシュされたイベントデータを使用するによって得られる。たとえば、データベースにおいて、ジオハッシュでインデックスされたデータは、所定の矩形エリアのすべてのポイントを連続するスライス内に有し、この場合のスライスの数は、符号化のジオハッシュ精度によって決まる。これは、複数インデックスクエリよりも遥かに簡単で高速である単一インデックスに対するクエリを可能にすることにより、データベースを改善する。また、ジオハッシュインデックス構造は、最も近いポイントが最も近いジオハッシュの中にあることが多いので、合理化された近接検索にも役立つ。

ブロック２０６において、少なくとも１つの実施形態において、ストリーム処理サーバシステム２００は、ロケーションルックアップを実行する。先に述べたように、ある実施形態において、システムを、ジオハッシュを符号化することで、定められた地理的エリア、たとえば、国、州、またはジップコードを特定するように構成することができる。システムは、緯度／経度を、そのエッジがストリング内の文字に比例する矩形にジオハッシュすることができる。

たとえば、ある実施形態において、ジオハッシュを５文字に符号化するように、ジオハッシュを構成することができ、州を５文字のジオハッシュされたロケーションで特定するように、システムを構成することができる。たとえば、５つのスライスまたは文字という精度で符号化されたジオハッシュは、＋／－２．５キロメートルの精度であり、これは州を特定するのに十分である。６文字へのジオハッシュは、ジップコードにジオハッシュされたロケーションを特定するために使用することができ、これは＋／－０．６１キロメートルの精度である。４文字へのジオハッシュは国を特定するために使用することができる。ある実施形態において、システム１０を、ジオハッシュを符号化して、ジオハッシュされたロケーションで車両を一意に特定するように構成することができる。ある実施形態において、システム１０を、ジオハッシュを９文字に符号化して車両を一意に特定するように構成することができる。

ある実施形態において、システム１０をさらに、ジオハッシュされたイベントデータマップデータベースにマッピングするように構成することができる。マップデータベースは、たとえばパブリックまたはプロプライエタリマップデータベースを含む、関心ポイントのデータベースまたは他のマップデータベースとすることができる。具体例としてのマップデータベースは、ローカルストリートマップ用のジオファブリック（Ｇｅｏｆａｂｒｉｃ）またはワールドマップデータベース等の現存ストリートマップデータを含み得る。本明細書に記載のジオハッシュの使用の、具体例としての利点は、ダウンストリームで処理されるときの車両イベントデータをより高速かつ低レイテンシで充実させることを可能にする点である。たとえば、地理的定義、マップデータ、および他の充実化は、ジオハッシュされたロケーションおよび車両ＩＤに容易にマッピングされる。また、フィードデータを、集約されたデータセットに組み込み、インターフェイスを用いて、たとえばＧＩＳ可視化ツール（たとえばＭａｐｂｏｘ、ＣＡＲＴＯ、ＡｒｃＧＩＳ、もしくはＧｏｏｇｌｅ（登録商標） Ｍａｐｓ ＡＰＩ）または他のインターフェイスを用いて、可視化することで、グラフィック報告を生成およびインターフェイスすることができる、または、アナリティックスインサイトを生成するために処理されたデータを使用して、たとえばエグレスサーバシステム４００またはポータルサーバシステム６００を介して第三者１５に報告を出力することができる。

少なくとも１つの実施形態において、ブロック２０８において、ストリームプロセッササーバシステム２００を、たとえば、イベントデータ内の車両データの車両識別番号（ＶＩＮ：Vehicle Identification Number）から個人識別情報を削除するまたはこれを不明瞭にすることによって識別情報を削除するために、データを匿名化するように構成することができる。各種実施形態において、イベントデータまたは他のデータはＶＩＮ番号を含むことができ、ＶＩＮ番号は、製造、モデル、および年等の、車両の製品情報を表す番号を含み、また、車両を一意に特定する文字を含み、所有者に対して個人的に特定するために使用することができる。システム１０は、たとえば、車両データから車両を一意に特定するＶＩＮ内の文字は削除するが他の識別シリアル番号（たとえば、製造、モデル、および年の番号）は残すアルゴリズム、たとえばＳｑｕｉｓｈ Ｖｉｎアルゴリズムを含み得る。ある実施形態において、システム１０を、匿名化されたデータに固有の車両タグを追加するように構成することができる。たとえば、システム１０を、固有の番号、文字、または他の識別情報を匿名化されたデータに追加するように構成することができ、それにより、固有の車両に関するイベントデータを、ＶＩＮに関連する個人識別情報が削除された後に、追跡、処理、および分析することができる。匿名化されたデータの具体例としての利点は、匿名化されたデータが、処理済みイベントデータを外部提供できるようにしつつ、たとえば法的に要求されるかまたはユーザが望む場合もある、データの個人識別情報の保護を可能にする点である。

少なくとも１つの実施形態において、本明細書に記載のように、９文字へのジオハッシュは、ＶＩＮデータ等の個人特定情報を取得または必要とせずに、車両の一意の識別を提供することも可能である。車両を、データベースイベントデータの処理によって識別し、固有の車両を特定するのに十分な精度で、たとえば９文字の精度でジオハッシュすることができ、そうすると、本明細書に記載のように、車両を識別し、追跡し、そのデータを処理することができる。

先に述べたように、リアルタイムストリーミングの場合、ブロック２０２において、データ検証は、過剰レイテンシ、たとえば７秒を超えるレイテンシのデータをフィルタリングによって除去する。しかしながら、バッチデータ処理は、ギャップなしの完全なデータセットで実行することができ、したがって、レイテンシのためにフィルタリングされないデータを含むことができる。たとえば、図５に関して説明する分析のためのバッチデータプロセスは、最大で６週前までのデータを受け入れるように構成することができるが、ストリーム処理サーバシステム２００のストリーミングスタックは、７秒前よりも古いデータをフィルタリングするように構成され、したがって、ブロック２０２におけるレイテンシ検証チェックを含み、より高レイテンシのイベントを拒否する。

ブロック２０９において、少なくとも１つの実施形態では、ストリームプロセッササーバシステム２００が、イベントデータの行程セグメント化分析を実行する。ある実施形態において、ストリームプロセッササーバシステム２００は、イベントデータから車両の行程を特定するように構成され、これは、所与の車両のルートまたは移動が、行程の目的地までの運転を目的としているか否かを特定することを含み、行程の特定は、車両のエンジンオンまたは最初の移動を特定することと、車両のエンジンオフまたは移動停止を特定することと、車両の滞留時間を特定することと、最短走行継続時間を特定することとを含む。行程セグメント化処理は、デバイス匿名化２０８の後に始まるものとして示されているが、行程セグメント化プロセス２０９は、データイングレス２０１の後のどのポイントで開始されてもよい。

少なくとも１つの実施形態において、行程は、開始点から最終目的地までの１つ以上の行程セグメントを含み得る。行程セグメントは、車両のエンジンオン／移動開始とエンジンオフ／移動停止イベントとの間の走行距離および走行継続時間を含む。

しかしながら、実際の運転者は、目的地まで移動しているときに１回以上停止する場合がある。行程は、複数回の停止を伴う行程がある場合のように、２つ以上の行程セグメントを有し得る。たとえば、運転者は、自宅から職場までの移動中に燃料補給のために停止するまたは信号で停止する必要がある場合がある。そのため、車両イベント分析における問題および課題は、本明細書に記載の実施形態に対して正確な車両追跡を開発することを含む。当該技術では他の行程アルゴリズムまたはプロセス、たとえば特定された車両の既知の目的地から行程を逆に設計することが採用されてきたが、本開示は、データ分析、データベース、インターフェイス、データ処理、およびその他の技術的生産物を含む、本明細書に記載の技術を用いた寛容な車両追跡のために開発され好都合に実現された実施形態およびアルゴリズムを含む。

ブロック２１０において、ストリームプロセッササーバシステム２００は、イベント情報から行程を認定するための計算を実行するように構成される。ある実施形態において、ストリームプロセッササーバシステム２００は、継続時間基準、距離基準、および滞留時間基準を含む、行程検出基準を用いて構成される。少なくとも１つの実施形態において、継続時間基準は、最短継続時間基準を含み、最短走行継続時間は、システムが行程セグメントを行程に含めるのに必要である。エンジンオンまたは移動開始後の最短走行継続時間は、たとえば約６０～約９０秒の走行継続時間を含み得る。ある具体例としての実施形態において、ストリームプロセッササーバシステム２００は、行程セグメントに含めるために６０秒を超える車両走行を必要とするように構成されてもよい。たとえば、（１）エンジンオン／点火イベントまたは（２）（たとえば前回の移動または行程の）既知の最後の移動後の特定された車両の最初の移動または（３）新たに特定された車両の最初の移動が、車両について特定され、６０秒未満の短い走行継続時間のイベントが続いた場合、ストリームプロセッササーバシステム２００は、この行程セグメントを行程の決定から除外するように構成される。ストリームプロセッササーバシステム２００は、車両の短い走行継続時間は行程の開始または目的地ではないと判断するように構成される。

ある実施形態において、行程検出基準は、走行距離基準、たとえば２００メートルを含む。ストリームプロセッササーバシステム２００は、２００メートル以下の距離を行程セグメントから除外するように構成されてもよい。最短走行距離基準は、たとえば約１００メートルから約３００メートルまでの走行距離の予め定められた継続時間を含み得る。最短距離ｘ（たとえば２００メートル）を、最短距離ｘの約５０％の許容誤差を含むインデックスと定義してもよい。

ある実施形態において、滞留時間基準は、車両の停止時間を含み得る。たとえば、滞留時間基準は、約３０～約９０秒であってもよい。最長滞留時間は、同じ車両のエンジンオフ／移動停止とエンジンオン／移動開始との間の停止継続時間、たとえば約２０～約１２０秒を含み得る。たとえば、ストリームプロセッササーバシステム２００は、３０秒未満車両が停止またはそのエンジンが停止したと判断した場合にこの停止期間を行程または行程オブジェクトの終了として含めないように構成される。

先に述べたように、ある実施形態において、ストリームプロセッササーバシステム２００は、車両イベントデータを処理することにより、１つ以上の行程セグメントが車両の行程を含むか否かを判断するように構成される。たとえば、エンジンオンまたは移動開始イベントの後に、距離基準を超える（たとえば２００メートルを超える）距離が続く場合がある。そうすると、システムの継続時間基準は、この行程のセグメントを識別しない。しかしながら、その後に車が停止し３０秒を超えて静止し続けた場合、ストリームプロセッササーバシステム２００は、これを行程のセグメントとしてカウントしないように構成される。その後車両が３０秒未満停止してから再び移動した場合、滞留時間基準が満たされ、ストリームプロセッササーバシステム２００は、この行程セグメントを、車両がその最終目的地まで走行する行程のセグメントに含めるように構成される。このように、たとえば運転者が自宅で車を起動（エンジンオン／移動開始）し１０マイル（距離基準）運転し停止信号で２９秒間停止し職場における最終目的地（エンジンオフ／移動停止）まで走行した場合、アルゴリズムは、目的地までの日々のリアルタイムの運転についての行程または行程オブジェクトに対して複数の行程セグメントを連結することができる。ストリームプロセッササーバシステム２００は、たとえば停止信号における２９秒間の停止（滞留基準）または２００メートル未満の移動（距離基準）または６０秒未満（継続時間基準）等の、行程内の中断を表す可能性が低いイベントを、無視するように構成されてもよい。

ある実施形態において、ストリームプロセッササーバシステム２００は、たとえば、可変データに基づく、滞留基準、距離基準、または時間基準の各々についての複数の基準を含み得る。したがって、アルゴリズムは、車両およびロケーションに関する追加データがわかっている場合、目的地までの一般的なリアルタイムの運転についての行程の複数の行程セグメントを結合することができる。たとえば、車両が電気自動車等の道路法上の電動車両として識別された場合、滞留基準は、充電ステーションとして識別されたロケーションでの２０分の最長滞留時間基準を含み得る。したがって、滞留時間は、たとえばこのロケーションに関する他のデータ（たとえば停止がガソリンスタンド、休憩エリア、またはレストラン等の関心ポイントであることを示すデータ）に基づいて、最大２～２０分まで延長することができる。電気自動車の運転者が自宅で車を起動し（エンジンオンまたは最初の移動）、充電（エンジンオフ／移動停止、１２分、滞留基準、可変、充電ステーション）のために充電ステーションまで１００マイル（距離基準）運転し、その後再び始動し（エンジンオン／移動開始）、販売ミーティングがある最終目的地まで走行した（エンジンオフ／移動停止）場合、ストリームプロセッササーバシステム２００は、行程を特定するように構成されてもよい。別の例において、強化されたデータがイングレスソースから提供された場合、たとえば燃料レベル、燃料消費量を基準に使用することができる。たとえば、停止時の燃料レベルの小さな変化（－００２）を用いることにより、無視できる滞留基準（たとえば燃料レベルの小さな降下を伴う６０秒未満の停止）を特定することができる。したがって、理解されるように、上記基準の各々は、特にイベント車両データポイントに関して導き出されたまたは得られた知識に応じて可変となるように構成されてもよい。

ある実施形態において、ブロック２１１で、ストリームプロセッササーバシステム２００は、行程セグメントをアグリゲートして行程オブジェクトにするように構成される。ストリームプロセッササーバシステム２００は、上記基準に従い所与のデバイスに対して候補となる行程セグメントチェーンを特定するように構成される。また、複合行程オブジェクトが、その開始をチェーンの始まりとしその終了を当該チェーン内の最後のセグメントとして、インスタンス化されてもよい。独立した行程オブジェクトテーブルがイベントデータから抽出されてもよく、導き出された複合行程が生成されてさらに他のテーブルにされてもよい。ある実施形態において、すべてのエンジンオン／エンジンオフまたは移動開始／移動停止イベントを含むデータセットが固有の車両ＩＤまたはデバイスＩＤに対して識別されてもよい。たとえば、ある車両のエンジンオン／エンジンオフまたは移動開始／移動停止イベントの各々を、候補行程セグメントを含む１つの行に配置してもよい。次に、エンジンオン／エンジンオフまたは移動開始／移動停止イベントの行を、距離基準、継続時間基準、および滞留基準の各々によって処理することにより、どの行程セグメントを、行程オブジェクトの行程決定に含めるかまたはそれから除外するかを決定してもよい。ある実施形態において、ストリームプロセッササーバシステム２００は、上記行程基準を満たす車両のイベントから決定された行程オブジェクトが含まれるさらに他の行程テーブルを生成することができる。

少なくとも１つの実施形態において、システム１０は、車両イベントデータのデータベースを分析し、ポイントの行程を集約して、開始時間、終了時間、開始位置、終了位置、データポイントカウント、平均間隔などのような属性を有する行程オブジェクトにすることにより、能動的車両検出を提供するように構成される。ある実施形態において、行程オブジェクトを処理のために別のデータテーブルに入れてもよい。

ある具体例としての実施形態において、システム１０は、（たとえばＶＩＮ番号による）車両の事前識別を必要とすることなく車両追跡を実行するように構成されてもよい。先に述べたように、ジオハッシュをイベントデータのデータベースに用いることにより、イベントを車両に対して一意に相関させるのに十分な形状に対応する９文字の精度まで、データをジオハッシュすることができる。ある実施形態において、能動的車両検出は、ある期間にわたる複数のイベントから車両経路を特定することを含む。ある実施形態において、能動的車両検出は、１日（２４時間）の期間にわたる複数のイベントから車両経路を特定することを含み得る。この特定は、たとえばコネクテッドコンポーネントアルゴリズムを用いることを含む。ある実施形態において、コネクテッドコンポーネントアルゴリズムを用いることにより、車両イベントの日を含む有向グラフにおいて車両経路を特定し、このグラフにおいて、ノードは車両でありノード間の接続は特定された車両経路である。たとえば、行程開始および行程終了のグラフが作成され、この場合のノードは開始および終了を表し、エッジは車両によって実施される行程である。各エッジにおいて、開始および終了が一時的にソートされる。エッジは、終了を、時間で順序付けられた、そのノードの次の開始に接続するために作成される。ノードは、ＧＰＳ座標の９桁のジオハッシュである。コネクテッドコンポーネントアルゴリズムは、一組のノードと、接続されたエッジとを発見し、１日の始まりで生成されたデバイスＩＤを、決定されたサブグラフに沿って送ることにより、同じ車両によって実施されている行程（エッジ）を一意に特定する。

この方策の具体例としての利点は、イベントデータに対して車両を予め特定する必要がない点である。本明細書に記載の行程基準を満たす車両経路からの行程セグメントを用いることにより、上記のように、行程を検出し、適格でない行程イベントを除外することができる。たとえば、車両の移動停止／エンジンオフから移動開始／エンジンオンイベントまでがｘ秒（３０秒）以内であったことを示すイベントデータについて９桁（最高分解能）に符号化されたジオハッシュは、行程の同一車両とみなすことができる。一連の到着と出発に対し、行程を、グラフを通して、行程セグメントの最短経路として計算することができる。

ある実施形態において、ブロック２１２において、レイテンシのためにフィルタリングされた変換済みロケーションデータと拒否されたレイテンシデータの両方が、サーバ待ち行列、たとえば、Ａｐａｃｈｅ Ｋａｆｋａ待ち行列に入力される。ブロック２１４において、ストリーム処理サーバシステム２００は、データを、フルデータ２１６を含む、すなわちレイテンシのためにフィルタリングされた変換済みロケーションデータおよび拒否されたレイテンシデータを含むデータセットと、変換済みロケーションデータ２２２の別のデータセットとに、分割することができる。フルデータ２１６は、アクセスのためまたは分析サーバシステム５００への送信のためにデータストア１０７に格納され、フィルタリングされた変換済みロケーションデータは、エグレスサーバシステム４００に送信される。別の実施形態において、拒否されたデータを含むフルデータセットまたはその一部を、第三者プラットフォームのためのエグレスサーバシステム４００に、それ自身による使用および分析のために送信することもできる。そのような実施形態において、ブロック２１３において、レイテンシのためにフィルタリングされた変換済みロケーションデータと、拒否されたレイテンシデータとを、直接、エグレスサーバシステム４００に提供することができる。

少なくとも１つの実施形態において、ストリーム処理サーバ２００は、イベントデータおよび行程決定データをデータウェアハウス１０７に格納するように構成されてもよい。データは、あるデータベースフォーマットで格納されてもよい。ある実施形態において、処理されたデータに時間カラムを追加してもよい。別の実施形態において、分析サーバ５００は、ストリーム処理サーバから独立して行程決定を実行するように構成することができるので、ストリーム処理サーバ２００による行程決定を、エグレスサーバ４００にエグレスしストリーム処理サーバから削除してもよい。

図４は、エグレスサーバシステム４００の論理アーキテクチャである。少なくとも１つの実施形態において、エグレスサーバシステム４００は、レコードを取り込み、処理し、イベントデータを出力するように配置された１つ以上のコンピュータとすることができる。エグレスサーバシステム４００を、プッシュまたはプルベースでデータを提供するように構成することができる。たとえば、ある実施形態において、システム１０を、Ａｐａｃｈｅ Ｓｐａｒｋクラスタからのプッシュサーバ４１０を使用するように構成することができる。プッシュサーバを、たとえばレイテンシフィルタリング４１１、ジオフィルタリング４１２、イベントフィルタリング４１３、変換４１４、および送信４１５のために、ストリームプロセスサーバシステム２００からの変換されたロケーションデータを処理するように構成することができる。本明細書に記載されるように、ジオハッシュは、システム１０のスループットレイテンシを大幅に改善し、これは、たとえば数分以内、さらには数秒以内に、イベントに近接して処理されたデータに対する適時プッシュ通知を行うという利点を可能にする。たとえば、ある実施形態において、システム１０は、６０秒未満のレイテンシを目標とするように構成される。先に述べたように、ストリーム処理サーバシステム２００は、７秒未満のレイテンシのイベントをフィルタリングするように構成され、スループットも改善する。ある実施形態において、プルデータのためのデータストア４０６を、ＡＰＩゲートウェイ４０４を介して提供することができ、プルＡＰＩ４０５は、どの第三者１５ユーザがデータをプルしているかおよびユーザが要求しているのはどのデータかを追跡することができる。

たとえば、ある実施形態において、エグレスサーバシステム４００は、システム１０によって提供されるフィルタに基づいてパターンデータを提供することができる。たとえば、システムを、特定の１つまたは複数のロケーションについてのイベントデータをフィルタリングするためにジオフェンスフィルタ４１２を提供するように構成することができる。ジオフェンスを、多数のパターンおよび構成のために本明細書に記載の行程およびイベントデータを境界設定および処理するように構成することができることが、理解されるであろう。たとえば、ある実施形態において、エグレスサーバシステム４００を、ユーザが提供または選択した経度／緯度内での行程の開始および終了（イグニッションキーオン／オフイベント）にデータを制限するように構成された「パーキング」フィルタを提供するように構成することができる。このデータのさらに他のフィルタまたは例外を、たとえば州（州コードまたは緯度／経度）によって構成することができる。また、システム１０を、「トラフィック」フィルタを用いて構成することで、たとえば特定の州および経度／緯度バウンディングボックスをフィルタから除外して、トラフィックパターンデータを提供することもできる。

図５は、データアナリティックスおよびインサイトのための分析サーバシステム５００の論理アーキテクチャを表す。少なくとも１つの実施形態において、分析サーバシステム５００は、イベントデータを分析するように配置された１つ以上のコンピュータとすることができる。リアルタイムデータおよびバッチデータの両方を、本明細書に記載の他のコンポーネントから、処理のために分析サーバシステム５００に送ることができる。ある実施形態において、バッチおよびストリーミングデータ処理を組み合わせる、Ａｐａｃｈｅ Ｓｐａｒｋクラスタ等のクラスタコンピューティングフレームワークおよびバッチプロセッサが、分析サーバシステム５００によって採用されてもよい。分析サーバシステム５００に提供されるデータは、たとえばイングレスサーバシステム１００、ストリーム処理サーバシステム２００、およびエグレスサーバシステム４００からのデータを含み得る。

ある実施形態において、分析サーバシステム５００を、データストア１０７等のデータストアに格納することができる車両イベントペイロードおよび処理済みの情報を受け入れるように構成することができる。図５に示されるように、ストレージは、エグレスサーバシステム４００からのリアルタイムのエグレスデータ、ストリーム処理サーバシステム２００からの変換されたロケーションデータおよび拒否データ、ならびにイングレスサーバシステム１００からのバッチおよびリアルタイムの生データを含む。図２に示されるように、データストア１０７に格納された、イングレスされたロケーションは、分析サーバシステム５００に出力またはプルすることができる。分析サーバシステム５００を、図３に示されるストリームプロセッササーバシステム２００と同じ方法で、イングレスされたロケーションデータを処理するように構成することができる。先に述べたように、ストリーム処理サーバシステム２００を、フルデータ（レイテンシのためにフィルタリングされた変換済みロケーションデータおよび拒否されたレイテンシデータ）を含むフルデータセット２１６と、変換されたロケーションデータ２２２のデータセットとに、データを分割するように構成することができる。フルデータセット２１６は、アクセスのためおよび分析サーバシステム５００への送信のためにデータストア１０７に格納され、フィルタリングされた変換済のロケーションデータは、エグレスサーバシステム４００に送信される。図５に示されるように、リアルタイムのフィルタリングされたデータを、パフォーマンス５２２、イングレス対エグレス５２４、動作モニタリング５２６、およびアラート５２８の報告を含む、準リアルタイムでの報告のために、処理することができる。

したがって、図５のブロック５０２において、少なくとも１つの実施形態では、分析処理サーバシステム５００を、図３のブロック２０２および図７のブロック７０１～７０５で示されるのと同じ方法で、イングレスされたロケーションから生のロケーションイベントデータの検証を任意で実行するように構成することができる。ある実施形態において、図７に示されるように、ブロック７０６において、システム１０は、レコードのバッチ処理を用いて、複数のイベントレコードの属性に対するさらなる検証を実施し、イベントデータポイントの属性間のレコード内関係が意味のあるものであることを確認することができる。たとえば、表５に示されるように、システム１０を、行程のイベントの論理的順序付け（たとえばある行程の行程イベントは「トリップ開始－トリップ終了－トリップ開始」のように交互に起こるものであって「トリップ開始－トリップ開始－トリップ終了－トリップ終了」という繰り返しではない）を確実にするために分析されたデータポイントを分析するように構成することができる。

図５のブロック５０４に戻ると、少なくとも１つの実施形態において、分析サーバシステム５００は、任意で、図３のブロック２０４に示されるように、ロケーションイベントデータのジオハッシュを実行するように構成されてもよい。図５のブロック５０６において、分析サーバシステム５００は、任意で、ロケーションルックアップを実行してもよい。図５のブロック５０８において、分析サーバシステム５００を、図３のブロック２０６および２０８に示されるデバイス匿名化を任意で実行するように構成してもよい。

ブロック５１０において、少なくとも１つの実施形態では、分析サーバシステム５００を、図３のブロック２０９に示されるように、イベントデータの行程セグメント分析を実行するように構成してもよい。ブロック５１２において、分析サーバ５００は、図３のブロック２１０に示されるように、イベント情報から行程を認定する（qualify）ための計算を実行するように構成される。少なくとも１つの実施形態では、ブロック５１４において、システム１０は、図２のブロック２１１で説明されるように、車両イベントデータのデータベースを分析し、属性を有する行程オブジェクトへのポイントの行程の要約を分析することにより、能動的車両検出を提供するように構成される。分析サーバシステムに採用される行程セグメント化アルゴリズムの説明は、その全体を本明細書に引用により援用する「System and Method for Processing Vehicle Event Data for Journey Analysis」と題された米国特許出願第１６／７８７，７５５号に記載されている。

少なくとも１つの実施形態において、ブロック５１５において、システム１０を、データウェアハウス５１７内にイベントデータおよび行程判定データを格納するように構成することができる。データはデータベースフォーマットで格納することができる。ある実施形態において、タイムカラムを処理済みデータに追加することができる。ある実施形態において、データベースは、関心ポイント（ＰＯＩ：Point of Interest）データを含むこともできる。

分析サーバシステム５００は、データウェアハウス５１７に格納されたデータ、たとえば、スパーク分析クラスタに対してデータ分析を実行する分析サーバコンポーネント５１６を含み得る。分析サーバシステム５００を、評価５３０、クラスタリング５３１、人口統計分析５３２、およびビスポーク分析５３３を実行するように構成することができる。たとえば、ウェアハウス５１７に格納された処理済みの行程データおよびロケーションデータに対するデータに、日付カラムおよび時間カラムを追加することができる。これは、たとえば、日付および時刻によって交差点ｘにどれだけ多くの車両があるかを判断する、ビスポーク分析５３３に使用することができる。また、システム１０を、図４に関して説明したように、エグレスサーバシステム４００におけるビスポーク分析５３３を提供するように構成することもできる。

ある実施形態において、地理空間インデックス行を、格納されたウェアハウス５１７のデータに追加して、たとえば、ジオハッシュされたデータに対するハイパーローカルターゲティングまたはアドホッククエリの高速化を実行することができる。たとえば、４桁または文字に分解されたロケーションデータは、２０メートル以下の分解能に相当し得る。

分析サーバシステム５００を、検証済み処理のためのフィールドを新たに識別しラベル付けするために、認識されていないフィールドを有する無効データのデータベース上で分析を実行するように構成された診断機械学習５３４で構成することができる。

ある実施形態において、システム１０を、ブロック５１０で説明したように行程セグメント化のバッチ分析を実行するように構成することができる。たとえば、図７のブロック７０７において、行程セグメント化抽出は、固有ＩＤでマークされたすべてのイベントを特定することによる行程の単純な抽出を含み得る。行程セグメント化抽出およびカウントの例を表６に示す。

また、システム１０を、図７のブロック７０８における行程値フィルタリングのために、ブロック５１２で説明したように行程基準を使用してイベント情報から行程を認定するための計算を実行するように構成することもできる。行程値フィルタリングの一例を表７に示す。

ある実施形態において、バッチデータを、システムパフォーマンス報告５３５のために処理することができる。たとえば、ある実施形態において、システム１０を、システムレイテンシの報告を生成するように構成することができる。捕捉されたタイムスタンプデータと受信されたタイムスタンプデータとの間のパーセンタイルの範囲に対するバッチ分析レイテンシ報告の一例を表８に示す。システム１０を、潜在データのインターバル分析を実行するように構成することができる。ある範囲のパーセンタイルに対するインターバル／捕捉レート報告の一例を表９に示す。

図６は、ポータルサーバシステム６００の論理アーキテクチャである。少なくとも１つの実施形態において、ポータルサーバシステム６００は、レコードおよびイベントデータを取り込んで処理するように配置された１つ以上のコンピュータとすることができる。ポータルサーバシステム６００を、ポータルＡＰＩ６０８がプラットフォームの第三者１５ユーザからのデータをインターフェイスし受け入れるためのポータルユーザインターフェイス６０４およびＡＰＩゲートウェイ６０６で構成することができる。ある実施形態において、ポータルサーバシステム６００は、毎日の静的総会を提供するように構成されてもよく、分析サーバシステム５００から提供されるデータのリアルタイムアクセスのための検索エンジンおよびアクセスポータルで構成される。少なくとも１つの実施形態において、ポータルサーバシステム６００を、ユーザに、たとえば、第三者１５クライアントコンピュータに、ダッシュボードを提供するように構成することができる。少なくとも１つの実施形態において、分析サーバシステム５００またはストリーム処理サーバシステム２００からの情報は、ポータルユーザインターフェイス６０４が提供する報告生成器に流すことができる。少なくとも１つの実施形態において、報告生成器を、パフォーマンス情報に基づいて１つ以上の報告を生成するように配置することができる。少なくとも１つの実施形態において、報告を、１つ以上の報告テンプレートに基づいて決定およびフォーマットすることができる。

少なくとも１つの実施形態において、ダッシュボードディスプレイが、システム１０の他の構成要素によって生成された情報の表示を提供してもよい。少なくとも１つの実施形態において、ダッシュボードディスプレイは、ネットワークを通してアクセスされるクライアントコンピュータ上に示されてもよい。少なくとも１つの実施形態において、クレームされている主題の精神および／範囲から逸脱することなく、ユーザインターフェイスを採用することができる。そのようなユーザインターフェイスは、さまざまなやり方で配置できる任意の数のユーザインターフェイス要素を有することができる。いくつかの実施形態において、ユーザインターフェイスは、ウェブページ、モバイルアプリケーション、ＧＩＳ可視化ツール８０２、マッピングインターフェイス、電子メール、ファイルサーバ、ＰＤＦ文書、テキストメッセージなどを用いて生成することができる。少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、またはポータルサーバシステム６００は、ユーザインターフェイスを生成するためのプロセスおよび／またはＡＰＩを含み得る。

図７は、上記データ処理のデータパイプラインを示すフローチャートである。図７に示されるように、ある実施形態において、イベントデータは、データ品質チェックの７段階パイプラインを通してデータを送る。加えて、ストリーム処理とバッチ処理の両方を用いてデータ処理を行う。ストリーミングは、一回につき一レコードに対して機能し、トリップの以前のレコードのコンテキストは保持せず、属性およびレコードレベルで実行されるチェックに使用することができる。バッチ処理は、より完全にデータを観察することができ、エンドツーエンドプロセス全体を包含することができる。バッチ処理は、ストリーミングと同一のチェックに加えて、複数のレコードおよび行程にわたって実行されるチェックを受ける。

低レイテンシは、車両ソースからエンドユーザ顧客に情報を配信する超高速接続を提供する。さらに、データ捕捉は、１データポイント当たり３秒という高い捕捉レートを有し、たとえば１ヶ月当たり最大３３００億のデータポイントを捕捉する。本明細書の記載において、データは、ロケーションデータについての車線レベルまで正確であり、典型的な車のサイズである半径３メートル以内までは９５％正確である。本明細書の記載において、車両データは、交差点レベルまで正確であり、どの道路が混雑しているかまたは空いているかを識別することを可能にし、混雑している場所および時間を正確に含む。この新たな粒度情報は、エンドユーザおよびパートナーに、たとえば運輸局およびその他の道路安全管理局ならびに交通アプリケーション開発者に、権限を与える。システムは、特に、混雑監視、有料道路使用、ならびに走行速度および方向を用いたシグナリングのための、分析およびインターフェイスを提供することにより、正確な交通情報をリアルタイムで提供するように、構成されてもよい。

たとえば、ある実施形態において、本明細書に記載のシステムは、交通流のための新たな遠近法的かつ直感的なインターフェイスを配信するように構成されてもよい。システムは、交通量の正確な履歴画面をエンドユーザに提供し、現在の監視および測定技術だけでは必ずしも見える訳ではない交通データの基本パターンを明らかにするように構成されてもよい。これは、ユーザが、季節的な交通の傾向を理解して管理し、走行時間をモデル化し、たとえば建設プロジェクトまたはメジャースポーツまたは音楽イベント中により効率的なルート設定を計画するのにも役立つ。交通インテリジェンスは、車両の量を正確に指摘することにより、真の傾向を特定し、挙動を予測する。これは、複数種類の道路交通性能を明らかにすることで、運転者が目的地に到達するのに要する時間を短縮する。

ある実施形態において、システムは、ある期間、たとえば１ヶ月の期間にわたり所与の道路セグメントに沿って発生するすべてのデータポイントをジオフェンスするように構成されてもよい。ある実施形態において、道路セグメント化は、関心領域の周囲に多角形を描いて道路網に「スナップ」することによって選択することができる。道路セグメントが選択されると、極端な運転イベントすべてを、各イベントに関連付けられたＧＰＳトレースの緯度および経度に基づいて、プロットすることができる。このマッピングされたイベントデータを使用することにより、本明細書に記載のインターフェイスに提供することができる分析を生成することができる。

ある実施形態において、フィード出力は、マップ上に表示されたいずれかの選択された道路網について、関心イベントから導き出された交通密度図を含み得る。この出力は、期間にわたって選択することができる。たとえば、この出力は、集計図として全１ヶ月分のデータに着目することができる。また、この出力は、１日単位の内訳を１ヶ月単位でまとめたものとして示すこともできる。この出力は、１日単位の内訳を示すこともできる。イベント分析出力を見るための任意の期間を選択できることが理解されるであろう。

本明細書に示されるように、システムは、たとえば、
スピード違反イベントが道路上のどこに主として集中しているか、
速度超過が道路の速度制限の変化と相関関係があるか否か、
急ブレーキと急加速との直接的な相関関係が同一領域内で生じているか否か、および、
平日の運転者と週末の運転者との間で通勤通学挙動に変化があるか否か
を含む、運転および交通挙動を捕捉し提供するように構成されたさらに他のデータ分析を提供するように構成される。

図８は、ファーストマイル／ラストマイル接続性についてのデータ処理の、具体例としてのデータパイプラインを示すフローチャートである。図８に示されるように、本明細書に記載の通り、誤りのあるデータポイントが削除され、可視化またはインターフェイスへの出力のために処理することができるクリーンなデータが生成される。特定の地域についてのデータが特定される。たとえば小数第６位（たとえば９ｍｓｑ）まで分解された地域ロケーションデータに対してイベントデータがジオフェンスされる。道路網データベース、たとえばＵＳＧＳ米国トランジットデータセットを含むデータベースを用いて、道路網を規定することができる。ジオフェンスされたデータセット全体に対して可視化ツール９０２を用いてデータをプロットすることができる。

たとえば、図９に示されるように、フィードデータを組み合わせて統合データセットにし、インターフェイス９０２を用いて、たとえばＧＩＳ可視化ツール（たとえばＭａｐｂｏｘ、ＣＡＲＴＯ、ＡｒｃＧＩＳ、もしくはＧｏｏｇｌｅ Ｍａｐｓ ＡＰＩ）またはその他のインターフェイスを用いて、可視化することができる。ある実施形態において、コネクテッド車両（ＣＶ）インサイトおよびそのための交通プロダクトインターフェイス９０２を提供するように構成されたシステムについて、図１０～図２９Ｂのインターフェイスに示されるようにフロリダおよびニューヨークからのＣＶイベントデータの具体例としてのデータ処理に関して、以下で説明する。図１０～図２９Ｂに示される例において、インターフェイスは、たとえばエグレスサーバまたはポータルサーバを介して分析インサイトを生成するように処理されたデータの直感的可視化物を出力するように、構成することもできる。図９に示されるように、データフィードは、たとえば、トランジットデータセット９０４、トランジットスケジュール９０６、および、行程データを含むジオフェンスされたコネクテッド車両移動データ９０６等の、具体例としてのフィードを含み得る。

図１０～図２９Ｂは、各種実施形態のうちの少なくとも１つに係る、ＣＶインサイト可視化のためのグラフィカルユーザインターフェイス９０２を示す。少なくとも１つの実施形態において、ユーザインターフェイス９０２を、本開示の精神および／または範囲から逸脱することなく採用することができる。そのようなユーザインターフェイス９０２は、さまざまなやり方で配置することができる、任意の数のユーザインターフェイス要素を有し得る。いくつかの実施形態において、ユーザインターフェイスを、ウェブページ、モバイルアプリケーションなどを用いて生成してもよい。少なくとも１つの実施形態において、イングレスサーバ１００、ストリーム処理サーバ２００、エグレスサーバ４００、分析サーバ５００、またはポータルサーバ６００は、ユーザインターフェイスを生成するためのプロセスおよび／またはＡＰＩを含み得る。

以下、コネクテッド車両（ＣＶ）の行程およびデータインサイトならびにそのための交通プロダクトインターフェイス９０２を提供するように構成されたシステムの実施形態を、本明細書に記載され図１０～図２９Ｂのインターフェイス９０２に示される、具体例としてのＣＶイベントのデータ処理およびフロリダからニューヨークまでの行程データとの関連で説明する。図９に関して先に述べたように、データフィードは、トランジットデータセット９０４、トランジットスケジュール９０６、および行程データを含むジオフェンスされたコネクテッド車両の移動データ９０６等の、具体例としてのフィードを含み得る。例として、１ヶ月の期間にわたる、マイアミの北のフォートローダーデール（Fort Lauderdale）における３５０万の行程をカバーする７５，０００を超える自動車からの情報を分析した。この期間中、７，０００を超える交通事故があった。本明細書に記載の行程データ分析およびジオフェンシングをマッピングデータベースと組み合わせることにより、急ブレーキおよび事故につながる道路状態、レイアウトまたは信号系に問題がある場所およびＰＯＩを特定した。急ブレーキと事故との間には強い関連性が見出されたが、急ブレーキ発生率が高いものの衝突が起こっていない場所もいくつかあった。したがって、本明細書に記載のインターフェイスは、たとえば事故を防止するまたは事故の原因を発見するために採用することが可能な、行程から導き出される関心イベントに結び付けられる、交通領域および道路の特徴を、正確に指摘することができる。

図１０は、例として、ブロワ―ド郡（Broward County）におけるバスサービスのすべての停車場およびルートを示す。トランジットデータを読取可能なフォーマットで表示するために、先ず、このデータを全体的な画像として可視化し、次に、より詳細なコンテキストを提供するために特定のルートおよびサービスに焦点を当てた。以下の図面において、インターフェイス９０２は、バスルート９１２を白で示し、利用できるすべてのバス停車場９１４を示すことにより、調べる可能性がある関心領域をユーザが瞬時に見ることができるようにしている。

図１１は、ブロワ―ド郡内のサービス１のバスルート９１２および停車場９１４を示すインターフェイス９０２である。図１２は、ブロワ―ド郡内のサービス１９のバスルートおよび停車場を示すインターフェイスである。

図１３Ａ～図１３Ｂは、ブロワ―ド郡内のルート７２のバスルート９１２および停車場９１４を表示するインターフェイスを示す。図１３Ａ～図１３Ｂのインターフェイスは、ブロワ―ド郡内のサービス７２のバスルート９１２と、障害を持つアメリカ人法（Americans with Disabilities Act (ADA)）の規則および規定に従う停車場を含む、停車場タイプによって区分された停車場９１４とを示す。濃い停車場９１４ｂは非ＡＤＡバス停車場（車いすでアクセス不能）を示し、薄い停車場９１４ａはＡＤＡ準拠停車場を示す。図１３Ｂは、図１３Ａの一部を示し、ルート７２に沿って非ＡＤＡバス停車場９１４ｂが集中していることおよびＡＤＡ準拠バス停車場９１４ａには隔たりがある可能性があることを示す。図１３Ｃおよび図１３Ｄに示されるように、ルート７２が、利用量の多さおよび週末に営業していることが理由で、さらに分析を行うために選択された。図１３Ｃに示されるように、ルート７２のスケジュールは、月曜日から土曜日まで、行程数に対して十分な網羅率を有している。図１３Ｄに示されるように、ルート７２のスケジュールは、日曜日の行程の大部分を、営業時間のより厳しい制限のために、落としている。処理されたデータインターフェイスは、バスルートの南西領域には事実上ＡＤＡ準拠停車場がないことを示している。

図１４は、インターフェイスにおいて、バスルート上のその行程が少なくとも５分間実施されたすべてのコネクテッド車両（ＣＶ）行程を示す。ある実施形態において、システムは、ルート上の行程時間の比率を示すために１ルートごとにしきい値を設定するように構成されてもよい。たとえば、システムは、２０分のバスルート上で少なくとも１５分間実施された行程を示すように構成されてもよい。行程を分析することにより、どの車両行程が任意のポイントでルート７２を進んだかを判断した。データの正しい簡潔さを保証するために、ルート７２に沿って５分以上実施された行程のみを選択した。いくつかの行程は非常に長いことが判明した。たとえば、図１４は、地図の上部中央の行程９１５がこの地図の右下まで続くことを示している。地図の左側の別の行程９１６は、この州を横断してこの地図の右方まで進んでいる。

図１５は、図１４の一部を拡大しデータのオーバーレイとともに行程を可視化したものを示す。先に述べたように、バスルート９１４のサービス７２では、このルート上で開始と停止の双方が実施される行程がいくつかあるので、これに特に着目した。拡大後、ルート７２（地図の中心でハイライトされたルート）の上、周囲、および全体で発生する行程がいくつかあることがわかった。ファーストマイル接続性がこの行程を複数回繰り返すことができる、という仮説を立てた。

図１６は、この州の北西で開始し最終的には７２のバスルート９１４上で終了するＣＶ行程９１５を表示するインターフェイス９０２を示す。インターフェイス９０２は、行程に着目しユーザがたとえばこの州を横断する特定の行程９１５を見ることができるように構成されてもよい。これを採用することにより、行程挙動に対する、可能性のあるインサイトを導き出すことができる。たとえば、複合一貫（multi-modal）行程を、ラストマイル行程時間とこの行程の残りとの対比に着目することにより（すなわち、公共交通機関によって解決可能な行程のラストマイルを移動するにはより時間がかかるのか？）、促進することが可能である。

図１７Ａのインターフェイス９０２はコネクテッド車両行程９１７を示し、これは、その行程のおよそ９０パーセントについてルート７２をミラーリングしている。行程９１７の最終点９１７ｅは、バスルート９１４からほんのわずか離れた場所にある。ここで、インターフェイスは、バスルート９１４をこのルートの外側にある始点と終点とを除いて事実上ミラーリングしている行程９１７を示す。参考のために、行程の始まり９１７ｓ（地図インターフェイスの左側）は、この行程のより濃い部分（地図インターフェイスの右側の、行程の終点９１７ｅ）まで続いている。図１７Ｂは、ルート７２の周辺のイベントクラスタリングのインターフェイスの例を示し、これは、所与の日において行程の始点および終点がルート７２に比較的近接した場所にあることをハイライト表示している。１日単位で１ヶ月の期間にわたるすべての行程の始点および終点について示されたイベントクラスタリングは、行程の始点および終点がハイウェイＲ８１６上のハイライト表示されたバスルート９１４に沿って明らかに集中していることを示した。このことは、何故人々がこのルートに沿ったバスに乗らないのか、という疑問につながる。

図１８Ａは、ＡＤＡのアクセス可能な停車場と比較される行程始点に注目した、一例としてのヒートマップインターフェイス９０２を示す。濃いポイントは非ＡＤＡ停車場９１４ｂを示し、薄いポイントはＡＤＡ準拠停車場９１４ａを示す。このヒートマップは、図１７Ｂのイベントクラスタリングをインターフェイス９０２に表示し、これは、行程の始点が明らかに非ＡＤＡ停車場に重なっていることを示す。

図１８Ｂは、ＡＤＡのアクセス可能な停車場と比較される行程始点に注目した、別の例としてのヒートマップインターフェイス９０２を示す。太い線は鉄道ルート９１９（トリレール（Tri-Rail）ルート）を示す。このインターフェイスは、可視化されたものの右に向かって密度が高くなるが領域のうちの１つに非ＡＤＡ準拠バス停車場９１４ｂしかないことをわかりやすくしている。これは、ルートのこの特定の区間に沿ってより多くのバス停車場への投資の潜在的な必要があることを強調表示している。また、ＡＤＡ停車場の周辺に必要なインフラストラクチャが不十分である（すなわち、パークアンドライドの場合に運転者が駐車してバスに乗車する機会がほとんどない）という仮説を立てることもできる。

密度がより高い領域をより詳細に調べると、インターフェイスは、はっきりと見える２つの特定位置が存在することを示している。画像の中心の領域９２０は、非ＡＤＡ準拠バス停車場９１４ｂしかない唯一の領域である。この特定位置を調べたところ、これはショッピングセンターであることが特定された。そのため、ここを訪れる人の数からすると、より多くのＡＤＡバス停車場がなければならないと考えられる。付近には公共機関で移動する他の方法がないので、このショッピングセンターで開始される行程の高密度領域が増す可能性がある。

図１９Ａ～図１９Ｅは、行程ホットスポットからの車両の行程の傾向を示す、具体例としてのビデオヒートマップインターフェイスからの一連のスクリーンショットを示す。図１８Ｂでハイライト表示されたホットスポット領域のうちの、非ＡＤＡ準拠停車場を有する領域９２０からの行程が描かれた。ビデオインターフェイスが、６時間にわたる行程を示すように構成された。インターフェイスは、複合一貫輸送のために、この領域９２０からその後他のバスルートに沿って進む行程を繋ぎ合わせることができることを示している。

図２０Ａは、トリレールルート９２１を示すインターフェイスを示す。トリレールのスケジュールおよびルートデータを用いて、トリレール停車場およびシャトル停車場の各々を描いた。濃いポイント９２２はトリレール停車場を示し、薄いポイント９２３はシャトル停車場を示す。図２０Ａに示されるように、いくつかの場所ではシャトル停車場が不足しており、他の場所、たとえば図１８Ｂのサイプレスクリーク（Cypress Creek）停車場では過剰である。

図２０Ｂは、行程９２４が、この行程の始まり９２４ｓでわずかに迂回して、バスルート９２１と全く同じルートに沿っていることを示す。運転者がルートをミラーリングする理由をさらに調べる際に、行程データから走行時間を分析すると、自動車ではこのルートの最後まで到達するのにおよそ１時間３分を要するが、バスでは１時間５３分から２時間３３分までのいずれかの時間を要し、さらに行程の始点から最も近いバス停車場まで歩くのに３３分を要することがわかった。

図２１は、サイプレスクリーク停車場で乗車される３つのシャトルのルート９２５、９２６、９２７の詳細を示す。図２２は、トリレールシャトルルート９２５、９２６、９２７を示すとともにサイプレスクリークシャトルサービスの３つのシャトルルート９２５、９２６、９２７に対する行程の混雑レベルを詳細に示すインターフェイス９０２である。インターフェイス９０２は、行程データ内において、特定領域９２８（マグノリアパーク駅（Magnolia Park Station））の周辺に高密度の交通量があることを示す。より詳しく調べると、バスルート９２１はここで終わっており、乗客がさらに北に進むためにはバスルートを切り替える必要があることがわかった。

図２３Ａ～図２３Ｅは、マグノリアパーク駅の停車場９２８におけるいくつかの行程９３０～９３５を示す。この一連のインターフェイスは、トリレールルート９２１上のマグノリアパーク停車場９２８で最終的に終わる、実施される行程９０３～９３５の起点を示す。関心のある行程は以下の通りである。

図２３Ｄは、トリレールを介して実施することができたであろう行程９３５を明確に示している。図２３Ａ、図２３Ｃおよび図２３Ｅに示される行程９３０、９３１、９３２は、複合一貫走行の機会の例を示す。各行程９３０、９３１、９３２の最初の部分は、自動車から、バスではなく鉄道に乗り換えることが可能であったトリレールまで進んでいる。

図２４は、行程のミラーリングを示すインターフェイスである。この画像は、ＣＶが実施する、トリレール行程９２１を南から北まで完璧にミラーリングする行程９３６を詳細に示す。問題の車両は、その行程をマグノリアパーク停車場９２８の領域で終えた。ミラーリングする行程９３６から、この場合に車両からトリレールに乗車しなかった理由についての疑問が生じた。行程データの分析は、問題の車両行程９３６が、その行程を終えるのにおよそ２０分の停車を含めて合計１時間３分を要したことを示した。これと比較して、同じ行程をトリレールで実施した場合は目的地に達するまで１時間５３分と２時間３３分との間のいずれかの時間を要したであろう。

図２５は、フォートローダーデール空港のトリレール停車場に近い行程開始の数を示す。１ヶ月の期間においてトリレール停車場の近くで開始された行程は１５０を超えていた。ＣＶデータを用いて特定領域におけるトリレール広告の影響を、たとえばこの領域を起点とするＣＶ行程の数が広告後に減少したか否かを判断することによって示すという仮説を立てることができる。

トランジットデータをＣＶ行程データとともに分析すると、ＣＶデータの使用を通じて複合一貫へのシフトに影響を与えるようにシステムを構成することが可能であることは明らかである。複合一貫輸送へのシフトの機会に寄与するいくつかの行程および挙動がある。複合一貫輸送へのシフトに影響を与えるためには、通勤通学時間が長くなることを意味しないトリレールまたはバスルートのいずれかを運転者が採用するようにするための、強制力のある議論が必要である。

図２６Ａは、フロリダターンパイク（有料道路）に沿った急ブレーキイベントを可視化したものを表示するインターフェイス９０２を示す。濃い円９３７は集中発生した急ブレーキイベントを表し、薄い円９３８は急加速イベントを表す。図２６Ｂは、ヒートマッピングされたスピード違反イベント９３９を表示するインターフェイス９０２を示す。図２６Ａの可視化を図２６Ｂのスピード違反の可視化と結合することにより、潜在的にリスクのある領域および事故のホットスポットをフロリダターンパイクに沿ってハイライト表示している。インターフェイス９０２は、ブレーキイベントおよび加速イベントがこの道路区間に沿った交差点に集中していることを示す。

ニューヨーク市は、世界では３番目に交通が混雑している都市であり、米国では、世界で最も混雑しているロサンゼルスに続いて２番目に混雑している都市である。２０１７年のニューヨーク市の運転者の平均混雑時間は９１時間であり、２番目のモスクワと互角である。ニューヨーク市の運転者は彼らの時間の１３％を渋滞で過ごし、そのうち１１％は日中の交通で生じている。

図２７Ａ～図２７Ｃは、粒状性を考慮して３区間に分割されたブロンクスクイーンズ高速道路（ＢＯＥ：Bronx Queens Expressway）を可視化したものを含むインターフェイス９０２を示す。薄い網掛け９３９（インターフェイス上で緑色）は低速移動交通を表し、スケールはより濃い網掛け９４０（インターフェイス上で濃い青色）に移ってより高い速度を示す。このように、インターフェイス９０２は、ＢＱＥに沿っていくつかの潜在的な混雑ポイントを示すように構成され、通勤通学ルートからの交通渋滞または一般的な都市の混雑があり得ることを示している。道路工事または建設区間も低速移動交通の原因になり得る。

図２８は、集中した急ブレーキおよび加速イベントを示すＢＱＥのインターフェイス可視化を示し、濃い円９３７は集中した急ブレーキイベントを示し、薄い円９３８は急加速イベントを示す。分析およびインターフェイスは、道路の曲がり角での発生数が多いことを示しており、これは、図２７Ａ～図２７Ｃの速度ヒートマップと一致する。

図２９Ａ～図２９Ｂは、図２８の急ブレーキイベント９３７を、事故ホットスポットデータのセットからなる事故ヒートマップ９４０に重ねたものを可視化したインターフェイス９０２を示す。図２９Ａ～図２９Ｂは、２つの事例間の直接的な相関関係を構築する。また、インターフェイス９０２は、急加速イベント９３８と事故ホットスポットデータのヒートマップ９４０との間の同じ相関関係を示す（図２９Ｂ）。このように、システムは、行程および関心イベントアルゴリズムから導き出された事故に結び付けられる一般的な交通挙動を確認する直感的なインターフェイスを特定し提供するように構成されている。

ある実施形態において、データを、さらに他の発見のために、ＰＯＩデータベースからのＰＯＩデータで強化してもよい。たとえば、ある実施形態において、先に述べたように、行程データがクラスタリングされ、スポーツイベントおよび音楽コンサートで階層化された。ローリングストーンズがコンサートで演奏した日は、車両によるニューアーク・リバティー国際空港までの行程が、平均で１５分長くかかることがわかった。ファンは、コンサートまたはＮＦＬの試合から、１０分だけ早く退出することにより、ローカル交通の混雑の最悪の事態を回避することができる。したがって、システムは、行程を特定し、イベント分析を実行し、ＰＯＩを特定し、混雑を回避するためにはいつ乗車するのが最適かをユーザに警告するように構成されてもよい。

フローチャート図の各ブロック、およびフローチャート図のブロックの組み合わせは、コンピュータプログラム命令によって実現できることが理解されるであろう。これらのプログラム命令をプロセッサに与えてマシンを生成し、プロセッサ上で実行される命令が１つ以上のフローチャートブロックで指定されたアクションを実現するための手段を生成するようにしてもよい。コンピュータプログラム命令をプロセッサが実行することにより、一連の動作ステップをプロセッサに実行させて、コンピュータで実装されるプロセスを生成し、プロセッサ上で実行される命令が、１つ以上のフローチャートブロックで指定されたアクションを実現するためのステップを提供するように、することができる。また、コンピュータプログラム命令は、フローチャートのブロックに示された動作ステップのうちの少なくともいくつかを並行して実行させることもできる。さらに、ステップのいくつかは、マルチプロセッサコンピュータシステムまたは複数のコンピュータシステムからなるグループでのように、２つ以上のプロセッサにまたがって実行することもできる。加えて、フローチャート図における１つ以上のブロックもしくはブロックの組み合わせは、本開示の範囲または精神から逸脱することなく、他のブロックもしくはブロックの組み合わせと同時に、または図示の順序とは異なる順序でさえ実行することもできる。

したがって、フローチャート図のブロックは、指定されたアクションを実行するための組み合わせ、指定されたアクションを実行するためのステップの組み合わせ、および指定されたアクションを実行するためのプログラム命令手段をサポートする。また、フローチャート図の各ブロック、およびフローチャート図のブロックの組み合わせは、指定されたアクションまたはステップを実行する専用ハードウェアベースのシステム、または専用ハードウェアおよびコンピュータ命令の組み合わせによって実現されてもよいことも理解されるであろう。上記例は、限定的および／または網羅的な例と解釈されてはならず、むしろ、さまざまな実施形態のうちの少なくとも１つの実装形態を示す例示のためのユースケースである。

Claims (17)

1. プログラム命令を含むメモリと、方法のための前記命令を実行するように構成されたプロセッサとを備えるシステムであって、前記方法は、
   車両についてのロケーションイベントデータをストリーム処理サーバまたは分析プロセッササーバに取り込むステップを含み、前記ロケーションイベントデータは車両についての時間および位置（緯度／経度）を含み、前記方法はさらに、
   前記ストリーム処理サーバまたは前記分析プロセッササーバのいずれかにおいて、前記ロケーションイベントデータから複数の車両行程を特定するステップを含み、前記車両行程を特定するステップは、各行程ごとに、所与の車両の移動が前記行程の行程セグメントであるか否かを特定することを含み、前記方法はさらに、
   ある期間にわたるジオフェンスされた領域についての前記ロケーションイベントデータに対して関心イベントアルゴリズムを実行するステップを含み、前記関心イベントは、急ブレーキイベント、急減速イベント、急加速イベント、およびスピード違反イベントからなる群より選択され、前記方法はさらに、
   前記関心イベントアルゴリズムからの関心イベント出力を可視化するように構成されたマッピング可視化インターフェイスにフィードを提供するステップを含む、システム。
2. 前記プロセッサは、前記イベントデータにおけるロケーションデータを近接度に符号化することをさらに含む前記方法のための前記命令を実行するように構成され、前記符号化することは、各イベントの緯度および経度を各イベントの近接度にジオハッシュすることを含む、請求項１に記載のシステム。
3. 前記イベントデータにおけるロケーションデータを近接度に符号化するための前記方法のための前記命令はさらに、
   緯度および経度を、前記近接度を定める形状にジオハッシュすること、
   前記ジオハッシュを符号化して州を特定すること、
   前記ジオハッシュを符号化してジップコードを特定すること、および
   前記ジオハッシュを精度に符号化して車両を一意に特定すること、
   のうちの少なくとも１つを含む、請求項２に記載のシステム。
4. 前記イベントデータにおけるロケーションデータを前記近接度を定める形状に符号化することは、前記緯度および経度を、そのエッジがストリング内の文字に比例する多角形にジオハッシュすることを含む、請求項３に記載のシステム。
5. 前記プロセッサは、前記マッピング可視化インターフェイスに出力するために、前記ジオハッシュをマップデータベースにマッピングすることをさらに含む前記方法のための前記命令を実行するように構成されている、請求項３に記載のシステム。
6. 前記マッピングすることは、前記ジオハッシュを関心ポイントデータベースにマッピングすることをさらに含む、請求項５に記載のシステム。
7. 前記行程を特定するステップは、
   前記車両のエンジンオンまたは移動開始を特定することと、
   前記車両のエンジンオフまたは移動停止を特定することと、
   前記車両の滞留時間を特定することと、
   前記車両の最短走行距離を特定することと、
   最短走行継続時間を特定することとを含む、請求項１に記載のシステム。
8. 前記プロセッサは、最短走行継続時間基準で構成され、前記最短走行継続時間基準を用いて前記車両の最短走行継続時間を特定するための命令を実行するように構成されている、請求項７に記載のシステム。
9. 前記プロセッサは、最長滞留時間基準で構成され、前記最長滞留時間基準を用いて前記車両の最長滞留時間を特定するための命令を実行するように構成されている、請求項８に記載のシステム。
10. 前記プロセッサは、最短走行距離基準で構成され、前記最短走行距離基準を用いて前記車両の最短走行距離を特定するための命令を実行するように構成されている、請求項９に記載のシステム。
11. 前記システムは、コネクテッドコンポーネントアルゴリズムを用いて、ある期間にわたる複数のイベントから車両経路を特定することにより能動的車両検出を提供するように構成されている、請求項１に記載のシステム。
12. 前記期間の前記ジオフェンスされた領域における前記関心イベントのイベントをクラスタリングするためのクラスタリングアルゴリズムをさらに含む、請求項１に記載のシステム。
13. 前記クラスタリングアルゴリズムは、前記急ブレーキイベント、前記急減速イベント、前記急加速、および前記スピード違反イベントからなる群より選択された前記関心イベントをクラスタリングするように構成されている、請求項１２に記載のシステム。
14. 前記関心イベントクラスタリングアルゴリズムを含む混雑検出アルゴリズムをさらに含む、請求項１３に記載のシステム。
15. 前記システムは、前記マッピング可視化インターフェイス上に、前記期間における前記ジオフェンスされた領域についての異なる関心イベントクラスタのオーバーレイを表示するように構成されている、請求項１４に記載のシステム。
16. 前記システムは、前記マッピング可視化インターフェイス上に、前記期間における前記ジオフェンスされた領域についての異なる関心イベントアルゴリズム出力のオーバーレイを表示するように構成されている、請求項１に記載のシステム。
17. 前記システムは、前記マッピング可視化インターフェイス上に、前記期間における前記ジオフェンスされた領域についての関心イベントアルゴリズム出力とともに行程のオーバーレイを表示するように構成されている、請求項１に記載のシステム。

Images