JP7059684B2 - 異常検知データ識別装置、および異常識別システム - Google Patents

Description

本発明は、異常が検出される場合に車両の位置と異常が発生した旨との情報を含む異常検知データを出力する車載異常通知装置からの前記異常検知データを受信する異常検知データ識別装置に関する。

たとえば下記特許文献１には、車両に搭載された装置が車両内の異常を検知する場合、情報センタ内のサーバに異常情報を送信する装置が記載されている。特にこの装置は、車両の位置がサービス工場内にある場合、異常情報の送信を禁止する。

国際公開第２００９／３８０２８号

ところで、上記の場合、修理中に生じた異常情報を情報センタにおいて認知すべき異常情報であると誤判定することを回避する上では、車両側の装置において、サービス工場であることを判定する必要がある。また、仮にサービス工場を登録し、登録したサービス工場であることを判定できる機能を搭載したところで、登録されていない修理工場等での修理中に異常情報が送信される場合には、情報センタ側で認知すべき異常情報であると誤判定するおそれがある。

以下、上記課題を解決するための手段およびその作用効果について記載する。
１．異常が検出される場合に車両の位置と異常が発生した旨との情報を含む異常検知データを出力する車載異常通知装置からの前記異常検知データを受信する異常検知データ識別装置において、処理回路と、記憶装置と、を備え、前記処理回路は、前記異常検知データを受信する受信処理と、前記受信した異常検知データを前記記憶装置に記録する記録処理と、前記受信した異常検知データが車両の修理に起因して生じた可能性の高低を判定する判定処理と、を実行し、前記判定処理は、前記記憶装置に記録された前記異常検知データのうち、判定対象とする異常検知データである対象データに基づき把握される前記異常が発生したときの前記車両の位置から所定範囲内において出力された前記異常検知データの数が所定数以上である場合に所定数未満である場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する処理である。

異常が発生した位置から所定範囲内における異常発生回数が多い場合には、所定範囲内には修理工場等があり、異常の発生は、修理に起因して生じたものである可能性がある。そこで上記構成では、所定範囲内における異常検知データの数が所定数以上である場合に所定数未満である場合よりも異常検知データが修理に起因して生じた可能性が高いと判定する。これにより、認知すべき異常であると誤判定することを抑制できる。

２．上記１記載の異常検知データ識別装置において、前記異常検知データは、異常が発生した時間に関する情報を含み、前記判定処理は、前記対象データに基づき、修理地点候補を特定する特定処理と、前記記憶装置に記録された前記異常検知データのうちの前記修理地点候補から規定範囲内において出力された前記異常検知データに基づき、時間帯毎の異常の発生回数を集計する時間帯別集計処理と、前記時間帯別集計処理によって分類された前記時間帯のうちの前記対象データが示す時間に該当するものにおける前記異常の発生回数が多い場合に少ない場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する時間帯別判定処理と、を含む。

車両の修理がなされるのは、たとえば修理工場における作業員の勤務時間等に依存することから、修理に起因して異常が生じる場合には、その異常発生回数が多くなる時間帯が存在する傾向にある。このため、上記構成では、時間帯別集計処理および時間帯別判定処理を設けることにより、異常検知データが多く出力される領域において、それらが実際に修理によって生じたものであるか否かをより精度良く判定することができる。

３．上記１または２記載の異常検知データ識別装置において、前記異常検知データは、前記異常が発生したときの車速に関する情報を含み、前記判定処理は、前記車速が小さい場合に大きい場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する車速反映判定処理を含む。

車両の修理は車速が小さいときに実行される可能性が高いと考えられることから、上記車速反映判定処理を設けることにより、異常検知データが多く出力される領域において、それらが実際に修理によって生じたものであるか否かをより精度良く判定することができる。

４．上記１～３のいずれか１つに記載の異常検知データ識別装置において、前記異常検知データは、前記異常が発生した曜日に関する情報を含み、前記判定処理は、前記対象データに基づき、修理地点候補を特定する特定処理と、前記記憶装置に記録された前記異常検知データのうちの前記修理地点候補から規定範囲内において出力された前記異常検知データに基づき、前記曜日毎の異常の発生回数を集計する曜日別集計処理と、前記曜日別集計処理による曜日の分類のうちの前記対象データが示す曜日に該当するものにおける前記異常の発生回数が多い場合に少ない場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する曜日別判定処理と、を含む。

車両の修理がなされるのは、たとえば修理工場における作業員の出勤日等に依存することから、修理に起因して異常が生じる場合には、その異常発生回数が多くなる曜日が存在する傾向にある。このため、上記構成では、曜日別集計処理および曜日別判定処理を設けることにより、異常検知データが多く出力される領域において、それらが実際に修理によって生じたものであるか否かをより精度良く判定することができる。

５．上記１～４のいずれか１つに記載の異常検知データ識別装置において、前記異常検知データは、前記車両を特定する情報を含み、前記判定処理は、前記記憶装置に記録された前記異常検知データに基づき、同一車両の異常の発生回数を集計する同一車両データ収集処理と、前記対象データによって特定される車両と同一車両の異常の発生回数が多い場合に少ない場合よりも、当該異常検知データが前記車両の修理に起因して生じた可能性が高いと判定する車両別判定処理と、を含む。

車両を自分で修理したり改造したりする車両のユーザも一定数存在し得る。こうしたユーザの車両からは異常検知データが多数出力される可能性がある。このため、上記構成では、同一車両における異常の発生回数が多い場合にはそれが実際には改造である場合も含めて修理の可能性が高いと判定することにより、対象データが実際に改造や修理によって生じたものである場合に、認知すべき異常であると誤判定することを抑制できる。

