JP6020611B2 - 車両データのリモート収集システム - Google Patents

Description

本発明は、センターを介した要求に応じて車両データをリモートで収集する車両データのリモート収集システムに関する。

従来、この種のシステムとしては、特許文献１に記載のシステムが知られている。このシステムでは、車両データをセンターに送信するための送信条件をセンターから車両に予め指示しておく。そして、この指示された送信条件が車両側で成立したとき、データ取得項目として指示された車両データをデータ送信用バッファに格納する。その後、定期的又はセンターからの要求に応じてデータ送信用バッファに格納された車両データを車両からセンターに返信するようにしている。

特開２００６−２８３６５１号公報

ところで、上記文献に記載のシステムでは、例えば指示されたデータ取得項目が車両側に存在しない等、車両データの収集の指示が車両にとって適切なものではないときには、センターを介した要求があったとしてもその要求に応じた車両データが車両からセンターに返信されない状況となることがある。もちろん、そのような状況の発生は未然に防ぐことが望ましい。

本発明は、このような実情に鑑みてなされたものであり、その目的は、センターを介した要求に応じて車両データを的確に収集することのできる車両データのリモート収集システムを提供することにある。

以下、上記課題を解決するための手段及びその作用効果について記載する。
上記課題を解決する車両データのリモート収集システムは、複数の車両の走行情報を管理するセンターから対象車両に対し収集対象とされる車両データの種類、車両データを収集するときの条件式、車両データを収集するときのサンプリング周期、もしくは、条件式のチェック周期を無線通信にて指示し、その対象車両に対する指示に基づき収集される車両データを無線通信にてセンターに取り込む車両データのリモート収集システムであって、前記センターは、前記対象車両に対して指示する車両データの種類、条件式、サンプリング周期、チェック周期の少なくとも一つの妥当性を、前記センター自身が備えるチェック基準に基づきチェックするセンター側チェック部を備え、前記対象車両は、前記センターからの指示に基づく車両データの収集時における対象車両のリソースが適正であるか否かをチェックする車両側チェック部を備える。

収集対象とされる車両データの種類、車両データを収集するときの条件式、車両データを収集するときのサンプリング周期、及び条件式のチェック周期が対象車両にとって妥当なものであるか否かをチェックするときには、その妥当性のチェック基準を車種ごとに予め用意する必要がある。こうしたチェック基準は、特に、収集対象とする車両データの種類が多岐に亘る場合や車両データを収集するときの条件式に自由度を持たせたい場合に、そのデータ量が膨大になってしまうため、こうしたチェック基準はセンター側で管理するのが一般的である。そこで、上記構成では、車両データの種類、条件式、サンプリング周期、チェック周期の妥当性をセンター自身が備えるチェック基準に基づきセンター側でチェックするようにし、こうしたチェックの際に上述したチェック基準をセンターと対象車両との間で通信することを不要とした。また、センターからの指示に基づく車両データの収集時における対象車両のリソースが適正であるか否かをチェックするときには、その都度の対象車両のリソースを把握する必要があるが、こうした対象車両のリソースは対象車両側で取得可能なものである。そこで、上記構成では、対象車両のリソースを対象車両側でチェックするようにし、こうしたチェックの際にその都度の対象車両のリソースをセンターと対象車両との間で通信することを不要とした。すなわち、上述したチェックの何れについても対象車両とセンターとの間の通信が不要となるため、車両の通信環境等の影響を抑えつつ、センターを介した要求に応じて車両データを的確に収集することができるようになる。

上記車両データのリモート収集システムにおいて、前記センター自身が備えるチェック基準は、前記対象車両の車種と、その車種において取得可能な車両データの種類とが関連付けされたデータベースに規定されており、前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する車両データの種類を割り出し、この割り出した車両データの種類と、前記対象車両に対して収集対象として指示した車両データの種類とが合致することを条件に、車両データの種類が妥当であると判断することが好まし
い。

上記構成によれば、センターがチェック基準として自ら備えるデータベースを用いて、センターから収集対象として指示された車両データの種類が対象車両にとって取得可能なものであるか否かをチェックすることができるようになる。

上記車両データのリモート収集システムにおいて、前記データベースには、車両データの取り得る値の範囲が車両データの種類に対して関連付けられており、前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から収集対象としている車両データの取り得る値の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示した条件式を満たす車両データのデータ値範囲が収まることを条件に、車両データの条件式が妥当であると判断することが好ましい。

上記構成によれば、センターがチェック基準として自ら備えるデータベースを用いて、センターから指示された条件式が対象車両にとって妥当なものであるか否かをチェックすることができるようになる。

上記車両データのリモート収集システムにおいて、前記データベースには、設定可能なチェック周期の範囲が条件式に対して関連付けられており、前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する条件式において設定可能なチェック周期の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示したチェック周期が収まることを条件に、チェック周期が妥当であると判断することが好ましい。

上記構成によれば、センターがチェック基準として自ら備えるデータベースを用いて、センターから指示されたチェック周期が対象車両にとって妥当なものであるか否かをチェックすることができるようになる。

上記車両データのリモート収集システムにおいて、前記データベースには、設定可能なサンプリング周期の範囲が車両データの種類に対して関連付けられており、前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する車両データの種類において設定可能なサンプリング周期の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示したサンプリング周期が収まることを条件に、サンプリング周期が妥当であると判断することが好ましい。

上記構成によれば、センターがチェック基準として自ら備えるデータベースを用いて、センターから指示されたサンプリング周期が対象車両にとって妥当なものであるか否かをチェックすることができるようになる。

