JP2023500524A - 道路セグメントの低レイテンシ速度分析のために車両イベントデータを処理するためのシステムおよび方法 - Google Patents

Abstract

実施形態は、複数の道路セグメントを含む道路回廊を通して車両を追跡するために車両イベントを低レイテンシ処理するためのシステムおよび方法に向けられている。

Description

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

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

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

開示の概要
以下、本明細書に記載のイノベーションのいくつかの側面の基本的理解が得られるよう、実施形態を簡単に説明する。この簡単な説明は、広範囲にわたる概要を意図しているのではない。重要または不可欠な要素を特定することを意図している訳でも、範囲を明確にするかそうでなければ狭くすることを意図している訳でもない。その目的は、後に示すより詳細な説明の前置きとしていくつかの概念を簡単な形で示すことにすぎない。本明細書に記載のシステムおよび方法の、具体例としての利点は、最適化された低レイテンシである。たとえば、本開示に記載のシステムおよび方法は、最大１２００万台の車両について毎秒最大少なくとも６００，０００のレコードを取り込んで処理することができる。

少なくとも１つの実施形態において、プログラム命令を含むメモリと、方法のための命令を実行するように構成されたプロセッサとを備えるシステムについて説明し、この方法は、
少なくとも３つの連続セグメントを含む道路回廊を生成するステップと、
車両イベントデータを取り込むステップと、
車両イベントデータを用いて、道路回廊の連続セグメントのうちの１つ以上の連続セグメントを通して車両を追跡するステップと、
車両が横断する１つ以上の連続セグメントの各々について、車両イベントデータから導出した車両移動データを含むセグメントイベントレコードを生成するステップと、
セグメントイベントレコードの生成後に車両イベントデータを削除するステップとを含む。

ある実施形態において、プロセッサは、以下のステップを含む、セグメントイベントレコードを生成する方法のための命令を実行するように構成されてもよく、上記ステップは
ａ）車両イベントデータから、第１の道路セグメントに入った車両の認定データポイントを特定するステップと、
ｂ）第２の連続道路セグメントにおける横断開始データポイントを特定するステップと、
ｃ）第２のセグメントにおける複数のデータポイントを追跡するステップと、
ｄ）第３の連続道路セグメントにおける第１のデータポイントを、第２の道路セグメントについてのセグメントイベント計算トリガデータポイントとして特定するステップと、
ｅ）第２のセグメントの複数のデータポイントに基づいて、第２の道路セグメントについてセグメントイベントレコードを生成するステップとを含む。プロセッサは、道路回廊の１つ以上の後続の道路セグメントの各々についてステップ（ａ）～（ｅ）を繰り返すステップをさらに含む、方法のための命令を実行するように構成されてもよく、先行する道路セグメントについてのセグメントイベント計算トリガデータポイントは、後続の道路セグメントの認定データポイントとして機能する。

ある実施形態において、セグメントイベントレコードの車両移動データは、車両の速度データを含み得る。プロセッサは、車両が速度しきい値を上回ったことを車両イベントデータが示す、すべてのデータポイントについて、スピードカウントを増分することをさらに含む方法のための命令を、実行するように構成されてもよい。

ある実施形態において、セグメントイベントレコードの車両移動データは、車両の横断時間を含み得る。プロセッサは、セグメントイベントレコードについて、セグメントを通る横断時間を計算するステップをさらに含む、方法のための命令を実行するように構成されてもよい。横断時間を計算するステップは、横断開始データポイントの、捕捉されたタイムスタンプを、計算トリガデータポイントの、捕捉されたタイムスタンプから減算することを含み得る。

ある実施形態において、セグメントイベントレコードを生成するステップは、セグメントイベントレコードについて、セグメントを通る車両の平均速度を計算することを含む。平均速度は、横断時間を取得しセグメント距離を横断時間で除算することによって計算してもよい。

ある実施形態において、システムは、例外基準が満たされた場合に、車両の車両イベントデータの追跡を停止するように構成されてもよい。例外基準は、システムが追跡される車両について車両イベントデータを受け取っていない予め定められた量の時間、追跡される車両が前のセグメントに戻ること、および、車両エンジンオン／オフイベントからなる群より選択される例外基準を含み得る。

ある実施形態において、システムは、エグレスサーバでセグメントイベントを生成し、エグレスサーバのエグレスインターフェイスを介して、生成したセグメントイベントレコードを出力するように、構成されてもよい。

