以下では、図1〜図10を参照しながら、本発明の実施形態を説明する。
図1は、本実施形態に係るメッセージ配信制御システムの構成例を示す図である。図1に示すメッセージ配信制御システムは、優先度を制御しながら車両200にメッセージを配信するものであり、サーバであるテレマティクスセンタ100と、車両200に搭載される車両データ生成装置210とを備える。テレマティクスセンタ100と車両データ生成装置210とは、ネットワーク290、テレマティクスセンタ100に搭載された通信部140、および車両200に搭載された通信部220を介して互いに接続されている。この接続により、テレマティクスセンタ100と車両データ生成装置210との間で通信が可能となっている。ネットワーク290としては、例えば携帯電話網、インターネット網、無線LAN(Local Area Network)等の近距離無線通信、あるいはそれら複数の組み合わせで構成されたものなどが挙げられる。なお、図1では、車両データ生成装置210を搭載した車両200を1台のみ図示しているが、こうした車両200は1台に限定するものではなく、複数台の車両200が車両データ生成装置210をそれぞれ搭載し、テレマティクスセンタ100と接続される。
テレマティクスセンタ100は、ネットワーク290を介して、車両200に搭載されている様々な各種ECUのセンシング情報を収集し、また車両200に対してメッセージを配信する。テレマティクスセンタ100は、中央演算処理装置110と、記憶装置120と、入出力装置130と、通信部140とを備える。
中央演算処理装置110は、例えばCPU(Central Processing Unit)やRAM(Random Access Memory)などから構成され、所定の動作プログラムを実行することで、テレマティクスセンタ100の機能を実現する処理を行う。中央演算処理装置110は、その機能として、車両データ受信部111、イベント発生情報生成部112、イベント種別登録部113、遭遇時間演算部114、メッセージ配信部115を備える。
車両データ受信部111は、記憶装置120に格納されている車両構成情報DB121、車両データ情報DB122の各情報を管理し、必要に応じて各情報の登録、変更、削除を行う。イベント発生情報生成部112は、記憶装置120に格納されているイベント発生情報DB123の各情報を管理し、収集した車両データから故障や渋滞などのイベントを検知した結果をもって、各情報の登録、変更、削除を行う。イベント種別登録部113は、あらかじめ発生しうるイベントの種別と、その種別に応じて配信するメッセージを生成し、イベント種別情報DB124に登録する。遭遇時間演算部114は、記憶装置120に格納されている遭遇時間情報DB125の各情報を管理し、収集および演算した車両データとイベント発生情報を用いて、ある車両があるイベントが発生した地点に到達するまでの時間(TTE:Time To Encounter)を算出した結果をもって、各情報の登録、変更、削除を行う。メッセージ配信部115は、算出したTTEに応じて配信優先度を決定し、メッセージを車両200に配信する。なお、これらの各構成の動作については、後で詳しく説明する。
記憶装置120は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ、ROM(Read Only Memory)などから構成される。記憶装置120には、中央演算処理装置110が実行するプログラムや、プログラムの実行に必要なデータ群などが格納される。記憶装置120に格納されるデータ群には、車両構成情報DB121、車両データ情報DB122、イベント発生情報DB123、イベント種別情報DB124、遭遇時間情報DB125、地図DB126などが含まれる。
車両構成情報DB121は、各車両200の車種と、搭載されているECUの種別を管理するための情報である車両構成情報を蓄積する。車両データ情報DB122は、各車両200に搭載されているECUから取得されたプローブデータと、そのプローブデータから判断されるイベントを管理するための情報である車両データ情報を蓄積する。イベント発生情報DB123は、収集された車両データ情報から算出される、どの地点でどの様なイベントが発生しているかを管理するための情報であるイベント発生情報を蓄積する。イベント種別情報124は、発生しうるイベントの種別とその検知条件を管理するための情報を蓄積する。遭遇時間情報DB125は、各車両200と各イベント発生情報の組合せについて、ある車両があるイベントに遭遇するまでの時間TTEを管理するための遭遇時間情報を蓄積する。地図DB126は、車両200が走行する地域の地図データを蓄積したものであり、交差点、道路、レーンなどの情報を点や線などで表現したものである。
入出力装置130は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。
通信部140は、ネットワーク290で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、有線LANなどの有線通信や無線LANなどの無線通信、あるいはその両方に必要な通信規格に準拠する。通信部140は、ネットワーク290を介して、各種プロトコルに基づき車両200とデータを送受信する。
車両200は、車両データ生成装置210と、通信部220と、ナビゲーション端末230と、エンジンECU240と、ブレーキECU241と、ステアリングECU242と、自動運転ECU243とを備える。
エンジンECU240は、車両200のエンジン動作を管理する。ブレーキECU241は、車両200のブレーキ制御を管理する。ステアリングECU242は、車両200のステアリング制御を管理する。自動運転ECU243は、車両200の自動運転の動作制御を管理する。各機器は、CAN(Controller Area Network)などの車内ネットワークで接続される。また、図1に示す通り、各ECUはバス型CANネットワークに接続されている。車両データ生成装置210は、これらのバス型ネットワークのハブ機能を有している。
なお、車両200に搭載されるECUは、図1に示したものに限定されない。例えば、サスペンション制御用のECUや電子ミラー制御用のECUなど、車両200の制御や安全を支援する機能を持つECUが、図1に示した各ECU以外に車両200に搭載されていても良い。逆に、車両200が図1に例示したECUを搭載していることを必須とするものでもない。なお、各ECUには、自身を動作させるためのソフトウェアがそれぞれ内蔵されている。このソフトウェアは、各ECUが持つ記憶装置にそれぞれ格納されている。
車両データ生成装置210は、中央演算処理装置211と、記憶装置216とを備える。
中央演算処理装置211は、例えばCPUやRAMなどから構成され、所定の動作プログラムを実行することで、車両データ生成装置210の機能を実現する処理を行う。中央演算処理装置211は、その機能として、プローブ情報生成部212、イベント検知部213、車両データ送信部214およびメッセージ受信部215を備える。
プローブ情報生成部212は、あらかじめ定められたルールあるいはテレマティクスセンタ100からのメッセージに記載されるルールに従い、車両200の各ECUからセンサ値や制御情報を収集し、その取得時刻と併せてプローブ情報として生成する。イベント検知部213は、収集したプローブ情報から渋滞や車両200の故障などのイベントが発生していないかを確認する。車両データ送信部214は、生成したプローブ情報とイベント発生情報を併せて車両データとし、テレマティクスセンタ100に送信する。メッセージ受信部215は、テレマティクスセンタ100から送信されるメッセージを受信し、その内容に応じて車両200の制御を変化させる。
記憶装置216は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成され、中央演算処理装置211が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。記憶装置216に格納されるデータ群には、生成ルール情報DB217、運転ポリシー情報DB218、イベント種別情報DB219などが含まれる。
生成ルール情報DB217は、プローブ情報生成部212で生成されるプローブデータの統計加工処理の方法として、生成ルール情報を蓄積する。運転ポリシー情報DB218は、自動運転ECU243の運転制御の方法に必要な、車両の走行計画を立案する運転ポリシー情報を蓄積する。イベント種別情報DB219は、テレマティクスセンタ100のイベント種別情報DB124と同等で、発生しうるイベントの種別とその検知条件を管理するための情報を蓄積する。
通信部220は、ネットワーク290で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、無線LANなどの無線通信に準拠する。通信部220は、ネットワーク290を介して、各種プロトコルに基づきテレマティクスセンタ100とデータを送受信する。
ナビゲーション端末230は、中央演算処理装置231と、記憶装置234と、タッチパネルやキーボード、マウスなどの組み合わせからなる入出力装置236と、位置測位装置237とを備える。
中央演算処理装置231は、例えばCPUやRAMなどから構成され、所定の動作プログラムを実行することで、ナビゲーション端末230の機能を実現する処理を行う。中央演算処理装置231は、その機能として、メッセージ表示部232とマップマッチング部233を備える。メッセージ表示部232は、テレマティクスセンタ100から送信されたメッセージ情報に基づく表示を入出力装置236に対して行う。マップマッチング部233は、地図DB235に蓄積される地図情報を基に、現在位置を補正した上で車両200が現在どの道路のどのレーンを走行中かを特定する。
記憶装置234は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成され、中央演算処理装置231が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。記憶装置234に格納されるデータ群には、地図DB235が含まれる。
地図DB235は、車両200が走行する地域の地図データを蓄積したものであり、交差点、道路、レーンなどの情報を点や線などで表現したものである。
入出力装置236は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。
位置測位装置237は、例えばGPS(Global Positioning System)センサなどから構成され、車両200の現在位置を緯度と経度で取得する。なお、マップマッチング部233による現在位置の補正処理には、例えばエンジンECU240やブレーキECU241など、車両200に搭載されるECUのセンシング情報を用いても良い。
なお、車両データ生成装置210とナビゲーション端末230は同一の機器であっても良い。また、ナビゲーション端末230は車両200に搭載されるものではなく、例えばスマートフォンなどの携帯端末をナビゲーション端末230として用いても良い。この場合、ナビゲーション機能及び通信部220は携帯端末側に存在し、車両データ生成装置210は例えばOBD(On-Board Diagnostics)などのコネクタを用いることで、携帯端末と接続すればよい。
図2Aは、テレマティクスセンタ100の車両構成情報DB121に格納されるデータ構造を表すテーブルの一例である。車両構成情報DB121には、VIN(Vehicle Identification Number)300、車種ID301、ECUID302、ECU種別ID303の各データが格納される。VIN300は、車両200を一意に特定可能な識別子である。車種ID301は、そのVIN300を持つ車両200の車種を一意に特定可能な識別子である。ECUID302は、そのVIN300を持つ車両200に搭載されるECUを一意に特定可能な識別子である。ECU種別ID303は、そのVIN300を持つ車両200に搭載されるECUの種別を一意に特定可能な識別子である。
図2Bは、テレマティクスセンタ100の車両データ情報DB122に格納されるデータ構造を表すテーブルの一例である。車両データ情報DB122には、VIN310、時刻311、位置312、進行方向313、道路ID314、レーン情報315、車速316、イベント検知情報317、更新日時318の各データが格納される。VIN310は車両構成情報DB121のVIN300と共通のデータであり、各車両200の車種を一意に特定可能な識別子である。時刻311は過去、現在もしくは未来の時刻情報である。位置312は、時刻311における車両200の位置情報である。車両200の位置を経緯度により表している。進行方向313は、時刻311における車両200の進行方向を方位角で表現した情報であり、例えば右手系東基準で表記された進行方向が蓄積される。道路ID314は、時刻311における車両200が走行中の道路を一意に特定可能な識別子であり、ナビゲーション端末230の地図DB235で管理されるものである。レーン情報315は、時刻311において車両200が道路ID314の道路を走行する時に、何車線の内の何番目のレーンを走行するかを示す情報である。車速316は、時刻311における車両200の速度情報である。イベント検知情報317は、時刻311において車両200がイベント検知部213により何かしらのイベントを検知していた場合に、そのイベントの内容を示す情報である。更新日時318は、このデータを更新した日時を示す情報である。
なお、車両データ情報DB122に管理される1台の車両200に対する車両データレコードは、1つだけであっても、複数あっても良い。ある車両200に紐付く車両データレコードが1つだけの場合は、テレマティクスセンタ100は車両200の最新の車両データレコードのみを管理することとなる。一方で車両200に紐付く車両データ情報が複数ある場合には、テレマティクスセンタ100は車両200の車両データレコード群、すなわち移動軌跡を管理することとなる。また、車両200に紐付く車両データレコードが2つ以上の場合、時刻311は過去の時刻であっても、未来の時刻であっても良い。時刻311が過去の時刻であれば、車両データレコードは車両200が実際に走行した移動軌跡を表現することとなる。一方で時刻311が未来の時刻であれば、車両データレコードは車両200がこれから走行する移動軌跡、すなわち走行計画を表現することとなる。
図3Aは、テレマティクスセンタ100のイベント発生情報DB123に格納されるデータ構造を表すテーブルの一例である。イベント発生情報DB123には、イベントID320、初回発生時刻321、発生位置322、道路ID323、レーン情報324、イベント種別ID325、被検知回数326、更新日時327の各データが格納される。イベントID320は、複数の車両200から得られたイベント検知情報317(図2B)について、テレマティクスセンタ100のイベント発生情報生成部112が類似するイベントを1つに集約した際に、その集約したイベント発生情報を一意に特定可能な識別子である。初回発生時刻321は、そのイベントID320で特定されるイベント発生情報が最初に発生した時刻情報である。発生位置322は、そのイベントが発生した位置情報である。道路ID323は、そのイベントが発生した位置情報322を地図DB126の地図情報にマップマッチングした結果として得られる、イベントが発生した道路を一意に特定可能な識別子である。レーン情報324は、そのイベントが発生した箇所が、道路ID323の何車線の内の何番目のレーンであるかを示す情報である。被検知回数326は集約されたイベント発生情報の数を示す情報である。更新日時327は、イベントID320で特定されるイベント発生情報の最新の時刻情報である。
図3Bは、テレマティクスセンタ100のイベント種別情報DB124に格納されるデータ構造を表すテーブルの一例である。イベント種別情報DB124には、イベント種別ID330、イベント内容331、イベント検知条件332、有効期間333、有効範囲334、配信メッセージ335の各データが格納される。イベント種別ID330は、発生し得るイベントの種別を一意に特定可能な識別子である。イベント内容331は、そのイベント種別ID330で定義される渋滞や故障などのイベントの内容を示す。イベント検知条件332は、そのイベントが発生したと車両200が判断するための条件を示す情報である。有効期間333は、そのイベントに応じて車両200にメッセージを配信する際に、配信処理を実行する有効期間を示す。有効範囲334は、そのイベントに応じて車両200にメッセージを配信する際に、配信対象となる車両200の位置的な制約情報を示す。有効範囲334は、その点列を直線で結ぶことで表現可能な多角形の情報が格納される。なお、イベント発生位置322(図3A)は都度異なることから、有効範囲334はある点(イベント発生位置)から見た相対的な位置関係を表現している。配信メッセージ335は、配信対象となった車両200に対して実際に配信するメッセージの中身が蓄積される。
なお、イベント種別情報DB124の各データは、テレマティクスセンタ100の管理者等によって入出力装置130を介して入力される。管理者としては、例えばテレマティクスセンタ100の運用者や、車両200の製造管理者などが考えられる。また、同一のデータが格納される車両データ生成装置210のイベント種別情報DB219に関しては、車両200の車両データ生成装置210が初めて実行された時に、テレマティクスセンタ100に問い合わせることで、最新のイベント種別情報を車両200へ配信する。
なお、イベント種別情報DBで定義されるイベントは表中に記載のものに限定されず、例えばエンジン故障や落下物検知など、様々なイベントを登録することが可能である。
図3Cは、テレマティクスセンタ100の遭遇時間情報DB125に格納されるデータ構造を表すテーブルの一例である。遭遇時間情報DB125には、イベントID340、VIN341、TTE342、配信済みフラグ343、更新日時344の各データが格納される。イベントID340はイベント発生情報DB123のイベントID320と共通のデータであり、イベント発生情報を一意に特定可能な識別子である。VIN341は車両構成情報DB121のVIN300と共通のデータであり、各車両200の車種を一意に特定可能な識別子である。TTE342は、VIN341を持つ車両200が走行を継続した場合に、イベントID340で示されるイベントに遭遇するまでの時間を示す。TTE342はテレマティクスセンタ100の遭遇時間演算部114により算出される。配信済みフラグ343は、VIN341を持つ車両200に対して、イベントID340に紐付く配信メッセージ335を既に配信したか否かを示す。更新日時344は、このデータを更新した日時を示す情報である。
図4は、本実施形態において実行される車両データの送信処理の流れを示す図である。図4に示す処理は、車両200に搭載されている車両データ生成装置210のプローブ情報生成部212、イベント検知部213、車両データ送信部214と、テレマティクスセンタ100の車両データ受信部111およびイベント発生情報生成部112とにより行われる。
図4において、車両200のプローブ情報生成部212は、エンジンECU240からの情報を用いて車両200のエンジン始動を検知する(ステップS400)。ステップS400でエンジン始動を検知したら、プローブ情報生成部212は一定時間、車両200内のネットワークを介してナビゲーション端末230および各ECUから情報を収集し、それらを集約してプローブ情報として蓄積する(ステップS401)。そして、生成ルール情報DB217に蓄積される生成ルール情報にしたがって、収集したプローブ情報に統計処理による加工を施し、車両データ情報DB122(図2B)に示すVIN310〜車速316の情報を生成する(ステップS402)。生成ルールとしては、例えば「車速のサンプリングレートが10Hzとなる様に加工する」などの統計処理が記載されている。
車両データ生成装置210のイベント検知部213は、ステップS401で収集したプローブ情報を用いて、イベント種別情報DB219(図3B)に蓄積されるイベント検知条件322を満たしているかを判定する(ステップS403)。
ステップS403の結果、車両のイベントを検知した場合(S404:Yes)には、ステップS402で加工したプローブデータに対して、検知したイベント種別のイベント種別ID330を、イベント検知情報317として追加する形で付与する(ステップS405)。そして、プローブ情報とイベント検知情報の2つを車両データとして、テレマティクスセンタ100に送信する(ステップS406)。ステップS403の結果、車両のイベントを検知しなかった場合(S404:No)には、ステップS402で加工したプローブ情報を車両データとして、テレマティクスセンタ100に送信する(ステップS406)。
車両200のプローブ情報生成部212は、エンジンECU240からの情報を用いて車両200のエンジンが停止しているかを確認(ステップS407)し、車両200の運転が終了している場合(S407:Yes)には、データ収集および送信を終了する。車両200の運転が終了していない場合(S407:No)には、再びステップS401を実行する。
ステップS406で車両200から送信された車両データは、テレマティクスセンタ100の通信部140により受信される(ステップS420)。ステップS420で車両データを受信したら、テレマティクスセンタ100の車両データ受信部111は、車両データ情報DB122にその車両データを蓄積する(ステップS421)。さらに、テレマティクスセンタ100のイベント発生情報生成部112は、これまでに蓄積された車両データ情報DB122の車両データを用いて、イベント発生情報を生成するか、既存のイベント発生情報を加工する(ステップS422)。ステップS422の処理は、図5に後述する。
以上説明した図4の処理により、車両200の車両データ生成装置210からテレマティクスセンタ100に対して、イベントの発生有無を含む車両データ情報が送信される。
図5は、本実施形態において実行されるイベント発生情報の生成処理の流れを示す図である。図5に示す処理は、テレマティクスセンタ100のイベント発生情報生成部112により、ステップS422(図4)にて行われる。
テレマティクスセンタ100のイベント発生情報生成部112は、ステップS420で受信した車両データから、初めてイベントを検知した時の車両データ情報の位置312をイベント検知地点として抽出した上で、既に検知されているイベント情報をイベント発生情報DB123から抽出し、位置312と発生位置322の距離がXkm以下となるイベント発生情報があるかを検索する(ステップS500)。この検索は1次フィルタの機能として利用するものであり、例えば北海道で検出したイベントに対して、遠く離れた九州で既に発生しているイベント発生情報を対象として図5の処理を実行しないためのものである。そのため、フィルタ条件は距離以外であってもよく、例えばイベント発生地点の行政区画(都道府県や市町村等)情報を使って限定しても良い。検索の結果、イベント検知地点からXkm以内に既検出のイベント発生情報が存在する場合(S501:Yes)には、次にその中に、検索されたイベント情報のイベント種別ID325が、車両データに含まれるイベント検知情報317と一致するイベント発生情報があるかを検索する(ステップS502)。検索の結果、同じイベント種別であるイベント発生情報が存在する場合(S503:Yes)には、更にその中に、検索されたイベント情報の更新日時327に有効期間333を加えた時間が、車両データでイベントを検知した時刻311より大きくなるイベント発生情報が存在するかを検索する(ステップS504)。検索の結果、イベント情報の更新日時327に有効期間333を加えた時間がイベントを検知した時刻311より大きいイベント発生情報が存在する場合(S505:Yes)には、ステップS420で受信した車両200の車両データに含まれるイベント検知情報は、既に他の車両200で検知されたイベント検知情報と同じ理由で発生したものであると判断し、該当するイベント発生情報の被検知回数326に1を加え、更新日時327を車両200がイベント検知した時刻311で上書きし(ステップS506)、図5の処理を終了する。ステップS506により更新日時327が更新されることにより、メッセージ配信の有効期限が延びることになる。
また、検索の結果、イベント検知地点からXkm以内に既検出のイベント発生情報が存在しない場合(S501:No)、あるいは同じイベント種別であるイベント発生情報が存在しない場合(S503:No)、あるいはイベント情報の更新日時327に有効期間333を加えた時間が時刻311より大きいイベント発生情報が存在しない場合(S505:No)には、いずれの場合も、ステップS420で受信した車両200の車両データに含まれるイベント検知情報は、新しく検知されたイベント発生情報であると判断し、新しくイベントID320を割り当て、初回発生時刻321には始めてイベントを検知した時刻311を、発生位置322には位置312を、道路ID323には道路ID314を、レーン情報324にはレーン情報315を、イベント種別ID325にはイベント検知情報317を、被検知回数326には数値の1を、更新日時327には初回発生時刻321のデータを格納する形で、新しくイベント発生情報を作成しイベント発生情報DB123に登録する(ステップS507)。
なお、例えばイベントの内容によっては、被検知回数326の値が増加するにつれて対象のイベント発生情報の有効期間を延ばすことが望ましい場合も考えられる。そのような場合は、同じイベント内容であってもイベント発生情報毎に有効期間を変化させるため、イベント種別情報DB124にイベント内容331は異なるが有効期間333が異なるデータを登録するなどにより、前述の機能を実現しても良い。
また、車両200の車種ID301を用いて、イベント発生情報を分割しても良い。この場合、S506にて被検知回数326に1を加える条件として、「イベント発生情報を生成した車両200の車種ID301と、今回イベントを検知した車両200の車両ID301が一致する」が追加される。これは、例えばブレーキ故障のイベントなど、車種特有のイベント情報を想定したものである。同様に、ECUID302あるいはECU種別ID303を用いて、イベント発生情報を分割しても良い。
また、図5に示すイベント発生情報生成部112の処理は、図4に示す様に車両データを受信する度に実行するのではなく、例えば10分間隔など、一定周期で実行するものとし、その間に受信した車両データを対象として実行するようにしても良い。
以上説明した図5の処理により、テレマティクスセンタ100は車両200から受信した車両データを用いて、新しいイベント発生情報の生成あるいは既に検出したイベント発生情報を更新する。
図6は、本実施形態において実行される遭遇時間(TTE)の演算処理の流れを示す図である。図6に示す処理は、テレマティクスセンタ100の遭遇時間演算部114にて、例えば10秒間隔など、一定周期で実行される。
図6において、テレマティクスセンタ100の遭遇時間演算部114は、イベント発生情報DB123から蓄積されているイベント発生情報を検索し、その内1件を抽出する(ステップS600)。そして、抽出されたイベント発生情報のイベント種別ID325に基づき、その有効期間333および有効範囲334の情報を引き出し、車両データ情報DB122からの時刻311が更新日時327に有効期間333を加えたものより小さく、かつ位置312が前述の有効範囲334の中にある車両データ情報を抽出する(ステップS601)。これにより、イベント発生情報の有効範囲内を有効期間中に走行している、あるいはこれから走行予定のある車両200を特定することになる。次に、抽出した車両データ情報群について、VIN310が同一である車両データ情報を纏めた上で、その内1つのVINを持つ車両200の車両データ情報を全て抽出する(ステップS602)。抽出した結果、対象となる車両データ情報が2つ以上であり、かつその車両データ情報の時刻311が現在時刻より未来の時刻であった場合(S603:Yes)には、その車両データ情報を送信した車両200はこれから走行する移動軌跡、すなわち走行計画を送信していることから、全ての車両データ情報の道路ID314及びレーン情報315を確認し、対象のイベント発生情報の道路ID323とレーン情報324と一致した車両データ情報の中で、最も発生位置322に近い位置312を持つ車両データ情報に含まれる、時刻311、位置312、車速316から遭遇時間(TTE)を算出する(ステップS604)。ステップS602で抽出した結果、対象となる車両データ情報が1つのみである、あるいは2つ以上だがその車両データ情報の時刻311が現在時刻より過去の時刻であった場合(S603:No)には、その車両データ情報を送信した車両200は走行計画を送信していないことから、最も現在時刻に近い時刻311を持つ車両データ情報に含まれる、時刻311、位置312、車速316から遭遇時間(TTE)を算出する(S605)。そして、TTEの計算対象となったイベント発生情報のイベントID320、車両200のVIN310、算出したTTE、現在時刻を、それぞれイベントID340、VIN341、TTE342、更新日時344として遭遇時間情報DB125に蓄積する(ステップS606)。この時、配信済みフラグ343はFalseの値で登録される。また、既に同じイベントID340、VIN341を持つレコードが遭遇時間情報DB125に登録されていた場合は、そのレコードのTTE342の値を更新する。
なお、S605に置ける遭遇時間(TTE)の算出においては、最も現在時刻に近い時刻311を持つ車両データ情報に含まれる進行方向313の情報と、車両200の位置312から見たイベント発生地点の方角に関する情報を用いても良い。例えば、イベント発生地点が車両200から見て方位角P度に存在し、自動車がQ度方向に進行している場合、イベントの発生位置322と車両200の位置312との距離をD、車速316をVと表現すると、TTEを次式で計算しても良い。
TTE=D/(V×Cos(P−Q))
また、この結果、TTEが0または負の値となる場合、ステップS606においては、遭遇時間情報DB125から対象となる車両200のレコードを削除しても良い。
そして、ステップS602で抽出したVIN以外に、他のVINを持つ車両200の車両データ情報が存在する場合(S607:Yes)には、ステップS602以降を繰り返す。全てのVINに対してTTEを計算した場合(S607:No)には、ステップS600で抽出した1件以外にも、他にイベント発生情報が存在する場合(S608:Yes)には、S600以降を繰り返す。そして、全てのVINとイベントIDの組合せに対してTTEの計算が終了した場合(S608:No)には、図6で示す遭遇時間演算部114の処理を終了する。
以上説明した図6の処理により、テレマティクスセンタ100は車両200から受信した車両データ情報とイベント発生情報とを用いて、ある車両200があるイベントに遭遇するまでの時間(TTE)を算出し、その結果を遭遇時間情報DBに登録する。
図7は、本実施形態において実行されるメッセージ配信の優先度制御処理の流れを示す図である。図7に示す処理は、テレマティクスセンタ100のメッセージ配信部115と、車両200のメッセージ受信部215により行われる。
図7において、テレマティクスセンタ100のメッセージ配信部115は、遭遇時間情報DB125から、配信済みフラグ343がFalseであり、かつTTE342がP秒以上であり、かつ最もTTEが小さいレコードを抽出する(ステップS700)。ここでP秒以上のレコードに限定する理由は、例えば1秒未満など極端にTTEが短いデータについては、ネットワーク遅延の影響によりイベントに遭遇するまでにメッセージ配信が間に合わない可能性が高いためである。なお、このP秒は固定の値であっても良いし、例えばネットワーク290の通信遅延状況をテレマティクスセンタ100が監視し、その遅延時間に応じて設定しても良い。
遭遇時間情報DB125からTTEがP秒以上かつ最も短いレコードを1件抽出した後、対象レコードのイベントID340を用いてイベント種別情報DB124から配信メッセージ335を抽出する(ステップS701)。更に、対象レコードのVIN341から配信対象となる車両200を特定し、メッセージを配信する(ステップS702)。メッセージ配信が完了した後は、対象レコードの配信済みフラグ343をTrueに、更新日時344を現在時刻に更新する。そして、遭遇時間情報DB125に他にレコードが存在しないかを確認し、存在する場合(S703:Yes)は再びステップS700を実行する。他にレコードが存在しない場合(S703:No)は、図7に示す処理を終了する。
ステップS702でテレマティクスセンタ100から送信されたメッセージは、車両200において、通信部220により受信される(ステップS710)。ステップS710で車両データを受信したら、車両200のメッセージ受信部215は、そのメッセージに従い生成ルール情報DB217や、運転ポリシー情報DB218の情報を更新する(S720)。
なお、テレマティクスセンタ100のメッセージ配信部115は、遭遇時間情報DB125のデータが更新される度に実行されても、例えば1秒など定期的に実行されても良い。
また、TTEが0秒以下となった情報は、検索速度を向上させるため、遭遇時間情報DB125から削除しても良い。
以上説明した図7の処理により、テレマティクスセンタ100は、全てのイベント情報に対して、TTEの優先度に従い、車両200にメッセージを配信する。
図8は、本実施形態において実行される第1のアプリケーションの流れの一例を示す図である。図8においては、アプリケーションの一例として、イベント種別情報DB124のイベント内容331が「ブレーキ故障」などの、ある車両200がある地点で故障が発生したと思われる状況下で、その故障が真に車両200の部品が原因であるか、あるいは路面凍結などの外部要因が原因で故障した様な挙動を取ったかを、テレマティクスセンタ100の管理者などが判断したい状況下を想定している。この時、テレマティクスセンタ100の管理者は、イベント発生地点を走行する可能性のある周辺車両に対して、より詳細な情報を取得するため、車両データ加工時のサンプリングレートを向上させるメッセージを配信したい状況下である。
この状況下において、周辺には5台の車両200が存在しており、それぞれはこれから走行する道路及び車線を計画している。この情報は、図4に示す処理によって、テレマティクスセンタ100の車両データ情報DB122に蓄積されている。そして、図5、図6に基づく処理により、各車両200のTTEが算出される。具体的には、走行計画によりイベント発生地点を通過する予定がない、VINが4GLQ、O74P、7RTMの車両200については、TTEが計算されない。一方で、走行計画によりイベント発生地点を通過する予定のある、VINがPC31、9GJHの車両200については、TTEが算出され遭遇時間情報DB125にその情報が蓄積される。この時、直線距離としてはVIN:PC31を持つ車両200の方がVIN:9GJHを持つ車両より近い一方で、車速の差により、遭遇時間情報DB125に示されるように、TTEはVIN:9GJHを持つ車両200の方が短くなっている。したがって、テレマティクスセンタ100のメッセージ配信部115は、この状況下ではVIN:9GJHを持つ車両200に対して、優先的に車両データ加工時のサンプリングレートを向上させるメッセージを配信することになる。
図9は、本実施形態においてテレマティクスセンタ100の入出力装置130に表示される画面の一例を示す図である。入出力装置130には、イベント種別情報DB124に新しくイベント種別情報を登録する、あるいは既に登録されているイベント種別情報を修正する画面として、例えば図9に示すような画面が表示される。
図9の画面は、符号800、801にそれぞれ示す画面領域により構成されている。画面下方の画面領域801には、対象のイベント種別ID330を持つイベント種別情報について、イベント内容331、イベント検知条件332、有効期間333、有効範囲334、配信メッセージ335の各情報の内容が表されている。なお、画面領域801では、テレマティクスセンタ100の管理者が入出力装置130を介して任意の情報を上書きすることで、イベント種別情報124の内容を変更することもできる。
画面上方の画面領域800は、イベント種別情報124の有効範囲334の情報を可視化して示したものである。画面領域800には、多角形として定義された有効範囲334が多角形802として図示されている。イベントの発生位置322は都度異なることから、有効範囲334は、車両200がイベントを検知した地点322を中心とする多角形の各頂点との経緯度の差分量の組として定義されている。多角形802は、有効範囲334を可視化したものである。
なお、有効範囲334は、例えば被検知回数326の回数に応じて、自動的に範囲が拡大あるいは縮小されるよう、設定しても良い。具体的には、イベント種別情報ごとに基準値を設定可能とし、その基準値と検知回数の比率を利用して、イベント発生位置の中心点と有効範囲を表現する各頂点との距離を拡大あるいは縮小することが考えられる。
図10は、本実施形態において実行される第2のアプリケーションの流れの一例を示す図である。図10においては、アプリケーションの別の例として、イベント種別情報DB124のイベント内容331が「渋滞発生」などの、ある車両200がある地点で渋滞が発生したと思われる状況下で、その情報を後続する自動運転中の車両200に通知したい状況下を想定している。図10の例では、高速道路の出口付近において、誘導路に車線変更可能な走行車線においてのみ渋滞が発生している。
自動運転機能を持つ車両200は、高速道路を走行中においては、障害物回避などの理由により、走行可能な車線であればどの車線であっても走行している可能性がある。一方で、ある出口で降りる必要がある場合には、必ず誘導路に車線変更可能な走行車線(図10の場合は最も左に位置する車線)に予め変更しなければならない。図10のケースでは、自動運転中の車両は、出口から2km手前になると誘導路に車線変更可能な走行車線に車線変更するべく、走行計画を立てることを想定している。この時、渋滞が3km程度発生しており、出口2km手前の車線変更では渋滞の列に割り込む必要性があるが、自動運転による割り込み処理は衝突のリスクが高く、そのため自動運転機能を解除し、ドライバによる手動運転状態に切り替えなければならないことを想定している。
この時、車両200に対してあらかじめ「渋滞が3km」発生していることを通知し、より早い段階で車線変更を行うようにすれば、自動運転機能を解除する必要性は無くなり、ドライバの利便性が向上する。このためテレマティクスセンタ100は、渋滞発生地点に接近し、かつその先の出口で高速道路を下りる予定のある車両200に対して、「出口前の事前の車線変更は2kmから」という条件(ポリシー)を、一時的に「出口前の事前の車線変更は4kmから」に変更するメッセージを配信する。
このようなアプリケーションを実行している状況下において、渋滞発生地点の後方には2台の車両200がそれぞれこれから走行する道路及び車線を計画している。この情報は、図4に示す処理によって、テレマティクスセンタ100の車両データ情報DB122に蓄積されている。そして、図5、図6に基づく処理により、各車両200のTTEが算出される。具体的には、走行計画によりイベント発生地点を通過する予定のある、VINがPC31、9GJHの車両200については、TTEが算出され遭遇時間情報DB125にその情報が蓄積される。この時、直線距離としてはVIN:PC31を持つ車両200の方が、VIN:9GJHを持つ車両より近い一方で、車速の差により、TTEはVIN:9GJHを持つ車両200の方が短くなっている。したがって、テレマティクスセンタ100のメッセージ配信部115は、この状況下ではVIN:9GJHを持つ車両200に対して、優先的に事前車線変更の運転ポリシーを変更させるメッセージを配信する。