上記車両データのリモート収集システムにおいて、前記車両側チェック部によってチェック対象とされる対象車両のリソースは、当該対象車両に搭載されたメモリ又はストレージの空き容量を含むことが好ましい。

例えばセンターからの指示に基づき収集される車両データを格納するのに十分な空き容量がメモリ又はストレージに確保できないとすると、こうした車両データを対象車両から収集することができなくなる。そこで、上記構成では、車両データの収集を実行する前にメモリ又はストレージの空き容量を対象車両側で予めチェックするようにしたことで、センターを介した要求に応じて車両データを的確に収集することができるようになる。

上記車両データのリモート収集システムにおいて、前記車両側チェック部によってチェック対象とされる対象車両のリソースは、当該対象車両に搭載された車両ネットワークのバス占有率を含むことが好ましい。

センターからの指示に基づく車両データの収集時に車両ネットワークのバス占有率が過剰となる状況を未然に防ぐため、こうした状況が生じるときには、車両ネットワークのバス占有率が十分に低下するまで、車両ネットワークを通じた車両データの収集がしばらく中断されることもある。すなわち、こうしたバス占有率が過剰となるという状況が発生するときには、センターを介した要求に応じて車両データが迅速に収集できなくなることもある。この点、上記構成では、車両データの収集を実行する前に車両ネットワークのバス占有率を予め対象車両側でチェックするようにしたことで、センターを介した要求に応じて車両データを的確に且つ迅速に収集することができるようになる。

上記車両データのリモート収集システムにおいて、前記車両データの収集条件は、１乃至複数の命令が記述されたスクリプトにより指定されることが好ましい。
上記構成によれば、スクリプト入力を通じて、自由度の高い車両データの収集条件の指定が実現可能となる。なお、こうしたスクリプトの入力によれば、対象車両に対して指示可能な車両データの種類、条件式、サンプリング周期、及びチェック周期が多岐に亘ることから、それら指示項目の対象車両における妥当性が問題となりやすい。また、スクリプト自体のデータサイズやスクリプト実行時の処理負荷等も多様となるため、スクリプトが指定する収集条件に基づく車両データの収集時に対象車両のリソースが適正に維持されるか否かも問題となりやすい。この点、上記構成によれば、スクリプトが指定する収集条件に基づく車両データの収集が行われる前に予めセンター側及び車両側でチェックが行われるため、上述した問題の何れも生じにくくなる。

上記車両データのリモート収集システムにおいて、前記対象車両は、コントローラエリアネットワーク（ＣＡＮ（登録商標））に接続された複数の車載制御装置を備えており、前記車両データは、ＣＡＮプロトコルに規定される通信によって１乃至複数の車載制御装置から収集されることが好ましい。

上記構成によれば、車両に多く利用されている汎用性の高いＣＡＮプロトコルを利用して車両データを収集することができるようになる。

車両データのリモート収集システムの一実施の形態についてその概略構成を示すブロック図。 収集可能データテーブル（データベース）の規定内容の一例を示す模式図。 情報収集テーブルの規定内容の一例を示す模式図。 同実施の形態の車両データのリモート収集システムが車両データの収集時に実行する処理の流れを示す模式図。 同実施の形態の車両データのリモート収集システムが実行する条件式チェックの処理手順を示すフローチャート。 同実施の形態の車両データのリモート収集システムが実行するデータ種類チェックの処理手順を示すフローチャート。 同実施の形態の車両データのリモート収集システムが実行する周期チェックの処理手順を示すフローチャート。 同実施の形態の車両データのリモート収集システムが実行するメモリチェックの処理手順を示すフローチャート。 同実施の形態の車両データのリモート収集システムが実行するストレージチェックの処理手順を示すフローチャート。 同実施の形態の車両データのリモート収集システムが実行するバス占有率チェックの処理手順を示すフローチャート。

以下、車両データのリモート収集システムの一実施の形態について図面を参照して説明する。
本実施の形態の車両データのリモート収集システムは、対象とする複数の車両と、それら複数の車両の走行情報を管理するセンターと、センターを介した複数の車両からの車両データの収集を指示すべくエンジニア等により操作される外部端末とにより構成されている。外部端末は、例えばインターネット回線を介してセンターに接続されており、車両からの車両データの収集条件をセンターに入力可能となっている。ここで、車両データの収集条件は高い自由度で設定できることが望ましく、本実施の形態では、こうした自由度の高い収集条件の設定をスクリプト入力により実現している。このスクリプトは、車両データの収集時に実行される１乃至複数のコマンド（命令）を記述した文字列である。そして、外部端末から入力されたスクリプトがセンターを介して無線通信により車両に送信されると、この送信されたスクリプトに記述された複数のコマンドが車両側で順次実行されることにより、スクリプトに記述された条件に基づいて車両データが収集される。その後、この収集された車両データは無線通信によりセンターに返信され、この返信された車両データがセンターを介して外部端末に転送される。

具体的には、図１に示すように、センター１００は、外部端末２００から入力されたスクリプトを登録するスクリプト登録部１０１を備えている。本実施の形態において、このスクリプトには、以下の（ａ）〜（ｅ）に列挙する項目が記述可能とされている。

（ａ）条件式：車内環境を判定するための条件式や車外環境を認識するための想定シー
ン（条件式）
（ｂ）チェック周期：車両データが条件式を満たしているのか判定したり、画像に対し
てシーン分類するチェック周期
（ｃ）データ収集期間：データ収集を開始してから終了するまでの期間
（ｄ）サンプリング周期：データをストレージに収集する周期
（ｅ）車両データ：収集対象のＣＡＮ（登録商標）データやＥＣＵ内部値