ある実施形態において、プログラム命令を含むメモリと、方法のための命令を実行するように構成されたプロセッサとを備えるシステムについて説明し、この方法は、
ロケーションイベントデータをサーバに取り込むステップと、
ロケーションイベントデータをサーバで処理することにより、道路セグメントを特定するステップとを含み、
処理するステップは、
道路セグメントを特定するステップと、
車両イベントデータを追跡することにより、複数の車両の各々について、道路セグメント内の複数の車両イベントデータポイントの位置を特定するステップと、
複数の車両の各々の速度を計算するステップと、
各車両の平均速度を、道路セグメントを通る複数の車両の各々の速度の算術平均によって計算するステップと、
平均車両速度の調和平均速度および道路セグメントの車両カウントを計算するステップと、
セグメントの長さＬを調和平均速度で除算することにより、道路セグメントの通過時間を得るステップと、
セグメントの通過時間をダウンストリームインターフェイスに出力するステップとを含む。

上記処理を実行するサーバは、イングレスサーバ、エグレスサーバ、分析サーバ、またはその組み合わせであってもよい。

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

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

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

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

各種実施形態のうちの少なくとも１つを実現することができる環境のシステム図である。 各種実施形態のうちの少なくとも１つに係るクラウドコンピューティングアーキテクチャを示す図である。 各種実施形態のうちの少なくとも１つに係るクラウドコンピューティングプラットフォームの論理アーキテクチャを示す図である。 各種実施形態のうちの少なくとも１つに係るイングレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るストリーム処理サーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るエグレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るエグレスサーバシステムのフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係る複数の道路セグメントを含む道路回廊の論理的レイアウトを示す図である。 各種実施形態のうちの少なくとも１つに係る複数の道路セグメントを含む道路回廊の論理的レイアウトを示す図である。 各種実施形態のうちの少なくとも１つに係る複数のセグメントを含む道路回廊を通して車両を追跡するためのシステムフローのある実施形態を示す図である。 各種実施形態のうちの少なくとも１つに係る分析サーバシステムのプロセスの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るポータルサーバシステムのプロセスの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに係るシステムのデータ処理チェックのデータ品質パイプラインを示すフローチャートの図である。 各種実施形態のうちの少なくとも１つに係るインターフェイスにフィードをエグレスするためのフローチャートおよびインターフェイスの図である。 車両イベント移動データポイントから正確な道路速度を求めるためのシステムフローのある実施形態を示す図である。

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

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

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

本明細書で使用される「ホスト」という用語は、１つ以上のデジタルメディアプロパティ（たとえばウェブサイト、モバイルアプリケーションなど）を所有または操作することができる、個々の人物、共同事業、組織、または企業体を意味する場合がある。ホストは、デジタルメディアプロパティをウィジェットコントローラまたはサーバと統合するように構成することにより、デジタルメディアプロパティをハイパーローカルターゲティングを使用するように構成することができる。

以下、車両イベントデータを処理するためのシステム、方法およびコンピュータプログラムプロダクトの各種実施形態について簡単に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本開示はクラウドコンピューティングプラットフォーム上での実施形態を説明するが、本明細書に記載の実施形態の実装は、クラウドコンピューティング環境に限定されない。

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

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

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

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

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

ある実施形態において、システム１０は、車両位置をより高い精度で検出しマッピングするように構成される。道路網に関して有用な総計を収集するために、たとえば１日／１週間周期の予想交通量および速度を収集するために、システム１０を、所与の道路網を通して車両がどのように移動しているかを判断するように構成してもよい。本明細書に記載されているように、各データポイントを最も近い道路区間に関連付けるまたは「スナップする」という単純な手法は失敗する可能性があり、その理由は、車両のＧＰＳデータがさまざまな周知の物理的効果に起因する固有の程度の誤差を有することにある。さらに、道路網は、複雑な形状で互いに近付いて交差することが多く、結果として複数の道路スナップ候補が存在するロケーションになる。

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

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

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

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

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

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

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

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

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

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

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