６．上記２または４記載の異常検知データ識別装置において、前記特定処理は、前記記憶装置に記録された過去の前記異常検知データから特定される前記車両の位置のうちの前記対象データから特定される前記車両の位置から予め定められた距離内に含まれるものに基づき、それら位置の平均値である重心を算出する重心算出処理を含み、前記算出された重心に基づき前記修理地点候補を特定する処理を含む。

ＧＰＳの性能等に起因して異常検知データの位置情報の精度が低い場合、異常検知データに含まれる位置情報のみから修理地点候補を定める場合には、その精度が低くなる懸念がある。そこで上記構成では、付近で生じた異常検知データのそれぞれが有する位置情報が示す車両の位置の重心を求めることによって、修理地点候補を定める。

７．上記６記載の異常検知データ識別装置において、前記特定処理は、前記重心算出処理によって算出された重心を第１重心の初期値とし、前記記憶装置に記録された過去の前記異常検知データから特定される前記車両の位置のうちの前記第１重心から前記予め定められた距離内に含まれるものに基づき、それら位置の平均値である第２重心を算出する第２重心算出処理と、前記対象データから特定される前記車両の位置と前記第２重心との距離が閾値よりも大きい場合、前記第１重心を前記修理地点候補とする第１選択処理と、前記対象データから特定される前記車両の位置と前記第２重心との距離が前記閾値以下であって、前記第１重心と前記第２重心との距離が規定値以下である場合、前記第２重心を前記修理地点候補とする第２選択処理と、を含み、前記第１重心と前記第２重心との距離が規定値よりも大きい場合、前記第１重心に前記第２重心を代入し、前記第２重心算出処理を実行する処理である。

上記構成では、第２重心算出処理を用いることにより、重心算出処理によって算出された重心を修理地点候補とする場合と比較すると、修理地点候補を、実際の修理地点としてより信頼性の高いものとすることができる。

８．上記１～７のいずれか１つに記載の異常検知データ識別装置において、前記処理回路は、前記異常検知データに基づく異常が発生した旨の情報と、当該情報に対応する前記判定処理による判定結果とを紐づけたデータを、表示装置による表示に用いるべく出力する出力処理を実行する。

上記出力処理によって出力されたデータは、異常が発生した旨の情報に判定結果が紐づけられているため、同データを視覚情報として表示装置に表示することにより、異常が発生した旨の情報が認知すべき情報であるか否かを簡易に判断することができる。

９．上記１～８のいずれか１つに記載の異常検知データ識別装置と、前記車載異常通知装置と、を備える異常識別システム。
１０．上記１～８のいずれか１つに記載の前記判定処理をコンピュータによって実行させる異常識別プログラム。

一実施形態にかかる異常識別システムを示す図。 同実施形態にかかる車両内の処理の手順を示す流れ図。 同実施形態にかかる異常検知データを示す図。 同実施形態にかかるセンタ内の処理の手順を示す流れ図。 同実施形態にかかるデータ収集処理の手順を示す流れ図。 同実施形態にかかる重心の算出例を示す図。 同実施形態にかかるデータ解析処理の手順を示す流れ図。 同実施形態にかかる曜日別集計処理を示す図。 同実施形態にかかる時間帯別集計処理を示す図。 同実施形態にかかる車両別集計処理を示す図。 同実施形態にかかる最終判定処理を示す図。 同実施形態にかかるデータの送信に関する処理の手順を示す流れ図。

以下、異常検知データ識別装置にかかる一実施形態について図面を参照しつつ説明する。
図１に示す車両１は、異常通知装置１０を搭載している。異常通知装置１０は、ＣＰＵ１２、ＲＯＭ１４、通信機１６、ＧＰＳ１８およびセンサ類２０を備え、それらがネットワーク２２によって通信可能とされている。

図２に、異常通知装置１０が実行する処理の手順を示す。図２に示す処理は、ＲＯＭ１４に記憶されたプログラムをＣＰＵ１２がたとえば所定周期で繰り返し実行することにより実現される。なお、以下では、先頭に「Ｓ」が付与された数字によって各処理のステップ番号を表現する。

図２に示す一連の処理において、ＣＰＵ１２は、まず、センサ類２０の出力値に基づき、車両内に異常があるか否かを判定する（Ｓ１０）。ここでの異常には、異常が生じた場合に車両のユーザに通知する異常と、通知しない異常とが含まれる。ここで、ユーザに通知する異常とは、修理工場にて修理してもらうことをユーザに促すことが要求される異常である。一方、通知しない異常とは、修理の必要まではないものの、製品の改善等にとって示唆に富む情報となりうる異常であり、車両の開発等において有益な情報となりうる異常である。具体的には、異常とは、たとえば電子回路のコネクタの接続不良等がある。ＣＰＵ１２は、異常があると判定する場合、異常検知データを生成する（Ｓ１２）。異常検知データは、いわゆるＦＦＤ（Ｆｒｅｅｚｅ Ｆｒａｍｅ Ｄａｔａ）である。

図３に、異常検知データを示す。図３に示すように、異常検知データは、車両を特定する車両ＩＤと、異常の種類に関する情報と、異常が発生したときの位置ＰＤに関する情報とを含む。ここで、位置ＰＤは、ＣＰＵ１２により、異常が発生したときのＧＰＳ１８の出力信号に基づき生成されるものである。また、異常検知データは、異常が生じたときの曜日に関する情報と、時間帯と、車速ＳＰＤとに関する情報を含む。なお、曜日、時間帯、および車速ＳＰＤは、いずれもセンサ類２０によって検知される。すなわち、センサ類２０に、時計や車速センサ等が含まれることとする。