また、センター１００は、スクリプト登録部１０１に登録されたスクリプトが車両データの収集対象とする車両３００にとって妥当であるか否かを解析するセンター側スクリプト解析部１０２を備えている。センター側スクリプト解析部１０２は、車両の車種と、その車種において車両データの収集条件として指定可能な条件式及び車両データの種類との関係を規定する収集可能データテーブルＴ１を備えている。また、この収集可能データテーブルＴ１には、車両データの取り得る値の範囲が車両データの種類に対して関連付けられている。

例えば図２に示すように、本実施の形態の収集可能データテーブルＴ１には、車両３００の内部で流れている信号を条件式Ａ（トリガー）の判定要素として指定するための変数Ａ１と、これら変数Ａ１が指定する信号の有無Ａ２と、これら変数Ａ１について条件式Ａが比較対象とする値である設定値の範囲Ａ３とが車種ごとに関連付けされている。なお、設定値の範囲Ａ３は、変数Ａ１として指定された信号が通常であれば取り得ることが想定される値の範囲を示したものである。例えば図２に示す例では、「ＡＣＣ（アダプティブクルーズコントロール）信号」といった変数Ａ１に対応する設定値の範囲Ａ３として「ＯＮ ｏｒ ＯＦＦ」が設定されるとともに、「車速」といった変数Ａ１に対応する設定値の範囲Ａ３として「０以上」が設定されている。またこの例では、「車種Ａ」及び「車種Ｃ」は、変数Ａ１が指定する信号として「ＡＣＣ信号」及び「車速」の双方を有する一方で、「車種Ｂ」は、これら信号のうち「車速」を有するものの「ＡＣＣ信号」は有していない。

また、収集可能データテーブルＴ１には、車両データの収集時における車載ＥＣＵの動作の信頼性を高めるために、条件式Ａの判定要素となる変数Ａ１ごとに設定可能なチェック周期の下限値が関連付けられている。例えば図２に示す例では、「ＡＣＣ信号」といった変数Ａ１に対して設定可能なチェック周期の下限値Ｃ１として「Ｔｃ１」が設定されるとともに、「車速」といった変数Ａ１に対して設定可能なチェック周期の下限値Ｃ２として「Ｔｃ２」が設定されている。

また、収集可能データテーブルＴ１には、車両データの種類Ｂが例えばＣＡＮからなる車両ネットワークＮＷを流れる信号の種類を示すＣＡＮデータＢ１と、車両ネットワークＮＷに接続された各種の車載ＥＣＵ（電子制御装置）の内部を流れる信号の種類を示すＥＣＵ内部値Ｂ２とに区分されている。そして、この収集可能データテーブルＴ１には、車両データの種類Ｂと、それら車両データの有無Ｂ３，Ｂ４とが車種ごとに関連付けられている。この例えば図２に示す例では、車両データの種類が、「ＡＣＣ信号」及び「車速」といったＣＡＮデータＢ１と、主にスポーツ車に採用される走行モードの一種である「ＶＳＣ（横滑り防止）スポーツモード」といったＥＣＵ内部値Ｂ２とに区分されている。またこの例では、「車種Ａ」は、「ＡＣＣ信号」及び「車速」といったＣＡＮデータＢ１を有するものの、「ＶＳＣスポーツモード」といったＥＣＵ内部値Ｂ２を有していない。その一方で、「車種Ｂ」は、「車速」といったＣＡＮデータＢ１を有するものの、「ＡＣＣ信号」といったＣＡＮデータＢ１は有しておらず、また「ＶＳＣスポーツモード」といったＥＣＵ内部値Ｂ２も有していない。また、「車種Ｃ」は、「ＡＣＣ信号」及び「車速」といったＣＡＮデータＢ１を有するとともに、「ＶＳＣスポーツモード」といったＥＣＵ内部値Ｂ２も有している。

また、収集可能データテーブルＴ１には、同じく車両データの収集時における車載ＥＣＵの動作の信頼性を高めるために、車両データの種類Ｂごとに設定可能なサンプリング周期の下限値が関連付けられている。例えば図２に示す例では、「ＡＣＣ信号」といったＣＡＮデータＢ１に対して設定可能なサンプリング周期の下限値Ｃ２として「Ｔｓ１」が設定されるとともに、「車速」といったＣＡＮデータＢ１に対して設定可能なサンプリング周期の下限値Ｃ２として「Ｔｓ２」が設定されている。また、この例では、「ＶＳＣスポーツモード」といったＥＣＵ内部値Ｂ２に対して設定可能なサンプリング周期の下限値Ｃ２として「Ｔｓ３」が設定されている。

そして、センター側スクリプト解析部１０２は、上述した収集可能データテーブルＴ１を参照しつつ、スクリプト登録部１０１に登録されたスクリプトの妥当性を解析する（図５、図６、図７）。

すなわち、センター側スクリプト解析部１０２は、スクリプトが指定する条件式の妥当性をチェックする際には、まずスクリプトから条件式を抽出する（図５のステップＳ１１）。続いて、収集可能データテーブルＴ１を参照して対象とする車両３００の車種から該当する変数Ａ１を割り出す。そして、この割り出した変数Ａ１と、スクリプトが指定する条件式の変数とが合致するか否かに基づき、条件式の変数が利用可能であるか否かを判定する（図５のステップＳ１３）。また、条件式の変数が利用可能であると判定したときには（図５のステップＳ１３＝ＹＥＳ）、再び収集可能データテーブルＴ１を参照してスクリプトが指定する条件式の変数から該当する設定値の範囲Ａ３を割り出す。そして、設定値の範囲Ａ３内にスクリプトが指定する条件式の設定値が収まるか否かを判定する（図５のステップＳ１４）。