マップデータベースは、たとえばパブリックまたはプロプライエタリマップデータベースを含む、関心ポイントのデータベースまたは他のマップデータベースとすることができる。具体例としてのマップデータベースは、ローカルストリートマップ用のジオファブリック（Ｇｅｏｆａｂｒｉｃ）またはワールドマップデータベース等の現存ストリートマップデータを含み得る。システムはさらに、本明細書に記載の、外部マッピングインターフェイス、ナビゲーションインターフェイス、トラフィックインターフェイス、およびコネクテッド車両インターフェイスにデータをエグレスするように構成されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ある実施形態において、データは本明細書に記載されているように処理することができる。たとえば、未集約データをデータベース（たとえばＰａｒｑｕｅｔ）に格納し時間で分割してもよい。データをストリーム内で検証しその後ストリーム内で逆ジオコーディングしてもよい。たとえば車両の種類によるデータ強化（data enrichment）をストリーム内で実行してもよい。車両イベントデータを、たとえば地域、行程、および日付で集約してもよい。データはＰａｒｑｕｅｔで保存することができ、Ｐｏｓｔｇｒｅｓで保存することもできる。基準データを、ストリーム内でのマージのためにＰａｒｑｕｅｔで適用してもよい。他の基準データを空間属性のためにＰｏｓｔｇｒｅｓで適用してもよい。

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

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

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

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

ある実施形態において、エグレスサーバ４００は、低レイテンシリアルタイムスループットを維持および改善するように構成された低レイテンシアルゴリズムでデータを処理するように、構成することができる。このアルゴリズムは、計算リソースを妨害しないまたは作動不能にしない、ターゲティングされたリアルタイムデータを必要とする、ダウンストリームインターフェイスをポピュレートすることが可能な、低レイテンシファイル出力のために、データを処理するように構成することができる。ある実施形態において、システム１０は、ストリーム処理サーバ２００からのライブ車両移動データストリームから事実上リアルタイムで出力されるよう、道路セグメントの低レイテンシ平均道路速度データを提供するように構成される。エグレスサーバ４００を、生データを順番に削除し軽量のデータパッケージをパートナー２０に提供するように構成し、たとえばプッシュサーバを介してダウンストリームインターフェイスのために構成することもできる。

図４Ｂに示されるように、ある実施形態において、ブロック４０８で、エグレスサーバ４００は、本明細書に記載の連続多角形のセットによって定められる、対象の道路セグメントと、入口および出口セグメントとを含む、道路回廊を用いて構成される。システムはまた、各セグメントごとに速度しきい値を含む。ブロック４１０において、システムは、高スループットのリアルタイム車両移動イベントデータを取り込むように構成され、このデータは、イングレスサーバ１００によってイングレスされストリーム処理サーバ３００によって処理された標準トリップイベントデータを含み、これは、デバイスＩＤ、緯度／経度、点火状態、速度、およびタイムスタンプ等のデータを含む。

ある実施形態において、ブロック４１２で、システムは、図４Ｂ～図４Ｅに関して本明細書で説明するように、車両のデータポイントを追跡するように構成される。システムは、車両ごとに、車両移動イベントデータストリームから、車両ごとの道路セグメント横断時間、車両ごとの道路セグメント通過平均速度、および、車両について道路セグメントの速度しきい値を上回るデータポイントを受けた回数を、提供するように構成される。ある実施形態において、車両から捕捉されるデータポイント間の間隔は、たとえば１～３秒であってもよい。

図４Ｃ～図４Ｄは、複数の道路セグメントを含む道路回廊の論理的レイアウトを示す図である。道路回廊は、交通を監視する道路の一部である。ある実施形態において、道路セグメントは、所与の道路区間の周りに描いた多角形によって画定することができる。多角形は、この区間の周りに２次元形状を構成する３つ以上のポイントとして定めることができる。本明細書で使用されるデータポイントは、緯度および経度で表されるポイントならびにそのポイントについての車両イベントデータを意味する。道路回廊は、対象道路セグメントの数（ｎ）、と、追加の入口セグメントおよび出口セグメントとを含む。したがって、道路回廊は、少なくとも３つのセグメントを含む一連の連続道路セグメントである。以下で説明するように、少なくとも３つの連続セグメントを用いて、所与のセグメントを車両が横断するときのこのセグメントについての車両データを取得する。

図４Ｃ～図４Ｄを参照して示され説明される例において、道路セグメントの各々は、道路の中心でドライブされる場合、１５３１．０６ヤードである。道路回廊は１１のセグメントを含み、道路回廊（全セグメント）の全長は１６８４１．６６ヤードまたは約９．５７マイルである。しかしながら、この回廊は、３つ以上の道路セグメントまたはそれよりも多い任意の数のセグメントを含むことができ、道路回廊のセグメントは可変長となるように定めることができる。