図２に戻り、ＣＰＵ１２は、通信機１６を操作することによって、異常検知データを図１に示すセンタＣＥにネットワーク５０を介して出力する（Ｓ１４）。なお、ＣＰＵ１２は、Ｓ１４の処理が完了する場合や、Ｓ１０の処理において否定判定する場合には、図２に示す一連の処理を一旦終了する。

図１に戻り、上記センタＣＥは、異常検知データ識別装置３０を備えている。異常検知データ識別装置３０は、ＣＰＵ３２、ＲＯＭ３４、記憶装置３６、通信機３８を備えており、それらがネットワーク４２によって通信可能とされている。異常検知データ識別装置３０は、通信機３８によってネットワーク５０を介して受信した異常検知データを解析し、その結果を、拠点６０に出力する。

拠点６０は、たとえば車両の開発拠点であってもよく、また車両の修理拠点であってもよい。拠点６０には、通信機６２、インターフェース６４および表示装置６６が設けられており、それらがネットワーク６８を介して通信可能となっている。そして拠点６０では、通信機６２によって異常検知データ識別装置３０の解析結果を受信すると、受信した解析結果を表示装置６６に出力する。

図４に、異常検知データ識別装置３０が実行する処理の手順を示す。図４に示す処理は、ＲＯＭ３４に記憶されたプログラムをＣＰＵ３２が実行することにより実現される。
図４に示す一連の処理において、ＣＰＵ３２は、まず通信機３８を介して異常検知データを受信する（Ｓ２０）。ＣＰＵ３２は、ここで今回新たに受信した異常検知データを、図４に示す以下の処理において、修理工場での修理に起因して生成されたものであるか否かを判定する判定対象とする。次にＣＰＵ３２は、受信した異常検知データを、記憶装置３６に記録する（Ｓ２２）。次にＣＰＵ３２は、記憶装置３６に記憶されている異常検知データのうちの現在から所定時間過去までの所定期間における異常検知データを抽出する（Ｓ２４）。この処理は、後述する修理地点候補を特定する処理の信頼性を高めるためのものである。すなわち、あまり長い期間内の異常検知データを全て参照する場合、その期間の途中で、修理工場が移転したり、あるいは新たに生じたりするおそれがある。これに対し、こうした修理工場の移転や新たな発生の可能性が十分に低いとみなせる長さに所定期間を設定すれば、上記のように所定期間における異常検知データを抽出することにより、ある領域内における異常検知データの全てが、その領域内に修理工場が存在する期間のデータか存在しない期間のデータかのいずれかとみなせる。なお、所定期間は、１年よりも長い期間とすることが望ましい。

次にＣＰＵ３２は、Ｓ２４の処理によって抽出された異常検知データのそれぞれから位置ＰＤを取得する（Ｓ２６）。そしてＣＰＵ３２は、判定対象とする異常検知データである対象データに含まれる情報である位置ＰＤから一定範囲Ａ内において異常検知データが出力された回数（過去異常発生回数）が所定数以上であるか否かを判定する（Ｓ２８）。ここで、一定範囲Ａとは、中心（ここでは位置ＰＤ）から所定の距離ＬＡ以内の領域のこととする。また、所定数は、一定範囲Ａ内において車両の修理に起因しない異常検知データが出力される回数としては過度に多いといえるほど大きい値に設定されている。

ＣＰＵ３２は、所定数未満であると判定する場合（Ｓ２８：ＮＯ）、対象データが車両の修理に起因して生じたものではないとして、車両の修理に起因しない実際の異常の発生に起因した異常検知データであると判定する（Ｓ３０）。なお、修理に起因した異常検知データとしては、たとえば車両の修理中に電子回路のコネクタを外した状態で車両の走行のための制御をさせる操作がなされることによるコネクタの接続不良の検知に基づき出力された異常検知データがある。

これに対しＣＰＵ３２は、所定数以上であると判定する場合（Ｓ２８：ＹＥＳ）、対象データと同一の発生箇所から送信された異常検知データを収集する（Ｓ４０）。
図５に、Ｓ４０の処理の詳細を示す。

すなわち、ＣＰＵ３２は、まず旧重心Ｇｏｌｄに、対象データが示す位置ＰＤから一定範囲Ａよりも十分に離れた位置を代入する（Ｓ４２）。次にＣＰＵ３２は、図４のＳ２４の処理において抽出した異常検知データのうち、対象データが示す位置ＰＤから一定範囲Ａ内において送信された異常検知データおよび対象データについて、それらのそれぞれが示す位置ＰＤに関する重心を算出し、新重心Ｇｎｅｗに代入する（Ｓ４４）。ここで、重心とは、異常検知データが示す各位置ＰＤの平均値であり、たとえば２次元座標をｘ成分およびｙ成分とすると各位置ＰＤのｘ成分の和をデータ数で除算した値がｘ成分の平均値となり、各位置ＰＤのｙ成分の和をデータ数で除算した値がｙ成分の平均値となる。ただし、複数のデータが同一の位置を示す場合、成分の和には同一の値が複数含まれることとする。なお、こうして定義された重心は、各位置ＰＤに同一の質点が存在する場合の質量中心と同一の値となる。次にＣＰＵ３２は、新重心Ｇｎｅｗが旧重心Ｇｏｌｄから一定範囲Ｂ内にあるか否かを判定する（Ｓ４６）。ここで、一定範囲Ｂは、中心（ここでは旧重心Ｇｏｌｄ）から所定の距離ＬＡよりも小さい規定の距離ＬＢ内の領域のこととする。このため、最初にＳ４６の処理に入る場合には、Ｓ４２の処理の設定に起因して、ＣＰＵ３２は、否定判定することとなる。