その後、センター側スクリプト解析部１０２は、条件式の設定値が設定値の範囲Ａ３内に収まるときには（図５のステップＳ１４＝ＹＥＳ）、スクリプトが指定する条件式が妥当であると判断する。その一方で、センター側スクリプト解析部１０２は、条件式の変数が利用可能ではないとき（図５のステップＳ１３＝ＮＯ）、又は、条件式の設定値が設定値の範囲Ａ３内にないときには（図５のステップＳ１４＝ＮＯ）、スクリプトが指定する条件式が妥当ではないと判断する。

また、センター側スクリプト解析部１０２は、スクリプトが指定する車両データの種類の妥当性をチェックする際には、まずスクリプトから車両データの種類を抽出する（図６のステップＳ２１）。続いて、収集可能データテーブルＴ１を参照して対象とする車両３００の車種から該当する車両データの種類Ｂを割り出す（図６のステップＳ２２）。そして、この割り出した車両データの種類Ｂと、スクリプトが収集対象として指定する車両データの種類とが合致するか否かに基づき、スクリプトが収集対象として指定する車両データの種類が利用可能であるか否かを判定する（図６のステップＳ２３）。

その後、センター側スクリプト解析部１０２は、車両データの種類が利用可能であるときには（図６のステップＳ２３＝ＹＥＳ）、スクリプトが指定する車両データの種類が妥当であると判断する。その一方で、センター側スクリプト解析部１０２は、車両データの種類が利用可能でないときには（図６のステップＳ２３＝ＮＯ）、スクリプトが指定する車両データの種類が妥当ではないと判断する。

また、センター側スクリプト解析部１０２は、スクリプトが指定するチェック周期及びサンプリング周期の妥当性をチェックする際には、まずスクリプトからこれら周期情報を抽出する（図７のステップＳ３１）。続いて、収集可能データテーブルＴ１を参照してスクリプトが指定する条件式の変数から該当するチェック周期の下限値Ｔｃ１，Ｔｃ２を割り出すとともに、スクリプトが収集対象として指定する車両データの種類から該当するサンプリング周期の下限値Ｔｓ１，Ｔｓ２，Ｔｓ３を割り出す（図７のステップＳ３２）。

続いて、スクリプトが指定するチェック周期が下限値Ｔｃ１，Ｔｃ２以上であるか否かを判定する（図７のステップＳ３３）。そして、スクリプトが指定するチェック周期が下限値Ｔｃ１，Ｔｃ２以上であるときには（図７のステップＳ３３＝ＹＥＳ）、スクリプトが指定するサンプリング周期が下限値Ｔｓ１，Ｔｓ２，Ｔｓ３以上であるか否かを判定する（図７のステップＳ３４）。

その後、センター側スクリプト解析部１０２は、スクリプトが指定するサンプリング周期が下限値Ｔｓ１，Ｔｓ２，Ｔｓ３以上であるときには（図７のステップＳ３４＝ＹＥＳ）、スクリプトが指定する周期情報が妥当であると判断する。その一方で、センター側スクリプト解析部１０２は、スクリプトが指定するチェック周期が下限値Ｔｃ１，Ｔｃ２を下回るとき（図７のステップＳ３３＝ＮＯ）、又は、スクリプトが指定するサンプリング周期が下限値Ｔｓ１，Ｔｓ２，Ｔｓ３を下回るときには（図７のステップＳ３４＝ＮＯ）、スクリプトが指定する周期情報が妥当ではないと判断する。

例えば、対象とする車両３００が「車種Ｂ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが指定する条件式の変数が「ＡＣＣ信号」であれば、「車種Ｂ」が「ＡＣＣ信号」を有さないことから、このスクリプトが妥当ではないと判断される。また、対象とする車両が「車種Ｃ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが指定する条件式が「車速＜０」であれば、「車速」に対応する設定値の範囲Ａ３として「０以上」が設定されていることから、このスクリプトが妥当ではないと判断される。また、対象とする車両３００が「車種Ａ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが指定する条件式の変数が「ＡＣＣ信号」であるときに、スクリプトが指定するチェック周期が「Ｔｃ１」を下回るのであれば、このスクリプトが妥当ではないと判断される。また、対象とする車両３００が「車種Ｂ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが収集対象として指定するＣＡＮデータが「ＡＣＣ信号」であれば、「車種Ｂ」が「ＡＣＣ信号」を有さないことから、このスクリプトが妥当ではないと判断される。また、対象とする車両が「車種Ａ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが収集対象として指定するＥＣＵ内部値が「ＶＳＣスポーツモード」であれば、「車種Ａ」が「ＶＳＣスポーツモード」を有さないことから、このスクリプトが妥当ではないと判断される。また、対象とする車両３００が「車種Ａ」であって、且つ、スクリプト登録部１０１に登録されたスクリプトが収集対象として指定するＣＡＮデータが「ＡＣＣ信号」であるときに、スクリプトが指定するサンプリング周期が「Ｔｓ１」を下回るのであれば、このスクリプトが妥当ではないと判断される。