各道路セグメントは速度しきい値を含む。速度しきい値はセグメントごとに定められるので、各セグメントは異なる速度しきい値を有し得る。速度しきい値は、車速がしきい値を上回るデータポイントをカウントするためのしきい値として構成される。速度しきい値は、たとえば、セグメントが対応する道路の、規定された速度制限に対応するように定めることができるが、そのように定められる必要はない。速度しきい値は、任意の速度に対して設定することができ、したがって、任意の目的で速度データを捕捉するために定められる。

システムは、車両イベントデータから、複数のデータポイントを監視することによって車両のセグメント横断について計算するように構成される。セグメント横断は、車両が道路セグメントを一端から他端まで完全に通過する場合のことである。

ある実施形態において、図４Ｄに示されるように、ポイントＡにおいて、システムは、車両がセグメント１内で最初に識別されたときに、特定のデバイスＩＤについて車両イベントデータを記録する。ポイントＢは、横断開始データポイントであり、ポイントＡで最初に識別された車両が横断してセグメント２に入っている。したがって、ポイントＡにおけるイベントデータは、システムが、ポイントＢにおいて、セグメント１からセグメント２へと境界を横切るものとして車両を認定することを可能にする認定ポイントである。ポイントＢにおいて、システムは、この車両の車両状態を確立する。車両が境界を横切ってセグメント２に入ったことをシステムが確認すると、ポイントＢが計算の開始ポイントとして使用される。

車両速度が速度しきい値と交差する任意のポイントにおいて、システムは、そのポイントについて車両のスピードカウントを増分するように構成される。図４Ｄに示されるように、ポイントＣにおいて、車両はまだセグメント２内に存在し、速度しきい値を上回る。システムは、その車両についてスピードカウントを１に増分する。ポイントＤにおいて、システムは、車両がまだセグメント２内に存在し、加速していないことを記録する。ポイントＥにおいて、システムは、車両がまだセグメント２内に存在し、速度しきい値と再び交差すると記録する。システムは、車両のスピードカウントを２に増分する。ポイントＦにおいて、システムは、車両がセグメント２から出てセグメント３に入ったことを識別する。ポイントＥは、セグメント３の認定データポイントでもある。よって、システムは、車両がセグメント２のセグメント横断を完了したことを識別する。このように、ポイントＦは、セグメント２についての計算をトリガするためのトリガポイントとして作用する。

計算トリガデータポイントＦにおいて、システムは次に、セグメント２のセグメントイベントレコードのデータを計算する。セグメントイベントレコードは、セグメント２の横断時間および平均速度を含む。横断時間は、セグメントの横断に要する時間の量である。横断時間は、道路セグメントの外に出た第１のデータポイントの捕捉されたタイムスタンプからこの道路セグメントの内側の第１のデータポイントの捕捉されたタイムスタンプをマイナスした、ミリ秒単位の時間である。たとえば、図４Ｄにおいて、セグメント２の横断時間は、ポイントＦ（道路セグメント２の外に出た第１のデータポイント）におけるタイムスタンプからポイントＢ（道路セグメント２の内側の第１のデータポイント）における横断のタイムスタンプをマイナスしたものとして計算される。

平均速度は、セグメント距離を横断時間で割ったものである。平均速度を乗算して所望の大きさを得てもよい。車両移動データポイントの所与の捕捉レート（たとえば３秒）に対し、駆動される正確な距離は、レコードによって変動し、セグメントの平均速度を計算するときには固定距離を使用することができる。たとえば、５０ＭＰＨでは、車両は３秒で約７３．３ヤード走行する。図４Ｃ～図４Ｄに示す例において、セグメント距離１５３１．０６ヤードは（横断時間に３６０００００を乗じたもの）で除算され、１７６０で除算されて、２小数点以下までの正確なＭＰＨで平均速度が得られる。

図４Ｄに示されるセグメントイベントレコードの作業例は以下の通りである。１２：００：００．３４２で、前のセグメント（セグメント１）で見られた車両は道路セグメントに入る。車両は、次の道路セグメント（セグメント２）において、１２：０１：３０．３４２で見られたと識別される。横断時間は、１２：０１：３０．３４２－１２：００：００．３４２＝９００００ミリ秒である。平均速度は（（１５３１．０６／９００００）＊３６０００００）／１７６０＝３４．８０ＭＰＨである。システムはまた、２のスピードカウントを含むセグメント２のセグメントイベントレコードを生成する。

