(57)【特許請求の範囲】
【請求項１】
複数の車両のそれぞれに搭載された複数の車載機が互いに車車間通信を実施するシステムで用いられる自機としての車載機であって、
車車間通信による情報の送受信を実施する無線通信部（１２）と、
前記自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、
前記システム情報取得部が取得する情報に基づいて、前記自機の前記制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、
前記指標データ生成部が生成した前記指標データを前記無線通信部に送信させるとともに、前記自機周辺に存在する他の車載機としての周辺車載機から送信された前記指標データを、前記無線通信部を介して取得する通信処理部（Ｆ４）と、
前記通信処理部が取得した前記周辺車載機の前記指標データに基づいて、前記自機の前記制御システムが正常に動作しているか否かを判定するための判定基準である自機判定基準を逐次決定する判定基準決定部（Ｆ６）と、
前記判定基準決定部が決定した前記自機判定基準と、前記自機の前記指標データとを比較することによって、前記自機の前記制御システムが正常に動作しているか否かを判定する自機診断部（Ｆ７）と、を備えることを特徴とする車載機。
【請求項２】
請求項１において、
前記判定基準決定部は、前記通信処理部が取得した前記周辺車載機の前記指標データに基づいて、前記周辺車載機のうち、所定の診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定するための判定基準である他機判定基準を逐次決定し、
前記判定基準決定部が決定した前記他機判定基準と、診断対象とする前記周辺車載機から前記通信処理部が取得した前記指標データとを比較することによって、診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定する他機診断部（Ｆ８）と、を備えることを特徴とする車載機。
【請求項３】
請求項２において
前記指標データは、複数種類の前記指標値を含み、
前記判定基準決定部は、前記自機判定基準及び前記他機判定基準として、前記通信処理部が取得した前記周辺車載機の前記指標データに基づいて、前記指標データに含まれる前記指標値毎に、その指標値が正常であると見なすことができる正常範囲を決定し、
前記自機診断部は、前記自機の前記指標データに含まれる前記指標値が、その指標値に対応する前記正常範囲内の値となっているか否かを、前記指標値の種類毎に判定することによって、前記自機の前記制御システムが正常に動作しているか否かを判定し、
前記他機診断部は、診断対象とする前記周辺車載機から取得した前記指標データに含まれる前記指標値が、その指標値に対応する前記正常範囲内の値となっているか否かを前記指標値の種類毎に判定することによって、診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定することを特徴とする車載機。
【請求項４】
請求項１から３の何れか１項において、
前記車載機の外部に設けられているセンター（３）と広域通信網を介した通信を行う広域通信部（１３）と、
前記自機診断部によって前記自機の前記制御システムが正常に動作していないと判定された場合に、前記広域通信部を介して、前記自機の前記制御システムが正常に動作していないことを前記センターに通知する自機異常通知部（Ｆ１０）と、を備えることを特徴とする車載機。
【請求項５】
請求項４において、
前記自機の現在位置を示す位置情報を逐次取得する位置情報取得部（１４）を備え、
前記自機異常通知部は、前記自機の前記制御システムが正常に動作していないことを前記センターに通知する場合には、前記位置情報取得部によって取得された現在位置を示す位置情報も通知することを特徴とする車載機。
【請求項６】
請求項２又は３において、
前記車載機の外部に設けられているセンター（３）と広域通信網を介した通信を行う広域通信部（１３）と、
前記他機診断部によって診断対象とする前記周辺車載機の前記制御システムが正常に動作していないと判定された場合に、前記広域通信部を介して、その周辺車載機の前記制御システムが正常に動作していないことを前記センターに通知する他機異常通知部（Ｆ１１）と、を備えることを特徴とする車載機。
【請求項７】
請求項６において、
前記自機の現在位置を示す位置情報を逐次取得する位置情報取得部（１４）を備え、
前記通信処理部は、前記指標データを送信する場合には、前記位置情報取得部によって取得された位置情報と対応付けて送信するとともに、前記周辺車載機から送信された、その周辺車載機の現在位置を示す位置情報と対応付けられた前記指標データを取得し、
前記他機異常通知部は、診断対象とした前記周辺車載機の前記制御システムが正常に動作していないことを前記センターに通知する場合には、その周辺車載機の現在位置を示す位置情報も通知することを特徴とする車載機。
【請求項８】
請求項１から７の何れか１項において、
前記制御システムは、
所定の処理を実行する中央処理部（１１１）と、前記中央処理部による処理に用いられるデータを一時的に記憶するメモリ（１１２）と、前記中央処理部による処理に用いられるデータを記憶する不揮発性の記憶媒体であるストレージ（１１３）と、を備え、
前記指標データは、前記指標値として、前記メモリの一定時間当りの使用量の平均値、前記中央処理部の一定時間当りの使用率の平均値、前記ストレージの空き容量、及び、前記ストレージの不良セクタ量の少なくとも１つを含んでいることを特徴とする車載機。
【請求項９】
請求項８において、
前記通信処理部は、前記自機の前記制御システムが用いているソフトウェアのバージョン情報と対応付けた前記指標データを送信させるとともに、前記周辺車載機から送信された、その周辺車載機で用いられているソフトウェアのバージョン情報と対応付けられた前記指標データを取得し、
前記判定基準決定部は、前記周辺車載機のうち、前記自機が利用している前記ソフトウェアと等しいバージョンの前記ソフトウェアを利用している前記周辺車載機から取得した前記指標データに基づいて前記自機判定基準を決定することを特徴とする車載機。
【請求項１０】
複数の車両のそれぞれに搭載された複数の車載機が互いに車車間通信を実施するシステムで用いられる自機としての車載機であって、
車車間通信による情報の送受信を実施する無線通信部（１２）と、
前記自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、
前記システム情報取得部が取得する情報に基づいて、前記自機の前記制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、
前記指標データ生成部が生成した前記指標データを前記無線通信部に送信させるとともに、前記自機周辺に存在する他の車載機としての周辺車載機から送信された前記指標データを、前記無線通信部を介して取得する通信処理部（Ｆ４）と、
前記通信処理部が取得した前記周辺車載機の前記指標データに基づいて、前記周辺車載機のうち、所定の診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定するための判定基準である他機判定基準を逐次決定する判定基準決定部（Ｆ６）と、
前記判定基準決定部が決定した前記他機判定基準と、診断対象とする前記周辺車載機から前記通信処理部が取得した前記指標データとを比較することによって、診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定する他機診断部（Ｆ８）と、を備えることを特徴とする車載機。
【請求項１１】
複数の車両のそれぞれに搭載され、互いに車車間通信を実施する複数の車載機を備える車載機診断システムであって、
複数の前記車載機のうちの１つである自機は、
車車間通信による情報の送受信を実施する無線通信部（１２）と、
前記自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、
前記システム情報取得部が取得する情報に基づいて、前記自機の前記制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、
前記指標データ生成部が生成した前記指標データを前記無線通信部に送信させるとともに、前記自機周辺に存在する他の前記車載機としての周辺車載機から送信された前記指標データを、前記無線通信部を介して取得する通信処理部（Ｆ４）と、
前記通信処理部が取得した前記周辺車載機の前記指標データに基づいて、前記周辺車載機のうち、所定の診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定するための判定基準である他機判定基準を逐次決定する判定基準決定部（Ｆ６）と、
前記判定基準決定部が決定した前記他機判定基準と、診断対象とする前記周辺車載機から前記通信処理部が取得した前記指標データとを比較することによって、診断対象とする前記周辺車載機の前記制御システムが正常に動作しているか否かを判定する他機診断部（Ｆ８）と、を備えることを特徴とする車載機診断システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車車間通信を実施する車載機、及び、その車載機を診断する車載機診断システムに関する。
【背景技術】
【０００２】
近年、複数の車両のそれぞれに搭載された車載機が、自機から所定の範囲内に存在する他の車載機と、広域通信網を介さない無線通信を実施するシステムが提案されている。一般的に、この種の車載機同士が実施する通信は車車間通信と称されている。
【０００３】
また、そのように車車間通信を実施する車載機が、車載機に対して所定のサービスを提供するサービス提供端末（例えば路側機）と、所定の情報を送受信することで、そのサービス提供端末が提供するサービスを享受することができるシステムも提案されている。例えば車載機が現在位置情報などの自機に関する情報をサービス提供端末に提供することで、現在位置に応じたサービスを享受することができるシステムが提案されている。
【０００４】
なお、特許文献１には、他の車載機との通信時における通信状態を示すパラメータを検出し、その検出したパラメータを予め定められた値と比較することによって、特定の通信エラーを検出する車載機が開示されている。また、この特許文献１の車載機は、その通信エラーの発生回数等に基づいて、車載機に正常に動作しているか否かの診断を行う。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−４７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
車載機が、サービス提供端末と通信を実施し、そのサービスを享受するためには、そのサービスを享受するためのソフトウェアが正常に実行されている必要がある。
【０００７】
しかしながら、例えば車載機の動作を制御する内部システム（以降、制御システムとする）に不具合が生じている場合、その不具合によって、サービスを享受するためのソフトウェアが正常に実行されなくなってしまう場合がある。サービスを享受するためのソフトウェアが正常に実行されていない場合には、そのサービスを享受することができない。したがって、車載機の制御システムが正常に動作しているかは、適宜診断されることが好ましい。
【０００８】
ところで、車載機の制御システムに生じる不具合の中には、その不具合を検出するための閾値を設定することが困難な種類の不具合も想定される。
【０００９】
例えば、車載機のＣＰＵ使用率が相対的に高い状態が一定時間以上維持されている場合には、制御システムに不具合が生じている可能性が懸念される。しかし、車載機のＣＰＵ使用率は、実行しているプログラムの種類によって変化したり、車車間通信を実施している車載機の数などによっても変化したりする。したがって、車載機のＣＰＵ使用率が高い状態が維持されているといった事象は、制御システムが正常な動作をしている場合であっても観測されうる事象である。
【００１０】
つまり、ＣＰＵ使用率が所定の閾値以上となっている状態が一定時間以上継続しているからといって、制御システムが正常に動作していないとは限らない。予め設計された（すなわち固定された）閾値を用いて制御システムが正常に動作しているか否かを判定する態様では、制御システムが正常に動作しているにも関わらず、正常に動作していないと誤判定してしまう恐れがある。言い換えれば、制御システムの不具合を検出するための適切な閾値を、例えばＣＰＵ使用率といった制御システムの状態を示す指標値に、予め設定しておくことは困難であるといえる。
【００１１】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、車載機のシステムが正常に動作しているか否かを判定できる車載機、及び車載機診断システムを提供することにある。
【課題を解決するための手段】
【００１２】
その目的を達成するための車載機についての第１の発明は、複数の車両のそれぞれに搭載された複数の車載機が互いに車車間通信を実施するシステムで用いられる自機としての車載機であって、車車間通信による情報の送受信を実施する無線通信部（１２）と、自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、システム情報取得部が取得する情報に基づいて、自機の制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、指標データ生成部が生成した指標データを無線通信部に送信させるとともに、自機周辺に存在する他の車載機としての周辺車載機から送信された指標データを、無線通信部を介して取得する通信処理部（Ｆ４）と、通信処理部が取得した周辺車載機の指標データに基づいて、自機の制御システムが正常に動作しているか否かを判定するための判定基準である自機判定基準を逐次決定する判定基準決定部（Ｆ６）と、判定基準決定部が決定した自機判定基準と、自機の指標データとを比較することによって、自機の制御システムが正常に動作しているか否かを判定する自機診断部（Ｆ７）と、を備えることを特徴とする。
【００１３】
以上の構成によれば、判定基準決定部が、周辺車載機から受信した指標データを用いて、自機の制御システムが正常に動作しているかを判定するための判定基準を逐次決定する。そして、自機診断部は、判定基準決定部によって決定された判定基準と、自機の指標データと比較することで、自機の制御システムが正常に動作しているか否かを判定する。
【００１４】
ここで、判定基準を生成するための元となった指標データを提供した複数の周辺車載機は、いずれも自機と車車間通信が実施できる範囲、つまり比較的小さい範囲内に存在している。
【００１５】
複数の周辺車載機は、いずれも自機を中心とする比較的小さい範囲内に存在しているため、自機が車車間通信を実施している車載機の数と、周辺車載機のそれぞれが車車間通信を実施している車載機の数は、類似している可能性が高い。また、自機がサービス提供端末とサービスを享受するための通信を実施している場合には、周辺車載機もまた同一のサービス提供端末と、サービスを享受するための通信を実施していることが期待される。
【００１６】
つまり、自機と周辺車載機とでは、例えばサービスを享受するためのアプリケーションといった、制御システムが実行しているソフトウェアや、制御システムにかかる負荷の大きさ（処理するべきタスクの数など）が共通している可能性が高い。自機及び周辺車載機において実行されているソフトウェアが同じであったり、処理すべきタスクの数などが類似していたりする場合には、各車載機のＣＰＵ使用率やメモリ使用量は類似性が高くなる。
【００１７】
したがって、自機が正常に動作している場合には、自機の制御システムの状態と、周辺車載機の制御システムの状態とは類似している可能性が高い。そのため、自機の指標データは、周辺車載機から取得した指標データと類似するはずである。
【００１８】
また、周辺車載機の何れもが、正常に動作していない可能性は相対的に低いため、周辺車載機から取得した指標データに基づいて動的に定まる自機判定基準は、その状況における制御システムの正常な状態を示すものとなる。
【００１９】
したがって、周辺車載機から取得した指標データに基づいて定まる自機判定基準と、自機の指標データとを比較することで、自機の制御システムが正常に動作しているか否かを判定することができる。
【００２０】
また、上記目的を達成するための車載機についての第２の発明は、複数の車両のそれぞれに搭載された複数の車載機が互いに車車間通信を実施するシステムで用いられる自機としての車載機であって、車車間通信による情報の送受信を実施する無線通信部（１２）と、自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、システム情報取得部が取得する情報に基づいて、自機の制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、指標データ生成部が生成した指標データを無線通信部に送信させるとともに、自機周辺に存在する他の車載機としての周辺車載機から送信された指標データを、無線通信部を介して取得する通信処理部（Ｆ４）と、通信処理部が取得した周辺車載機の指標データに基づいて、周辺車載機のうち、所定の診断対象とする周辺車載機の制御システムが正常に動作しているか否かを判定するための判定基準である他機判定基準を逐次決定する判定基準決定部（Ｆ６）と、判定基準決定部が決定した他機判定基準と、診断対象とする車載機から通信処理部が取得した指標データとを比較することによって、診断対象とする周辺車載機の制御システムが正常に動作しているか否かを判定する他機診断部（Ｆ８）と、を備えることを特徴とする。
【００２１】
以上の構成において判定基準決定部は、周辺車載機から受信した指標データを用いて、周辺車載機のうち、診断対象とする周辺車載機の制御システムが正常に動作しているかを判定するための他機判定基準を逐次決定する。そして、他機診断部は、判定基準決定部によって決定された他機判定基準を用いて、診断対象とする周辺車載機の制御システムが正常に動作しているか否かを判定する。
【００２２】
このような構成によれば、前述の車載機についての第１の発明と同様の作用によって、周辺車載機の制御システムが正常に動作しているか否かを判定することができる。
【００２３】
さらに、上記目的を達成するための車載機診断システムの発明は、複数の車両のそれぞれに搭載され、互いに車車間通信を実施する複数の車載機を備える車載機診断システムであって、複数の車載機のうちの１つである自機は、車車間通信による情報の送受信を実施する無線通信部（１２）と、自機の動作を制御する制御システムの状態を示す情報を取得するシステム情報取得部（Ｆ２）と、システム情報取得部が取得する情報に基づいて、自機の制御システムの状態を示す指標値を含む指標データを生成する指標データ生成部（Ｆ３）と、指標データ生成部が生成した指標データを無線通信部に送信させるとともに、自機周辺に存在する他の車載機としての周辺車載機から送信された指標データを、無線通信部を介して取得する通信処理部（Ｆ４）と、通信処理部が取得した周辺車載機の指標データに基づいて、周辺車載機のうち、所定の診断対象とする周辺車載機の制御システムが正常に動作しているか否かを判定するための判定基準である他機判定基準を逐次決定する判定基準決定部（Ｆ６）と、判定基準決定部が決定した他機判定基準と、診断対象とする車載機から通信処理部が取得した指標データとを比較することによって、診断対象とする周辺車載機の制御システムが正常に動作しているか否かを判定する他機診断部（Ｆ８）と、を備えることを特徴とする。
【００２４】
この車載機診断システムは、車載機についての第２の発明として上述した構成を備える車載機を、複数備えることによって実現されるシステムである。つまり、前述の車載機についての第２の発明と同様の作用によって、当該車載機診断システムが備える各車載機は、他の車載機の制御システムが正常に動作しているか否かを判定することができる。
【００２５】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００２６】
【図１】本実施形態に係る車載機診断システム１００の概略的な構成を示すブロック図である。
【図２】本実施形態に係る車載機１の概略的な構成を示すブロック図である。
【図３】制御部１１の概略的な構成の一例を示すブロック図である。
【図４】指標データの概略的な構成の一例を示す図である。
【図５】制御部１１が実施する自端末診断処理について説明するためのフローチャートである。
【図６】自端末診断基準決定処理について説明するためのフローチャートである。
【図７】制御部１１が実施する他端末診断処理について説明するためのフローチャートである。
【図８】他端末診断処理の作動について説明するための図である。
【発明を実施するための形態】
【００２７】
以下、本発明の実施形態について図を用いて説明する。図１は、本発明に係る車載機診断システム１００の概略的な構成の一例を示す図である。この車載機診断システム１００は、複数の車両の各々で１つずつ用いられる車載機１と、各車両の外部に設けられたセンター３を備える。センター３は、電話回線網やインターネットなどの広域通信網２に接続している。なお、本実施形態において車載機１は、車両に組み込まれる（つまり、搭載される）構成とするが、他の態様として、車両に持ち込まれてホルダなどにユーザによって着脱自在に取り付けられる構成としてもよい。
【００２８】
各車両に搭載された車載機１は、予め割り当てられた周波数帯の電波を用いて、自端末周辺に存在する他の車載機１と、広域通信網２を介さない無線通信（いわゆる車車間通信）を行う。車車間通信に用いられる周波数帯は、例えば７００ＭＨｚ帯の電波や、５．８〜５．９ＧＨｚ帯、２．４ＧＨｚなどである。ここでの自端末周辺とは、車車間通信が実施できる範囲を指す。車車間通信や路車間通信ができる範囲は、適宜設計されればよく、数十ｍ〜数百ｍに設計される場合が多い。
【００２９】
以降では、便宜上、符号Ａで示す車両を自車両と称し、自車両Ａの周辺に存在する車両を周辺車両と称するとともに、周辺車両には符号Ｂを付与して、この車載機診断システム１００、及び車載機１について説明する。図１に示す周辺車両Ｂは、自車両Ａに搭載された車載機１と車車間通信を実施している車載機１を搭載した車両である。
【００３０】
自車両Ａに搭載された車載機１と、周辺車両Ｂに搭載された車載機１とを区別する場合には、自車両Ａに搭載された車載機１の符号を１Ａとし、周辺車両Ｂに搭載された車載機１の符号を１Ｂとして記載する。周辺車両Ｂに搭載された車載機１Ｂは、周辺車載機１Ｂとも記載する。
【００３１】
なお、各車載機１は、予め割り当てられた周波数帯の電波を用いて、道路上又は道路沿いに設けられた路側機と、広域通信網２を介さない無線通信（いわゆる路車間通信）を行ってもよい。各車載機１は、車車間通信や路車間通信を行うための所定の通信規格に準拠して、車車間通信や路車間通信を行う。例えば、車載機１は、ＩＥＥＥ１６０９．０（Ｇｕｉｄｅ  ｆｏｒ  Ｗｉｒｅｌｅｓｓ  Ａｃｃｅｓｓ  ｉｎ  Ｖｅｈｉｃｕｌａｒ  Ｅｎｖｉｒｏｎｍｅｎｔ）の規格に準拠して、車車間通信や路車間通信を実施すればよい。以降において車載機１と路側機とを区別しない場合には、単に通信端末と称する。
【００３２】
車載機診断システム１００が備える通信端末のそれぞれには、複数の通信端末をそれぞれ識別するための識別コード（端末ＩＤとする）が設定されている。また、各通信端末が送信するデータには、その送信端末の端末ＩＤが含まれており、データを受信した通信端末は、当該データに含まれる端末ＩＤによって送信端末を特定することができるようになっている。
【００３３】
そして、車載機１は、車載機１に対して所定のサービスを提供するサービス提供元が管理する通信端末（サービス提供端末とする）と路車間通信又は車車間通信を実施することで、そのサービス提供端末が提供するサービスを享受するための処理を行う。サービス提供端末は、路側機であってもよいし、車両に搭載された車載機１であってもよい。サービス提供端末が提供するサービスの一例としては、ドライブスルーでの自動決済や、有料駐車場での駐車料金の自動決済や、交差点の通行の支援や渋滞情報の提供などがある。
【００３４】
（車載機１の構成について）
次に、図２を用いて、車載機１の概略的な構成について説明を行う。図２に示すように車載機１は、制御部１１、狭域通信部１２、広域通信部１３、及びＧＮＳＳ受信機１４を備えている。制御部１１と、狭域通信部１２、広域通信部１３、及びＧＮＳＳ受信機１４のそれぞれとは、相互通信可能に接続されている。
【００３５】
狭域通信部１２は、車車間通信や路車間通信に用いられる周波数帯の電波を送受信可能なアンテナを備えており、そのアンテナを介して、自端末周辺に存在する他の通信端末（車載機１や路側機）と無線通信を実施する。より具体的に、狭域通信部１２は、アンテナで受信した信号を復調して制御部１１に出力するとともに、制御部１１から入力されたデータを変調し、さらに電波に変換して送信する。この狭域通信部１２が請求項に記載の無線通信部に相当する。
【００３６】
広域通信部１３は、広域通信網２に接続し、センター３との通信を実施する。広域通信部１３は、広域通信網２を介して受信した信号を復調して制御部１１に提供するとともに、制御部１１から入力されたベースバンド信号を変調して、センター３に送信する。
【００３７】
ＧＮＳＳ受信機１４は、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）で用いられる衛星（ＧＮＳＳ衛星とする）からの電波を受信することで、ＧＮＳＳ受信機１４の現在位置を示す情報を取得する。ＧＮＳＳ受信機１４が取得した現在位置は、例えば、緯度、経度、高度で表されれば良い。高度は、所定の基準面（例えば海面）からの高さを表すものとすればよい。
【００３８】
ＧＮＳＳ受信機１４が取得した位置情報は逐次（例えば１００ミリ秒毎に）制御部１１に提供される。なお、この実施形態においてＧＮＳＳ受信機１４は、任意の要素であって、備えていなくてもよい。ＧＮＳＳ受信機１４が請求項に記載の位置情報取得部に相当する。
【００３９】
制御部１１は、通常のコンピュータとして構成されており、周知のＣＰＵ１１１、メモリ１１２、ストレージ１１３、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えている。メモリ１１２は、例えばＲＡＭなどの一時記憶媒体によって実現されればよく、周知の主記憶装置として機能する。ストレージ１１３は、ＲＯＭやフラッシュメモリなどの不揮発性の記憶媒体によって実現されればよく、周知の補助記憶装置として機能する。
【００４０】
ストレージ１１３には、種々の処理を実行するためのソフトウェアやデータ、車載機１に割り当てられている端末ＩＤ等が格納されている。ここでのソフトウェアとは、例えばオペレーティングシステムや、前述のサービス提供端末が提供するサービスを享受するためのアプリケーションソフトウェアなどを含む。なお、本実施形態では各車載機１には、同一のソフトウェアがインストールされているものとする。
【００４１】
この制御部１１は、上述のソフトウェアによって実現する機能ブロックとして、図３に示すように、システム管理部Ｆ１、システム情報取得部Ｆ２、指標データ生成部Ｆ３、狭域通信制御部Ｆ４、指標データ管理部Ｆ５、正常範囲決定部Ｆ６、自端末診断部Ｆ７、他端末診断部Ｆ８、広域通信制御部Ｆ９、自端末異常通知部Ｆ１０、及び他端末異常通知部Ｆ１１を備える。なお、制御部１１が実行する機能の一部又は全部は、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。この制御部１１が請求項に記載の制御システムに相当する。また、ＣＰＵ１１１が請求項に記載の中央処理部に相当する。
【００４２】
システム管理部Ｆ１は、制御部１１に接続するデバイスとの通信を管理したり、制御部１１に障害が発生した場合にその障害状態から復旧したり、データ入出力の調停を行ったりする。また、システム管理部Ｆ１は、制御部１１に供給される電源の管理や、システム時刻の修正、実行中のアプリケーションやプロセスの管理などを行う。システム時刻は、ＧＮＳＳ受信機１４が受信するＧＮＳＳ衛星からの電波に基づいて修正する。
【００４３】
さらに、予め定められた異常事象が生じた場合には、その異常事象をダイアグ情報として、ストレージ１１３に記録する。ダイアグ情報として記録される異常事象とは、例えば、制御部１１に接続するデバイスとの通信の失敗や、接続されているはずのデバイスが接続されていない（または認識できない）といった事象が該当する。なお、ストレージ１１３においてダイアグ情報を記録するための領域のサイズは一定値とし、当該記憶領域が一杯となった場合には、古い情報から削除していくものとする。
【００４４】
システム情報取得部Ｆ２は、自端末のシステム情報を取得する。ここでのシステム情報とは、システム時刻、メモリ１１２の使用量、ＣＰＵ１１１の使用率、ストレージ１１３の空き容量、不良セクタ量、ダイアグ情報などが該当する。
【００４５】
指標データ生成部Ｆ３は、システム情報取得部Ｆ２が取得したシステム情報に基づいて自端末の制御部１１の状態（動作状況など）を示す指標値を含む指標データを生成する。例えば指標データは指標値として図４に示すように、現在のシステム時刻と、平均メモリ使用量、平均ＣＰＵ使用率、ストレージ空き容量、不良セクタ量、ダイアグ履歴情報を含む。
【００４６】
平均メモリ使用量は、現時点から過去一定時間（例えば数秒等）以内におけるメモリ使用量の平均値である。なお、指標データは、平均メモリ使用量の代わりに、最新のメモリ使用量を含んでもよく、さらには、平均メモリ使用量と、最新のメモリ使用量の両方を含んでいても良い。
【００４７】
平均ＣＰＵ使用率は、現時点から過去一定時間以内におけるＣＰＵ使用率の平均値である。なお、指標データは、平均ＣＰＵ使用率の代わりに、最新のＣＰＵ使用率を含んでもよく、さらには、平均ＣＰＵ使用率と、最新のＣＰＵ使用率の両方を含んでいても良い。
【００４８】
ストレージ空き容量は、ストレージ１１３の空き容量を示し、不良セクタ量とは、ストレージ１１３においてデータを保存できないセクタの量を表す。ダイアグ履歴情報は、現時点から一定時間（例えば１０秒〜数分）以内におけるダイアグ情報である。ダイアグ履歴情報は、一定時間以内において、所定の異常事象が発生した頻度や、その種類を示す情報である。
【００４９】
もちろん、以上で例示した指標データの内容は一例であって、これに限らない。上述した以外の種類の指標値を含んでいても良い。また、上述した全ての種類の指標値を含んでいる必要はない。さらに、ここでは複数種類の指標値を指標データに含める態様を例示しているが、指標データは少なくとも１種類の指標値を含んでいればよい。なお、例えば、種々の平均値に代わって、統計学において用いられる中央値や分散、標準偏差等を含んでいてもよい。また、指標データは、自端末にインストールされているソフトウェアのバージョン情報を含んでいてもよい。
【００５０】
指標データ生成部Ｆ３によって生成された指標データは、生成時刻を示すタイムスタンプが付与されてメモリ１１２に格納される。また、指標データ生成部Ｆ３は、指標データを生成すると、その生成した指標データを狭域通信制御部Ｆ４に提供する。
【００５１】
指標データ生成部Ｆ３が指標データを生成するタイミングは、適宜設計さればよく、例えば、一定時間毎に生成してもよいし、後述する狭域通信制御部Ｆ４が、路側機との通信を開始した場合であってもよい。また、他の車載機１から、その車載機１を診断対象とする後述の他端末診断処理を実施するように要求する信号を受信した場合としてもよい。
【００５２】
狭域通信制御部Ｆ４は、狭域通信部１２の動作を制御するとともに、狭域通信部１２が受信したデータを取得する。また、狭域通信部１２に対し、他の車載機１や路側機に送信するべきデータを出力して、送信させる。つまり、狭域通信制御部Ｆ４は、他の車載機１や路側機とデータの送受信を実施するインターフェースとしても機能する。
【００５３】
例えば狭域通信制御部Ｆ４は、指標データ生成部Ｆ３から指標データが提供された場合には、当該指標データを含む送信用データを生成し、狭域通信部１２に送信させる。送信用データは、車車間通信の通信規格において採用されているデータ・フォーマットに従って生成されればよく、例えば、車載機１の端末ＩＤなどを含むヘッダを、指標データに付与したデータとすればよい。
【００５４】
また、狭域通信制御部Ｆ４は、他の車載機１が送信した指標データを含むデータを取得した場合には、その指標データを、送信元の端末ＩＤと対応付けて指標データ管理部Ｆ５に提供する。この狭域通信制御部Ｆ４が請求項に記載の通信処理部に相当する。
【００５５】
指標データ管理部Ｆ５は、狭域通信制御部Ｆ４から提供される、他の車載機１から送信された指標データを、送信元の車載機１毎に区別してメモリ１１２に保存する。車載機１毎の指標データは、例えば受信順にソートされて保存されればよい。また、一定時間以上の過去のデータは逐次破棄されればよい。
【００５６】
正常範囲決定部Ｆ６は、自端末を診断するための診断基準や、他の車載機１を診断するための診断基準を決定する。診断基準は、所定の複数の診断項目のそれぞれに対する正常範囲を規定するものである。正常範囲は、その診断項目が正常であると見なすことができる範囲の上限と下限を表す。この正常範囲決定部Ｆ６が請求項に記載の判定基準決定部に相当する。
【００５７】
ここでは一例として、複数の診断項目は、指標データに含まれる項目に対応するものとする。つまり、診断項目は、システム時刻、平均メモリ使用量、平均ＣＰＵ使用率、ストレージ空き容量、不良セクタ量、異常事象の発生頻度とする。異常事象の発生頻度はダイアグ履歴情報に基づいて診断される。もちろん、診断項目は、ここで例示したものに限らない。一部の項目については、診断項目としなくてもよい。
【００５８】
正常範囲決定部Ｆ６は、上述の診断基準を、周辺車載機１Ｂから受信した指標データに基づいて決定する。また、本実施形態ではより好ましい態様として、診断の対象とする車載機１以外の周辺車載機１Ｂから受信した指標データに基づいて決定する。
【００５９】
例えば、自端末を診断するための診断基準は、周辺車載機１Ｂから受信した指標データに基づいて決定する。また、周辺車載機１Ｂのうち、任意の１つの周辺車載機１Ｂを診断対象とする場合には、その診断基準は、診断対象とする周辺車載機１Ｂ以外の周辺車載機１Ｂから受信した指標データに基づいて決定する。
【００６０】
なお、周辺車載機１Ｂのうち、任意の１つの周辺車載機１Ｂを診断対象とする場合には、診断対象とする周辺車載機１Ｂ以外の周辺車載機１Ｂから受信した指標データに加えて、自端末の指標データを用いて診断基準を決定してもよい。
【００６１】
この正常範囲決定部Ｆ６の作動については別途後述する。以降において自端末を診断するための診断基準は、自端末診断基準とも称し、他の車載機１のセンサを診断するための診断基準は、他端末診断基準とも称する。自端末診断基準が請求項に記載の自機判定基準に相当し、他端末診断基準が請求項に記載の他機判定基準に相当する。
【００６２】
自端末診断部Ｆ７は、正常範囲決定部Ｆ６が決定した自端末診断基準に示される診断項目毎の正常範囲と、自端末の指標データとを比較することによって、自端末の制御部１１が正常に動作しているか否かを判定する。この自端末診断部Ｆ７の詳細については、別途図５に示すフローチャートの説明の中で言及する。自端末診断部Ｆ７が請求項に記載の自機診断部に相当する。
【００６３】
他端末診断部Ｆ８は、正常範囲決定部Ｆ６が決定した他端末診断基準に示される診断項目毎の正常範囲と、診断対象とする周辺車載機１Ｂから取得した指標データとを比較することで、診断対象とする周辺車載機１Ｂの制御部が正常に動作しているか否かを判定する。この他端末診断部Ｆ８の詳細については、別途図７に示すフローチャートの説明の中で言及する。他端末診断部Ｆ８が請求項に記載の他機診断部に相当する。
【００６４】
広域通信制御部Ｆ９は、広域通信部１３の動作を制御するとともに、広域通信部１３が受信したデータを取得する。また、センター３に送信するべきデータを広域通信部１３に出力して、送信させる。
【００６５】
自端末異常通知部Ｆ１０は、自端末の制御部１１が正常に動作していないと自端末診断部Ｆ７が判定した場合、自端末の制御部１１が正常に動作していない旨のメッセージ（自端末異常通知とする）を、センター３に送信するように広域通信制御部Ｆ９に要求する。広域通信制御部Ｆ９は、自端末異常通知部Ｆ１０からの要求に基づいて、自端末異常通知をセンター３に送信する。自端末異常通知は、自端末の端末ＩＤを含んでいればよく、また、より好ましい態様として、正常に動作していないと診断した根拠（診断項目など）についての情報などを含むものとする。自端末異常通知部Ｆ１０が請求項に記載の自機異常通知部に相当する。
【００６６】
他端末異常通知部Ｆ１１は、診断対象とした周辺車載機１Ｂの制御部が正常に動作していないと他端末診断部Ｆ８が判定した場合、その周辺車載機１Ｂの制御部が正常に動作していない旨を示すメッセージ（他端末異常通知とする）を、センター３に送信するように広域通信制御部Ｆ９に要求する。広域通信制御部Ｆ９は、他端末異常通知部Ｆ１１からの要求に基づいて、他端末異常通知をセンター３に送信する。他端末異常通知は、診断対象とした周辺車載機１Ｂの端末ＩＤを含んでいればよく、より好ましい態様として、正常に動作していないと診断した根拠などを含むものとする。他端末異常通知部Ｆ１１が請求項に記載の他機異常通知部に相当する。
【００６７】
（センター３について）
センター３は、広域通信網２に接続しており、車載機診断システム１００が備える各車載機１と、広域通信網２を介して相互通信可能に構成されている。センター３は、１つのサーバ装置からなるものであってもよいし、複数のサーバ装置からなっていてもよい。
【００６８】
センター３は、或る車載機１から自端末異常通知を受信した場合には、例えば、その車載機１に対してメンテナンスを行うためのスタッフの手配を行う。また、予め車載機１の端末ＩＤと、ユーザの連絡先（例えばメールアドレス）と対応付けたデータを備えている場合には、その連絡先に、車載機１が正常に動作していない旨を通知してもよい。
【００６９】
他端末異常通知を受信した場合も同様に、異常が生じている車載機１に対してメンテナンスを行うためのスタッフを手配したり、その異常が発生している車載機１のユーザに対して、利用中の車載機１のセンサに異常が生じている旨を通知したりする。
【００７０】
（自端末診断処理について）
次に、図５に示すフローチャートを用いて、車載機１の制御部１１が、自端末を診断する処理（自端末診断処理とする）について説明する。便宜上、当該処理を行う車載機１と、他の車載機１とを区別するため、車載機１Ａを当該処理の主体として説明する。
【００７１】
このフローチャートは、例えば車載機１Ａの指標データ生成部Ｆ３が指標データを生成したことをトリガとして開始されれば良い。もちろん、自端末診断処理を開始する条件は適宜設計されれば良く、例えば周辺車載機１Ｂから指標データを取得した場合であってもよい。また、車載機１Ａが所定の数以上の周辺車載機１Ｂと車車間通信を実施している場合において、指標データ生成部Ｆ３が指標データを生成した場合に開始されてもよい。その他、車載機１Ａが図示しない路側機と路車間通信を開始した場合に開始してもよい。
【００７２】
まず、ステップＳ１０では正常範囲決定部Ｆ６が自端末診断基準決定処理を実施してステップＳ１１に移る。このステップＳ１０での自端末診断基準決定処理は、周辺車載機１Ｂから受信した指標データに基づいて、所定の診断項目毎の正常範囲、つまり自端末診断基準を決定する処理である。
【００７３】
この自端末診断基準決定処理の、より具体的な処理手順の一例を図６のフローチャートに示す。まず、ステップＳ１０１では、メモリ１１２に格納されている周辺車載機１Ｂから受信した指標データのうち、自端末診断基準を生成するための母集団とする指標データを抽出してステップＳ１０２に移る。
【００７４】
ここでは、一例として、周辺車載機１Ｂから受信した指標データのうち、指標データ生成部Ｆ３が指標データを生成した時点よりも過去一定時間以内に受信した指標データを、自端末診断基準を決定するための母集団として抽出する。
【００７５】
ここでの一定時間は、診断精度の観点から、例えば指標データを送信する周期や数秒〜数十秒程度の、比較的短い時間とすることが好ましい。これは、本車載機診断システム１００は、或る車載機１（ここでは自端末）の制御部１１の状態と、その周辺に存在する車載機１の制御部１１の状態とは類似している可能性が高いという想定に基づいて、車載機１の制御部１１を診断するものであるためである。
【００７６】
具体的には次の通りである。制御部１１の状態、例えば、ＣＰＵ１１１の使用率や、メモリ１１２の使用量は、ＣＰＵ１１１によって実行されるアプリケーションやプロセスに応じて異なる。より具体的には、自端末が車車間通信を実施する車載機１Ｂの数が多いほど、処理すべきイベントの数が増加するとともに、一時的に格納すべきデータの数が増加するため、ＣＰＵ１１１の使用率やメモリ１１２の使用量は増加する。
【００７７】
また、自端末がサービス提供端末とサービスを享受するための通信を実施している場合には、ＣＰＵ１１１の使用率やメモリ１１２の使用量は、そのサービスを享受するために実行されているアプリケーションの影響を受ける。サービス提供端末が提供するサービスを享受するために、ＣＰＵ１１１によって実行されるアプリケーションやプロセスは、享受するサービスの種類によって異なることが想定される。
【００７８】
しかしながら、そのことは、仮に複数の車載機１が同一のサービス提供端末と通信している場合には、それらの車載機１において実行されているアプリケーションやプロセスが共通している可能性が高いことを意味する。各車載機１において実行されているアプリケーションやプロセスが同じである場合には、各車載機１のＣＰＵ使用率やメモリ使用量は類似性が高くなる。
【００７９】
ところで、周辺車載機１Ｂは、自端末にとって車車間通信可能な範囲に存在する車載機１である。このため、自端末が車車間通信を実施している車載機１の数と、周辺車載機１Ｂが車車間通信を実施している車載機１の数は、類似している可能性が高い。また、自端末がサービス提供端末とサービスを享受するための通信を実施している場合には、周辺車載機１Ｂもまた同一のサービス提供端末と、サービスを享受するための通信を実施していることが期待される。
【００８０】
つまり、自端末の制御部１１が正常に動作している場合、自端末の制御部１１の状態は周辺車載機１Ｂの状態と類似する可能性が高い。言い換えれば、自端末の制御部１１の状態と周辺車載機１Ｂの状態とが類似していない場合には、自端末の制御部１１が正常に動作していない可能性を示唆している。したがって、自端末の制御部１１の状態と周辺車載機１Ｂの状態とを比較することで、自端末の制御部１１が正常に動作しているか否かを判定することができる。
【００８１】
しかしながら、各端末における制御部１１の状態は時々刻々と変化する。このため、診断対象と車載機１の指標データの生成時刻から一定時間以上離れた時刻において受信した指標データは、自端末の制御部１１が正常に動作しているか否かの判断材料として不適切なデータである可能性が高くなってしまう。
【００８２】
したがって、メモリ１１２に格納されている指標データから、自端末診断基準を決定するための母集団とする指標データを選定するための条件として用いる一定時間は、できるだけ短いことが好ましい。もちろん、この一定時間が短すぎると、母集団として抽出される指標データの数が少なくなってしまう。母集団採用時間は、上記のトレードオフを鑑みて適宜決定されればよい。
【００８３】
なお、この一定時間以内に同一の車載機１から受信した指標データが複数存在する場合には、受信時刻が最も新しい指標データを採用することとする。また、ここでは、指標データ生成部Ｆ３が指標データを生成した時点から過去一定時間以内に受信した指標データを、自端末診断基準を決定するための母集団として採用することするが、これに限らない。指標データ生成部Ｆ３が指標データを生成した時点から母集団採用時間経過するまでに受信した指標データを、母集団として採用してもよい。また、指標データ生成部Ｆ３が指標データを生成した時点の前後母集団採用時間以内に受信した指標データを母集団として採用してもよい。
【００８４】
ステップＳ１０２では、ステップＳ１０１で抽出された指標データの数が、所定の数以上存在する否かを判定する。ここでの所定の数は、十分な信頼度のある診断基準を設定できるだけの数を意味する。例えば、少ない指標データに基づいて診断基準を決定する場合であって、仮にその指標データに正常に動作していない車載機からの指標データが含まれている場合、決定される診断基準もまたその影響を相対的に強く受けて、不適切な基準となってしまう恐れがある。
【００８５】
したがって、診断基準は、十分な信頼度のある診断基準を設定できるだけの数以上の指標データに基づいて決定されることが好ましい。十分な信頼度のある診断基準を設定できるだけの数は適宜設計されればよく、ここでは５とする。なお、他の態様として、所定の数は１つであってもよい。
【００８６】
抽出された指標データの数が所定の数以上存在する場合には、ステップＳ１０３に移る。一方、抽出された指標データの数が所定数に満たない場合にはステップＳ１０４に移る。
【００８７】
ステップＳ１０３では、ステップＳ１０１で抽出された複数の指標データに基づいて、診断項目毎の正常範囲を決定する。まず、ステップＳ１０１で抽出された複数の指標データに基づいて、指標データに含まれる項目毎に、その代表値を算出する。複数の指標データは、いずれも異なる周辺車載機１Ｂから受信したデータであるため、当然、同じ項目についての値であっても指標データ毎にその値は異なる（ばらつく）ことが想定される。或る項目の代表値とは、複数の指標データのそれぞれにおけるその項目の値を、代表的に表す値である。
【００８８】
或る項目の代表値は、複数の指標データのそれぞれにおけるその項目の値を母集団として定まる、統計学等で用いられる平均値であってもよいし、中央値であってもよい。また、平均値に標準偏差を加えた値、さらには、平均値に標準偏差の２倍を加えた値であってもよい。項目毎に、どのような値を代表値とするかは適宜設計されれば良い。ここでは一例として何れの項目も、各指標データにおけるその項目の値を母集団として定まる平均値とする。
【００８９】
そして、各項目の正常範囲の下限は、その項目の平均値に、標準偏差の２倍の値を減算した値とし、上限は、平均値に標準偏差の２倍の値を加えた値とする。もちろん、各項目の正常範囲の決定方法は上記に限らず、適宜設計されればよい。
【００９０】
例えば、或る項目の正常範囲の上限は、その項目の代表値に所定の値を加えた値とし、下限は、その項目の代表値に所定の値を引いた値としてもよい。また、或る項目の正常範囲の上限と下限のどちらか一方は、代表値に依らず固定の値としてもよい。
【００９１】
さらに、或る項目の正常範囲の上限は、その項目の代表値に所定の上限用係数を乗算した値とし、下限は、その項目の代表値に所定の下限用係数を乗算した値としてもよい。上限用係数は１以上の値となるように、下限用係数は１未満の値となるように、適宜設計されればよい。例えば、ある項目の上限用係数を１．３とし、下限用係数を０．７とした場合には、その項目の正常範囲は、代表値の±３０％となる範囲となる。
【００９２】
以上のようにして、診断項目毎の正常範囲（つまり自端末診断基準）を決定すると、呼び出し元の処理である自端末診断処理（図５）に戻り、ステップＳ１１に移る。
【００９３】
ステップＳ１０４では、当該自端末診断基準決定処理、及び本フローの呼び出し元である自端末診断処理を終了させる。
【００９４】
図５のステップＳ１１では自端末診断部Ｆ７が、指標データ生成部Ｆ３が生成した（つまり、自端末の）指標データに含まれる各項目の値が、ステップＳ１０で決定された診断項目毎の正常範囲に収まっているか否かを判定する。
【００９５】
例えば、自端末診断部Ｆ７は、自端末のシステム時刻が、正常範囲決定部Ｆ６によってシステム時刻に対して決定された正常範囲に収まっているか否かを判定する。自端末診断部Ｆ７は、自端末の平均メモリ使用量が、平均メモリ使用量に対して決定された正常範囲に収まっているか否かを判定する。その他の項目についても同様に、自端末についての情報と、正常範囲とを比較して、その正常範囲に収まっているか否かを判定する。
【００９６】
ここで、種々の正常範囲は、自端末周辺に存在する車載機１Ｂの指標データに基づいて定まるものである。このため、自端末の或る項目の値（例えば平均メモリ使用量）がその項目に対して決定された正常範囲に収まっているかを判定することは、言い換えれば、自端末におけるその項目の値が、周辺車載機１Ｂと同様の値となっているかを判定することに相当する。例えば、自端末のシステム時刻が、システム時刻に対して決定された正常範囲に収まっているか否かの判定は、自端末のシステム時刻と、周辺車載機１Ｂのシステム時刻との乖離度合いが所定の許容範囲内か否かを判定することに相当する。
【００９７】
そして、自端末の或る項目の値がその項目に対して決定された正常範囲に収まっていないということは、その項目について、自端末は周辺車載機１Ｂとは異なる挙動をしていることを意味する。自端末は周辺車載機１Ｂとは異なる挙動をしているということは、自端末に不具合が生じている可能性を示唆する。
【００９８】
このステップＳ１１で、指標データ生成部Ｆ３が生成した指標データに含まれる全ての項目において、その項目の値が、対応する正常範囲で定義される範囲に収まっているか否かの判定を完了すると、ステップＳ１２に移る。
【００９９】
ステップＳ１２では、ステップＳ１１の判定の結果、自端末の制御部１１が正常に動作しているか否かを判定する。正常に動作しているか否かを判定する条件（異常判定条件）は、適宜設定されれば良い。例えば、複数の診断項目のうち、１つでも正常範囲から逸脱している項目があった場合には、自端末の制御部１１が正常に動作していないと判定してもよい。また、複数の診断項目のうち、正常範囲から逸脱している項目の数が所定の数（例えば３つ）以上であった場合に、自端末の制御部１１が正常に動作していないと判定してもよい。
【０１００】
ここでは一例として、複数の診断項目のうち、１つでも正常範囲から逸脱している項目があった場合には、制御部１１が正常に動作していないと判定するものとする。各診断項目が正常範囲から外れていることから、制御部１１が正常に動作していないと判定する理由について、簡単に言及する。
【０１０１】
例えば、自端末のシステム時刻が、システム時刻に対して決定された正常範囲から外れている場合とは、自端末のシステム時刻が周辺車載機１Ｂのシステム時刻と大きくずれていることを意味する。自端末のシステム時刻が周辺車載機１Ｂのシステム時刻とずれているということは、自端末がシステム時刻を修正するためのデータ（すなわち、ＧＮＳＳ衛星からの信号）の取得できていないことを意味する。
【０１０２】
つまり、ＧＮＳＳ受信機１４との物理的な通信インターフェース部分に不具合が生じていたり、ＧＮＳＳ受信機１４を制御するためのデバイスドライバに不具合が生じていたりする可能性が懸念される。したがって、自端末のシステム時刻が正常範囲から外れている場合には、自端末の制御部１１が正常に動作していないと判定すればよい。
【０１０３】
もちろん、自端末のシステム時刻が周囲とずれているからといって、上述した不具合が生じているとは限らない。例えば自端末が、トンネルや立体駐車場などの、ＧＮＳＳ衛星からの電波が到達しない環境に存在する場合には、ＧＮＳＳ衛星からの信号を取得できず、システム時刻がずれてしまうためである。このような誤判定を防ぐ態様については、別途変形例にて後述する。
【０１０４】
また、自端末の平均メモリ使用量が、正常範囲から外れている場合、つまり周辺車載機１Ｂの平均メモリ使用量と大きくずれている場合には、自端末のみ、実行すべきアプリケーションの起動に失敗していたり、又は、不適切なアプリケーションが実行していたり、メモリ１１２の解放が失敗していたりすることが懸念される。したがって、自端末の平均メモリ使用量が正常範囲から外れている場合には、自端末の制御部１１が正常に動作していないと判定すればよい。
【０１０５】
平均ＣＰＵ使用率が正常範囲から外れている場合も、平均メモリ使用量がその正常範囲から外れている場合と同様の理由によって、自端末の制御部１１が正常に動作していないと判定すればよい。
【０１０６】
各車載機１にインストールされているソフトウェアは同一であるため、ストレージ１１３においてプログラムのデータが格納されているサイズも同じとなっているはずである。また、ストレージ１１３自体の記憶容量も同一であることから、車載機１同士のストレージ空き容量は等しいはずである。
【０１０７】
つまり、ストレージ空き容量が正常範囲から外れている場合とは、自端末のストレージ１１３に、本来保存されているはずのないプログラムが保存されている可能性を示唆している。したがって、ストレージ空き容量が、正常範囲から外れている場合には、制御部１１が正常に動作していないと判定する。なお、ここでは、指標データがストレージ空き容量を含むものとするが、ストレージ１１３の使用量を含んでいても良い。
【０１０８】
不良セクタ量が、正常範囲から外れている場合とは、ストレージ１１３の初期不良などが懸念される。したがって、不良セクタ量が正常範囲から外れている場合にも、制御部１１が正常に動作していないと判定すればよい。
【０１０９】
ダイアグ履歴情報は、一定時間以内における所定の異常事象の発生頻度を表す情報とも言える。正常範囲決定部Ｆ６が、ダイアグ履歴情報から決定する正常範囲は、一定時間あたりの異常事象の発生頻度の許容範囲である。なお、ここでの異常事象とは、前述の通り、制御部１１に接続するデバイスとの通信エラーなど、観測可能な事象であって、予め定められた種類のものである。
【０１１０】
自端末の制御部１１が正常に動作していない場合には、一定時間以内における異常事象の発生頻度は、周辺車載機１Ｂの制御部１１に比べて大きくなることが想定される。したがって、自端末のダイアグ履歴情報に示される異常事象の発生頻度が、正常範囲から外れている場合には、自端末の制御部１１が正常に動作していないと判定すればよい。
【０１１１】
なお、例えば、車載機１が置かれている外部環境によっては、制御部１１が正常に動作していても、異常事象が頻発する場合もある。例えば、異常事象としてＧＮＳＳ受信機１４がＧＮＳＳ電波を受信できていないことが定義されている場合、トンネル走行時などにおいては、ＧＮＳＳ電波が受信できていない旨を示すダイアグ情報が記録される。
【０１１２】
しかし、トンネルなど、そもそもＧＮＳＳ電波が受信できない環境下に自端末が存在する場合には、ＧＮＳＳ電波が受信できていない旨を示すダイアグ情報が複数記録されることは、正常な作動である。したがって、異常事象の発生頻度が所定の閾値以上となっているか否かによって制御部１１が正常に動作しているか否かを判定する態様では、外部環境の影響によって誤判定してしまう恐れがある。
【０１１３】
ところで、自端末がＧＮＳＳ電波を受信できない環境下に存在する場合には、周辺車載機１Ｂもまた、ＧＮＳＳ電波を受信できない環境下に存在する可能性が高い。つまり、周辺車載機１Ｂにおいても自端末と同様に、ＧＮＳＳ電波が受信できていない旨を示すダイアグ情報が記録されていく。その結果、周辺車載機１Ｂから取得したダイアグ履歴情報に基づいて設定される正常範囲は、外部環境の影響が反映された範囲となっている。
【０１１４】
したがって、本実施形態の態様によれば、正常に動作しているにも関わらず、正常に動作していないと判定してしまう恐れを低減することができる。
【０１１５】
ステップＳ１２の判定処理の結果、異常判定条件が充足されている場合には、ステップＳ１２がＹＥＳとなってステップＳ１３に移る。一方、ステップＳ１２の判定処理の結果、異常判定条件が充足していない場合には、ステップＳ１２がＮＯとなって本フローを終了する。
【０１１６】
ステップＳ１３では自端末異常通知部Ｆ１０が、自端末異常通知をセンター３に送信するように広域通信制御部Ｆ９に要求する。そして、広域通信制御部Ｆ９が、自端末異常通知部Ｆ１０からの要求に基づいて自端末異常通知をセンター３に送信し、本フローを終了する。
【０１１７】
（他端末診断処理について）
次に、図７に示すフローチャートを用いて、制御部１１が、任意の周辺車載機１Ｂを診断する処理（他端末診断処理とする）について説明する。このフローチャートは、任意の周辺車載機１Ｂから指標データを取得したことをトリガとして開始されれば良い。もちろん、自端末診断処理を開始する条件は適宜、設計されれば良く、例えば指標データ生成部Ｆ３が指標データを生成した場合であってもよい。
【０１１８】
また、或る周辺車載機１Ｂから、その周辺車載機１Ｂを診断対象とする他端末診断処理を実施するように要求された場合に開始されてもよい。その他、図示しない路側機と路車間通信を開始した場合に開始してもよい。
【０１１９】
便宜上、以降では、周辺車載機１Ｂのうち、診断対象とする周辺車載機１Ｂを診断対象機１Ｂｂとし、周辺車載機１Ｂのうち診断対象機１Ｂｂ以外の周辺車載機１Ｂを周辺車載機１Ｂａとして表す（図８参照）。また、図８の車載機１Ａは、冒頭でも述べたように、自端末に相当する車載機１である。この他端末診断処理を実行する主体は、車載機１Ａである。
【０１２０】
まず、ステップＳ２０では正常範囲決定部Ｆ６が、他端末診断基準決定処理を実施してステップＳ２１に移る。このステップＳ２０での他端末診断基準決定処理は、周辺車載機１Ｂａから受信した指標データに基づいて、診断項目毎の正常範囲を決定する処理である。
【０１２１】
この他端末診断基準決定処理の処理手順は、診断基準を決定するための母集団となりうる指標データが異なる点を除いて、前述の自端末診断基準決定処理の処理手順と同様である。より具体的には、前述の自端末診断基準決定処理においては、周辺車載機１Ｂから取得した指標データのうち、所定の条件を満たす指標データを用いて診断基準を決定した。
【０１２２】
この他端末診断基準決定処理においては、周辺車載機１Ｂａ（すなわち診断対象機１Ｂｂ以外の車載機１）から取得した指標データのうち、所定の条件を満たす指標データを用いて診断基準を決定する。つまり、周辺車載機１Ｂａから受信した指標データのうち、診断対象機１Ｂｂからの指標データを受信した時点の過去一定時間以内に、周辺車載機１Ｂａから受信した指標データを母集団として採用する。また、診断対象機１Ｂｂからの指標データを受信した時点よりも過去、一定時間以内に、自端末の指標データが生成されている場合には、その指標データも母集団として採用する。
【０１２３】
この他端末診断基準処理は、上記相違点を除いて、前述の自端末診断基準決定処理の処理手順と同様であるため、詳細な処理手順についての説明は省略する。
【０１２４】
なお、本実施形態では、診断対象機１Ｂｂから取得した指標データを、他端末診断基準を決定するための母集団として採用しない態様とするが、これに限らない。他の態様として、正常範囲決定部Ｆ６は、診断対象機１Ｂｂから取得した指標データも用いて、他端末診断基準を決定してもよい。
【０１２５】
ステップＳ２１では他端末診断部Ｆ８が、診断対象機１Ｂｂから受信した指標データに含まれる各項目の値が、ステップＳ２０で他端末診断基準として決定された診断項目毎の正常範囲に収まっているか否かを判定する。
【０１２６】
例えば、他端末診断部Ｆ８は、診断対象機１Ｂｂのシステム時刻が、正常範囲決定部Ｆ６によってシステム時刻に対して決定された正常範囲に収まっているか否かを判定する。平均メモリ使用量や平均ＣＰＵ使用率、ストレージ空き容量といった、その他の項目についても同様に、その項目に対応する正常範囲と、その項目についての自端末の情報とを比較して、正常範囲に収まっているか否かを判定する。
【０１２７】
ここで、種々の正常範囲は、周辺車載機１Ｂａや自端末の指標データに基づいて定まるものである。このため、診断対象機１Ｂｂの或る項目の値（例えば平均メモリ使用量）が、その項目に対して決定された正常範囲に収まっているか否かを判定するということは、言い換えれば、診断対象機１Ｂｂにおけるその項目の値が、周辺車載機１Ｂａや自端末と同様の値となっているか否かを判定することに相当する。
【０１２８】
そして、診断対象機１Ｂｂの或る項目の値が、その項目に対して決定された正常範囲に収まっていないということは、その項目について、診断対象機１Ｂｂは周辺車載機１Ｂａや自端末とは異なる挙動をしていることを意味する。診断対象機１Ｂｂが、周辺車載機１Ｂａや自端末と異なる挙動をしているということは、診断対象機１Ｂｂに不具合が生じている可能性を示唆する。
【０１２９】
このステップＳ２１で、診断対象機１Ｂｂから取得した指標データに含まれる全ての項目において、その項目の値が、対応する正常範囲で定義される範囲に収まっているか否かの判定を完了すると、ステップＳ２２に移る。
【０１３０】
ステップＳ２２では他端末診断部Ｆ８が、ステップＳ２１の判定の結果、診断対象機１Ｂｂの制御部が正常に動作しているか否かを判定する。診断対象機１Ｂｂの制御部が正常に動作しているか否かを判定する条件（つまり、異常判定条件）は、前述の自端末診断処理と同様に、適宜設計されれば良い。
【０１３１】
ステップＳ２２の判定処理の結果、異常判定条件が充足している場合には、ステップＳ２２がＹＥＳとなってステップＳ２３に移る。一方、ステップＳ２２の判定処理の結果、異常判定条件が充足されていない場合には、ステップＳ２２がＮＯとなって本フローを終了する。
【０１３２】
ステップＳ２３では他端末異常通知部Ｆ１１が、他端末異常通知をセンター３に送信するように広域通信制御部Ｆ９に要求する。そして、広域通信制御部Ｆ９が、他端末異常通知部Ｆ１１からの要求に基づいて他端末異常通知をセンター３に送信し、本フローを終了する。
【０１３３】
なお、以上では正常範囲決定部Ｆ６が、他端末診断基準を、周辺車載機１Ｂａから取得した指標データに加えて、自端末の指標データを用いて決定する態様としたが、これに限らない。他端末診断基準は、自端末の指標データを用いずに、周辺車載機１Ｂａの指標データに基づいて決定する態様としてもよい。
【０１３４】
（実施形態のまとめ）
以上の構成では、診断対象とする車載機１の制御部１１の状態を示す指標値と、診断対象を除く周辺車載機１Ｂの制御部１１の状態を示す指標値に基づいて定まる診断基準とを比較することで、診断対象とする車載機１の制御部１１が正常に動作しているか否かを判定する。
【０１３５】
より具体的には、自端末の制御部１１について診断する場合には、正常範囲決定部Ｆ６は、周辺車載機１Ｂの制御部１１の状態を示す指標値に基づいて、指標値毎の正常範囲を決定する（ステップＳ１０）。そして、自端末診断部Ｆ７は、自端末の制御部１１の状態を示す指標値が、その正常範囲に収まっているか否かを判定する。
【０１３６】
ここで、正常範囲に収まっていない指標値の数や種類が、所定の異常判定条件を充足している場合に、自端末の制御部１１は正常に動作していないと判定する（ステップＳ１２）。自端末診断部Ｆ７が自端末の制御部１１が正常に動作していないと判定した場合には、自端末異常通知部Ｆ１０がその旨をセンター３に通知する。
【０１３７】
ここで、自端末を診断するための指標値毎の正常範囲、すなわち自端末診断基準を生成するための元となった指標データを提供した複数の周辺車載機１Ｂは、いずれも自端末と車車間通信が実施できる範囲、つまり比較的小さい範囲内に存在している。
【０１３８】
複数の周辺車載機１Ｂはいずれも比較的小さい範囲内に存在しているため、自端末が車車間通信を実施している車載機１の数と、周辺車載機１Ｂのそれぞれが車車間通信を実施している車載機１の数は、類似している可能性が高い。また、自端末がサービス提供端末とサービスを享受するための通信を実施している場合には、周辺車載機１Ｂもまた同一のサービス提供端末と、サービスを享受するための通信を実施していることが期待される。
【０１３９】
つまり、自端末と周辺車載機１Ｂとでは、制御部１１（特にＣＰＵ１１１）が実行しているソフトウェア（例えばサービスを享受するためのアプリケーションプログラム）や、ＣＰＵ１１１にかかる負荷（処理するべきタスクの数など）が共通している可能性が高い。自端末及び周辺車載機１Ｂにおいて実行されているソフトウェア等が同じである場合には、各車載機１のＣＰＵ使用率やメモリ使用量は類似性が高くなる。
【０１４０】
また、複数の周辺車載機１Ｂの何れもが、正常に動作していない可能性は相対的に低い。このため、周辺車載機１Ｂから取得した指標データに基づいて定まる自端末診断基準は、現在の状況における制御部１１が正常に動作していると見なすことができる範囲を示している。
【０１４１】
本来、自端末が正常に動作している場合には、自端末の制御部１１の状態と、周辺車載機１Ｂの制御部１１の状態とは類似している可能性が高いため、自端末の指標データは、周辺車載機１Ｂから取得した指標データと類似するはずである。つまり、自端末の制御部１１の指標データに含まれる各項目の値は、その項目に対応する正常範囲に収まっているはずである。言い換えれば、自端末の制御部１１の指標データに含まれる各項目の値は、その項目に対応する正常範囲に収まっていない場合には、自端末の制御部１１が正常に動作していない可能性を示唆している。
【０１４２】
つまり、周辺車載機１Ｂから取得した指標データに基づいて定まる自端末診断基準と、自端末の指標データとを比較することで、自端末の制御部１１が正常に動作しているか否かをより精度よく判定することができる。
【０１４３】
また、複数の周辺車載機１Ｂのうち、任意の周辺車載機１Ｂを診断対象とする場合には、正常範囲決定部Ｆ６がその診断対象機１Ｂｂを除く周辺車載機１Ｂａの制御部１１の状態を示す指標値に基づいて指標値毎の正常範囲を決定する（ステップＳ２０）。そして、他端末診断部Ｆ８は、診断対象機１Ｂｂの制御部１１の状態を示す指標値が、その正常範囲に収まっているか否かを判定する。
【０１４４】
正常範囲に収まっていない指標値の数や種類が、所定の異常判定条件を充足している場合に、診断対象機１Ｂｂの制御部１１は正常に動作していないと判定する（ステップＳ２２）。他端末診断部Ｆ８が、診断対象機１Ｂｂの制御部１１が正常に動作していないと判定した場合には、他端末異常通知部Ｆ１１がその旨をセンター３に通知する。
【０１４５】
ここで、診断対象機１Ｂｂと、周辺車載機１Ｂａは、何れも自端末と車車間通信可能な範囲に存在する車載機１であるため、いずれも相対的に小さい範囲内に存在する。したがって、自端末を診断する際と同様の作動によって、正常範囲決定部Ｆ６が決定する他端末診断基準は、現在の状況における正常な制御部１１正常に動作していると見なすことができる範囲を示している。
【０１４６】
そして、他端末診断部Ｆ８は、その他端末診断基準と診断対象機１Ｂｂから取得した指標データとを比較することで、診断対象機１Ｂｂの制御部１１が正常に動作しているか否かをより精度よく判定することができる。
【０１４７】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、次の実施形態も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。
【０１４８】
＜変形例１＞
上述の実施形態では、車載機１が他端末診断部Ｆ８と他端末異常通知部Ｆ１１を備える構成を示したが、必ずしもこれに限らない。例えば、車載機１は、他端末診断部Ｆ８を備えていなくても良いし、他端末異常通知部Ｆ１１を備えていなくても良い。
【０１４９】
＜変形例２＞
上述の実施形態では、車載機１が自端末診断部Ｆ７と自端末異常通知部Ｆ１０を備える構成を示したが、必ずしもこれに限らない。例えば、車載機１は、自端末診断部Ｆ７を備えていなくても良いし、自端末異常通知部Ｆ１０を備えていなくても良い。
【０１５０】
また、自端末異常通知部Ｆ１０及び他端末異常通知部Ｆ１１を備えない構成とする場合には、さらに、広域通信部１３及び広域通信制御部Ｆ９もまた備えていなくてもよい。
【０１５１】
＜変形例３＞
以上では、車載機診断システム１００が備える車載機１を何れも同様の機能を備えるものとしたが、これに限らない。診断される側の車載機１と、診断する側の車載機１とでは、備えるべき機能は異なる。そして、車載機診断システム１００が備える車載機１の中には、診断されるための機能のみを備える車載機１が存在してもよい。
【０１５２】
診断される側の車載機１は、少なくとも、システム情報取得部Ｆ２と、指標データ生成部Ｆ３と、自端末の指標データを送信する機能を有する狭域通信制御部Ｆ４と、を備えていればよい。
【０１５３】
また、診断する側の車載機１は、少なくとも、診断される側の車載機１から送信された指標データを取得する機能を有する狭域通信制御部Ｆ４と、指標データ管理部Ｆ５と、正常範囲決定部Ｆ６と、他端末診断部Ｆ８とを備えていれば良い。
【０１５４】
ただし、上記構成によれば、診断する側の車載機１は、診断される側の車載機１を診断することは出来ても、自分自身を診断したり、診断してもらうことができない。したがって、診断する側の車載機１は、上記必要最低限の構成に加えて、システム情報取得部Ｆ２と、指標データ生成部Ｆ３と、を備え、さらに狭域通信制御部Ｆ４は、自端末の指標データを送信する機能を備えていることが好ましい。
【０１５５】
なお、自端末診断部Ｆ７は備えていなくとも、他の診断する側の車載機１に、自分の指標データを送信することによって診断してもらうことが可能である。そのため、自端末診断部Ｆ７は備えていなくても良い。つまり、自端末診断部Ｆ７は、任意の要素である。
【０１５６】
＜変形例４＞
以上では、自端末のシステム時刻が周辺車載機１Ｂのシステム時刻とずれているか否かに基づいて、自端末の制御部１１が正常に動作しているか否かを判定する態様について言及した。
【０１５７】
しかしながら、例えば自端末が、トンネルや立体駐車場などの、ＧＮＳＳ衛星からの電波が到達しない環境に存在する場合には、ＧＮＳＳ衛星からの信号を取得できず、システム時刻がずれてしまう。
【０１５８】
したがって、システム時刻のズレに基づいて、制御部１１が正常に動作しているか否かを判定する際には、ＧＮＳＳ受信機１４によるＧＮＳＳ衛星からの信号の受信状況や、自端末が存在する環境について考慮することが好ましい。
【０１５９】
例えば、ＧＮＳＳ受信機１４がＧＮＳＳ衛星からの信号を受信できていない場合には、システム時刻による判定を実施しない構成としてもよい。ＧＮＳＳ受信機１４がＧＮＳＳ衛星からの信号を受信できているか否かは、ＧＮＳＳ受信機１４が、ＧＮＳＳ衛星からの信号の受信状況（捕捉衛星数など）を示す情報を制御部１１に逐次出力する構成とすれば良い。
【０１６０】
なお、以上では、自端末診断部Ｆ７がシステム時刻のずれに基づいて、自端末の制御部１１が正常に動作しているか否かを診断する態様について言及したが、他端末診断部Ｆ８についても同様である。つまり、診断対象機１Ｂｂから取得した指標データのダイアグ履歴情報に、ＧＮＳＳ受信機１４がＧＮＳＳ衛星からの信号を取得できていない旨が示されている場合には、システム時刻による判定を行わない態様とすればよい。
【０１６１】
＜変形例５＞
自端末診断部Ｆ７によって自端末が正常に動作していないと判定された場合、自端末異常通知部Ｆ１０は、その時点においてＧＮＳＳ受信機１４が出力している位置情報を含む自端末異常通知を生成し、広域通信制御部Ｆ９にセンター３に送信させてもよい。
【０１６２】
このような態様によれば、センター３は、正常に動作していない車載機１が存在する地点や、車載機１の制御部１１が正常に動作しなくなる地点を把握することができる。これによって、車載機１が正常に動作しなくなる地点の解析などを実施しやすくすることができる。
【０１６３】
また、自端末異常通知に示される位置が、例えば立体駐車場などの、ＧＮＳＳ衛星からの信号が届きにくい箇所であって、かつ、その自端末の制御部１１が正常に動作していないと判定した理由がシステム時刻のずれである場合には、センター３は、当該自端末異常通知に伴うメンテナンスの手配などの処理を行わない態様としてもよい。ＧＮＳＳ衛星からの信号が届きにくい箇所においては、制御部１１が正常であってもシステム時刻がずれることが想定されるためである。
【０１６４】
＜変形例６＞
他端末診断部Ｆ８によって診断対象機１Ｂｂが正常に動作していないと判定された場合、他端末異常通知部Ｆ１１は、その時点においてＧＮＳＳ受信機１４が出力している位置情報を含む他端末異常通知を生成する態様としてもよい。その場合、広域通信制御部Ｆ９は、位置情報を含む他端末異常通知をセンター３に送信する。
【０１６５】
このような態様によれば、変形例５と同様に、センター３は、正常に動作していない車載機１が存在する地点や、車載機１の制御部１１が正常に動作しなくなる地点を把握することができる。これによって、車載機１が正常に動作しなくなる地点の解析などを実施しやすくすることができる。
【０１６６】
また、他端末異常通知に示される位置がＧＮＳＳ衛星からの信号が届きにくい箇所であって、かつ、制御部１１が正常に動作していないと判定した理由がシステム時刻のずれである場合には、当該他端末異常通知に伴うメンテナンスの手配などの処理を行わなくてもよい。
【０１６７】
＜変形例７＞
ところで、車載機１で用いられるソフトウェアは、随時新しいバージョンが公開され、それにともなって、各車載機１で用いられるソフトウェアもまた随時バージョンアップされていくことが想定される。しかしながら、全ての車載機１が同時にソフトウェアを更新するとは限らない。その結果、古いバージョンのソフトウェアを用いている車載機１と、新しいバージョンのソフトウェアを利用している車載機１とが混在することが想定される。
【０１６８】
当然、古いバージョンのソフトウェアと、新しいバージョンのソフトウェアとでは、ストレージ１１３でのデータサイズや、ＣＰＵ使用率やメモリ使用量などが異なることが想定される。
【０１６９】
したがって、古いバージョンのソフトウェアを用いている車載機１の制御部１１と、新しいバージョンのソフトウェアを利用している車載機１の制御部１１とでは、その状態が異なっている可能性が高い。仮に、古いバージョンのソフトウェアを利用している車載機１の制御部１１を診断するための診断基準を、新しいバージョンのソフトウェアを利用している車載機１から取得した指標データに基づいて生成すると、誤判定を行ってしまう恐れがある。
【０１７０】
つまり、正常範囲決定部Ｆ６は、診断対象とする車載機１が利用しているソフトウェアと、同じバージョンのソフトウェアを利用している車載機１から取得した指標データに基づいて、診断基準を決定することが好ましい。
【０１７１】
この変形例は例えば次のような構成とすればよい。まず、各車載機１の狭域通信制御部Ｆ４は、当該指標データに、端末ＩＤと、現在利用しているソフトウェアのバージョン情報とを含むヘッダを付与した送信用データを周辺車載機１Ｂに送信する。また、狭域通信制御部Ｆ４は、周辺車載機１Ｂから送信された指標データを含むデータを取得した場合には、その指標データと、端末ＩＤと、ソフトウェアのバージョン情報とを対応付けて指標データ管理部Ｆ５に提供する。指標データ管理部Ｆ５は、車載機１毎の指標データを、その車載機１が利用しているソフトウェアのバージョン情報と対応付けてメモリ１１２に保存する。
【０１７２】
そして、正常範囲決定部Ｆ６は、診断対象とする車載機１が利用しているソフトウェアと、同じバージョンのソフトウェアを利用している車載機１から取得した指標データに基づいて、診断基準を決定する。
【０１７３】
具体的には、正常範囲決定部Ｆ６は自端末診断基準を決定する際には、自端末が利用しているソフトウェアと同じバージョンのソフトウェアを利用している周辺車載機１Ｂから取得した指標データに基づいて自端末診断基準を決定する。もちろん、このとき、上述した実施形態と同様に、自端末診断基準を決定するための指標データを選定するための条件として、時間的な条件を用いてもよい。
【０１７４】
また、正常範囲決定部Ｆ６は他端末診断基準を決定する際には、診断対象機１Ｂｂが利用しているソフトウェアと同じバージョンのソフトウェアを利用している周辺車載機１Ｂａから取得した指標データに基づいて他端末診断基準を決定する。もちろん、このとき、上述した実施形態と同様に、他端末診断基準を決定するための指標データを選定するための条件として、時間的な条件を用いてもよい。また、自端末が利用しているソフトウェアのバージョンが、診断対象機１Ｂｂが利用しているソフトウェアのバージョンと同じ場合である場合には、自端末の指標データを用いて他端末診断基準を決定してもよい。
【０１７５】
なお、ここでは現在利用しているソフトウェアのバージョン情報を、端末ＩＤ等と同様に、指標データの外部（例えば送信用データのヘッダ部分）に付与されて送信する態様としたが、これに限らない。例えば、ソフトウェアのバージョン情報は、指標データに含ませてもよい。送信元の車載機１が現在利用しているソフトウェアのバージョン情報が、受信側の車載機１によって特定できればよい。
【０１７６】
＜変形例８＞
以上では、自端末異常通知部Ｆ１０や他端末異常通知部Ｆ１１が、自端末又は診断対象とした周辺車載機１Ｂが正常に動作していない旨を、広域通信によってセンター３に通知する構成を示したが、必ずしもこれに限らない。例えば、自端末異常通知部Ｆ１０は、自端末の制御部１１が正常に動作していない旨を、表示や音声によってユーザに報知する構成としてもよい。
【０１７７】
また、他端末異常通知部Ｆ１１は、診断対象とした周辺車載機１Ｂに対して、車車間通信によって、その制御部１１が正常に動作していないことを通知してもよい。これに伴って、車載機１は、周辺の車載機１から自端末の制御部１１が正常に動作していないことを通知する信号を取得した場合には、表示や音声によってその旨を報知する構成を備えていても良い。
【符号の説明】
【０１７８】
１００  車載機診断システム、Ａ  自車両、Ｂ  周辺車両、１・１Ａ・１Ｂ・１Ｂａ・１Ｂｂ  車載機、３  センター、１１  制御部、１２  狭域通信部（無線通信部）、１３  広域通信部、１４  ＧＮＳＳ受信機（位置情報取得部）、１１１  ＣＰＵ（中央処理部）、１１２  メモリ、１１３  ストレージ、Ｆ１  システム管理部、Ｆ２  システム情報取得部、Ｆ３  指標データ生成部、Ｆ４  狭域通信制御部（通信処理部）、Ｆ５  指標データ管理部、Ｆ６  正常範囲決定部（判定基準決定部）、Ｆ７  自端末診断部（自機診断部）、Ｆ８  他端末診断部（他機診断部）、Ｆ９  広域通信制御部、Ｆ１０  自端末異常通知部（自機異常通知部）、Ｆ１１  他端末異常通知部（他機異常通知部）
【図１】
0006398739.tif 000002
【図２】
0006398739.tif 000003
【図３】
0006398739.tif 000004
【図４】
0006398739.tif 000005
【図５】
0006398739.tif 000006
【図６】
0006398739.tif 000007
【図７】
0006398739.tif 000008
【図８】
0006398739.tif 000009