そして、センター側スクリプト解析部１０２は、スクリプトが妥当ではないと判断したときには、エラー応答をセンター通信機１０３を通じて外部端末２００に出力する（図５のステップＳ１６、図６のステップＳ２５、図７のステップＳ３６）。その一方で、センター側スクリプト解析部１０２は、スクリプトが妥当であると判断したときには、正常応答として、そのスクリプトを含む送信メッセージを作成するとともに、その作成した送信メッセージをセンター通信機１０３から無線通信にて車両３００に送信する（図５のステップＳ１５、図６のステップＳ２４、図７のステップＳ３５）。

車両３００は、センター１００との間で無線通信にて上記送信メッセージを含めた各種の情報を授受する車載通信機３１０を備えている。車載通信機３１０は、センター１００からの送信メッセージを通信部３１１を通じて受信したときには、その受信した送信メッセージからスクリプトを抽出してスクリプト格納部３１２に一時保存するとともに、その保存したスクリプトを車両側スクリプト解析部３１３に入力する。

車両側スクリプト解析部３１３は、入力されたスクリプトが指定する条件に基づき車両データを収集したとしても、車両のリソースが適正に維持されるか否かを解析する。
具体的には、車両側スクリプト解析部３１３は、車両リソースの一種として、車載通信機３１０が車両データの収集時にデータを一時的に保存するためのメモリの空き容量を解析する（図８）。この際、車両側スクリプト解析部３１３は、まず以下の［式１］に基づきスクリプトの実行時に必要となる追加のメモリ使用量を算出する（図８のステップＳ４１）。

追加のメモリ使用量＝（スクリプト実行領域サイズ）＋（トリガー変数合計サイズ）
＋（一時格納データサイズ）・・・［式１］

なお、「スクリプト実行領域サイズ」とは、スクリプトを格納したファイルのデータサイズを意味している。また、「トリガー変数合計サイズ」とは、車両データの収集時に用いられる条件式Ａにおいて変数Ａ１として使用する車両データのデータサイズの合計を意味している。また、「一時格納データサイズ」とは、以下の（Ｄ１）〜（Ｄ３）のデータサイズの合計を意味している。

（Ｄ１）スクリプトにより収集対象として指定されているＣＡＮデータの一時格納デー
タサイズ
（Ｄ２）ＣＣＰ（ＣＡＮキャリブレーションプロトコル）にて収集するＥＣＵ内部値の
一時格納データサイズ
（Ｄ３）ダイアグ通信にて収集するＥＣＵ内部値の一時格納データ量

なお、ＣＣＰとは、車両ネットワークＮＷに接続された複数の車載ＥＣＵにおけるＥＣＵ内部値の同期（キャリブレーション）を図るためのプロトコルの一種である。そして、このＣＣＰで定められたキャリブレーションを実行することにより、時間同期の図られたＥＣＵ内部値がダイアグ通信を通じて複数の車載ＥＣＵから取得されることとなる。

続いて、車両側スクリプト解析部３１３は、算出した追加のメモリ使用量を現在のメモリ使用量に合算し、その合算したメモリ使用量が予め設定したメモリ使用量の上限値を超えないか否かを判断する（図８のステップＳ４２）。

ここで、車両側スクリプト解析部３１３は、メモリ使用量の上限値を超えると判断したときには（図８のステップＳ４２＝ＮＯ）、スクリプトが指定する条件に基づく車両データの収集を実行したとすると車両のリソースが適正に維持されない旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、スクリプトが指定する条件に基づく車両データの収集を実行すべきではない旨を示すエラー応答を通信部３１１を介してセンター通信機１０３を経由して外部端末２００に出力する（図８のステップＳ４４）。

その一方で、車両側スクリプト解析部３１３は、メモリ使用量の上限値を超えないと判断したときには（図８のステップＳ４２＝ＹＥＳ）、スクリプトが指定する条件に基づく車両データの収集を実行したとしても車両のリソースが適正に維持される旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、正常応答として、スクリプトが指定する条件に基づく車両データの収集を開始すべく、その解析対象となったスクリプトをスクリプト解釈実行部３１４に入力する（図８のステップＳ４３）。

また、車両側スクリプト解析部３１３は、車両リソースの一種として、車載通信機３１０が収集後の車両データを保存するためのストレージの空き容量も解析する（図９）。この際、車両側スクリプト解析部３１３は、スクリプトの実行時に必要となる追加のストレージ使用量を算出する（図９のステップＳ５１）。ここで、追加のストレージ使用量とは、以下の（Ｄ４）〜（Ｄ６）のデータ量の合計を意味している。

（Ｄ４）スクリプトにより収集対象として指定されているＣＡＮデータのデータ量
（Ｄ５）ＣＣＰにて収集するＥＣＵ内部値のデータ量
（Ｄ６）ダイアグ通信にて収集するＥＣＵ内部値のデータ量

そして、車両側スクリプト解析部３１３は、算出した追加のストレージ使用量を現在のストレージ使用量に合算し、その合算したストレージ使用量が予め設定したストレージ使用量の上限値を超えないか否かを判断する（図９のステップＳ５２）。

ここで、車両側スクリプト解析部３１３は、ストレージ使用量の上限値を超えると判断したときには（図９のステップＳ５２＝ＮＯ）、スクリプトが指定する条件に基づく車両データの収集を実行したとすると車両のリソースが適正に維持されない旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、スクリプトが指定する条件に基づく車両データの収集を実行すべきではない旨を示すエラー応答を通信部３１１を介してセンター通信機１０３を経由して外部端末２００に出力する（図９のステップＳ５４）。

その一方で、車両側スクリプト解析部３１３は、ストレージ使用量の上限値を超えないと判断したときには（図９のステップＳ５２＝ＹＥＳ）、スクリプトが指定する条件に基づく車両データの収集を実行したとしても車両のリソースが適正に維持される旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、正常応答として、スクリプトが指定する条件に基づく車両データの収集を開始すべく、その解析対象となったスクリプトをスクリプト解釈実行部３１４に入力する（図９のステップＳ５３）。