図４Ｂを再び参照して、ブロック４１４において、車両が、あるセグメント全体を（前のセグメントから入り、次のセグメントに出ることによって）終了するたびに、セグメントイベントレコードが生成される。セグメントイベントレコードは、システムがセグメントイベントを生成した個々のデータポイントに対して内部的に監査することを可能にする固有のＩＤであるデータポイントＩＤを含む。したがって、各セグメントイベントレコードは、セグメントレコードを一意に識別するためのデータポイントＩＤを有する。セグメントイベントレコードはまた、セグメントの固有ＩＤであるセグメントＩＤを含む。セグメントイベントレコードはまた、ミリ秒単位の、セグメントを横断するのに要する時間である横断時間と、ＭＰＨ単位の、セグメントを通過する平均速度である平均速度とを含む。最後に、セグメントイベントレコードは、車両がセグメントを通じて速度しきい値を上回った回数である、速度しきい値超過カウントを含む。ある実施形態において、セグメントイベントレコードは、ＪＳＯＮフォーマットで生成されてもよい。ブロック４１８において、各セグメントイベントレコードが生成され、セグメントごとに送信および分割される。ある実施形態において、送信されたファイルは、ペイロードアレイ内に１つ以上のセグメントイベントレコードを含み得る。ある実施形態において、セグメントを通過する車両がない場合、ファイルは生成されない。セグメントイベントレコードの具体例としての論理ペイロードが表６に示される。

図４Ｃに示されるように、（たとえばセグメント２について）セグメントイベントレコードが計算された後に道路回廊が別のセグメント（たとえばセグメント３）を有する場合、ポイントＦは、ポイントＥによって認定される、そのセグメントについての横断開始データポイントでもある。したがって、システムは、別のセグメントイベントレコードを生成するために車両状態を追跡するように構成されるが、セグメントイベントレコードの生成後に、前のセグメント（セグメント２）を計算するために使用された生データを破棄することができる。このプロセスは、車両が道路回廊のいずれかのセグメントから出るまで、または以下で説明する例外基準の１つを満たすまで、連続するセグメントごとに繰り返される。

図４Ｂに示されるように、ある実施形態において、システムは、ブロック４１８で、車両状態が確立されスピードカウントおよびタイムスタンプがセグメントイベントレコードに記録された後に、データポイントについての車両移動イベントデータを削除するように構成される。図４Ｃに示されるように、車両がポイントＡで認定された後にシステムがポイントＢで車両の状態を確立すると、システムは、データポイントＩＤを使用して、セグメントを通して車両を追跡する。各ポイントが識別され、その速度カウントが計算されるので、システムはもはやそのポイントの生イベントデータを保持する必要がない。したがって、セグメントイベントレコードが作成されると、エグレスサーバ４００は生データを削除してシステムのレイテンシを改善するように構成される。

本明細書で説明するように、低レイテンシはシステムの重要な技術的特徴なので、改善されたレイテンシは、セグメントイベントをエグレスするために使用されるアルゴリズムおよびセグメントイベントレコードコンテナの設計および実装にとって偶然ではない。さらに、軽量セグメントイベントレコードコンテナは、ダウンストリームコンソール、たとえば交通管理コンソールが機能することを可能にする。たとえば、図４Ｂのブロック４１６において、セグメントイベントレコードは、プッシュサーバから外部パートナー２０にリアルタイムで送信することができる。たとえば、ある実施形態において、セグメントレコードは、プッシュサーバから、ＡＷＳ Ｓ３バケット、ウェブソケット、またはＡＰＩ等のインターフェイスに送られるように構成されてもよい。ある実施形態において、セグメントイベントレコードは、インサイト処理のために分析サーバ５００に送信され、ＡＰＩまたは他のインターフェイスのためにポータルサーバ６００に出力されてもよい。したがって、ブロック４１８において、システムは、システム自体のレイテンシならびにダウンストリームインターフェイスおよびコンソールの操作性の両方を改善するために、エグレスサーバ４００で使用される生データを破棄するように構成されてもよい。

上記例に示されるように、少なくとも３つの連続セグメントを用いて、所与のセグメントの平均速度を計算する。図４Ｅは、初期の入口セグメントおよび出口セグメントを含む複数のセグメントを含む道路回廊を通して車両を追跡するためのシステムフローの実施形態を示す。ブロック４３０において、第１のセグメントは、車両がシステムによって最初に識別されるときに車両を認定する。車両が最初に識別されるセグメントでは、車両が横断境界でセグメントに入ったか否か判断することができない。ブロック４３２において、車両が第２のセグメント内にあるとシステムが識別すると、システムは、第１のセグメント内に出現した車両が第１のセグメントと第２のセグメントとの間の境界を横切ったことを確認する。次に車両状態が確立されセグメントを通して追跡される。ブロック４３４において、車両は、第２のセグメントから第３のセグメントに入ると追跡され、システムは、車両が第２のセグメント全体を横断したことを確認する。ブロック４３５において、システムは、本明細書に記載のセグメントイベントレコードのデータを算出し、セグメントイベントを作成する。ステップ４３６において、このプロセスは、車両が道路回廊から出るかまたは道路回廊内の所与のセグメントから出るときのブロック４３８まで、道路回廊の各連続セグメントについて繰り返される。車両が道路回廊の外側にある場合、ブロック５４０において、車両追跡は終了する。