ＣＰＵ３２は、一定範囲Ｂ内にないと判定する場合（Ｓ４６：ＮＯ）、旧重心Ｇｏｌｄに、新重心Ｇｎｅｗを代入する（Ｓ４８）。次に、ＣＰＵ３２は、新重心Ｇｎｅｗから一定範囲Ａ内の位置から送信された異常検知データについて、それらのそれぞれが示す位置ＰＤに関する重心を算出し、新重心Ｇｎｅｗに代入する（Ｓ５０）。

図６に、この時点における、旧重心Ｇｏｌｄと新重心Ｇｎｅｗとを示す。図６は、対象データが修理工場での修理に起因して生じたものである場合を想定しており、特にＧＰＳ１８の精度等に起因して異常検知データが示す位置ＰＤに誤差が生じている場合を示している。すなわち、異常検知データが示す位置ＰＤに誤差が含まれるため、修理工場内での修理に起因して生成された異常検知データが示す位置ＰＤが大きくばらついている。

特に図６では、対象データが示す位置ＰＤ（図６にＰＤと記載）が、それ以前に受信されている異常検知データが示す位置ＰＤ（図６には、ＰＤと記載せずバツ印のみ記載）の分布の周辺部分に位置する例となっている。このため、Ｓ４８の処理によって定まった旧重心ＧｏｌｄおよびＳ５０の処理によって定まった新重心Ｇｎｅｗは、位置ＰＤよりも分布の中心よりとなっている。

図５に戻り、ＣＰＵ３２は、対象データが示す位置ＰＤから一定範囲Ａ内に新重心Ｇｎｅｗがあるか否かを判定する（Ｓ５２）。この処理は、新重心Ｇｎｅｗが、対象データの送信元として適切な位置であるか否かを判定する処理である。ＣＰＵ３２は、一定範囲Ａ内に新重心Ｇｎｅｗがないと判定する場合（Ｓ５２：ＮＯ）、対象データの送信元である修理地点候補を、旧重心Ｇｏｌｄとする（Ｓ５４）。

すなわち、対象データが示す位置ＰＤから一定範囲Ａ内に新重心Ｇｎｅｗがない場合、新重心Ｇｎｅｗが、対象データの送信元から実際に離れている懸念があるとして、旧重心Ｇｏｌｄを採用する。

図５に戻り、ＣＰＵ３２は、一定範囲Ａ内に新重心Ｇｎｅｗがあると判定する場合（Ｓ５２：ＹＥＳ）、Ｓ４６の処理に戻る。そして、ＣＰＵ３２は、新重心Ｇｎｅｗが旧重心Ｇｏｌｄから一定範囲Ｂ内にないと判定する場合（Ｓ４６：ＮＯ）、Ｓ４８～Ｓ５０の処理によって、旧重心Ｇｏｌｄと新重心Ｇｎｅｗとを更新する。

一方、ＣＰＵ３２は、新重心Ｇｎｅｗが旧重心Ｇｏｌｄから一定範囲Ｂ内にあると判定される場合（Ｓ４６：ＹＥＳ）、対象データの送信元である修理地点候補を、新重心Ｇｎｅｗとする（Ｓ５６）。すなわち、新重心Ｇｎｅｗが旧重心Ｇｏｌｄから一定範囲Ｂ内にある場合には、Ｓ４８，Ｓ５０の処理による旧重心Ｇｏｌｄと新重心Ｇｎｅｗとの更新処理によってもそれ以上、算出結果が大きく変わることがなく収束していると考えられることから、対象データの送信元である修理地点候補が新重心Ｇｎｅｗとされる。

ＣＰＵ３２は、Ｓ５４の処理を完了する場合、Ｓ２４の処理において抽出した異常検知データのうちの修理地点候補としての旧重心Ｇｏｌｄから一定範囲Ａ内の異常検知データを収集する（Ｓ５８）。これに対し、ＣＰＵ３２は、Ｓ５６の処理を完了する場合、Ｓ２４の処理において抽出した異常検知データのうちの修理地点候補としての新重心Ｇｎｅｗから一定範囲Ａ内の異常検知データを収集する（Ｓ６０）。

なお、ＣＰＵ３２は、Ｓ５８，Ｓ６０の処理が完了する場合、図４のＳ４０の処理を完了する。そしてＣＰＵ３２は、図４に示すように、収集したデータに基づき、データ解析処理を実行する（Ｓ７０）。

図７に、データ解析処理の手順を示す。
図７に示す一連の処理において、ＣＰＵ３２は、Ｓ４０の処理によって収集された異常検知データを、同異常検知データのそれぞれが有する曜日情報に基づき、曜日別に集計し（Ｓ７２）、集計結果に基づき、対象データが修理に起因して生じた可能性を判定する（Ｓ７４）。

図８に、曜日別の集計結果を示す。図８に示す例では、月曜日から金曜日のそれぞれのデータ数が、土曜日および日曜日のそれぞれのデータ数と比較して多くなっている。これは、修理工場に作業員が出勤するのが月曜日から金曜日である場合の集計結果に相当すると考えられる。すなわち、収集された異常検知データの総数に占める割合が所定以上である曜日の異常検知データは、修理工場における修理に起因して生じたデータである可能性が高いと考えられる。このため、本実施形態において、ＣＰＵ３２は、図８に示すように、Ｓ４０の処理によって収集された異常検知データの総数を、曜日数と、第１除算値ＫＬとで除算した値よりも、異常検知データ数が少ない曜日については、修理中の可能性が低いと判定する。また、ＣＰＵ３２は、Ｓ４０の処理によって収集された異常検知データの総数を、曜日数と、第１除算値ＫＬよりも値が小さい第２除算値ＫＨとで除算した値以上の異常検知データ数を有する曜日については、修理中の可能性が高いと判定する。