また、車両側スクリプト解析部３１３は、車両リソースの一種として、車両データの収集時における車両ネットワークＮＷのバス占有率を解析する（図１０）。この際、車両側スクリプト解析部３１３は、スクリプトの実行時に必要となる追加のバス占有率を算出する（図１０のステップＳ６１）。ここで、追加のバス占有率とは、以下の（Ｄ７）〜（Ｄ８）のバス占有率の合計を意味している。

（Ｄ７）ＣＣＰによりＥＣＵ内部値を収集した場合のバス占有率
（Ｄ８）ダイアグ通信によりＥＣＵ内部値を収集した場合のバス占有率

そして、車両側スクリプト解析部３１３は、算出した追加のバス占有率を現在のバス占有率に合算し、その合算したバス占有率が予め設定したバス占有率の上限値を超えないか否かを判断する（図１０のステップＳ６２）。

ここで、車両側スクリプト解析部３１３は、バス占有率の上限値を超えると判断したときには（図１０のステップＳ６２＝ＮＯ）、スクリプトが指定する条件に基づく車両データの収集を実行したとすると車両のリソースが適正に維持されない旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、スクリプトが指定する条件に基づく車両データの収集を実行すべきではない旨を示すエラー応答を通信部３１１を介してセンター通信機１０３を経由して外部端末２００に出力する（図１０のステップＳ６４）。

その一方で、車両側スクリプト解析部３１３は、バス占有率の上限値を超えないと判断したときには（図１０のステップＳ６２＝ＹＥＳ）、スクリプトが指定する条件に基づく車両データの収集を実行したとしても車両のリソースが適正に維持される旨の解析結果を得る。その結果、車両側スクリプト解析部３１３は、正常応答として、スクリプトが指定する条件に基づく車両データの収集を開始すべく、その解析対象となったスクリプトをスクリプト解釈実行部３１４に入力する（図１０のステップＳ６３）。

スクリプト解釈実行部３１４は、スクリプトの命令を順次読み込んで実行することにより、スクリプトが指定する条件に基づく車両データの収集を車両ネットワーク通信部３１５を通じて行う。

車両ネットワーク通信部３１５には、各種の車載装置の動作を制御するための車載ＥＣＵが車両ネットワークＮＷを介して接続されている。ここで、車載ＥＣＵには、例えば車両の窓やドア等の電装品の動作を制御するボディＥＣＵ３２０や、ブレーキの動作を制御するブレーキＥＣＵ３２１等が含まれる。なお、ボディＥＣＵ３２０には、エンジンの電源モードをＩＧ（イグニッション）モード、ＡＣＣモード、及びＯＦＦモード等の間で切り替える際に操作されるエンジンスイッチ３２２が接続されている。また、ブレーキＥＣＵ３２１には、車両３００の車速を検出する車速センサ３２３や、ドライバによるブレーキペダルの踏込み量を検出するブレーキセンサ３２４が接続されている。

また、車両ネットワーク通信部３１５は、収集対象とする車両データの種類と、それら車両データの取得元となる車載ＥＣＵやそれら車載ＥＣＵのネットワーク識別値との関係を規定する情報収集テーブルＴ２を備えている。

例えば図３に示すように、本実施の形態の情報収集テーブルＴ２には、「車速」及び「ブレーキ踏込み量」といった車両データの取得元となる車載ＥＣＵとして「ブレーキＥＣＵ」が、またそのネットワーク識別値として「ＣＡＮ‐ＩＤ１」がそれぞれ関連付けられている。また、この情報収集テーブルＴ２には、「ＩＧ‐ＯＮ回数」といった車両データの取得元となる車載ＥＣＵとして「ボディＥＣＵ」が、またそのネットワーク識別値として「ＣＡＮ‐ＩＤ２」がそれぞれ関連付けられている。

そのためこの例では、例えばスクリプトが収集対象となる車両データの種類として「車速」及び「ＩＧ‐ＯＮ回数」といった車両データを指定していれば、車両ネットワーク通信部３１５は、これら車両データに関連付けられたネットワーク識別値として「ＣＡＮ‐ＩＤ１」及び「ＣＡＮ‐ＩＤ２」を情報収集テーブルＴ２から特定する。そして、車両ネットワーク通信部３１５は、この特定したネットワーク識別値からそれら車両データの取得元である「ブレーキＥＣＵ」及び「ボディＥＣＵ」をそれぞれ割り出し、「車速」及び「ＩＧ‐ＯＮ回数」といった車両データを車両ネットワークＮＷを通じてそれぞれ収集する。

そして、図１に示すように、車両ネットワーク通信部３１５は、車両ネットワークＮＷを通じて収集した車両データを上述したストレージとして機能する車両データ格納部３１６に格納する。この車両データ格納部３１６に格納された車両データは、車載通信機３１０からセンター通信機１０３に送信された後、センター１００が備える車両データ格納部１０４に一時的に格納されるなどして外部端末２００に取り込まれる。