ある実施形態において、システムは、いくつかの例外について車両追跡を終了するように構成される。ブロック４３１に示されるように、ある実施形態では、システムは、システムが３０分以内にその車両のデータポイントを受信していない場合、車両イベントデータの追跡を停止するように構成される。この場合、システムはブロック４４０に進み、その車両を追跡することを停止する。

ブロック４３３において、システムはまた、前のセグメントに戻る（すなわちＵターン）車両を削除または無視するように構成される。この場合、システムはブロック４４０に進み、その車両を追跡することを停止する。

ある実施形態では、ブロック４３７およびブロック４３９において、イベントデータがエンジンオンまたはエンジンオフイベントを含む場合、そのセグメントの道路セグメントデータは削除される。エンジンオン／オフイベントの存在は、車両がセグメントで停止したときに接続性が失われたことを示す。この場合、システムは再びブロック４４０に進み、その車両を追跡することを停止する。

理解されるように、システム１０は、低レイテンシで極めて正確なインサイトを提供し、車両の変動および起こり得る偏りを考慮することができ、加えて、エッジケースが偏りを導入しないことを保証する。エッジケースは、遅いまたはアウトオブオーダーデータ、多車線州間に起因する速度の広範な変動、および結果をスキューする小型車両を、含む。

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

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

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

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

ブロック５１０において、少なくとも１つの実施形態では、分析サーバシステム５００は、イベントデータの行程セグメント分析を実行することができる。ブロック５１２において、分析サーバ５００は、イベント情報から行程を認定するための計算を実行するように構成される。少なくとも１つの実施形態では、ブロック５１４において、システムは、車両イベントデータのデータベースを分析し、開始時間、終了時間、開始ロケーション、終了ロケーション、データポイントカウント、平均間隔等の属性を有する行程オブジェクトへのポイントの行程の要約を分析することにより、能動的車両検出を提供するように構成される。ある実施形態において、行程オブジェクトを処理のために別のデータテーブルに入れてもよい。

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

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

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

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

ある実施形態において、地理空間インデックス行を、格納されたウェアハウス５１７のデータに追加して、たとえば、ジオハッシュされたデータに対するハイパーローカルターゲティングまたはアドホッククエリの高速化を実行することができる。たとえば、４桁または文字に分解されたロケーションデータは、２０メートル以下の分解能に相当し得る。分析サーバ５００を、検証済み処理のためのフィールドを新たに識別しラベル付けするために、認識されていないフィールドを有する無効データのデータベース上で分析を実行するように構成された診断機械学習で構成することができる。

ある実施形態において、システム１０は、車両イベントデータを処理することにより、向上したインサイトおよび効率的な処理を提供するように、構成することができる。イベントデータを処理するための、具体例としてのプロセスおよびシステムは、
データポイントを道路にスナップするためのグラフローカル検索およびカスタムメトリックを用いるＲツリーにおけるＫ近傍、
関心ポイントに関連する駐車エリアを発見するためのカスタムメトリックを用いるＤＢＳＣＡＮ、
Ｎａｔｉｏｎａｌ Ｈｏｕｓｅｈｏｌｄ Ｔｒａｖｅｌ Ｓｕｒｖｅｙデータ上で構築されたものから修正された分類器を用いる行程目的の分類のためのＸＧＢｏｏｓｔ、
ストリートアドレスマッチングのためのＬｅｖｅｎｓｈｔｅｉｎおよびＳｏｕｎｄｅｘ、
交通量時系列予測のためのＡＲＩＭＡ、
道路共依存の判断のための相互相関および動的タイムワーピング、
データポイントボリューム予測のためのＦａｃｅｂｏｏｋ（登録商標） Ｐｒｏｐｈｅｔ、
交通渋滞状態を識別するためのガウス混合モデル、および
異常検出制御チャートのためのＸｍＲを、含む。