図８に示す例では、月曜日から金曜日までについては、該当する異常検知データ数が、Ｓ４０の処理によって収集された異常検知データの総数を、曜日数と、第２除算値ＫＨとで除算した値以上となっているため、ＣＰＵ３２は、修理中の可能性が高いと判定する。また、土曜日と日曜日とについては、該当する異常検知データ数が、Ｓ４０の処理によって収集された異常検知データの総数を、曜日数と、第１除算値ＫＬとで除算した値に満たないため、ＣＰＵ３２は、修理中の可能性が低いと判定する。なお、図８に示した例では該当するものがないものの、Ｓ４０の処理によって収集された異常検知データの総数を、曜日数と、第１除算値ＫＬとで除算した値以上であって、総数を、曜日数と、第２除算値ＫＨとで除算した値未満である場合には、ＣＰＵ３２は、修理中の可能性が「中」であると判定する。

以上より、図８に例示したデータの場合、ＣＰＵ３２は、判定対象となる異常検知データが示す曜日が月曜日である場合には、修理中の可能性が高いと判定し、日曜日の場合には、修理中の可能性が低いと判定する。

図７に戻り、ＣＰＵ３２は、Ｓ４０の処理によって収集された異常検知データを、同異常検知データが有する時間帯情報に基づき、時間帯別に集計し（Ｓ７６）、集計結果に基づき、対象データが修理に起因して生じた可能性を判定する（Ｓ７８）。

図９に、時間帯別の集計処理を示す。図９に示す例では、９時から２１時までのデータ数が、それ以外のデータ数と比較して多くなっている。これは、修理工場にて作業員が作業に従事するのが９時から２１時である場合の集計結果に相当すると考えられる。すなわち、収集された異常検知データの総数に占める割合が所定以上である時間帯の異常検知データは、修理工場における修理に起因して生じたデータである可能性が高いと考えられる。このため、本実施形態において、ＣＰＵ３２は、図９に示すように、Ｓ４０の処理によって収集された異常検知データの総数を、２４時間の分割数（ここでは、８個）と、第１除算値ＫＬとで除算した値よりも、異常検知データ数が少ない時間帯については、修理中の可能性が低いと判定する。また、ＣＰＵ３２は、Ｓ４０の処理によって収集された異常検知データの総数を、分割数と、第１除算値ＫＬよりも値が小さい第２除算値ＫＨとで除算した値以上の異常検知データ数を有する時間帯については、修理中の可能性が高いと判定する。また、ＣＰＵ３２は、Ｓ４０の処理によって収集された異常検知データの総数を、分割数と、第１除算値ＫＬとで除算した値以上であって、分割数と、第２除算値ＫＨとで除算した値未満である場合、修理中の可能性が「中」であると判定する。

図９に示した例の場合、ＣＰＵ３２は、対象データが示す時間が６時から９時の時間帯に該当する場合には、修理中の可能性が「中」であると判定し、９時から１２時の時間帯に該当する異常検知データについては、修理中の可能性が高いと判定する。

図７に戻り、ＣＰＵ３２は、対象データが示す車速ＳＰＤが規定速度Ｓｔｈ以下であるか否かを判定する（Ｓ８０）。この処理は、対象データが示す異常が生じたときに車両が停止しているか否かを判定するためのものであり、規定速度Ｓｔｈはゼロに近い値に設定されている。そして、ＣＰＵ３２は、規定速度Ｓｔｈ以下であると判定する場合（Ｓ８０：ＹＥＳ）、修理中の可能性が高いと判定し（Ｓ８２）、規定速度Ｓｔｈよりも大きいと判定する場合（Ｓ８０：ＮＯ）、作業中の可能性が低いと判定する（Ｓ８４）。

ＣＰＵ３２は、Ｓ８２，Ｓ８４の処理が完了する場合、Ｓ４０の処理によって収集された異常検知データから、対象データが示す車両ＩＤと同一の車両ＩＤを有する異常検知データを収集する（Ｓ８６）。そして、ＣＰＵ３２は、収集した異常検知データの数に基づき、修理中の可能性を判定する（Ｓ８８）。

すなわち、図１０に示すように、本実施形態において、ＣＰＵ３２は、対象データが示す車両ＩＤと同一の車両ＩＤを有する異常検知データの数と、設定値Ｎ１および設定値Ｎ１よりも大きい設定値Ｎ２との大小比較に基づき、修理中の可能性を判定する。具体的には、ＣＰＵ３２は、異常検知データ数が、設定値Ｎ１に満たない場合、修理中の可能性が低いと判定する。また、ＣＰＵ３２は、異常検知データ数が設定値Ｎ２以上であると判定する場合、修理中の可能性が高いと判定する。また、ＣＰＵ３２は、異常検知データ数が設定値１以上であって設定値Ｎ２未満である場合、修理中の可能性が「中」であると判定する。図１０に示す例では、車両ＶＣ１の異常検知データ数が設定値Ｎ２を超えている。このため、対象データが示す車両ＩＤが車両ＶＣ１の場合には、修理中の可能性が高いと判定する。これに対し、対象データが示す車両ＩＤが車両ＶＣ２の場合には、異常検知データ数が設定値Ｎ１未満のため、修理中の可能性が低いと判定する。Ｓ８８の処理は、車両を自分で改造したり修理したりするユーザが一定数存在し得ることに鑑みた処理である。すなわち、自分で改造する場合に異常検知データが出力される場合であっても、これを修理工場での修理の可能性が高いとみなすことにより、改造に起因して異常検知データが出力された場合に、認知すべき異常の可能性が低いとすることができる。