次に、本実施の形態の車両データのリモート収集システムの作用について図４を参照して説明する。
図４に示すように、外部端末２００を通じてエンジニア等からスクリプトが入力されると、その入力されたスクリプトがセンター１００に登録される。そして、この登録されたスクリプトの妥当性のチェックが収集可能データテーブルＴ１を参照しつつセンター１００側で行われる。このスクリプトの妥当性のチェックには、車両データを収集するときの条件式Ａの妥当性のチェック（「条件式チェック」）、収集対象としている車両データの種類の妥当性のチェック（「データ種類チェック」）、及び、車両データを収集するときのチェック周期及びサンプリング周期のチェック（「周期チェック」）が含まれる。ここで、本実施の形態では、車両データを収集するときの収集条件の指定がスクリプト入力により高い自由度を持って実現されていることから、条件式Ａの判定要素として指定される変数Ａ１の種類、及び、収集対象とする車両データの種類Ｂが多岐に亘っている。そのため、収集可能データテーブルＴ１は、そのデータ量が膨大となることは避けられず、ストレージ容量に限りのある車両３００側で管理することは困難である等の理由から、ストレージ容量に比較的自由度のあるセンター１００側で管理されている。そして、こうした収集可能データテーブルＴ１を参照しつつスクリプトの妥当性のチェックが行われる際には、収集可能データテーブルＴ１の情報はセンター１００内で処理されることとなり、センター１００と車両３００との間で通信されることはない。

また、スクリプトの妥当性のチェックがセンター１００側で行われた後には、そのスクリプトが指定する条件に基づき車両データを収集したときの車両のリソースのチェックが車両側で行われる。この車両のリソースのチェックには、車載通信機３１０のメモリの空き容量のチェック（「メモリチェック」）、車載通信機３１０のストレージの空き容量のチェック（「ストレージチェック」）、及び、車両ネットワークＮＷのバス占有率のチェック（「バス占有率チェック」）が含まれる。そして、こうした車両３００のリソースのチェックが行われる際、その都度の車両のリソースの情報は車両３００側で取得されることとなり、センター１００と車両３００との間で通信されることはない。

また、車両のリソースのチェックが車両３００側で行われた後には、そのスクリプトの実行に伴ってスクリプトが指定する条件に基づく車両データの収集が車両３００側で行われる。この収集された車両データは、車両３００からセンター１００に送信された後、センター１００が備えるデータ閲覧ＵＩ（ユーザインタフェース）によって外部端末２００に出力表示される。

以上説明したように、上記実施の形態によれば、以下に示す効果を得ることができる。
（１）条件式Ａ、車両データの種類Ｂ、条件式Ａのチェック周期、及び車両データのサンプリング周期の妥当性をセンター１００自身が備える収集可能データテーブルＴ１に基づきセンター１００側でチェックするようにした。また、スクリプトが指定する条件に基づき車両データを収集したときの車両のリソースの適正度合いを車両３００側でチェックするようにした。そのため、上述したチェックの何れについても車両３００とセンター１００との間の通信が不要となるため、車両３００の通信環境等の影響を抑えつつ、センター１００を介した要求に応じて車両データを的確に収集することができるようになる。

（２）センター１００が備える収集可能データテーブルＴ１には、車両３００の車種と、その車種において取得可能な車両データの種類Ｂとが関連付けされている。そのため、センター１００は、この収集可能データテーブルＴ１を用いて、スクリプトが収集対象として指定している車両データの種類Ｂが車両３００にとって収集可能なものであるか否かをチェックすることができるようになる。

（３）センター１００が備える収集可能データテーブルＴ１には、車両データの取り得る値の範囲が車両データの種類Ｂに対して関連付けられている。そのため、センター１００は、この収集可能データテーブルＴ１を用いて、スクリプトが指定する条件式Ａが車両３００にとって妥当なものであるか否かをチェックすることができるようになる。

（４）センター１００が備える収集可能データテーブルＴ１には、設定可能なチェック周期の下限値Ｔｃ１，Ｔｃ２が条件式Ａの変数Ａ１に関連付けられている。そのため、センター１００は、この収集可能データテーブルＴ１を用いて、スクリプトが指定するチェック周期が車両３００にとって妥当なものであるか否かをチェックすることができるようになる。

（５）センター１００が備える収集可能データテーブルＴ１には、設定可能なサンプリング周期の下限値Ｔｓ１，Ｔｓ２，Ｔｓ３が車両データの種類Ｂに対して関連付けられている。そのため、センター１００は、この収集可能データテーブルＴ１を用いて、スクリプトが指定するサンプリング周期が車両３００にとって妥当なものであるか否かをチェックすることができるようになる。

（６）車両データの収集を実行する前に車載通信機３１０のメモリ及びストレージの空き容量を車両３００側で予めチェックするようにした。そのため、センター１００を介した要求に応じて車両データを的確に収集することができるようになる。

（７）車両データの収集を実行する前に車両ネットワークＮＷのバス占有率を予め車両３００側でチェックするようにした。そのため、センター１００を介した要求に応じて車両データを的確に且つ迅速に収集することができるようになる。

（８）車両データの収集条件は、車両データの収集の際に実行される複数の命令が記述されたスクリプトにより指定されるようにしている。そのため、スクリプトの入力を通じて自由度の高い車両データの収集条件の指定が実現されるようになる。なお、こうしたスクリプトの入力によれば、車両３００に対して指示可能な条件式Ａ、車両データの種類Ｂ、サンプリング周期、及びチェック周期が多岐に亘ることとなり、それら指示項目の車両３００における妥当性が問題となりやすい。また、スクリプト自体のデータサイズやスクリプト実行時の処理負荷等も多様となるため、スクリプトが指定する収集条件に基づき車両データを収集したときの対象車両のリソースが適正に維持されるか否かも問題となりやすい。この点、上記実施の形態によれば、スクリプトが指定する収集条件に基づく車両データの収集が行われる前に予めチェックが行われるため、上述した問題の何れも生じにくくなる。