分析サーバシステム５００は、上記のイングレスサーバシステム１００に関して説明したように、道路スナップを実行するように構成することができる。上述のアルゴリズムは、好都合にはスナップのために個々のポイントを使用することができ、各データポイントを道路形状と比較することによって各データポイントからできるだけ多くの情報を抽出することができる。データポイントはまた、集約されたデータから形成された統計と比較されてもよい。ある実施形態において、スナップアルゴリズムは、イングレスサーバにおいて実現され、とりわけ、実質的にリアルタイムの低レイテンシフィードにおける利点を提供する。ある実施形態において、スナップアルゴリズムはまた、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、または分析サーバシステム５００において提供されてもよい。ある実施形態において、システム１０はさらに、本明細書に記載のようにイベントデータをマップデータベースにマッピングするように構成されてもよい。

ある実施形態において、ベースマップは、線分の集合として与えられる。システム１０は、たとえば、本明細書に記載のＲツリーインデックスを用いて、道路セグメントの線分の集合として与えられるベースマップを含むように構成されてもよい。本明細書に開示されるように、システム１０は、各線分ごとに、その最も近い近傍に対する線分の関係に関する幾何学的情報を含む。各線分について、予測される交通量および速度に関する統計情報が、プロセスの最初の反復から生成される。車両移動イベントデータは、経度、緯度、進行方向、速度、および時刻を含む。本明細書に記載されるように、車両移動イベントデータは、たとえば６文字のジオハッシュにジオハッシュされる。ジオハッシュで強化された車両移動データは、ベースマップに対してマップマッチングされてもよい。

システム１０の１つの具体例としての利点は、車両移動データの大きなデータセットの中で、システムが非常に選択的でしかも高度の分解能で正確なマップインターフェイスとなるように構成できる点である。たとえば、システム１０は、米国における少なくとも１０００万ジオハッシュと同じくらいの数のマップデータおよびインターフェイスを識別し訂正することができる。

別の具体例としての利点は、マップインターフェイスおよびナビゲーションシステムを改善して車両を正確にナビゲートできることである。

別の実施形態において、上述のマップマッチング強化から進んで、分析サーバ５００またはエグレスサーバ４００を、車両イベント移動データポイントから正確な道路速度を決定するように構成することができる。図９に示されるように、ブロック４５０において、システム１０は、図４Ａ～４Ｅに関して本明細書に記載されるように、固有セグメントＩＤを有する道路セグメントを生成し、道路セグメントの長さを取得するように構成される。マップマッチングを通じて、システムは、車両イベントデータを分析して道路セグメント上の各車両データポイントの位置を特定するように構成することができる。各ポイントは、マッチングを行うために移動した距離と関連付けている。上述のように、道路はマップにおいて単一の線分として表されるので、マッチ距離は道路上のレーンの存在を示すことができる。したがって、車両イベントデータポイントは、道路セグメントの識別を判断するためにマップマッチングシステムを通じて処理される。データは、セグメントＩＤ、セグメント長、移動ＩＤ、タイムスタンプおよび速度を含む。

図９に示されるように、ブロック４５２において、道路の各セグメントおよび一定期間（たとえば１日の６０秒）ごとに、システム１０は、車両イベントデータにおいて報告された速度の算術平均を通じて各車両の平均速度を追跡および計算するように構成される。システム１０は、１日の瞬間、セグメントＩＤ、セグメント長、行程ＩＤ、および平均速度を取得する。次に、ブロック４５４において、システム１０は、算術平均を用いて計算された平均車両速度の調和平均を計算するように構成される。したがって、システム１０は、１日の瞬間、セグメントＩＤ、セグメント長、調和平均速度および車両カウントを取得する。ブロック４５６において、システム１０は、セグメントの長さＬを調和平均速度で除算してセグメントの通過時間を得るように構成される。

ブロック４５８において、システム１０は、各セグメントＩＤおよび期間について、計算された交通の平均流量、観測された車両の数、および通過時間を出力するように構成される。

たとえば、図４Ｂ～図４Ｅに関して示されるように、一連の道路セグメントにわたる推定通過時間を合計することにより、目的地への推定到着時間を生成する際に使用するのに適切となり得る、総通過時間の値を与えることができる。