図７に戻り、ＣＰＵ３２は、Ｓ７４，Ｓ７８，Ｓ８２，Ｓ８４，Ｓ８８の処理に基づき、修理中の可能性についての最終判定処理を実行する（Ｓ９０）。ここでは、図１１に示すように、各判定処理による判定結果のうちの一番低い可能性を最終判定結果とする。図１１において、「車速」の欄は、Ｓ８０～Ｓ８４の処理による判定結果に対応し、「曜日」の欄は、Ｓ７４の処理による判定結果に対応し、「時間」の欄は、Ｓ７８の処理による判定結果に対応し、「同一車両」の欄は、Ｓ８８の処理による判定結果に対応し、「判定結果」の欄は、Ｓ９０の処理による最終的な判定結果に対応する。

図７に戻り、ＣＰＵ３２は、Ｓ９０の処理を完了する場合、図４に示したＳ７０の処理が完了する。ＣＰＵ３２は、Ｓ７０，Ｓ３０の処理が完了する場合には、判定結果を記憶装置３６に登録する（Ｓ３２）。なお、ＣＰＵ３２は、Ｓ３２の処理が完了する場合、図４に示す一連の処理を一旦終了する。

異常検知データ識別装置３０では、図１に示した拠点６０からの要求に応じて、記憶装置３６に記憶したデータを送信する処理を実行する。
図１２に、こうした処理の手順を示す。図１２に示す処理は、ＲＯＭ３４に記憶されたプログラムをＣＰＵ３２がたとえば所定周期で繰り返し実行することにより実現される。

図１２に示す一連の処理において、ＣＰＵ３２はまず、拠点６０からのデータの送信要求があるか否かを判定する（Ｓ１００）。そしてＣＰＵ３２は、データの送信要求があると判定する場合（Ｓ１００：ＹＥＳ）、記憶装置３６から、異常検知データと、当該異常検知データに紐づけられた修理中の可能性の判定結果とからなる登録データを読み出す（Ｓ１０２）。そしてＣＰＵ３２は、通信機３８を操作して、読み出したデータをネットワーク５０を介して拠点６０に送信する（Ｓ１０４）。なお、ＣＰＵ３２は、Ｓ１０４の処理を完了する場合や、Ｓ１００の処理において否定判定する場合には、図１２に示す一連の処理を一旦終了する。

ここで、本実施形態の作用および効果について説明する。
ＣＰＵ３２は、異常検知データを受信すると、それが示す位置ＰＤから一定範囲Ａ内の領域から過去に所定数以上の異常検知データが出力された履歴があるか否かを判定し、あると判定する場合、位置ＰＤに基づき修理地点候補を特定する。そしてＣＰＵ３２は、記憶装置３６に記録されている異常検知データのうちの、修理地点候補から一定範囲Ａ内のデータに基づき、修理中である可能性を判定する。そして修理中である可能性の判定結果を異常検知データに紐づけて記憶装置３６に登録する。

一方、拠点６０の作業員は、インターフェース６４を介して通信機６２を操作し、異常検知データの解析結果を送信するように要求する。これに対しＣＰＵ３２は、異常検知データと、それに紐づけられた判定結果とを有したデータを、拠点６０に送信する。

これにより、拠点６０では、表示装置６６によって、異常がある旨の情報とともにその異常が修理に起因して生じたものである可能性に関する視覚情報が表示される。したがって拠点６０内の作業員は、それぞれの異常が、修理中に生じた可能性が高いために要因を解析する優先度が低いものであるか否かを迅速に判断することができる。

＜対応関係＞
上記実施形態における事項と、上記「課題を解決するための手段」の欄に記載した事項との対応関係は、次の通りである。以下では、「課題を解決するための手段」の欄に記載した解決手段の番号毎に、対応関係を示している。［１］処理回路は、ＣＰＵ３２およびＲＯＭ３４に対応する。受信処理は、Ｓ２０の処理に対応し、記録処理は、Ｓ２２の処理に対応し、判定処理は、Ｓ２６～Ｓ３０，Ｓ４０～Ｓ９０の処理に対応する。所定範囲は、一定範囲Ａに対応する。［２］特定処理は、Ｓ４２～Ｓ５６の処理に対応する。規定範囲は、一定範囲Ａに対応する。［３］車速反映判定処理は、Ｓ８０～Ｓ８４の処理に対応する。［４］特定処理は、Ｓ４２～Ｓ５６の処理に対応する。規定範囲は、一定範囲Ａに対応する。［６］重心算出処理は、Ｓ４４の処理に対応する。予め定められた距離内は、一定範囲Ａ内に対応する。［７］第２重心算出処理は、Ｓ５０の処理に対応する。第１選択処理は、Ｓ５２，Ｓ５４の処理に対応する。第２選択処理は、Ｓ４６，Ｓ５６の処理に対応する。規定値は、一定範囲Ｂを定める規定の距離ＬＢに対応する。［８］出力処理は、Ｓ１０４の処理に対応する。［１０］コンピュータは、ＣＰＵ３２に対応する。

＜その他の実施形態＞
なお、本実施形態は、以下のように変更して実施することができる。本実施形態および以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。

・「特定処理について」
図５の処理において、Ｓ４４の処理において算出した新重心Ｇｎｅｗを、修理地点候補と特定してもよい。またたとえば重心を求める処理を実行することなく、位置ＰＤ自体を修理地点候補としてもよい。この場合、Ｓ７０の処理は、位置ＰＤから一定範囲Ａ内の異常検知データに基づき実行されることとすればよい。

・「Ｓ７０の処理において用いられる規定範囲内の異常検知データについて」
上記実施形態では、Ｓ２４の処理によって抽出された異常検知データのうち、それらのそれぞれが示す位置ＰＤが、修理地点候補から規定範囲としての一定範囲Ａ内に入るものを、Ｓ７０の処理において利用したがこれに限らない。たとえば、規定範囲を、重心の算出に用いた一定範囲Ａよりも狭くするなど、一定範囲Ａと相違させてもよい。