（９）車両３００は、ＣＡＮからなる車両ネットワークＮＷに接続された複数の車載ＥＣＵを備えており、車両データは、ＣＡＮプロトコルに規定される通信によって複数の車載ＥＣＵから収集される。そのため、車両３００に多く利用されている汎用性の高いＣＡＮプロトコルを利用して車載ＥＣＵからの車両データを収集することができるようになる。

なお、上記実施の形態は、以下のような形態にて実施することもできる。
・上記実施の形態において、車両３００によるチェック対象とされる車両のリソースとして、例えば、車両データの取得元となる車載ＥＣＵのメモリ及びストレージの空き容量等も含めるようにしてもよい。

・上記実施の形態において、車両３００によるチェック対象とされる車両のリソースは、車両３００に搭載されたメモリ及びストレージの空き容量、並びに車両ネットワークＮＷのバス占有率のうちの一部のみが含まれる場合であってもこの発明を適用することはできる。

・上記実施の形態において、車両データを収集するときの条件式Ａ、収集対象とされる車両データの種類Ｂ、及び、車両データを収集するときのチェック周期及びサンプリング周期のうちの一部のみがセンター１００によるチェック対象として含まれる場合であってもこの発明を適用することはできる。

・上記実施の形態において、車両データの収集経路を構成する車両ネットワークＮＷの通信規格はＣＡＮに限らず、例えばＦｌｅｘＲａｙやイーサネット（登録商標）等の他の通信規格であってもこの発明を適用することはできる。

１００…センター、１０１…スクリプト登録部、１０２…センター側スクリプト解析部、１０３…センター通信機、１０４…車両データ格納部、２００…外部端末、３００…車両、３１０…車載通信機、３１１…通信部、３１２…スクリプト格納部、３１３…車両側スクリプト解析部、３１４…スクリプト解釈実行部、３１５…車両ネットワーク通信部、３１６…車両データ格納部、３２０…ボディＥＣＵ、３２１…ブレーキＥＣＵ、３２２…エンジンスイッチ、３２３…車速センサ、３２４…ブレーキセンサ、Ｔ１…収集可能データテーブル、Ｔ２…情報収集テーブル。

Claims (9)

1. 複数の車両の走行情報を管理するセンターから対象車両に対し収集対象とされる車両データの種類、車両データを収集するときの条件式、車両データを収集するときのサンプリング周期、もしくは、条件式のチェック周期を無線通信にて指示し、その対象車両に対する指示に基づき収集される車両データを無線通信にてセンターに取り込む車両データのリモート収集システムであって、
   前記センターは、前記対象車両に対して指示する車両データの種類、条件式、サンプリング周期、チェック周期の少なくとも一つの妥当性を、前記センター自身が備えるチェック基準に基づきチェックするセンター側チェック部を備え、
   前記対象車両は、前記センターからの指示に基づく車両データの収集時における対象車両のリソースが適正であるか否かをチェックする車両側チェック部を備える
   ことを特徴とする車両データのリモート収集システム。
2. 前記センター自身が備えるチェック基準は、前記対象車両の車種と、その車種において取得可能な車両データの種類とが関連付けされたデータベースに規定されており、
   前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する車両データの種類を割り出し、この割り出した車両データの種類と、前記対象車両に対して収集対象として指示した車両データの種類とが合致することを条件に、車両データの種類が妥当であると判断する
   請求項１に記載の車両データのリモート収集システム。
3. 前記データベースには、車両データの取り得る値の範囲が車両データの種類に対して関連付けられており、
   前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から収集対象としている車両データの取り得る値の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示した条件式を満たす車両データのデータ値範囲が収まることを条件に、車両データの条件式が妥当であると判断する
   請求項２に記載の車両データのリモート収集システム。
4. 前記データベースには、設定可能なチェック周期の範囲が条件式に対して関連付けられており、
   前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する条件式において設定可能なチェック周期の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示したチェック周期が収まることを条件に、チェック周期が妥当であると判断する
   請求項２又は請求項３に記載の車両データのリモート収集システム。
5. 前記データベースには、設定可能なサンプリング周期の範囲が車両データの種類に対して関連付けられており、
   前記センター側チェック部は、前記データベースに基づいて前記対象車両の車種から該当する車両データの種類において設定可能なサンプリング周期の範囲を割り出し、この割り出した範囲内に前記対象車両に対して指示したサンプリング周期が収まることを条件に、サンプリング周期が妥当であると判断する
   請求項２〜４の何れか一項に記載の車両データのリモート収集システム。
6. 前記車両側チェック部によってチェック対象とされる対象車両のリソースは、当該対象車両に搭載されたメモリ又はストレージの空き容量を含む
   請求項１〜５の何れか一項に記載の車両データのリモート収集システム。
7. 前記車両側チェック部によってチェック対象とされる対象車両のリソースは、当該対象車両に搭載された車両ネットワークのバス占有率を含む
   請求項１〜６の何れか一項に記載の車両データのリモート収集システム。
8. 前記車両データの収集条件は、１乃至複数の命令が記述されたスクリプトにより指定される
   請求項１〜７の何れか一項に記載の車両データのリモート収集システム。
9. 前記対象車両は、コントローラエリアネットワーク（ＣＡＮ（登録商標））に接続された複数の車載制御装置を備えており、
   前記車両データは、ＣＡＮプロトコルに規定される通信によって１乃至複数の車載制御装置から収集される
   請求項１〜８の何れか一項に記載の車両データのリモート収集システム。

Images