プールされた車両速度の調和平均を用いることにより、システム１０は、報告された流量値がより低い推定値に有利に働く傾向があることを、好都合に保証する。したがって、システム１０は、観測される車両の流れにおける速度の急激な低下に対してより反応するように構成され、より高速の車両が全体平均を引き上げる効果を抑える。フリーフロー交通では、速度分散が小さい場合、調和平均値は算術平均に近付いたが、分散が増加し、交通流が不安定になるにつれて、調和平均値はそれに応じて低下することがわかった。したがって、低速に関する情報は高速よりも予見性があるので、システム１０は正確な交通通知を提供するように構成される。よって、システム１０の測定値は、平均をより小さく見積もることにより、より応答性が高く、より正確になるように構成される。

また、瞬間捕捉データポイントはトラップにおいて観察されるまで速度のアップストリームおよびダウンストリームの変化を考慮しなかったので、調和平均は、瞬間速度が捕捉される速度トラップの使用よりも改善された結果をもたらすことも、見出された。

このように、システム１０は、モデル化および予測を目的として履歴流量のデータセットを構築し、また（たとえばマッピングおよび交通インターフェイスのための）流量の予期しない変化のタイムリーな通知を提供するために、交通流を正確かつ頻繁に、好都合に測定することができる。したがって、システム１０は、エグレスサーバシステム４００（たとえば第三者２０パートナーおよび／またはダウンストリームインターフェイスのため）または分析サーバシステム５００（たとえばモデル化および予測のため）において、図９に関して説明されるような速度計算を提供するように構成することができる。

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

低レイテンシは、車両ソースからエンドユーザ顧客に情報を配信する超高速接続を提供する。さらなるデータ捕捉は、データポイント当たり３秒という高い捕捉レートを有し、たとえば、月当たり３３００億データポイントまで捕捉する。本明細書に記載のように、データは、位置データでレーンレベルに精密であり、典型的な車のサイズである半径３メートル以内に９５％精密である。

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

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

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

図１Ａ～図９との関連で記載されたシステム１０、５０、１００、２００、４００、５００、６００、７００、８００および９００に関して説明された実施形態は、単一のネットワークコンピュータによって実現および／またはその上で実行できる。他の実施形態において、これらのプロセスまたはこれらのプロセスの部分は、複数のネットワークコンピュータによって実装することができ、および／または複数のネットワークコンピュータ上で実行することができる。同様に、少なくとも１つの実施形態において、システム１０、５０、１００、２００、４００、５００、６００、７００、８００、９００、またはそれらの部分に関して説明されるプロセスは、ネットワークコンピュータ、クライアントコンピュータ、仮想マシン等の１つ以上の種々の組み合わせ上で動作することができる。さらに、少なくとも１つの実施形態では、図１Ａ～図９に関連して説明したプロセスは、図１Ａ～図９にも関連して説明したような論理アーキテクチャを有するシステムで動作することができる。

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

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

Claims (29)

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. 前記例外基準は、
    前記システムが前記追跡される車両について車両イベントデータを受け取っていない予め定められた量の時間、
    追跡される車両が前のセグメントに戻ること、および、
    車両エンジンオン／オフイベント
    からなる群より選択される例外基準を含む、請求項２３に記載の方法。
27. 前記プロセッサは、
    エグレスサーバでセグメントイベントを生成し、
    前記エグレスサーバのエグレスインターフェイスを介して、前記生成したセグメントイベントレコードを出力するように、
    構成されている、請求項１６に記載の方法。
28. プログラム命令を含むメモリとプロセッサとを備えるコンピュータのための、コンピュータにより実現される方法であって、前記プロセッサは前記方法のための命令を実行するように構成され、前記方法は、
    ロケーションイベントデータをサーバに取り込むステップと、
    前記ロケーションイベントデータを前記サーバで処理することにより、道路セグメントを特定するステップとを含み、前記処理は、
    前記道路セグメントを特定することと、
    車両イベントデータを追跡することにより、道路セグメント内の複数の車両の各々について複数の車両イベントデータポイントの位置を特定することと、
    前記複数の車両の各々について速度を計算することと、
    前記道路セグメントを通る前記複数の車両の各々の速度の算術平均により各車両の平均速度を計算することと、
    前記道路セグメントについて前記平均車両速度の調和平均スピードと車両カウントとを計算することと、
    セグメントの長さＬを前記調和平均スピードで除算することにより、前記道路セグメントの通過時間を得ることと、
    前記セグメントの通過時間をダウンストリームインターフェイスに出力
    することとを含む、コンピュータにより実現される方法。
29. イングレスサーバ、エグレスサーバ、分析サーバ、またはその組み合わせを用いて前記処理を実行するステップをさらに含む、請求項２６に記載の方法。

Images