さらに、Ｓ２４の処理によって抽出された異常検知データであることも必須ではなく、たとえば記憶装置３６に記憶されている全ての異常検知データのうち、それらのそれぞれが示す位置ＰＤが、修理地点候補から規定範囲内に入るものを、Ｓ７０の処理において用いてもよい。この際、たとえば、所定領域内において異常検知データが新たに規定時間に渡って生じない場合には、所定領域内のデータを削除する処理を加えてもよい。

・「時間帯別集計処理、時間帯別判定処理について」
上記実施形態では、３時間毎に、時間帯を区別したがこれに限らない。たとえば２時間毎であってもよく、またたとえば６時間毎であってもよい。

また、修理中である可能性を３段階で判定する処理に限らない。たとえば最大値を１００パーセントとし、最小値をゼロパーセントとし、「０～１００」の範囲で「１０１」段階で判定してもよい。これはたとえば、上記第１除算値ＫＬと第２除算値ＫＨとに代えて、１００個の互いに異なる閾値を用いることにより実現できる。

・「車速反映判定処理について」
上記実施形態では、規定速度Ｓｔｈを、停車を判定するための値に設定したが、これに限らない。また、車速ＳＰＤに応じて、修理中の確率が高いか低いかの２値的な判定をするものに限らない。たとえば、３値以上の判定をするものであってもよい。その場合、たとえば、高速走行中の場合には修理中である可能性が低いことに鑑み、低速度領域、中速度領域、高速度領域の順に、順次修理中の可能性が低いと判定すればよい。

・「曜日別集計処理、曜日別判定処理について」
上記実施形態では、月、火、水、木、金、土、日のそれぞれで曜日を区別したが、これに限らない。たとえばウィークデイ（月、火、水、木、金）とウィークエンド（土、日）とで区別してもよい。ただし、この場合、ウィークデイについては、収集された異常検知データの総数を、「５」と第１除算値ＫＬや第２除算値ＫＨで除算した値と比較することとし、ウィークエンドについては、総数を、「２」と第１除算値ＫＬや第２除算値ＫＨで除算した値と比較することとする。

また、修理中である可能性を３段階で判定する処理に限らない。たとえば最大値を１００パーセントとし、最小値をゼロパーセントとし、「０～１００」の範囲で「１０１」段階で判定してもよい。これはたとえば、上記第１除算値ＫＬと第２除算値ＫＨとに代えて、１００個の互いに異なる閾値を用いることにより実現できる。

・「判定処理について」
上記実施形態では、曜日別判定処理と、時間帯別判定処理と、Ｓ８０～Ｓ８４の処理と、車両別判定処理とのそれぞれの判定結果のうちの修理中の可能性の最大値と最小値とを同一としたが、これに限らない。たとえば、車両別判定処理の判定結果を、修理中の可能性が「中」または「低」として、車両別判定処理による修理中の可能性の最大値を、曜日別判定処理と、時間帯別判定処理と、Ｓ８０～Ｓ８４の処理とのそれぞれによる判定結果における修理中の可能性の最大値よりも小さくしてもよい。

上記実施形態では、曜日別判定処理と、時間帯別判定処理と、Ｓ８０～Ｓ８４の処理と、車両別判定処理とのそれぞれの判定結果のうちの修理中である可能性が最も低いと判定された結果を採用したがこれに限らない。たとえば、各判定処理による判定結果を数値化し、それらの平均値を最終的な判定結果としてもよい。

上記実施形態では、曜日別判定処理と、時間帯別判定処理と、Ｓ８０～Ｓ８４の処理と、車両別判定処理とのそれぞれの判定結果に基づき最終的な判定を実行したがこれに限らない。たとえば、曜日別判定処理と、時間帯別判定処理と、Ｓ８０～Ｓ８４の処理と、車両別判定処理との４つの処理に関しては、それらのうちの３つの処理のみに基づき最終的な判定を実行したり、２つの処理のみに基づき最終的な判定を実行したり、１つの処理のみに基づき最終的な判定を実行したりしてもよい。

またたとえば、Ｓ２８の処理において肯定判定される場合、Ｓ４０，Ｓ７０の処理を実行することなく、修理中の可能性が高いと判定してもよい。
上記実施形態では、Ｓ２８の処理において否定判定される場合、修理中ではないと断定したが、これに限らない。たとえば、修理中の可能性が低いと判定してもよい。

・「異常検知データ識別装置について」
上記実施形態では、異常検知データ識別装置３０が、異常検知データを利用して解析する作業員の所在地である拠点６０とは相違するセンタＣＥに配置される例を示したがこれに限らず、拠点６０内に配置されてもよい。

またたとえば、記憶装置３６と、処理回路を構成するＣＰＵ３２およびＲＯＭ３４が同一箇所に配置されるものにも限らない。たとえば、記憶装置３６をセンタＣＥに配置し、処理回路については、センタＣＥと拠点６０とに配置し、センタＣＥでは、図４の処理のうちのＳ２０，Ｓ２２の処理を実行し、図４の処理のうちの残りについては拠点６０において実行するようにしてもよい。

・「処理回路について」
処理回路としては、ＣＰＵ３２とＲＯＭ３４とを備えて、ソフトウェア処理を実行するものに限らない。たとえば、上記実施形態においてソフトウェア処理されたものの少なくとも一部を、ハードウェア処理する専用のハードウェア回路（たとえばＡＳＩＣ等）を備えてもよい。すなわち、処理回路は、以下の（ａ）～（ｃ）のいずれかの構成であればよい。（ａ）上記処理の全てを、プログラムに従って実行する処理装置と、プログラムを記憶するＲＯＭ等のプログラム格納装置とを備える。（ｂ）上記処理の一部をプログラムに従って実行する処理装置およびプログラム格納装置と、残りの処理を実行する専用のハードウェア回路とを備える。（ｃ）上記処理の全てを実行する専用のハードウェア回路を備える。ここで、処理装置およびプログラム格納装置を備えたソフトウェア処理回路や、専用のハードウェア回路は複数であってもよい。

１…車両、１０…異常通知装置、１２…ＣＰＵ、１４…ＲＯＭ、１６…通信機、１８…ＧＰＳ、２０…センサ類、２２…ネットワーク、３０…異常検知データ識別装置、３２…ＣＰＵ、３４…ＲＯＭ、３６…記憶装置、３８…通信機、４２…ネットワーク、５０…ネットワーク、６０…拠点、６２…通信機、６４…インターフェース、６６…表示装置、６８…ネットワーク。

Claims (9)

1. 異常が検出される場合に車両の位置と異常が発生した旨との情報を含む異常検知データを出力する車載異常通知装置からの前記異常検知データを受信する異常検知データ識別装置において、
   処理回路と、記憶装置と、を備え、
   前記処理回路は、
   前記異常検知データを受信する受信処理と、
   前記受信した異常検知データを前記記憶装置に記録する記録処理と、
   前記受信した異常検知データが車両の修理に起因して生じた可能性の高低を判定する判定処理と、を実行し、
   前記判定処理は、判定対象とする異常検知データである対象データよりも過去に受信されたデータであって且つ前記記憶装置に記録された前記異常検知データのうちの所定範囲内において出力された前記異常検知データの数が所定数以上である場合に所定数未満である場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する処理であり、
   前記所定範囲は、前記対象データに基づき把握される前記異常が発生したときの前記車両の位置からの所定範囲である異常検知データ識別装置。
2. 前記異常検知データは、異常が発生した時間に関する情報を含み、
   前記判定処理は、
   前記対象データに基づき、修理地点候補を特定する特定処理と、
   前記記憶装置に記録された前記異常検知データのうちの前記修理地点候補から規定範囲内において出力された前記異常検知データに基づき、時間帯毎の異常の発生回数を集計する時間帯別集計処理と、
   前記時間帯別集計処理によって分類された前記時間帯のうちの前記対象データが示す時間に該当するものにおける前記異常の発生回数が多い場合に少ない場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する時間帯別判定処理と、を含む請求項１記載の異常検知データ識別装置。
3. 前記異常検知データは、前記異常が発生したときの車速に関する情報を含み、
   前記判定処理は、前記車速が小さい場合に大きい場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する車速反映判定処理を含む請求項１または２記載の異常検知データ識別装置。
4. 前記異常検知データは、前記異常が発生した曜日に関する情報を含み、
   前記判定処理は、
   前記対象データに基づき、修理地点候補を特定する特定処理と、
   前記記憶装置に記録された前記異常検知データのうちの前記修理地点候補から規定範囲内において出力された前記異常検知データに基づき、前記曜日毎の異常の発生回数を集計する曜日別集計処理と、
   前記曜日別集計処理による曜日の分類のうちの前記対象データが示す曜日に該当するものにおける前記異常の発生回数が多い場合に少ない場合よりも、前記対象データが前記車両の修理に起因して生じた可能性が高いと判定する曜日別判定処理と、を含む請求項１～３のいずれか１項に記載の異常検知データ識別装置。
5. 前記異常検知データは、前記車両を特定する情報を含み、
   前記判定処理は、
   前記記憶装置に記録された前記異常検知データに基づき、同一車両の異常の発生回数を集計する同一車両データ収集処理と、
   前記対象データによって特定される車両と同一車両の異常の発生回数が多い場合に少ない場合よりも、当該異常検知データが前記車両の修理に起因して生じた可能性が高いと判定する車両別判定処理と、を含む請求項１～４のいずれか１項に記載の異常検知データ識別装置。
6. 前記特定処理は、前記過去に受信された前記異常検知データから特定される前記車両の位置のうちの前記対象データから特定される前記車両の位置から予め定められた距離内に含まれるものに基づき、それら位置の平均値である重心を算出する重心算出処理を含み、前記算出された重心に基づき前記修理地点候補を特定する処理を含む請求項２または４記載の異常検知データ識別装置。
7. 前記特定処理は、
   前記重心算出処理によって算出された重心を第１重心の初期値とし、
   前記過去に受信された前記異常検知データから特定される前記車両の位置のうちの前記第１重心から前記予め定められた距離内に含まれるものに基づき、それら位置の平均値である第２重心を算出する第２重心算出処理と、
   前記対象データから特定される前記車両の位置と前記第２重心との距離が閾値よりも大きい場合、前記第１重心を前記修理地点候補とする第１選択処理と、
   前記対象データから特定される前記車両の位置と前記第２重心との距離が前記閾値以下であって、前記第１重心と前記第２重心との距離が規定値以下である場合、前記第２重心を前記修理地点候補とする第２選択処理と、を含み、
   前記第１重心と前記第２重心との距離が規定値よりも大きい場合、前記第１重心に前記第２重心を代入し、前記第２重心算出処理を実行する処理である請求項６記載の異常検知データ識別装置。
8. 前記処理回路は、前記異常検知データに基づく異常が発生した旨の情報と、当該情報に対応する前記判定処理による判定結果とを紐づけたデータを、表示装置による表示に用いるべく出力する出力処理を実行する請求項１～７のいずれか１項に記載の異常検知データ識別装置。
9. 請求項１～８のいずれか１項に記載の異常検知データ識別装置と、
   前記車載異常通知装置と、を備える異常識別システム。

Images